Anton Staykov

Posted on Oct 7

To passkey or not to passkey? Microsoft Entra has changed the question

#microsoftentra #passkeys #passwordless #identitysecurity

Scepticism about passkey onboarding is understandable. It is not a reason to evaluate today's synced-passkey support in Microsoft Entra through yesterday's Authenticator Passwordless sign-in setup. For an employee signing in on their own phone, the important change is how much of the registration journey can stay on that phone.

A customer needed one working phone, not a passwordless programme

The discussion started with a concrete customer situation: front-line workers needed access to a web-based application from their personal mobile devices, outside the corporate network. The company did not provide laptops, mobile phones or other authentication hardware. There were no terminals on the manufacturing floor, and deploying terminals was not the desired answer.

The company also did not want to distribute passwords. That matters because a recommendation built around sending every worker an initial password changes the requirement before the architecture discussion has even started. The desired outcome was a usable access journey on the device the worker already owned, not a new fleet-management project.

The existing authenticator passwordless sign-in onboarding was generating too many support requests. In the customer's discussion, approximately half the users were reportedly unable to complete the configuration. That is the reported experience of this population, not an industry-wide failure rate or a measured comparison with a completed passkey deployment.

One contributing factor was that workers were being asked to configure an authenticator application both for multifactor authentication (MFA) and for passwordless sign-in. Those are different capabilities inside Microsoft Authenticator, not interchangeable names for the same setup. For the worker, the distinction appeared as more instructions, more settings and more opportunities to get stuck.

It is tempting to answer this with the architecture that works well for a managed corporate laptop. Require a particular authenticator, prohibit synced credentials, standardize the hardware, then write a guide around that standard. That is a coherent answer to a different problem.

Here, neither a managed computer nor a company-issued phone was available. Requiring one as the starting point would not simplify the customer scenario; it would replace it. The useful question was whether the worker's existing phone could provide both the application surface and the authentication experience.

This is why an account of difficult cross-device registration in a restrictive corporate environment is relevant evidence, but not a verdict. You still need to test the experience under the actual device, browser and provider combinations that Entra supports. A phone-only browser journey deserves its own evaluation.

Optimize the journey the worker must complete, not the deployment you would prefer to manage. The device constraint is part of the design brief, not a detail to remove from it.

The recent Entra changes make this a different discussion

There are specific changes behind this recommendation, not just renewed enthusiasm for passkeys. Microsoft lists synced passkeys as generally available in March 2026, with passkey profiles controlling their use alongside device-bound credentials. An evaluation based on an earlier device-bound-only assumption is therefore evaluating a different set of available choices.

Microsoft then lists passkey support in registration campaigns as generally available in May 2026. The initial experience is optimized for users whose passkey profile has no restrictions. That is particularly relevant when the goal is to let a heterogeneous population use an available provider rather than an administrator's predicted provider.

There is also a more recent default change. From September 1, 2026, Microsoft documents automatic passkey enablement and registration nudges for users enabled for SMS or voice authentication, with a documented temporary opt-out. This is not a statement that every user is already enrolled, that every tenant now has the same policy, or that passwords have disappeared.

Those adoption nudges are useful context, but they do not bootstrap a worker who has no usable sign-in method yet. A campaign that appears after an existing authentication succeeds and a first-credential onboarding process solve different problems. The latter still needs a deliberate entry path, described later.

The practical change is that Entra supports passkeys in native and third-party providers as well as Microsoft Authenticator and security keys. For a supported phone with its provider already configured, the synced-passkey registration flow can use that provider. A separate Authenticator installation is not inherently part of that journey.

Notice the qualification: with its provider already configured. Microsoft explicitly documents a password-manager prerequisite for synced-passkey registration, including platform-specific settings. The improvement is not that every phone arrives in an identical state; it is that a usable existing state no longer has to be replaced with an additional application setup.

It would also be wrong to freeze Authenticator at an old onboarding experience. Microsoft now documents direct passkey registration from the Authenticator application, including configuration of passkey, passwordless and MFA capabilities according to account policies. That is a legitimate alternative when Authenticator is the chosen provider.

Reassess the current supported experience, not the reputation of an older one. For this customer, the meaningful improvement is a shorter same-phone route, not a promise that every operating-system dialog has become identical.

Authenticator is an application, not an authentication method

"Use Authenticator" is not a sufficiently precise authentication recommendation. The application supports MFA notifications and verification codes, passwordless phone sign-in, and device-bound passkeys. Those capabilities do not have the same enrollment requirements or the same authentication strength.

