Microsoft Entra ID Passkeys by Default: The Real Operational Impact

On 1 September 2026, Microsoft will begin making passkeys the default authentication experience in Microsoft Entra ID.

Five months later, on 1 February 2027, Microsoft will stop providing native SMS and voice authentication delivery.

This is a sound security decision. SMS and voice remain vulnerable to phishing, social engineering, SIM swapping and interception. Passkeys replace shared secrets with public-key cryptography and are resistant to credential replay and traditional phishing.

But organizations should not treat this as a simple MFA configuration change.

The real impact reaches identity lifecycle management, device strategy, account recovery, privileged access, frontline operations, supplier contracts and business continuity.

What Microsoft is actually changing

Several related changes are being introduced.

First, system-preferred authentication is being expanded. When it is set to Microsoft Managed, Entra ID can present the strongest registered credential for both first-factor and multifactor authentication.

A user who already has a password and a passkey may therefore see the passkey presented before the password. The user can still select another permitted sign-in method.

Second, from 1 September 2026, users enabled for SMS or voice authentication will automatically be enabled for passkeys.

Microsoft states that this includes users enabled through either:

• The Entra Authentication Methods Policy

• Legacy MFA settings

These users will be placed in a passkey profile that allows all passkey types. The Registration Campaign will be set to Microsoft Managed and will target passkey registration.

When an affected user signs in and completes MFA, Entra ID can prompt that user to register a passkey.

By default, users can snooze this prompt an unlimited number of times during the initial transition period.

Third, from 1 February 2027, Microsoft-provided SMS and voice authentication delivery will end.

Users whose only available MFA method is SMS or voice will face a blocking passkey registration requirement before they can continue signing in. Microsoft has stated that there will be no opt-out from this February 2027 enforcement.

Organizations that still require SMS or voice will need to select a third-party telecom provider through the Microsoft Security Store and carry the associated contractual and telecom costs.

Enabled does not mean actively used

This is one of the most important details in the announcement.

Microsoft is initially targeting users who are enabled for SMS or voice. It is not limiting the change to users who actively use those methods.

Many Entra tenants enabled SMS years ago for broad groups, sometimes for the entire workforce, as an emergency fallback. Most users may now sign in with Microsoft Authenticator, but the SMS method remains enabled in policy.

Those users can still fall within the migration scope.

An assessment based only on recent SMS usage could therefore underestimate the actual number of affected accounts.

IT teams should separately establish:

• Who is enabled for SMS or voice

• Who has SMS or voice registered

• Who has actively used it

• Who has no alternative phishing-resistant method

• Who depends on it for a specific operational process

These are different populations and require different actions.

Default does not mean enforced

Enabling passkeys and prompting users to register them does not automatically create a phishing-resistant environment.

If passwords, SMS, voice, TOTP or push notifications remain available, users may still be able to select another sign-in method.

System-preferred authentication improves the default user journey, but it does not necessarily remove weaker alternatives. Registration campaigns drive enrolment, but a prompt is not evidence of adoption.

Organizations that need to enforce phishing-resistant authentication should evaluate Conditional Access authentication strengths.

This makes it possible to require phishing-resistant methods for specific scenarios, such as:

• Privileged administrator access

• Sensitive business applications

• High-risk sign-ins

• Access from unmanaged locations

• Administrative actions inside critical applications

The correct sequence matters.

Removing fallback methods before recovery and device replacement processes are ready can create avoidable lockouts. Leaving them permanently available can undermine the security benefit of the passkey rollout.

Passkey choice is a governance decision

Microsoft Entra ID supports both synced and device-bound passkeys.

Synced passkeys

Synced passkeys can be stored through providers such as:

• Apple iCloud Keychain

• Google Password Manager

• 1Password

• Bitwarden

They offer a convenient user experience because the credential can become available across the user’s devices. They also reduce the cost and operational burden of issuing separate physical authenticators.

However, administrators currently cannot see exactly which devices hold a synchronized copy of a passkey. They also cannot query where the credential has been synchronized.

That limitation matters in BYOD, regulated and privileged-access scenarios.

An organization should explicitly decide whether corporate passkeys may be stored in personal Apple, Google or third-party credential stores.

This decision should not be left to whichever option an employee happens to select during registration.

Device-bound passkeys

Device-bound passkeys remain on one physical device.

Examples include:

• Passkeys in Microsoft Authenticator

• Microsoft Entra passkeys on Windows

• FIDO2 hardware security keys

• Windows Hello for Business

• macOS Platform SSO credentials

Device-bound credentials provide greater control over credential location. Attestation can also provide stronger assurance about the authenticator being used.

The trade-off is operational. Lost devices, replaced phones and missing security keys can generate additional recovery and support work.

