Microsoft Entra Passkey Rollout: An SMB Admin Checklist

Microsoft Entra ID is changing the authentication experience for organizations that still rely on text messages or voice calls. Beginning September 1, 2026, users enabled for SMS or voice will be automatically enabled for passkeys and may be prompted to register one after completing multifactor authentication. On February 1, 2027, Microsoft-provided SMS and voice delivery retires. For an SMB, this is not merely a settings change; it is an identity rollout that needs an owner, a tested recovery path, and evidence that every user can still sign in.

The safest approach is to treat September as the start of a controlled migration and February as the hard dependency deadline. Inventory who is actually using telephony authentication, choose passkey types by user and device scenario, pilot the registration and recovery experience, then drive down SMS and voice reliance while exceptions remain visible. Microsoft confirms that the September automatic enablement affects users enabled through the Authentication Methods Policy or legacy MFA settings, and that the February enforcement has no opt-out. See Microsoft’s retirement timeline and transition guidance.

What changes on September 1, 2026

Microsoft says users enabled for SMS or voice in the Entra Authentication Methods Policy, or in legacy MFA settings, will be placed in scope for passkeys. They will be assigned a passkey profile that allows all passkey types, and Registration Campaign settings will move to a Microsoft-managed state targeting passkeys. When an in-scope user next signs in and completes MFA on an eligible device, the user may be nudged to register a passkey. Microsoft also says the default nudge permits unlimited snoozes, so a prompt alone is not proof of migration.

That distinction matters operationally. Enabled means policy permits a method. Registered means a user has enrolled it. Used means a sign-in event actually relied on it. An admin who reviews only the policy can miss users who still depend on a phone call; an admin who reviews only registration can miss accounts with a passkey that continue using SMS.

On February 1, 2027, Microsoft-provided telecommunications delivery for SMS and voice retires. A user whose only available MFA method is SMS or voice, and whose organization has not configured a supported customer-managed telephony provider, will face a blocking passkey-registration requirement during sign-in. Microsoft states that the February behavior applies to all tenants and cannot be opted out of. The business risk is therefore straightforward: unmanaged exceptions can become account-access incidents.

Step 1: establish tenant scope before changing policy

Start with a dated tenant-scope worksheet. Record the tenant ID, cloud environment, administrators responsible for Authentication Methods and Conditional Access, current registration campaign state, legacy MFA use, relevant licensing, and any managed service provider with delegated access. Then divide the user population into operating groups rather than treating “all users” as one deployment unit.

• Privileged administrators and emergency-access accounts
• Standard office users on managed Windows or macOS devices
• Mobile-first and bring-your-own-device users
• Frontline users, shared-workstation users, and shift-based staff
• Remote employees and contractors
• Guests or external collaborators where tenant policy applies
• Accounts still governed through legacy MFA settings
• Nonhuman or automation accounts that should not depend on interactive user MFA

Export the current Authentication Methods Policy and group assignments before editing them. Microsoft recommends managing methods through the current policy, but a user can remain enabled through more than one policy surface. The authentication-method management guidance explains that Entra evaluates all applicable policies, which is why legacy and modern scope must be reconciled rather than sampled.

Step 2: find active SMS and voice dependence

Build the inventory from three evidence layers:

1. Policy scope: export the groups and users enabled for SMS, voice, and passkeys in Authentication Methods Policy, then document any legacy MFA enablement.
2. Registration state: use Entra Usage & insights or Microsoft Graph’s user registration details report to identify registered methods, passwordless capability, administrator status, and the report’s last-updated time.
3. Actual use: review the Authentication methods activity Usage tab and sign-in-log authentication details for recent SMS and voice events. Microsoft’s Usage & insights documentation separates registration statistics from method usage, while sign-in logs show how a particular authentication attempt was completed.

Keep the evidence window explicit. A 30-day view may be sufficient for daily staff but can miss seasonal workers, traveling executives, quarterly contractors, or an emergency account that should rarely be used. Extend the window where retention permits, and ask business owners to validate dormant-looking accounts before exclusion or disablement. The output should be a named owner and migration path for every active SMS or voice dependency—not a list with unresolved usernames.

