From Authenticator MFA to multi-device passkeys

Purpose and prerequisites

The purpose of this article is to describe a migration from Microsoft Authenticator multifactor authentication to multi-device passkeys in Microsoft Entra ID. The discussion assumes that every mailbox already requires a second factor, and that most users hold Microsoft 365 Business Premium, or another license that includes Entra ID P1, so Conditional Access can require a named authentication strength rather than “MFA, always.” Readers who are still choosing a license should begin with Business Standard vs Premium. Readers whose only second factor is still Authenticator push should begin with Intune and authentication. The remainder of this article addresses the next step after those foundations are in place: replacing Authenticator push with passkeys.

A passkey is not a redesigned Authenticator prompt. A passkey is a public-key credential. The authenticator on the phone or computer holds the private key; Entra ID stores only the matching public key. The person proves presence by unlocking that authenticator with a biometric or a device PIN. For the general workforce, the private key is stored in a platform credential manager such as Apple Passwords or Google Password Manager so that a second device signed into the same manager can use the same credential. The practical result is a different class of secret, not a different skin on the same six-digit code.

Why Authenticator MFA is no longer sufficient

The phrase “the Authenticator app” names three different methods that most tenants treat as one product. The first method is a push notification, including number matching, in which Entra ID sends a prompt and the user approves it on the phone. The second method is a time-based one-time password (TOTP), a six-digit code that rotates every thirty seconds. The third method is passwordless phone sign-in, which uses the phone as the first factor rather than as a second factor after a password. Only a passkey stored in Authenticator is a FIDO2 credential, and even that passkey is device-bound rather than multi-device. Operators who want to leave Authenticator MFA must first distinguish these methods, because they are not equivalent and they are not equally resistant to phishing.

Number matching reduced a real problem, MFA fatigue, in which users approved prompts they had not initiated. Number matching did not stop an adversary-in-the-middle attack. In that attack, a lookalike sign-in page sits between the user and the genuine Microsoft login host, relays the password, relays the matching number or the TOTP, and captures the session cookie. The user has followed the prompt correctly. The authenticator has still signed the attacker’s transaction, because the secret is a shared code rather than a signature bound to the real origin. Figure 1 contrasts that relay with a passkey, which will not produce a signature unless the origin is the genuine Microsoft login host. Shared-code MFA can be completed on a fraudulent page; that is the limitation number matching does not repair.

Shared-code MFA

1. User opens a lookalike sign-in page
2. Attacker relays the password to Microsoft
3. Authenticator push or TOTP is relayed the same way
4. Attacker receives the session cookie

The code is not bound to the real site, so a proxy can complete the sign-in.

Passkey (FIDO2)

1. User opens a lookalike sign-in page
2. The authenticator checks the origin
3. The origin is not Microsoft’s login host
4. No signature is produced

The private key will not sign a challenge for a fraudulent host.

Guidance from CISA and NIST follows from that limitation. Those agencies do not classify Authenticator push or TOTP as phishing-resistant. They do classify Windows Hello for Business, certificate-based authentication, and passkeys (FIDO2) as phishing-resistant, because the private key never leaves the authenticator and the authenticator will not sign a challenge for a lookalike host. A page that merely resembles login.microsoftonline.com cannot obtain a passkey assertion. Authenticator push remains useful as a historical control; it is not the control those standards treat as resistant to verifier impersonation.

Microsoft’s own platform schedule reinforces the same direction. Passkeys become the default authentication experience in Entra ID from 1 September 2026 for users who are still enabled for SMS or voice. Microsoft-provided SMS and voice delivery retires on 1 February 2027. Authenticator push is not on that retirement list. An organization that treats push MFA as the destination will complete one migration and then need another when the rest of the platform has already moved to passkeys. The schedule is an additional reason to migrate now, not the only reason.

Authentication methods and the role of each

Authentication methods should be classified by the job they perform, not by how modern the prompt appears. The jobs that matter in a small or mid-size tenant are four: methods that must leave daily use, a bootstrap used only for enrollment and recovery, a default phishing-resistant method for the workforce, and a stricter device-bound method for privileged roles. The table at the end of this section summarizes that classification. The paragraphs that precede the table explain why each group belongs where it does.