Microsoft recommends device-bound passkeys for administrators, highly privileged users and scenarios with strict device-boundary requirements. Synced passkeys are positioned as the more practical option for most standard users.

A single tenant-wide policy is therefore unlikely to be the best design.

Passkey profiles should be based on user persona and risk.

Recovery becomes a critical control

Passkeys make credential phishing significantly harder.

They do not eliminate the need for account recovery.

Users will still:

• Lose phones

• Replace devices

• Forget PINs

• Damage security keys

• Change credential providers

• Become locked out

• Join without an existing strong authentication method

Microsoft positions the Temporary Access Pass, or TAP, as an important bootstrap and recovery mechanism.

A TAP is a time-limited passcode that can allow a user to register a new passwordless authentication method. It can be configured for one-time or multiple use and with a limited validity period.

This makes TAP issuance a high-value security process.

If an attacker can convince the helpdesk to issue a TAP through weak identity verification, the organization may have deployed phishing-resistant authentication while leaving a socially engineerable recovery route behind it.

The recovery process should define:

• Who may issue a TAP

• How the user’s identity is verified

• Whether stronger approval is required for privileged accounts

• How the TAP is securely delivered

• How long it remains valid

• Whether it is limited to one use

• Which audit events trigger an alert

• How compromised or lost credentials are revoked

• How emergency recovery is handled outside business hours

The security risk is not removed. It moves towards identity proofing and recovery governance.

Joiner, mover and leaver processes need to change

Passkeys affect the complete user lifecycle.

Joiners

A new employee needs an approved method for establishing the first trusted credential.

This may involve:

• A Temporary Access Pass

• A preregistered FIDO2 security key

• An existing strong authentication method

• A corporate device prepared with Windows Hello for Business

• A supervised onboarding process for sensitive roles

The organization should also determine which passkey profile applies before registration starts.

Movers

A standard user who moves into an administrator or highly privileged role may need a different credential type.

A synced passkey that was acceptable for normal business access may not meet the policy for privileged administration.

Role changes should therefore trigger a review of authentication methods, not only access rights.

Leavers

Disabling the user account remains the primary access control during offboarding. Active sessions should also be revoked and registered authentication methods reviewed or removed.

This is particularly important because passkeys currently have no automatic expiry in Entra ID.

For synced passkeys, administrators can revoke the credential from the Entra account, but cannot see every device to which the provider may have synchronized a copy. Once the Entra account is disabled or the credential is removed, that copy should no longer grant access, but lifecycle hygiene remains necessary.

Account and UPN changes

Microsoft documents an additional limitation that matters during reorganizations, company renaming and M&A integration.

When a user’s User Principal Name changes, an existing passkey cannot simply be modified to reflect that change. The user must delete the old passkey and register a new one.

For organizations planning domain changes, tenant consolidation or identity migration, passkey re-registration should therefore become part of the migration plan.

Frontline and shared-device scenarios require separate design

Some of the most affected users may be found outside the traditional office environment.

SMS-based sign-in has often been used for frontline workers who:

• Do not have a dedicated corporate laptop

• Share devices across shifts

• Do not have a corporate smartphone

• Need a simple sign-in journey

• Work in locations with restricted connectivity

• Depend on operational applications rather than Microsoft 365 alone

Moving these users to passkeys requires more than sending installation instructions for Microsoft Authenticator.

Microsoft also positions QR-code authentication as an option for certain frontline shared-device scenarios.

For users sharing Windows devices, Microsoft recommends using Microsoft Entra passkeys on Windows or portable credentials rather than treating every shared workstation like a personally assigned device.

The appropriate design depends on the operating environment:

• Who owns the device?

• Is the device shared?

• Can personal phones be used?

• Is Bluetooth permitted?

• Is internet access consistently available?

• Which applications support the intended authentication journey?

• What happens at shift handover?

• Who supports registration outside normal office hours?

These questions need to be answered before broad enforcement.

Shared accounts will become harder to ignore

Many organizations still operate shared user accounts for reception desks, operational teams, suppliers, administration or emergency access.

Passkeys expose the weaknesses of this model.

Attaching multiple credentials to one shared account may be technically possible, but it creates governance problems:

• Weak individual accountability

• Unclear credential ownership

• Difficult offboarding

• Complicated recovery

• Limited auditability

• Greater risk of credentials remaining after someone changes role

The stronger long-term design is usually based on named identities, delegated access and properly governed privileged or emergency accounts.

Service accounts and non-human identities should also remain separated from interactive user authentication. They require workload identity controls, credential rotation and application-specific access design rather than a human passkey rollout.

Emergency access must remain independent

Every Entra tenant should maintain tested emergency access accounts.

Microsoft recommends at least two cloud-only emergency accounts using the tenant’s onmicrosoft.com domain. Passkeys using FIDO2 security keys are the recommended authentication method for these accounts.

