---
title: Passkey profiles in Entra ID: the migration that quietly happened to you
description: In May and June 2026 Microsoft automatically migrated tenants to the passkey profiles schema. It may have enabled synced passkeys and changed your registration campaign targeting. What to check, and what is coming next.
url: https://www.malachis.eu/en-US/news/passkey-profiles-migration
published: 2026-08-01
modified: 2026-08-14
---

# Passkey profiles in Entra ID: the migration that quietly happened to you

**In short:** In May and June 2026, Microsoft automatically migrated tenants with Passkeys (FIDO2) enabled to the new passkey profiles schema. If you did not have attestation enforced, that migration may have **enabled synced passkeys** in your tenant. If your registration campaign was in the Microsoft-managed state, it may also have changed who gets prompted to register, and how often. None of this required your approval. Below: three things to check, and one more change on the way.

> **Sources:** Message center MC1221452 · [Enable passkeys for your organization](https://learn.microsoft.com/entra/identity/authentication/how-to-authentication-passkeys-fido2) · [fido2AuthenticationMethodConfiguration resource type](https://learn.microsoft.com/graph/api/resources/fido2authenticationmethodconfiguration?view=graph-rest-1.0)

---

## What happened

Passkey profiles and synced passkeys have been generally available since March 2026. The change is not cosmetic: passkey configuration stopped being a single tenant-wide setting and became a set of named profiles targeted at user groups. A profile can enforce attestation, restrict specific authenticator models by AAGUID, and now determine the passkey type through the new `passkeyType` property.

Tenants that did not opt in to the new model were migrated automatically. For the public cloud, that migration ran **from early May to late June 2026** — so for most organisations it is already done. The migration:

- moved existing configuration into a **Default passkey profile**,
- auto-populated `passkeyType` based on your attestation settings at the time,
- left existing key restrictions and user targeting intact,
- did **not** enable any new authentication method.

That last point is technically true and still misleading. The rule that determined `passkeyType` is what matters:

- attestation **enforced** → device-bound passkeys only,
- attestation **not enforced** → device-bound **and synced** passkeys allowed.

So if you did not have attestation enforced — the common state for tenants that switched FIDO2 on and never tuned it further — you now have synced passkeys allowed in production. That means credentials which are encrypted and synchronised to a provider's cloud, such as iCloud Keychain, Google Password Manager, or an employee's personal password manager. This is legitimate and, for plenty of scenarios, the right choice. The problem is that it was not a decision anyone made and justified. If you fall under NIS2 or are working towards ISO/IEC 27001, deal with it now. For a regulated customer, that is an audit finding rather than a technical detail.

---

## Three things to check today

**1. The Default passkey profile and the `passkeyType` value.** Look at what the migration configured, and compare it with what you intended. If you do not want synced passkeys for some of your users, the answer is not to disable them globally — it is to split users across profiles. Privileged accounts into a profile with attestation enforced and an AAGUID allow-list; everyone else by device type.

**2. Your registration campaign state.** If you met all the in-scope conditions — Passkeys (FIDO2) enabled, registration campaign in the Microsoft-managed state, self-service setup allowed, no AAGUID restrictions configured, and at least one user enabled for both passkey types — Microsoft changed your campaign settings after migration as follows:

| Setting | Before | After |
| --- | --- | --- |
| Targeted authentication method | Microsoft Authenticator | passkeys (FIDO2) |
| Days allowed to snooze | 3 days | **1 day**, no longer configurable |
| Limited number of snoozes | Enabled | **Disabled**, no longer configurable |
| Default user targeting | voice call or text message users | **all MFA-capable users** |

The last row is the one your helpdesk noticed. The passkey registration prompt stopped targeting the at-risk group of phone-based users and started targeting the entire organisation. If you saw an unexplained spike in "what is this thing asking me to do" tickets in May or June, that is your answer.

You can of course take the campaign back: switch it from Microsoft-managed to Enabled and keep targeting Authenticator, or disable it altogether. Treat that as a way to control timing, not to avoid the change — **your users still need a passkey or another phishing-resistant method registered before 1 February 2027**.

**3. Runbooks and helpdesk guidance.** If what users see at sign-in has changed, what the helpdesk tells them has to change too. This is the cheapest item on the list and the most frequently skipped.

---

## Coming next: changing a password without knowing it

**Late October 2026.** My Sign-Ins gains the ability to change a password using an existing strong credential — a passkey, FIDO2 security key, or Windows Hello for Business — **without knowing the current password**, and without using SSPR or calling the helpdesk.

The practical impact is larger than it sounds. Most organisations move toward passwordless while keeping passwords for legacy applications and services. That creates the absurd situation where a user has not typed a password in years, therefore does not know it, and the moment one old application demands it they end up on the phone to support. This feature addresses exactly that.

Two constraints to plan around:

- The feature is **disabled by default** and requires explicit administrator enablement.
- The setting is **tenant-wide**. There is no per-user or per-group scoping — everyone or no one. A pilot with a test group is therefore not possible, which changes how you introduce it in a tenant with thousands of users.

Connecting back to the previous article: passkeys cannot be used for self-service password reset, and this feature does not change that. Changing a password with a strong credential is not the same as resetting a password for a user who cannot sign in. The SSPR gap remains and still needs covering with another method.

---


## What we offer: FIDO2 and passkey deployment in Entra ID

**We do not sell hardware keys.** We specify the models and quantities; you buy them through your own distributor or standard IT procurement. We take no hardware commission, so the model recommendation follows your environment rather than a margin. We have also had several months of hands-on operational experience with this and can advise accordingly.

What we do:

- **Current state audit** — what the automatic migration configured, your `passkeyType`, attestation, AAGUID restrictions, and registration campaign state
- **Passkey profile design** by user segment: privileged accounts, office users with corporate devices, BYOD and contractors, shared and operational devices
- **Hardware key specification** — form factor (USB-A, USB-C, NFC), biometrics, FIDO2 certification level, attestation and AAGUID support, resident credential limits per key, PIN lockout behaviour, firmware update path. Including quantities, spares, and budget.
- **Configuration** of passkey profiles, the AAGUID allow-list, and Conditional Access authentication strength
- **Break-glass accounts** — hardware keys in a safe, with a documented and practically tested emergency procedure
- **Enrollment** — pilot, bulk registration, and registration campaign control on your schedule
- **Operational processes** — lost key, employee departure, replacement, inventory
- **Handover** — documentation, a helpdesk runbook, and end-user guides in Czech, Slovak and English

All work happens inside your own Microsoft 365 tenant, and no data leaves it.

**Questions, or want to talk through a deployment?** Email us at [support@malachis.eu](mailto:support@malachis.eu) or use the contact form. We are equally happy to answer a single question about your environment — including just telling you what the May migration configured.

---

*Based on Microsoft Message center announcements and the associated Microsoft Learn documentation, as of 1 August 2026. Microsoft may adjust dates and technical details.*