The distinction that matters most is passwordless versus phishing-resistant. Microsoft's built-in authentication-strength definitions place Authenticator phone sign-in in passwordless MFA, but not phishing-resistant MFA. Removing the password prompt is valuable; it is not the same property as requiring a phishing-resistant credential.

Passkeys use Fast Identity Online 2 (FIDO2) authentication. Entra treats both synced and device-bound passkeys as phishing-resistant, while giving administrators controls over which credentials they permit. The storage decision adds a separate trust question; it does not turn a synced passkey into an Authenticator notification.

Experience	Passwordless?	Phishing-resistant?	What the worker is configuring
Authenticator MFA, using a notification or verification code	Not by itself; it supplies an additional factor	No	An MFA method in the application, commonly used alongside a password
Authenticator passwordless phone sign-in	Yes	No	The application's passwordless phone-sign-in capability, distinct from a passkey
Device-bound passkey in Authenticator	Yes	Yes	A FIDO2 credential bound to that phone, with Authenticator acting as its provider
Synced passkey in a native or third-party provider	Yes	Yes	A FIDO2 credential managed and synced by the selected provider, rather than necessarily by Authenticator

The first row often leaves the worker with a password plus an additional verification step. The second removes the password from the sign-in experience, but remains a different method from FIDO2 passkey authentication. You cannot infer the required strength from the fact that the same application appears on the screen.

The third row is not "phone sign-in with a new label." Microsoft documents Authenticator passkeys as device-bound credentials. Choosing that option is a credential decision, not just enabling the application's older passwordless-notification feature.

The fourth row moves the credential-storage relationship into a passkey provider such as Apple Passwords or Google Password Manager. Microsoft documents provider-dependent synchronization across the user's devices. It is not a promise of unrestricted portability between every ecosystem.

The worker does not need this taxonomy on the welcome sheet. You need it in the design review so that "passwordless," "Authenticator" and "passkey" do not silently become synonyms. Otherwise, an apparently small wording error becomes a different enrollment path or an authentication-strength mismatch.

An application name is not a security property. Specify the credential and the required strength before deciding which application, if any, the worker must configure.

Same-device is the design choice that removes the detour

There are two independent axes in this discussion. Synced versus device-bound describes how the credential is stored and made available; same-device versus cross-device describes where the application and the authenticator are used. Microsoft documents both same-device and cross-device sign-in with device-bound Authenticator passkeys, so device-bound does not mean cross-device.

For the customer scenario, same-device means the worker opens the application on the phone and uses an available passkey provider on that phone. The supported synced-passkey setup follows that local provider experience. The user does not need a second screen merely to make the intended phone-only journey work.

Phone-assisted cross-device sign-in is different: the application is on a computer, while the passkey is on the phone. Microsoft's documented synced-passkey flow uses a QR code and requires Bluetooth and internet connectivity on both devices. Those are additional participants and dependencies, not properties that every passkey sign-in necessarily has.

Same-device sign-in

flowchart LR
    A["Web app on phone"] --> B["Passkey provider<br/>on that phone"]
    B --> C["Local verification:<br/>face, fingerprint or PIN"]

Phone-assisted cross-device sign-in

flowchart LR
    D["Web app on computer"] --> E["QR code, Bluetooth<br/>and internet"]
    E --> F["Passkey provider<br/>on phone"]
    F --> G["Local verification:<br/>face, fingerprint or PIN"]

Both paths still need to complete authentication and meet the application's Conditional Access authentication requirements. The two diagrams separate the user-facing topology, not different levels of permission. Cross-device is a useful capability when there actually is another device to sign in on.

A synced passkey does not force a cross-device ceremony either. If the provider has made the credential available locally on another supported device, that device can use the local credential rather than borrowing the phone. That follows the provider-dependent availability model for synced passkeys; it is a different situation from scanning a computer's code with a phone.

Why start a phone-only worker's registration guide on a computer?

For this scenario, that adds a device the worker was never promised. It also moves the demonstration away from the experience the company actually wants to support. A guide that begins on the personal phone keeps the registration flow and its provider selection in the same place as subsequent application use.

This is where the experience becomes almost unremarkable on a supported, correctly configured phone: select the passkey flow, confirm with the device's local verification, finish registration, then use the credential for sign-in. That is the target the documented registration and local sign-in experiences make possible. It is not a claim that every browser, old handset or provider configuration will behave identically.

The demonstration worth showing is the complete same-phone journey.

Keep the intended journey local before evaluating cross-device exceptions. Credential storage and authentication topology are separate decisions, and neither should be inferred from the other.

A permissive worker profile is a deliberate trust decision

