Entra Passkey Migration: The Default Problem

Here is the procedure. A user reports a phish, or your tooling catches one. You reset the password, revoke the sessions, and close the ticket. It has been the correct sequence for a decade, and it is what almost every account-compromise runbook still says.

There is now a credible technique it does not cover, and on 1 September Microsoft made the conditions for it a great deal more common across every tenant still using SMS or voice. The technique is claimed rather than captured, and I will be precise at the end about how much weight that supports. What matters more is what your own tenant would do about it, because that part is documented and has a date attached.

The credential that survives your remediation

The kit is called iAuthFlow V2 and the mechanism, as described by Abnormal, starts out ordinary. An attacker-side headless browser runs in lockstep with the victim's phishing page and relays the authentication exchange in real time. That much is adversary-in-the-middle and has been for years, and it is the same credential-theft route that leads to directory enumeration once the attacker is inside.

The addition is what happens next, and it happens on the attacker's side rather than the victim's. While the victim is held on a "Verification, Processing" message, the toolkit uses the authenticated browser session to open the account's own passkey settings and request a new credential. The registration is performed by "a software-based virtual authenticator" which, in Abnormal's words, "can perform WebAuthn registration and retain the credential's private key without requiring the target's physical device to create or store it".

So the victim does not approve a passkey prompt, and nothing appears on their device. The attacker later returns, chooses "try another way", and signs in with the credential they registered.

This defeats the standard runbook for a structural reason. A passkey is a credential registered against the account. It is not derived from the password and it is not a token minted from a session. Resetting the password changes something the passkey does not depend on. Revoking sessions kills tokens that the passkey can simply mint again.

Earlier versions of this attack stole a session, and sessions expire. A registered passkey does not expire the way a session does.

If you read nothing else: after a confirmed phish, enumerate the user's registered authentication methods and delete anything they cannot account for. The rest of this post is why that step now matters considerably more than it did before 1 September 2026.

What Entra changed on 1 September

From the SMS and voice retirement documentation, as it stood on 23 September:

On September 1, 2026, users enabled for SMS or Voice in the Entra Authentication Methods Policy (AMP), or in legacy MFA settings, will be auto-enabled for passkeys in AMP. These in scope users will be put into a passkey profile allowing all types of passkeys. Your Registration Campaign settings will be set to Microsoft Managed state targeting passkeys, and will automatically bring these users into scope.

The middle sentence is the one that costs you. Some of what follows from it is documented and some is inference, and I mark which.

A profile allowing all types of passkeys must have attestation disabled. That is not a guess: Entra documents exactly two passkey types, device-bound and synced, and states that synced passkeys do not support attestation. A profile that permits both cannot be enforcing it. Microsoft's own example response on the Graph v1.0 reference page shows the same combination in its Default passkey profile, with "passkeyTypes": "deviceBound,synced" and "attestationEnforcement": "disabled". That is a documentation example, not your tenant.