SMS, voice, Authenticator TOTP, Authenticator push, and passwordless phone sign-in should leave daily use as soon as passkeys are registered. SMS and voice are interceptable and SIM-swappable, and Microsoft stops delivering them natively in February 2027. TOTP and push, including number matching, can be relayed through a lookalike page. Passwordless phone sign-in is easy to confuse with a passkey in Authenticator, but it is not origin-bound FIDO2. Each of these methods was a reasonable control on the path to MFA. None of them should still satisfy Conditional Access once a phishing-resistant method is in place.

A Temporary Access Pass (TAP) is the bootstrap, not a daily factor. Helpdesk issues a TAP as a time-limited code so that a user can register a first passkey, or recover after every device is lost. A TAP is not phishing-resistant. The organization nevertheless needs TAP the moment phishable fallbacks are removed, because otherwise a lost phone has no high-assurance path back into the account. TAP should be treated as a controlled exception: a short lifetime measured in hours rather than days, one-time use where the policy allows it, a recorded proof-of-identity step, and an audit trail.

The default method for the workforce should be a multi-device, or synced, passkey. The user unlocks the device with a fingerprint, face, or PIN. The same credential is available on the user’s other devices through Apple Passwords, Google Password Manager, or a manager such as 1Password or Bitwarden. The assertion is bound to the real Microsoft origin, so a fraudulent page does not receive a signature. Recovery, when a single device is lost, is the provider’s account rather than a second phone app. Microsoft reports that about 99 percent of users register a synced passkey successfully, that sign-in takes on the order of three seconds rather than a minute, and that users complete sign-in about three times as often as with legacy methods. Those figures describe why synced passkeys are the default for people who are not in highly privileged roles.

Privileged roles should keep a tighter, device-bound credential in addition to whatever the workforce uses. A passkey in Microsoft Authenticator is genuine FIDO2, stored in the iPhone Secure Enclave or the Android Keystore; if the phone is lost, the user must register again because the key does not sync. A FIDO2 security key is the same idea in hardware the user can touch. Windows Hello for Business and macOS Platform SSO are the daily path on an enrolled company computer and do not help at a hotel kiosk. A forty-person firm that puts every mailbox on Authenticator passkeys alone will spend the next hardware-refresh Friday restoring people who received a new iPhone. Device-bound methods belong with admins and with a backup that is not the same phone.

Method	Phishing-resistant?	Role in the design
SMS, voice, TOTP, Authenticator push, passwordless phone sign-in	No	Transition only; must not satisfy sign-in after passkeys are required
Temporary Access Pass	No	Enrollment and recovery; not a daily login
Multi-device (synced) passkey	Yes	Default for the workforce
Passkey in Authenticator, FIDO2 security key	Yes, and device-bound	Privileged roles, and a backup that is not the same phone
Windows Hello for Business, macOS Platform SSO	Yes, on that computer	Daily sign-in on enrolled company PCs

The classification in the table is the design, not a menu from which each user picks a favorite. Workforce users receive synced passkeys. Administrators receive a device-bound method as well. TAP remains available to helpdesk. Push and TOTP remain only until registration coverage is real, and then they stop satisfying Conditional Access. The rest of the article describes how Entra ID represents that design and how to introduce it without an outage.

Device-bound passkeys and multi-device passkeys

Microsoft Entra ID distinguishes two types of passkey, and the distinction is configured per passkey profile in the Authentication methods policy. A device-bound passkey is created on one authenticator and never leaves it. A multi-device passkey is created in hardware on the device, encrypted, and synchronized by a passkey provider so that another device signed into that provider can use it. The two types solve different problems. Choosing the wrong type for a population is the usual reason a passkey rollout either fails to register or fails to recover.

Device-bound passkeys include Authenticator passkeys, hardware security keys, and Entra passkeys on Windows. Attestation can prove the authenticator’s make and model against the FIDO Metadata Service, which is why a regulator or an administrator role can require “this exact key, on this exact device.” The cost of that assurance is recoverability: lose the device, and the credential is gone until someone issues a TAP and the user registers again. Device-bound passkeys are the correct choice when physical control of the authenticator is a requirement.

