Passkeys are about to become the default in Entra ID. Here's what that actually means for your tenant.
On 13 July, Microsoft confirmed the biggest change to Entra ID authentication in years. From 1 September 2026, passkeys become the default authentication experience. From 1 February 2027, Microsoft stops delivering SMS and voice codes altogether.
Most coverage has framed this as a deadline. It is worth separating out what is actually happening, because there are two distinct changes and they affect organisations differently.
The two changes
1 September 2026. As the rollout reaches your tenant, any user enabled for SMS or voice is automatically enabled for passkeys and nudged to register one at their next MFA sign-in. Read that wording carefully. Enabled for, not reliant on. A user whose primary method is the Authenticator app, with a phone number sitting behind it as a backup, is in scope. In most tenants that is a considerably larger group than the people who genuinely have nothing but a phone number.
The nudge itself is not blocking in September. Users can snooze it indefinitely. There is also a tenant-level change worth knowing about: your Registration Campaign is set to Microsoft Managed state targeting passkeys, and pulls those users in automatically. If you have a campaign configured for something else today, check it.
1 February 2027. Microsoft retires its own telecom delivery for SMS and voice. The methods do not disappear entirely, but if you want to keep them you will need to bring your own telecom provider through the Microsoft Security Store, configurable from 30 October 2026, and paid for per message.
Otherwise, users whose only method is a phone number get a blocking registration prompt. There is no opt-out from the February behaviour.
A temporary opt-out covers the September to February window, which gives teams room to plan. It does not extend the final date.
Who is unaffected
Users already on FIDO2 security keys, Windows Hello for Business or another phishing-resistant method carry on as they are. No prompt, no change, no migration work. Everyone else splits into two groups, and the distinction matters:
Enabled for SMS or voice alongside other methods. These users get the September nudge but face no hard deadline. They can snooze it, and February's enforcement does not apply to them because they have another method to fall back on.
SMS or voice as their only method. This is the migration backlog. On 1 February they hit a blocking registration prompt and cannot sign in until they have registered a passkey. There is no opt-out from that behaviour, for any tenant.
The second group is rarely spread evenly across a business. It concentrates on shop floors, in warehouses, on wards, in contact centres and among field teams, the places where a personal phone was never a comfortable answer in the first place.
The detail most people have missed
When Microsoft auto-enables passkeys on 1 September, affected users are placed in a passkey profile that permits all passkey types. That includes synced passkeys held in iCloud Keychain or Google Password Manager, alongside device-bound options.
For many organisations that is perfectly acceptable. For others it will be a meaningful shift in where corporate credentials live, arrived at by default rather than by decision.
If your authentication methods policy has not been reviewed recently, review it before September. The choice of which passkey types you permit is yours, and it is easier to make deliberately now than to unwind later.
Where the awkward cases sit
Passkeys work well when a user has a single assigned device they carry. The transition gets harder in three situations:
- Shared workstations. A device-bound credential on a shared PC does not belong to anyone in particular. Platform authenticators tie the credential to the machine rather than the person, which is the opposite of what an auditor wants to see.
- No phone available. Phones are banned on the floor in a good number of regulated, retail and manufacturing environments. A phone-based passkey is not an option there, and neither was SMS.
- Cross-platform estates. Users moving between Windows, macOS, iPads and thin clients need a credential that travels with them rather than one tied to a single operating system.
In these cases a portable hardware authenticator is usually the cleaner answer. The credential belongs to the person, works across any FIDO2-enabled platform, and functions on machines that are offline or locked down.
A practical sequence before September
- Identify who is enabled for SMS or voice. (Microsoft publishes a PowerShell script for this.) Include self-service password reset flows, which are in scope.
- Separate the phone-only users from those who merely have a phone registered. The first group faces the February hard cutoff.
- Review your authentication methods policy and decide which passkey types you want permitted. Check your Registration Campaign settings while you are there.
- Decide on how phoneless users and shared-device users will authenticate, because they will not be solved by the same approach as everyone else.
- Move deliberately rather than waiting for the automatic prompt to set your schedule.
Where Misco can help
For customers reaching step four, Misco supplies AuthenTrend ATKeys, biometric FIDO2 security keys in USB, credit-card and badge formats.
The fingerprint is enrolled directly on the device itself, with no companion app or endpoint agent involved, which keeps the rollout out of your software deployment pipeline. The credential never leaves the hardware. The card and badge formats also carry an NFC tag, so on sites already running UID-based access control the same item can serve as a building credential.
Biometrics is the focal point of what AuthenTrend does. Every key in the range carries a fingerprint sensor, and that changes the day-to-day experience in ways that matter more than the spec sheet suggests.
A hardware key that authenticates on a PIN still asks the user to remember something and type it in, at every sign-in. A fingerprint replaces that with a touch. Nothing to recall, nothing to mistype, nothing to be shoulder-surfed, and no help-desk call when it is forgotten.
It also settles the shared-workstation problem cleanly. The fingerprint is matched on the key itself, so the person authenticating is demonstrably the person the key was issued to. A PIN can be passed to a colleague at the end of a shift. A fingerprint cannot.
The keys work with Entra ID, Microsoft 365, Windows Hello for Business, Okta, Google Workspace and any FIDO2-compliant service.
Trial units are available. Speak to your Misco account manager to find out more.