For this particular population, the proposed starting point is a passkey profile without provider restrictions. Allow both device-bound and synced passkeys, do not enforce attestation, and do not target specific authenticator identifiers. These are supported passkey-profile choices, scoped to the relevant worker group rather than automatically applied to the whole tenant.

An Authenticator Attestation GUID (AAGUID) identifies an authenticator type, such as its make and model. Attestation gives Entra evidence about the authenticator creating the credential. Microsoft documents both controls and their limitations; they are not equivalent to confirming that a worker's personal phone is company-managed.

Here is the administrative intent, not an API payload. The self-service setting is global rather than profile-specific, which is a relevant distinction when reviewing existing configuration.

Population: Front-line worker pilot
Allow self-service set up (global): Yes
Enforce attestation (profile): No
Passkey types (profile): Device-bound + Synced
Target specific authenticators / AAGUID restrictions: Off

The sharp edge is that synced passkeys do not support attestation. Disabling attestation does not make FIDO2 authentication cease to be phishing-resistant, but it gives up verified authenticator provenance. Microsoft's warning is explicit: without enforced attestation, Entra cannot guarantee passkey attributes, including whether the credential is synced or device-bound.

That is why an AAGUID allowlist without attestation is not a substitute for hardware assurance. Microsoft says to treat unattested AAGUID restrictions as policy guidance rather than a strict security control. If the requirement is an attested, approved, device-bound authenticator, use a design that actually supplies that assurance.

For these workers, however, predicting one approved provider for every personal phone can add the constraint that the customer is trying to remove. An unrestricted profile permits the available native or third-party provider experience instead of blocking it through an administrator-maintained list. It does not guarantee that Entra will always choose the fastest provider or eliminate every provider-selection prompt.

The expectation in the discussion was that most users would register a synced passkey and a smaller number might choose a device-bound one. Treat that as a pilot hypothesis, not documented product behavior. Measure the registered methods and actual completion rate before turning an expectation into a rollout claim.

There are also configuration boundaries to review before changing an existing tenant. Microsoft documents that opting into passkey profiles cannot be reversed and transfers existing settings to a Default profile. It also documents that users scoped for multiple profiles can register or authenticate when the credential fully satisfies at least one applicable profile.

Do not accidentally put privileged accounts into a permissive worker scope and assume a stricter profile takes precedence. Conversely, do not assume tightening provider restrictions later is only a registration change: removing an allowed AAGUID can also prevent existing credentials from signing in. Scope and recovery are part of the policy change.

Less restrictive onboarding is a conscious trust decision, not absent security design. Keep the worker profile separate from populations whose credential-provenance requirements are different.

Bootstrap registration before you enforce the credential

The worker still needs a secure starting point. A Temporary Access Pass (TAP) is a time-limited passcode that can be configured for single use or multiple sign-ins and used to register passwordless authentication methods. It is the bootstrap credential, not the permanent method you want the worker to keep using.

First verify the worker's identity through the established onboarding process. Then issue a short-lived TAP through a controlled delivery process, and ensure the user is actually included in the TAP authentication-method policy. Creating a TAP for an account does not, by itself, make that account eligible to sign in with it.

SMS, personal email and a physical help desk are possible delivery channels to assess, not interchangeable identity-proofing guarantees. The security question is who can obtain the bootstrap credential and register the next method. A printed code handed to a verified worker and a code sent to an unverified contact address do not establish the same trust contract.

Prefer a single-use TAP where the tested journey supports it. Microsoft documents a 10-minute completion limit for passwordless-method registration after sign-in with a one-time TAP, so do not write an onboarding process that spends that window on unrelated setup. The code is also only visible at creation, making secure handling and delivery part of the operational design.

Conditional Access is where a sensible credential choice can still become a circular dependency. TAP satisfies the MFA authentication strength, not the phishing-resistant strength. Requiring an already-registered phishing-resistant method as the only way to reach its initial registration is not a stronger bootstrap; it is a route the new worker cannot complete.

Separate the bootstrap-compatible security-information registration policy from application access enforcement. Require an appropriate registration strength that permits the issued TAP, then require the intended credential for the application once the worker is ready. Review the complete applicable policy set, including broad resource scopes, rather than assuming one new registration policy neutralizes every other requirement.

Be precise about the application's requirement too. The built-in phishing-resistant MFA strength allows methods besides passkeys. If the requirement is specifically passkey-only access, use a custom authentication strength permitting Passkeys (FIDO2), with restrictions consistent with the worker profile.

The intended sequence is short. The TAP bootstrap and same-device passkey registration establish the method before application enforcement becomes the worker's gate.