Multi-device, or synced, passkeys trade attestation for portability. Apple Passwords, Google Password Manager, and comparable managers encrypt the key and synchronize it. Synced passkeys cannot present a trustworthy attestation statement. The organization therefore cannot cryptographically prove the device model at registration. In return, a user who replaces a phone does not need a helpdesk TAP for the ordinary case, because the credential is already on the next device. That trade is the reason synced passkeys are the default for the workforce rather than a compromise forced by missing hardware keys.

Attestation and synchronization are mutually exclusive inside a single passkey profile. If the profile still has Enforce attestation enabled from an earlier FIDO2 security-key deployment, iCloud credentials will not register, and operators will conclude that passkeys do not work on iPhones. The credentials work; the profile refused them. A tenant that wants synced passkeys for staff must turn attestation off on the workforce profile. A tenant that wants attested device-bound keys for administrators must keep attestation on for that population in a separate profile.

The mixed model that follows from those constraints is ordinary and should be stated explicitly. The workforce profile allows synced and device-bound passkeys, with attestation off and self-service registration on. The privileged profile allows device-bound passkeys only, with attestation on and, if the organization has standardized, an allow-list of authenticator models. Break-glass accounts remain two cloud-only identities with long passwords, exclusion from most Conditional Access, and monitoring; a passkey on those accounts is optional insurance, not a substitute for the sealed recovery process. Figure 2 shows that arrangement as a standard implementation: Entra ID holds only public keys and policy, each population uses a different authenticator, and TAP is reserved for enrollment and recovery. That mixed model is what the migration sequence later in this article implements.

Microsoft Entra ID Stores the public key only Authentication methods policy and passkey profiles Phishing-resistant authentication strength Conditional Access, including device grants

Workforce Multi-device (synced) passkey Apple Passwords, Google Password Manager, or a comparable vault Self-service registration; attestation off

Company PC Windows Hello for Business or macOS Platform SSO Daily sign-in on the enrolled machine Synced passkey used on other devices

Administrators Device-bound passkey Authenticator passkey or FIDO2 security key Attestation on; backup is not the same phone

Recovery Temporary Access Pass issued by helpdesk for first enrollment and for total device loss. Break-glass accounts remain separate, monitored, and excluded from most Conditional Access.

Components of a passkey transaction

A passkey sign-in is a short protocol among named components, not an unexplained prompt from an app. Operators who cannot name those components cannot read an Entra sign-in log when registration or assertion fails. The components fall into two groups: the policy objects an administrator configures, and the cryptographic parties that execute each ceremony. Both groups are required. Policy without the ceremony is a toggle that nobody uses. The ceremony without policy leaves Authenticator push as the method users still choose because it is familiar.

The policy objects are the controls that make a passkey required rather than optional. The user is the Entra account; the passkey is registered to that person, not to a laptop. The Authentication methods policy is now the single place that enables Passkey (FIDO2), TAP, Authenticator, and the remaining methods; the legacy MFA and self-service password reset blades are retired, and a second copy of the truth there will drift. A passkey profile, of which Entra ID supports up to three including Default, sets the passkey type, attestation, authenticator-model restrictions, and the groups the profile targets, which is how workforce and administrators receive different rules in one tenant. Authentication strength is the Conditional Access condition; the built-in phishing-resistant strength accepts passkeys, Windows Hello for Business, and multifactor certificates, and it does not accept Authenticator push. Conditional Access is the policy that actually requires that strength. TAP remains the enrollment and recovery exception described above, not a Tuesday sign-in method. Enabling FIDO2 without these objects leaves the tenant able to register passkeys and still signing in with push.

The cryptographic parties are what happen under the prompt. The relying party is Entra ID, and the passkey is bound to Microsoft’s sign-in origin rather than to a customer vanity domain, which is why a fraudulent site cannot obtain a signature. The browser or operating system speaks the WebAuthn API to an authenticator: the phone or computer the user is holding, a security key over USB or NFC, or the phone answering a computer through a QR code and Bluetooth. For a synced passkey, Apple, Google, or a password manager is the provider that encrypts and synchronizes the private key; Entra ID never sees that private key and does not operate the synchronization fabric. Those parties, not the Authenticator push service, are what produce a phishing-resistant assertion.