Their credentials should not depend on the same devices, identity provider, Conditional Access requirements or network path used by normal administrator accounts.

Emergency credentials should be stored securely in separate locations, monitored for any sign-in and tested regularly.

A passkey migration is a good moment to verify that emergency access still works after policy changes.

The worst time to discover that a break-glass account is unusable is during an identity outage.

Registration campaigns have blind spots

Microsoft’s Registration Campaign can accelerate adoption, but administrators should not assume that every eligible user will see the same prompt.

The passkey nudge is evaluated for each device and browser combination. A user may therefore be prompted on one device while not being prompted on another.

Other documented limitations include:

• Users already signed in through SSO might not see the prompt

• Linux users are not covered by the registration nudge

• B2B guest users cannot register a passkey in the resource tenant

• Conditional Access custom controls can prevent the nudge from appearing

• Terms-of-use screens can interfere with the prompt

• Profiles restricted to synced only or device-bound only do not receive the Microsoft Managed nudge

• Attestation or specific authenticator restrictions require a more deliberate rollout

Organizations should measure registration and actual authentication usage, not the number of users targeted by a campaign.

The Authentication Methods Activity report and Entra sign-in logs should be part of the rollout dashboard.

SMS and voice exceptions become a sourcing decision

Microsoft is not making SMS and voice technically impossible in every scenario.

Organizations with a regulatory, technical or operational requirement will be able to select a telecom provider through the Microsoft Security Store.

But the responsibility changes.

Microsoft plans to publish the provider list, pricing and commercial terms on 18 September 2026. Configuration becomes available from 30 October 2026. Microsoft-provided delivery stops on 1 February 2027.

Organizations retaining SMS or voice may need to complete:

• Provider selection

• Commercial negotiation

• Data protection review

• Regional coverage validation

• Procurement approval

• Technical configuration

• Pilot testing

• Support preparation

• Cost allocation

That is a short implementation window for a large or regulated organization.

SMS and voice exceptions should therefore be limited to documented user segments with a genuine business, regulatory or operational requirement.

A practical preparation sequence

Organizations do not need to wait until September.

A controlled preparation plan should include the following steps.

1. Establish the real population

Inventory users who are enabled, registered and actively using SMS or voice. Identify users with no phishing-resistant alternative.

2. Segment by persona and risk

Separate standard information workers, administrators, executives, developers, frontline workers, contractors, shared-device users, regulated users and emergency accounts.

3. Define the credential model

Decide where synced passkeys are acceptable, where device-bound credentials are required and which authenticators or providers are permitted.

4. Build recovery before enforcement

Define TAP issuance, identity verification, lost-device handling, after-hours support, privileged-user recovery and emergency access.

5. Run targeted pilots

Test each important persona, device platform, browser, application and operating scenario. Do not validate the design only with IT staff using managed Windows laptops.

6. Communicate the actual user journey

Explain what users will see, why the change is happening, which option they should choose and where they can get support.

7. Measure registration and usage

Track who registered a passkey, which type was registered, whether it is being used and which users still depend on weaker methods.

8. Enforce in stages

Use Conditional Access authentication strengths where phishing-resistant authentication is required. Remove obsolete fallback methods only when recovery and operational readiness are proven.

Questions IT leadership should ask now

The relevant executive questions are straightforward:

• How many accounts are currently enabled for SMS or voice?

• How many have no other viable authentication method?

• Are personal passkey providers acceptable for corporate identities?

• Which user groups require device-bound credentials?

• How will frontline and shared-device users authenticate?

• Who can issue a Temporary Access Pass?

• How is identity verified during recovery?

• Are privileged and emergency accounts independently protected?

• Which processes still depend on SMS or voice?

• Are telecom exceptions documented, budgeted and ready for procurement?

• Can we prove adoption through actual sign-in data?

If these questions cannot be answered, the organization is not ready for the transition.

The bottom line

Microsoft has made the direction clear: phishing-resistant authentication is becoming the standard, while SMS and voice are being moved out of the native Entra experience.

That is the right security direction.

But enabling passkeys does not automatically deliver a controlled implementation.

The organizations that treat this as a login-screen change will spend the coming months reacting to prompts, exceptions and support tickets.

The organizations that treat it as an identity lifecycle programme can use the deadline to remove years of accumulated authentication debt.

A passkey rollout is not simply an MFA configuration change.

It is a change to the identity operating model.

Sources and further reading

• Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID

• Passkeys by default and retirement of Microsoft-provided SMS and voice authentication

• System-preferred authentication in Microsoft Entra ID

• Run a Registration Campaign to set up a passkey

• Passkey FAQs for Microsoft Entra ID

• Plan a phishing-resistant passwordless authentication deployment