How to roll out passkeys without locking users out

Microsoft says passkeys are becoming the default sign-in experience in Entra ID, and Microsoft-provided SMS and voice authentication are being phased out on a fixed schedule. That does not mean every business must switch everything overnight. It does mean the old “we will deal with it later” approach becomes riskier as the dates get closer.

For a small business without a dedicated security team, the real issue is continuity. If staff, contractors or external users still depend on SMS or voice, they may only discover the change when they try to log in. Microsoft’s FAQ says that if SMS or voice is the only available MFA method, users will be prompted to register a passkey during sign-in before they can continue, and that prompt is blocking if no other path exists.

Before you announce anything, work out who actually uses SMS or voice. Microsoft recommends targeting communication to the security group of SMS and voice users so the right people get the right message. That is good advice because not everyone needs the same timing or level of support.

The key point is that access changes should follow actual usage, not org chart assumptions. A founder or operations lead can usually get enough clarity from a simple list: who uses SMS, who uses voice, who already has another MFA method, and who would struggle most if their login method changed.

1. 1

   Enable passkey support first

   Microsoft advises ensuring Passkey (FIDO2) is enabled and included in the authentication methods policy before you run a registration campaign. In plain English: make sure the new path exists before asking people to use it.

2. 2

   Map your exception groups

   Identify the people who genuinely need a fallback route. That might be because of device constraints, travel, shared equipment, or a temporary transition period. Keep this list small and reviewed.

3. 3

   Communicate before the deadline

   Tell users what is changing, why it matters and what they need to do next. Keep the message simple. Avoid security jargon unless the audience needs it.

4. 4

   Run a registration window

   Give users time to enrol the passkey while SMS or voice still works for sign-in. That reduces pressure and support load.

5. 5

   Test recovery before broad enforcement

   Do not assume recovery works because it is documented. Walk through a realistic reset or device-loss scenario and confirm who can help, how long it takes and what evidence is required.

6. 6

   Review support tickets after launch

   If many users get stuck at the same step, the problem is usually in the instructions, sequencing or exception handling—not in passkeys themselves.

A good migration is not the same as removing every alternative. Microsoft says organisations with a legitimate business, regulatory or technical need can continue SMS or voice by configuring a telephony provider through Microsoft Security Store. That matters because some businesses will need a temporary bridge, not an abrupt cut-off.

A fallback is useful when it is deliberate. It becomes a liability when nobody can explain who is allowed to use it or how long it is meant to remain.

Most access problems become support problems when recovery is unclear. If a user loses their phone, changes device, or never completed enrolment properly, someone has to decide what happens next. That decision should already be written down.

0 of 6 complete

• Sending a single company-wide announcement and assuming everyone understands what to do.
• Switching on enforcement before passkey enrolment is actually possible for the users who need it.
• Using the same message for administrators, casual users and external users.
• Leaving the helpdesk without a recovery script.
• Treating the migration as a technical change only, when it is really an access and support change as well.

These mistakes are avoidable because they are mostly planning failures. The technology may be new, but the operational pattern is familiar: when people do not know what happens next, they contact support or keep trying the old path.

If your Microsoft 365 environment is small and straightforward, you may be able to handle the transition with internal admin time and careful testing. Specialist help becomes more useful when you have mixed user groups, unusual access policies, external users, or no clear owner for identity and recovery.

This is also where a broader security review can help. Passkeys work best when they sit inside a sensible identity setup: clear admin roles, documented recovery, least-privilege access and a support process that does not break during busy periods. If you need help shaping that rollout, a short security review can be more useful than a long policy document nobody reads.

If you do those five things, you will have a much better chance of moving to passkeys without unnecessary lockouts. The point is not to make login perfect. It is to make the change understandable, supported and recoverable for the people who actually use it.