Whether that profile also carries no key restrictions, meaning no list of allowed or blocked authenticators by AAGUID (the identifier for an authenticator's make and model), is my inference rather than Microsoft's statement. Nobody hand-populates an allow-list on a profile generated automatically for a mass migration, and the migration's whole purpose is low friction, so I would be astonished if one were there. But Learn does not say so, and this post is going to be strict about that distinction elsewhere, so it should be strict here.

What the migration did to the profile your tenant already had, Learn does not say. It either rewrote that object or placed another one beside it, so the settings you chose before September are not necessarily the settings your users are under now. Which of the two happened, and with what values, is a question only your own tenant answers, and it takes about two minutes:

GET https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/fido2

Look at passkeyProfiles: the passkey types each profile allows, attestationEnforcement, and whether keyRestrictions is enforced or merely present. It needs Policy.Read.AuthenticationMethod, the least privileged permission the v1.0 page documents for this call.

Read the key restriction settings carefully. An empty AAGUID list restricts nothing while enforcement itself is switched off, whether the enforcement type shows block or allow. It will still read as configured to anyone counting settings rather than reading them. If what you find is a profile permitting both synced and device-bound passkeys with attestation off, the rest of this post is about your tenant.

The retirement page sets out four dates:

Those last two rows changed on 16 September 2026, after the migration had run. Until then Learn described a single February cut-off for everybody. The 23 September text splits the population: Global Administrators and external users keep Microsoft-provided SMS and voice until July, while internal guest users stay on February. If you built a plan from the earlier version of that page, the dates in it are wrong for your administrators.

Learn is less settled on what that February date means for those internal guests. The retirement timeline puts them on the same blocking passkey-registration prompt as everyone else. The passkey article's known issues say: "Registration of passkey (FIDO2) credentials isn't supported for internal or external guest users, including B2B collaboration users in the resource tenant." The retirement FAQ reconciles the two as a matter of timing: "Passkey support for B2B users and internal guest users is planned to be available by the end of calendar year 2026." So the known issue describes current behaviour, Microsoft plans to close it by the end of 2026, and the February date for internal guests depends on that shipping. If internal guests are part of your population, test the behaviour in your tenant before February rather than assuming either page is current.

The split matters. The accounts most worth phishing are the ones that keep the phishable method five months longer. Microsoft's reason is not hard to guess, since locking every Global Administrator out of a tenant on a single Monday morning is the failure mode that cannot be allowed to happen. It is sensible operational caution, and it leaves your most privileged accounts reachable by SMS until July unless you move them yourself. That is a reason to put administrators on attested, key-restricted passkeys by choice, rather than waiting for a deadline to do it for you.

There is a deferral, and it is narrow:

PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json
 
{
  "optOutSettings": {
    "passkeyDynamicMigration": true
  }
}

It needs Policy.ReadWrite.AuthenticationMethod, it is a beta endpoint, and Microsoft is explicit that "standard passkey migration and enforcement timelines apply regardless of this setting" from February. Learn defines the opt-out period as 1 September 2026 to 1 February 2027. It does not say whether the window extends to July for Global Administrators and external users, so plan for February. After that, most of your users meet the February retirement, and Global Administrators and external users run on to July. One practical note: optOutSettings is not in the published Graph beta metadata, so the typed SDKs and Update-MgBetaPolicyAuthenticationMethodPolicy will not know about it. Use Invoke-MgGraphRequest -Method PATCH or raw REST.

The five-minute rule that looks like a control

The first thing most people reach for, on being told an attacker can register a passkey mid-phish, is that Entra will not let them. There is a requirement, and it is real:

Users must complete multifactor authentication (MFA) within the past five minutes before they can register a passkey (FIDO2).

It sounds decisive. In this scenario it is not. The requirement is that a fresh MFA has been completed. In a relay attack the victim completes a genuine MFA, live, seconds earlier, and the attacker holds the resulting session.

The control works as documented. It checks that the user completed MFA recently, and in a relay attack the user did.

What attestation refuses, and what key restrictions add

Entra does have controls that bear directly on which authenticator may be registered against a user, and they live in passkey profiles: named policy objects that bind attestation, passkey type and AAGUID settings to a group of users.

Enforcing attestation requires the authenticator to prove its make and model at registration, against trusted metadata. Microsoft is blunt about the alternative: "If enforce attestation is set to No, Microsoft Entra ID can't guarantee any attribute about a passkey, including if it's synced or device-bound."

Key restrictions allow or block specific authenticators by AAGUID, the identifier a passkey provider supplies at registration. They apply at both ends: "Key restrictions set the usability of specific models or providers for both registration and authentication."

So an AAGUID allow-list does gate registration. On its own it is not a security control, and Microsoft says so directly:

Use AAGUID lists as a policy guide rather than a strict security control when Enforce attestation is set to No.

Without attestation the AAGUID is self-asserted by the authenticator. Anything that can assert an AAGUID can assert an allowed one.

Now put that beside the mechanism. The credential in this technique is created by a software-based virtual authenticator running on the attacker's infrastructure. Software can attest: Microsoft Authenticator does it, through Apple's App Attest service on iOS and, on Android, the Play Integrity API or hardware-backed key attestation, and it registers with fixed AAGUIDs that Microsoft publishes for each platform. An arbitrary virtual authenticator on attacker infrastructure cannot do that: it has no path to attestation that chains to trusted metadata, and its AAGUID is whatever it says it is. Attestation enforcement is therefore the control that would refuse this registration.

An AAGUID allow-list alone would not refuse it, as Microsoft's wording above says. The two controls do different jobs: attestation confirms what kind of authenticator made the credential, and the allow-list narrows registration to the specific models you trust.

Now look again at the profile your SMS and voice users were placed into on 1 September.

Why the permissive default is not carelessness

Microsoft made a defensible trade.

Synced passkeys cannot be attested. That is a property of the credential type, not a gap in Entra. So the moment you enforce attestation you have excluded iCloud Keychain, Google Password Manager and every other synced provider your workforce may already be using. For a migration whose purpose is moving millions of people off SMS quickly and without burying the service desk, a profile that rejects the most convenient credential most people already have would be self-defeating.

It is a default with security consequences, and the risk sits with your tenant.

Split the population instead of enforcing attestation everywhere. Use attestation and an AAGUID allow-list for administrators and anyone with standing access to something that matters, and keep the permissive profile for everyone else, deliberately, with the reasoning written down. The Authenticator passkey article adds a constraint: "Users can't use cross-device registration if you enable attestation." Plan how the attested group registers before you enforce it.

Keep break-glass accounts out of that attested group if you register them through Authenticator. Authenticator's attestation depends on Apple's and Google's services, and Microsoft is explicit that when those services are down, Authenticator attestation blocks any registration that requires it until they come back. A break-glass account exists for the day something else is broken, so it belongs on a hardware FIDO2 security key instead, and it stays excluded from Conditional Access altogether, as the linked Conditional Access post already sets out.

You get three passkey profiles in total, including Default, so the segmentation has to be coarse. Opting in to passkey profiles cannot be undone: "After you opt in to enable passkey profiles, you can't opt out." Decide before you click.

Learn does not state whether the profile created by the September migration is the same formal object that carries the three-profile ceiling, or something system-managed alongside it. The articles use the same term and cross-reference each other, so treating them as one thing is reasonable, but I have not seen it confirmed.

Tightening attestation afterwards does not undo anything

This is the sentence to put in front of anyone who thinks they can handle this reactively:

Attestation enforcement governs whether a passkey (FIDO2) is allowed only during registration. Users who register a passkey (FIDO2) without attestation aren't blocked from sign-in if Enforce attestation is set to Yes later.

Enforcement happens at registration and only at registration. A credential registered under a permissive profile keeps working when the profile is tightened. If an attacker registered a passkey against one of your users last week, turning attestation on this week changes nothing about their access.

The policy object says the same thing in its own schema, where the attestation property takes the literal value registrationOnly. Registration-time enforcement is how the policy is designed to work.

Key restrictions behave differently. Learn states that if you remove a previously allowed AAGUID, "users who previously registered an allowed method can no longer use it for sign-in". That is retroactive in a way attestation is not: it removes an already-registered credential's ability to sign in, not merely its ability to register again.

Disabling a passkey type on the profile reaches backwards the same way. For synced passkeys, Learn's note is direct: "If you disable synced passkeys for a given passkey profile, targeted users can't sign in with a synced passkey even if they already registered one." So there are two levers that undo an earlier registration after the fact: removing an AAGUID from the key-restrictions allow-list, and turning off a passkey type on the profile. Attestation is not one of them.

The thing that reliably removes an attacker's credential is deleting the method from the user, so the detection has to work.

What your logs will and will not tell you

The obvious place to look is the Authentication Methods Activity report, and for incident response it is the wrong tool twice over.

It lags: Microsoft's stated figure is that the data "may reflect a latency of up to 36 hours". For a phish you detected an hour ago, a report that might tell you tomorrow evening is not part of your response. I measured a comparable gap between documented and actual latency for Graph activity logs elsewhere on this site, so do not take a vendor latency figure on trust either.

Its Registration and reset events view also enumerates methods as app notification, app code, phone call, office call, alternate mobile call, SMS, email and security questions. Passkeys are not in that list. The per-user registration details do show FIDO2 security key among a user's registered methods, so you can establish that a credential exists. You will not learn from this view that one just appeared.

The audit log is the better source. Microsoft's audit activity reference lists three activities under UserManagement that matter here:

• Get passkey creation options, which is the request that begins a registration
• Add Passkey (device-bound)
• Delete Passkey (device-bound)

Alongside the generic User started security info registration and User registered security info, that gives you a sequence to hunt for in the window around a suspected phish.

There is no activity listed for a synced passkey, only device-bound, and the permissive profile allows synced. Either synced registrations appear under the generic security info activities or the reference has not caught up; I have not confirmed which, and it matters, because the default configuration is precisely the one that permits the type with no named activity. I have also not verified what the entries carry in their payload, in particular whether the AAGUID is recorded, which is what would let you tell an attacker's virtual authenticator from a user's new phone.

What to change now

1. Amend the account-compromise runbook. After any confirmed phish, enumerate the user's registered authentication methods and remove anything unrecognised. Keep the password reset and the session revocation, and add this step after them:

   GET https://graph.microsoft.com/v1.0/users/{id}/authentication/methods

   That needs UserAuthenticationMethod.Read.All. This is a documentation change and a service-desk briefing, it costs nothing, and it is the step that would actually have helped. Do it first even if you do nothing else here.

   Be honest with the service desk about the hard part. "Unrecognised" is easy to write and difficult to action at half past four on a Friday, when the question is whether a passkey registered eleven minutes ago belongs to the user's new phone or to somebody else. The workable version is to compare against what the user says they own, and to treat any method they cannot account for as hostile until they can.

2. Find out who is in scope. Microsoft publishes a PowerShell script that reports the policy targets still enabled for SMS or voice: the included and excluded groups and any explicit user targets in your Authentication Methods Policy. It is, in the README's own words, "a read-only policy scope scanner, not a user inventory or usage report", so a non-zero result tells you the migration reached that policy, and you still need to expand group membership yourself to get a head count. Run it before you argue about whether this applies to you.

3. Read what you inherited, then decide what you actually want. The migration has run, so the profile question is no longer a forecast: GET the FIDO2 configuration shown above and look at what your users are in. If your administrators and privileged accounts should be on attested, key-restricted, device-bound passkeys, configure that deliberately rather than inheriting it. Remember the ceiling of three profiles and the one-way door on opting in. If you already run authentication strengths for privileged access, this is the same population and the two should agree.

4. Decide about the deferral deliberately. passkeyDynamicMigration buys you until February. Learn documents the opt-out against the 1 September changes and does not say whether applying it now reverses an enablement that has already happened, so test what it does in your tenant. Taking it is reasonable if you need the time to segment properly. Taking it because you have not looked at this yet is how February arrives with the problem intact and a blocking prompt attached.

5. Put a Conditional Access policy on registration itself. Target the Register security information user action and require an authentication strength. This control acts on the session that is doing the registering, which is exactly the session a phishing proxy relays. Microsoft defines the phishing-resistant methods as those that "require an interaction between the authentication method and the sign-in surface". A sign-in completed through the attacker's proxy with SMS or an Authenticator approval does not meet that bar. The registration is refused before any authenticator is involved. Exclude break-glass accounts, as above.

   The built-in phishing-resistant strength cannot be the whole answer, because it leaves no way in. Microsoft's strength table gives it three methods: FIDO2 security keys, Windows Hello for Business or platform credential, and multifactor certificate-based authentication. A Temporary Access Pass satisfies only the MFA strength. A user whose only method is SMS or voice therefore has nothing that meets the built-in strength, and could never register a first passkey. Microsoft's documented pattern is a custom strength for this user action that includes the Temporary Access Pass alongside the stronger methods. That reopens a narrow gap: a Temporary Access Pass is a code the user types, and an administrator issues it as a time-limited credential, so the exposure shrinks to the lifetime of each pass rather than disappearing.

   Guests need their own plan. Microsoft's guidance for this policy is direct: "Temporary Access Pass does not work for guest users." Plan the bootstrap for your SMS and voice population before you turn the policy on, and handle guest users as a separate problem.

What is verified, and what is not

The claim about the kit is the weakest-sourced thing here, and it should be weighed accordingly. Abnormal's analysis is built on the seller's forum posts, Telegram channel and demonstration videos. The researchers say so themselves: "This is a vendor demonstration in a seller-controlled environment, and we have not reproduced it," and "We did not run the toolkit, sign into an account through it, or reproduce the attack." Nobody has captured this kit. Treat the mechanism as plausible and consistent with how WebAuthn registration works, and treat the specifics as marketing produced by a criminal about a criminal product.

Nor have I established that the technique works against Entra end to end. The published analysis is against Google. The mechanism is protocol-level rather than provider-specific, which is a reason to take it seriously and not a substitute for measuring it.

Everything else above is from Microsoft's own documentation, quoted rather than paraphrased. I re-read every page quoted here on 1 October 2026 and each quote matched. The retirement article has a 16 September 2026 revision, which is where the July date and the guest-user carve-out came from, and a 23 September 2026 revision, the version quoted here. Learn pages change, so check the article rather than trusting my table.

Microsoft has already answered, in writing, the questions that bear on your tenant: whether the September migration placed your SMS and voice users into a profile that permits any authenticator to register, whether an allow-list without attestation is advisory, whether tightening the policy later evicts anything, and whether your reporting would tell you in time.

Start with the runbook: after any confirmed phish, list the user's registered authentication methods and remove the ones they cannot account for. Then read the passkey profile your users are in.