Step 3: choose the passkey type by risk and work pattern

Microsoft Entra supports synced and device-bound passkeys. Both are phishing-resistant FIDO2 credentials, but they differ in custody, recovery, attestation, and convenience. Microsoft recommends device-bound approaches for administrators and highly privileged users, while synced passkeys can reduce friction for standard users. The right answer depends on who controls the device and what happens when it is lost.

Do not assume browser support is uniform. Microsoft’s current FIDO2 compatibility matrix lists broad support across current Chrome, Edge, Firefox, and Safari combinations, but it also documents platform-specific limits for native apps, security-key transports, older operating systems, and some administrative tooling. Test the exact device, browser, native application, and sign-in path your users rely on—including remote desktops and privileged PowerShell workflows.

Step 4: design a pilot that can fail safely

Create targeted groups instead of enabling the entire tenant at once. A useful pilot includes IT administrators, help-desk staff, a small set of ordinary users, at least one remote user, and representatives of each important device or work pattern. Keep emergency accounts outside the general campaign; manage and test them under a separate procedure.

For each pilot user, test the full lifecycle:

• Initial sign-in and MFA completion
• Registration-campaign prompt, snooze behavior, and successful registration
• Sign-in through the web browser and required native applications
• Conditional Access behavior for ordinary and sensitive resources
• Device replacement, lost credential, and deleted passkey scenarios
• Remote support and help-desk identity verification
• Offboarding and removal of the user’s registered credential

Use Microsoft’s group-targeted passkey profiles to control allowed passkey types, attestation, and authenticator restrictions. Remember that changing restrictions can make an already registered authenticator unusable. Record the before state, pilot assignment, expected result, observed result, and rollback decision for every policy change.

Step 5: prepare registration and Temporary Access Pass onboarding

A Registration Campaign prompts eligible users after they sign in and complete MFA. Before targeting users, confirm passkeys are enabled for the pilot group, self-service setup is allowed, the chosen passkey profile matches the device strategy, and help-desk coverage is available during the first registration window. Microsoft’s registration-campaign guidance includes a platform matrix for supported prompts; a user who is not nudged may still be able to register through Security info, so test both paths.

Temporary Access Pass is the bootstrap and recovery tool for users who cannot complete registration with an existing strong method. A TAP is a time-limited passcode that can be configured for one use or multiple sign-ins. Microsoft documents it as a supported way to onboard passwordless credentials and recover after a strong authenticator is lost. Enable it only for the required groups, keep its validity narrow, verify the person through an approved process before issuance, deliver it through a controlled channel, and remove or let it expire after registration. Review Microsoft’s Temporary Access Pass configuration and limitations before setting policy values.

Step 6: prepare users and the help desk

User communication should arrive before the prompt. Explain what a passkey is, which device or security key employees should use, what the real Microsoft registration flow looks like, whether personal devices are permitted, and where to call for help. Warn users not to approve an unexpected request or disclose a TAP. Send a short reminder on launch day and a separate escalation to users who still have not registered.

The help desk needs more than a script that says “re-register MFA.” Give support staff:

• A verified caller-identity procedure that resists social engineering
• A decision tree for lost phone, lost security key, damaged device, and unavailable biometric
• Authority boundaries for deleting passkeys, issuing TAPs, and escalating privileged accounts
• Known-good screenshots or Microsoft links for each approved registration path
• A prohibition on asking for passwords, TAP values, biometric data, or security-key PINs
• A ticket template that records the reason, approver, old-method removal, new-method validation, and closure evidence

Shared and frontline environments deserve a named exception register, not a blanket exclusion. Record the device model, sign-in path, business owner, approved method, compensating controls, review date, and retirement plan. If a portable security key is used, manage assignment and spare inventory like any other access credential. If an employee’s phone is used, document ownership, privacy, support, loss, and offboarding expectations.

Step 7: protect emergency access and recovery

