Entra ID's February 2027 Sign-In Block: A Dated Migration Plan for the Accounts That Will Break

The date that matters in Microsoft's Entra ID authentication overhaul is 1 February 2027. On that day Microsoft-provided telecom delivery for SMS and voice stops. Any user whose only registered MFA method is a text message or a phone call gets a passkey registration prompt at sign-in that they cannot dismiss.

Microsoft's documentation is unusually direct about the consequences. There is, it says, "no opt out from this February 1 behavior", and the requirement applies to every tenant. The temporary opt-out that exists today expires on the same date.

Three other deadlines sit between now and then. The nearest has nothing to do with SMS, and lands this month.

The published timeline

These dates come from Microsoft Learn and the Microsoft 365 message centre. Treat them as the planning spine.

The nearest cliff is custom controls, not SMS

Custom controls have always been a preview capability. From 30 September you cannot create a new one or edit an existing one; Microsoft's Entra blog puts end of life in May 2027, while the Learn article on custom controls says only "early 2027". Take the earlier of the two when you plan.

If you front Duo, RSA, Okta or Ping through a custom control, the destination is External MFA. Configure the provider as an external authentication method, then switch the affected policies to the standard require-MFA grant control and delete the custom control references.

There is a compliance reason to move faster than the date implies. Custom controls never satisfied MFA claim requirements, sign-in frequency, PIM role elevation, SSPR, Intune enrolment or device join. Microsoft states plainly that the legacy custom controls preview does not satisfy the mandatory Azure MFA requirement. If that is how you have been meeting it, you are not meeting it.

October removes an excuse, and adds a trap

Per message centre item MC1450134, Windows Hello for Business and macOS Platform SSO become complete MFA methods in their own right from early October, completing by late November. They will satisfy step-up prompts, Authentication Strength policies and sign-in frequency challenges without a separately registered passkey, and will appear in My Security Info as auto-registered passkeys. No admin configuration is required.

The trap is that both are device-bound. A user whose only credential is Windows Hello on their laptop cannot complete MFA from any other machine. Microsoft's own guidance in the same notice is to keep at least one portable method in play.

The population that actually breaks

The general workforce is not the hard part. A registration campaign and three rounds of comms will move most of them.

The February block does not fall evenly. It lands hardest on the accounts your identity inventory is worst at describing — the ones with no human attached, and the humans with no device.

User accounts doing service account work

Workload identities — managed identities and service principals — are out of scope for Azure's mandatory MFA enforcement. A user object running a scheduled task is not. Microsoft publishes a PowerShell analyser (the entra-sms-voice-usage-analyzer repository) that lists users still enabled for SMS or voice; you need global reader, authentication policy administrator or security reader to run it. Anything it returns that has a mobile number registered and a cron job behind it is a February outage waiting to happen. Migrate those to a managed identity or service principal. You can reclaim the user licence and apply a workload identities licence to keep Conditional Access coverage.

Break-glass accounts

They are not exempt. Microsoft's mandatory MFA guidance is explicit that emergency access accounts must complete MFA, and recommends passkey (FIDO2) or certificate-based authentication because both satisfy the requirement. If your break-glass accounts still list a phone number as the fallback, that fallback disappears. Two hardware keys, held in separate physical locations, bound to two separate accounts. Test the sign-in now, not in a crisis.

Shared mailboxes and shared devices

Shared mailbox accounts are supposed to be sign-in blocked. Plenty are not. Any shared mailbox account that can interactively sign in and has SMS registered is in scope. Query for enabled accounts with no assigned licence owner and fix the sign-in block rather than registering a credential.

Shared terminals are genuinely harder, because device-bound passkeys assume one user to one device. Per-person FIDO2 security keys are the cleanest answer where the budget exists. A passkey in Microsoft Authenticator works where staff have phones. Where neither applies, that segment is what the Security Store telecom route exists for.

Staff who cannot carry a phone

Ward staff, factory floors, secure facilities, and users with accessibility needs that make a handset impractical. For most of these a FIDO2 key on a lanyard is cheaper and faster than arguing the case. Document the ones where it genuinely is not workable, because that documentation is what justifies the paid telecom fallback.

Working backwards from February

1. This week. Run the analyser and get a number. Check whether your Registration Campaign was switched to Microsoft Managed on 1 September. If it was and your comms are not ready, set passkeyDynamicMigration to true on the authentication methods policy via Microsoft Graph beta — you need Policy.ReadWrite.AuthenticationMethod. This controls timing only; it expires on 1 February regardless.
2. Before 30 September. Inventory every Conditional Access policy referencing a custom control. Stand up External MFA, cut the policies over, validate, then delete the controls.
3. Early October. Review custom Authentication Strength policies before Windows Hello and Platform SSO start satisfying them. Decide whether you want a mandatory portable backup method and write it into onboarding.
4. By 30 October. If you have a documented telecom need, contract the provider and pilot it. Pricing is per-message and varies by provider and region.
5. November and December. Pilot passkeys with the awkward populations first, not last. Build the helpdesk recovery path around a Temporary Access Pass with identity verification, single use, short expiry, immediate re-registration.
6. January 2027. Re-run the analyser. A non-zero result is a list of people who will be locked at the door on the first of the month.

Scope gaps worth checking before you scale

The timeline applies to public cloud only; other clouds follow later. Azure AD B2C is out of scope entirely, and Microsoft Entra External ID gets a separate announcement next year. Passkey migration itself carries no additional cost.

The gap to watch is B2B. Guest and internal guest users are in scope for the retirement, but Microsoft says passkey support for them is only planned to arrive by the end of calendar year 2026. If your tenant leans heavily on external collaborators, that leaves roughly a month between the capability landing and the block going live. Count your guests now and decide whether you are comfortable with that margin.