sequenceDiagram
    participant Support as Onboarding support
    participant Worker
    participant Entra
    participant Phone as Phone passkey provider
    Support->>Worker: Verify identity and deliver time-limited TAP
    Worker->>Entra: Open Security info on phone and sign in with TAP
    Entra-->>Phone: Request passkey creation
    Phone->>Worker: Present provider and request local verification
    Phone-->>Entra: Complete credential registration
    Worker->>Entra: Fresh web app sign-in using the passkey
    Entra-->>Worker: Application access after policy checks

The worker-facing instruction should follow that sequence, using the labels in the documented registration flow. It should not ask the worker to choose a security architecture before they can open the application.

On your personal phone:
1. Open the Security info link in your onboarding message.
2. Enter the work username supplied in that message.
3. Sign in using your Temporary Access Pass.
4. Choose Add sign-in method, then Passkey.
5. Continue with the passkey provider offered on this phone.
6. Confirm with your face, fingerprint or device PIN.
7. Name the passkey, finish, then test the web application sign-in.
8. If Passkey is missing or setup cannot finish, contact support.

Test this with a genuinely new account, not just an administrator's already-configured phone. Microsoft documents that some combined MFA or password-reset registration interruptions after TAP sign-in do not support FIDO2 registration. An unrelated registration requirement can therefore derail the carefully written passkey guide.

Register, perform a fresh sign-in using the passkey, verify the application accepts the intended strength, and then enforce for the ready population. Use the documented report-only approach when evaluating registration policy, and keep an established recovery path. A recorded credential is not the same evidence as a successful application journey.

One final distinction: TAP does not replace or delete the account's password. This design avoids distributing a password and using one for this access journey. It does not, by itself, prove that every password-based route in the tenant has been removed.

Bootstrap establishes the credential; enforcement requires it. Keep those stages connected without making either one depend on a method the worker does not yet possess.

Automate the surrounding work, not the user's private key

Can onboarding be automated? Much of the surrounding work can, but installing an application and registering a personal credential are different operations. The supported synced-passkey registration flow still includes the user interacting with the provider on their device.

Microsoft Entra Lifecycle Workflows has a built-in task that generates a TAP and emails it to the new user's manager. That is a concrete automation option, not a claim that a workflow silently creates a synced passkey in the worker's personal provider. The documented task also has prerequisites, including manager and manager-email attributes.

The prehire onboarding tutorial documents the relevant licensing requirements. If that fits the organization's operating model, automate eligibility, timing, manager notification and the supported bootstrap task. Still decide how the manager verifies the recipient and delivers the code without turning a sensitive credential into an indefinitely retained onboarding attachment.

A third-party onboarding product can improve orchestration, guidance or verified delivery. Ask which step it automates and which device-side interaction remains. A claim of "automated passwordless onboarding" is not enough to establish that it removes the user steps in the supported registration flow.

There is a different administrator-led route for hardware. Microsoft documents FIDO2 security-key provisioning through Microsoft Graph and custom clients as a preview capability, including provisioning and registering a physical key for the user. That introduces hardware procurement, handling, distribution and replacement, so it changes this customer's no-additional-hardware scenario rather than automatically solving it.

Recovery deserves the same attention as first registration. With a synced credential, the provider's synchronization and account-access model becomes part of the trust decision. Do not assume that a worker replacing a phone always has the right provider account, settings and recovery access immediately available.

With an Authenticator passkey, do not promise that restoring application backup moves the credential to new hardware. Microsoft explicitly states that Authenticator passkeys are device-bound and cannot be synced. Maintain a verified recovery process for workers who lose access to their existing method.

Nor does phishing-resistant authentication establish the security posture of an unmanaged personal phone. The passkey policy's credential controls and attestation limits are not a device-management programme. Accepting this access model remains a business and security decision about the application and its exposure.

The pilot should therefore measure more than whether a passkey can be created. Record unassisted registration completion, time to a fresh successful application sign-in, support contacts, provider distribution and recovery completion. Compare those outcomes with the existing journey before claiming the customer problem has been solved.

The honest answer to "to passkey or not to passkey" is not a universal instruction to relax every policy. For this population, a broadly compatible passkey profile and same-device synced-passkey journey are the design worth testing first. A corporate population requiring attested, device-bound credentials has a different requirement and can reach a different answer.

Keep the administrative concepts in the control plane and the worker's task on the worker's phone. The useful improvement is not asking workers to understand four authentication methods; it is no longer requiring them to navigate four methods to reach one application.

DEV Community