Passkey rollout is a dangerous time to discover that the only Global Administrator depends on the same phone platform or Conditional Access path as everyone else. Microsoft recommends at least two cloud-only emergency-access accounts, phishing-resistant authentication that differs from normal administrator methods, separate secure storage, monitoring, and regular validation. Its emergency-access guidance recommends testing at least every 90 days.

Before broad deployment, conduct a supervised recovery drill. Simulate a lost phone or key, verify the user without relying on information an attacker could easily obtain, revoke the missing credential, issue a narrowly scoped TAP where appropriate, register the replacement, test sign-in, and inspect the audit trail. For administrators, require a second authorized person and preserve the evidence. A recovery flow that works only when the original device is present is not a recovery flow.

Step 8: define audit evidence and success measures

Keep a concise rollout evidence package. It should contain:

• Dated exports of Authentication Methods Policy, passkey profiles, Registration Campaign settings, and target groups
• Counts of SMS/voice-enabled, registered, and actively using users, with the data window and report freshness
• Pilot roster, device/browser matrix, test cases, failures, and go/no-go approvals
• TAP policy, issuance records, expiration evidence, and recovery tickets
• Passkey registration and use trends from authentication-method reports
• Sign-in and audit-log evidence for registrations, deletions, failures, and policy changes
• Named exceptions with owners, controls, deadlines, and review dates
• Emergency-account test evidence and alert verification

Measure outcomes, not just registrations. Track the number of users whose only viable MFA method is SMS or voice, actual SMS/voice sign-ins, successful passkey sign-ins, failed registrations, recovery events, help-desk volume, and unresolved exceptions. A high passkey-registration percentage can still hide business risk if the remaining users are the warehouse shift, the managing partner, or the only payroll administrator.

The temporary opt-out is a schedule control, not a strategy

Microsoft documents a temporary opt-out for the September automatic passkey enablement and Registration Campaign rollout. It requires Microsoft Graph permission Policy.​ReadWrite.​AuthenticationMethod and the currently documented optOutSettings.​passkeyDynamicMigration policy setting. Because the documented endpoint is in Microsoft Graph beta and the setting name is easy to misread, verify the current Microsoft instructions immediately before making any change, use least privilege, capture the before/after policy, and obtain an explicit business owner approval.

The boundary is more important than the mechanism: the opt-out only creates time between September 1, 2026 and February 1, 2027. It does not cancel the retirement of Microsoft-provided telephony, and there is no opt-out from the February enforcement. If the tenant must retain SMS or voice for a documented operational or regulatory reason, evaluate Microsoft’s supported customer-managed telephony route separately, with procurement, coverage, privacy, support, and failure testing. Do not let that exception delay phishing-resistant authentication for users who can adopt it.

A practical rollout sequence for an SMB

If September 1 has already passed when you begin, do not assume the rollout is complete. Capture the tenant’s current Microsoft-managed changes, identify who was auto-enabled or nudged, and run the same inventory, pilot, recovery, and exception sequence from the actual state. Automatic configuration is not the same as controlled adoption.

Where ITECS fits

ITECS helps SMBs connect Microsoft 365 security settings to the devices, users, support processes, and business deadlines around them. A controlled passkey project can include tenant discovery, authentication-method inventory, pilot design, Conditional Access coordination, help-desk runbooks, recovery testing, and audit-ready handoff through our Microsoft 365 consulting services. Organizations that need a broader identity and control baseline can also begin with a cybersecurity assessment.

Editorial note: Microsoft’s rollout details can change. This article reflects Microsoft documentation available on August 26, 2026. Verify current Microsoft Entra documentation and your tenant’s Message Center before changing authentication policy. Tenant-specific implementation should be reviewed by a qualified Microsoft 365 or identity administrator.

Primary sources

• Microsoft Learn: Passkeys by default and retirement of Microsoft-provided SMS and voice authentication
• Microsoft Learn: Enable passkeys (FIDO2) in Microsoft Entra ID
• Microsoft Learn: Passkey (FIDO2) authentication compatibility matrix
• Microsoft Learn: Run a registration campaign for passkeys or Microsoft Authenticator
• Microsoft Learn: Configure a Temporary Access Pass
• Microsoft Learn: Manage emergency access administrator accounts