The authenticator generates a key pair and retains the private half. Entra ID stores the public key, a credential identifier so that a later sign-in can request the correct key, and an authenticator attestation GUID (AAGUID) that identifies the authenticator model. Passkey profiles and authentication strengths use the AAGUID to allow or block a vendor. Synced passkeys still have an AAGUID; they cannot present a trustworthy attestation statement. Each ceremony begins with a random challenge from Entra ID. The signature covers that challenge and the origin, so a captured response cannot be replayed later or against a different site. User verification — a biometric or a PIN — is the flag that allows the passkey to count as multifactor authentication; a mere touch of a key is a weaker presence check and is not the assurance this design requires. The stored public key, the challenge, and user verification together are what Entra ID checks before it issues a token.

Cross-device use has one operational requirement that policy often contradicts. An organization does not configure the cable protocol between a browser and a security key. An organization does configure whether a phone may answer for a computer: Bluetooth must be available, and no endpoint policy should block pairing with FIDO authenticators. A firm that disables Bluetooth for security and then requires phone passkeys on desktop sign-in has designed a helpdesk queue. Hybrid, or QR-plus-Bluetooth, sign-in is optional for tenants that keep Hello on every company PC; it is mandatory for any design that expects a phone-held passkey to unlock a PC.

Registration and authentication events

Every passkey is created by a registration event and later used by an authentication, or assertion, event. Both events are challenge-and-response protocols. Neither event sends a shared secret such as a six-digit code to Microsoft. Understanding the two events is what allows an operator to distinguish “the user cancelled,” “the profile forbade this passkey type,” and “Conditional Access still required a weaker method” when a log line is unhelpful. The subsections below walk through registration first, then sign-in.

Registration begins only after the user is already signed in strongly enough, either with recent multifactor authentication or with a TAP, and opens Security info, a registration campaign, or the Authenticator passkey flow. Entra ID sends a challenge and the account details. The device asks the user to verify with a biometric or PIN. The authenticator creates a new key pair, retains the private key, and, for a synced passkey, gives an encrypted copy to the provider. Entra ID verifies the challenge and the origin, verifies attestation if the profile requires it, and stores the public key against the user. Figure 3 presents those five steps as a single sequence. At the end of a successful registration, the account holds a passkey that later sign-ins can present; the private key has never been transmitted to Microsoft.

• 1
  Already signed in

  The user is authenticated with recent MFA or a Temporary Access Pass, then opens Security info or a registration campaign.

• 2
  Entra ID sends a challenge

  The relying party includes the Microsoft sign-in origin and the account identity. No shared secret is sent.

• 3
  The user verifies on the device

  Face ID, a fingerprint, Windows Hello, or a device PIN proves presence. This is user verification, which allows the passkey to count as MFA.

• 4
  The authenticator creates a key pair

  The private key stays on the authenticator, or in the platform vault for a synced passkey. Only the public key, credential ID, and authenticator model are returned.

• 5
  Entra ID stores the public key

  The challenge and origin are checked. Attestation is checked if the profile requires it. The private key is never transmitted to Microsoft.

Attestation changes where registration is allowed to occur. If the profile requires attestation, an Authenticator passkey must be created in the Authenticator application on the phone. The hybrid path that displays a QR code on a computer and asks the phone to register cannot produce an attested Authenticator passkey. That restriction is expected behavior, not a product defect. Synced passkeys never take the attested path; they register from the platform sheet on the device the user is sitting at. Operators who require attestation for administrators and allow sync for staff must therefore accept two different registration surfaces, and must not diagnose the QR path as “broken” when attestation is on.

A single Entra account may hold more than one passkey. Typical combinations are a synced passkey in a phone vault, Windows Hello on a company laptop, and a hardware security key as a backup. Microsoft Authenticator itself still allows only one Authenticator passkey per account. Administrators should be planned for two credentials, and the backup should not be the same phone that holds the daily Authenticator passkey. Multiple credentials are what make a lost device an inconvenience rather than an outage.

Authentication, or assertion, begins when the user opens a Microsoft application or the genuine Microsoft login host. If a passkey is registered, Entra ID can promote that method ahead of a password plus push. The platform uses a local copy of a synced passkey, or, if the key is on the phone and the sign-in is on a computer, presents a QR code and uses Bluetooth to prove the phone is nearby. After user verification, the authenticator signs the challenge. Entra ID verifies the signature with the stored public key, verifies the origin, verifies that user verification occurred, and issues a token. Conditional Access then evaluates authentication strength, device compliance, and any other grants. Figure 4 is that authentication process from the user’s request through the device grant. A successful assertion proves the identity factor; it does not, by itself, prove that the device is managed.

• 1
  The user opens a Microsoft app

  Outlook, Teams, or the genuine Microsoft login host starts sign-in. If a passkey is registered, Entra ID can offer it first.

• 2
  Entra ID issues a one-time challenge

  The challenge is bound to Microsoft’s sign-in origin. A lookalike host cannot reuse it.

• 3
  The authenticator finds the matching key

  A local copy is used when the vault is on this device. If the key is on a phone and this is a PC, a QR code and Bluetooth prove the phone is nearby.

• 4
  The user verifies, then the key signs

  A biometric or PIN unlocks the private key. The authenticator signs the challenge. The private key still does not leave the device or vault.

• 5
  Entra ID verifies, then Conditional Access runs

  The signature, origin, and user-verification flag are checked, and a token is issued. Conditional Access still evaluates authentication strength and device compliance as separate grants.

The separation between the identity factor and the device grant is the point operators most often miss. A passkey satisfies phishing-resistant multifactor authentication. A compliant Windows or macOS device, or an app-protected iOS or Android client, remains a separate Conditional Access grant. Strengthening the factor is not a reason to retire Intune. Leaving Authenticator push in the chain after a passkey has already succeeded is also a mistake: a second prompt after a successful passkey is how users install a “helper” that steals tokens. The correct end state is one phishing-resistant sign-in plus the device control the tenant already designed.

What the Entra sign-in log should show

A working passkey deployment produces sign-in records that are uneventful in a useful way. The authentication method is Passkey (FIDO2), sometimes with the authenticator’s display name or AAGUID. The authentication requirement is multifactor authentication, or the named strength the policy required. A passkey with user verification satisfies MFA by itself, so a successful event should not also show a push approval unless a weaker method is still in the chain. Authentication details record that the challenge was satisfied, not that a code was typed. Conditional Access still records which policy required which strength and whether the device grant passed. An operator who sees those fields populated as described can treat the ceremony as healthy.

Failures and method changes have equally specific places to look. Failures in authentication details are usually a cancelled prompt, a hybrid Bluetooth flow that never completed, or a profile that forbids the passkey type the user offered. Registration and deletion of methods appear under the user’s authentication-method activity, not only in the interactive sign-in log. A passkey that disappears while TOTP reappears is either a new phone or a rollback to a phishable method. Issuance of a TAP by helpdesk should be a ticket, not an unlogged Graph call. Reading those two surfaces — the sign-in log and the method-activity log — is how the organization notices that the design is drifting.

A sequenced migration

A tenant-wide phishing-resistant Conditional Access policy should not be enabled on a Monday for users who have not yet registered a passkey. The migration must be sequenced so that people can register before they are required to use the new method, and so that helpdesk can recover an account before phishable methods are removed. The sequence below is the order we use. Each step assumes the previous step is complete. Skipping the bootstrap or the pilot is how the project becomes an outage.

The first step is to finish the move into the Authentication methods policy. Any method that still exists only in the legacy MFA or self-service password reset blades should be brought across before passkeys are added, so that there is a single policy surface. The second step is to enable TAP for helpdesk or identity administrators, with a lifetime measured in hours, a written proof-of-identity procedure, and a copy of that procedure stored somewhere that does not depend on the tenant being healthy — the same discipline used for break-glass accounts. Until TAP exists, removing push MFA has no safe recovery path.

The third step is to enable Passkey (FIDO2) with self-service registration and to create the two profiles already described: a workforce profile that allows synced and device-bound passkeys with attestation off, and a privileged profile that allows device-bound passkeys with attestation on, targeted at the administrative roles rather than at all users. The fourth step is a pilot of about ten people who already use Authenticator and who together cover a Mac, an iPhone, an Android device, a hybrid-joined Windows PC, and a person who signs in from a browser on a personal computer. Those people should register a synced passkey from Security info, sign in on a second device, and, if hybrid sign-in is in scope, sign in on a PC using the phone. Bluetooth and browser allow-lists should be corrected in the pilot, not after a company-wide campaign.

The fifth step is a registration campaign that nudges remaining users to register a passkey at sign-in. Microsoft-managed campaigns will also include SMS and voice users as passkeys become the default experience. A nudge is not enforcement. Registration should be tracked until the holdouts are known by name. The sixth step is to require the phishing-resistant authentication strength by persona: administrators first, every time, with no persistent browser session and a compliant device; then the workforce, for the core cloud applications, with a temporary exception group that expires on a published date. The exception should not be labeled as a VIP list. The exception should be labeled as a date.

Company computers should receive Windows Hello for Business or macOS Platform SSO as the daily path, with the synced passkey used on other devices and when Hello is not available. From October 2026, Entra ID will treat Hello and Platform SSO as satisfying multifactor authentication on their own; a passkey prompt stacked on a machine that has already completed phishing-resistant sign-in should be removed. After registration coverage is real, Authenticator push and TOTP should stop satisfying Conditional Access. The Authenticator application may remain installed during the overlap so that the same phone can hold a device-bound passkey for people who need one. Notification and OTP should then be disabled for groups that have completed registration. TAP remains. Recovery should be drilled for a new phone, a lost phone, and a user who turned off iCloud Keychain. The recovery answer is a TAP followed by registration of a new passkey, not an SMS code. If helpdesk cannot issue a TAP without a Global Administrator, the tenant does not yet have a recovery process.

What users will tolerate

Adoption depends on the number and familiarity of prompts, not on the correctness of the cryptography. A fingerprint on a laptop the user already unlocks is tolerated. A QR code and Bluetooth the first time are tolerated if people are warned. A second Authenticator prompt after a successful passkey is not tolerated, and it is the prompt that sends people looking for a workaround. The user-experience rule is therefore the same as the Conditional Access rule: one phishing-resistant sign-in, then work, with no extra factor on the same session.

Explanation should use the vault the person already knows. “Your iPhone Passwords, or iCloud, account” is a sentence users understand. “FIDO2 discoverable credential” is not. An Apple ID shared with a spouse is, under a synced-passkey design, an identity question rather than a household trivia fact, and it should be asked before registration. Information technology staff should not collect phones to “set up the app” unless the person is receiving a device-bound Authenticator passkey. Synced passkeys are registered by the user, on the user’s device, in about thirty seconds; staff who register on the user’s behalf usually attach the credential to the wrong iCloud account. Clear language and user-initiated registration are what keep the vault and the Entra account aligned.

Shared equipment remains a device-management problem. A front-desk computer used by several people needs a shared-device or assigned-access model, not a personal iCloud passkey left signed in. Passkeys replace Authenticator push as the identity factor. Passkeys do not replace the Intune design for enrollment, compliance, and wipe. Identity and device control are still one design after the factor has changed.

Recommendations this practice will not make

Several recommendations look adjacent to this migration and are still wrong. Authenticator number matching will not be described as phishing-resistant because the prompt looks modern. Global Administrators will not be placed on iCloud-synced passkeys as their only credential. Phishable fallbacks will not be disabled before TAP and break-glass accounts have been tested on a weekday. Push MFA will not be left enabled “just in case” after the authentication-strength policy is live, because that exception is the path the phishing kit uses. Those refusals are part of the design, not omissions from it.

A tenant that already has Authenticator everywhere can still make this change. The work is a sequenced configuration of methods, profiles, Conditional Access, and recovery, not a weekend switch. Organizations that want the sequence implemented, rather than only described, may talk with us. Organizations that want a shorter test of readiness can use the twelve-question Assessment.