On 1 February 2027 Microsoft stops delivering SMS and voice codes for Entra ID. Most organisations have given the work a name by now, and the name is usually “the passkey project”.
The name sets the scope. A passkey project ends when users have passkeys. You can finish it on time, report 100 percent, and have an environment that behaves exactly as it did before, because nothing in it requires the passkey that everyone now has.
A passkey is one authentication method. Whether it changes anything depends on five things around it. This article goes through them, because they decide how large the project really is.
LakeForest runs this as an Entra ID project, not as a method rollout. See the passkey offers →
1. What can be registered
The authentication methods policy and the passkey profiles decide which credentials a user is allowed to add: a passkey that syncs through a provider account, one that stays in Microsoft Authenticator, one on a Windows computer, a physical security key.
In many tenants nobody made this decision. When Microsoft moved tenants to passkey profiles in spring 2026, the default profile was built from settings that already existed. Practitioners who inspected their tenants afterwards found that it allowed credential types the organisation had never discussed.
The first question of the project is therefore not “how do we roll out passkeys” but “which passkeys, for which group of people, and who decided that”.
2. What is required
This is the part a passkey project leaves out.
Registering a passkey adds a method to the account. It does not remove the others, and it does not change which of them a sign-in accepts. A user with a passkey can keep signing in with a password and a push notification for years.
What a sign-in requires is decided somewhere else: in Conditional Access, through authentication strength. That is where an organisation says which methods are accepted for which applications and which people.
A tenant where every user has a passkey and no policy asks for one has changed its inventory, not its sign-in. The decision that matters is which authentication strength applies to whom, and from what date.
Three details from Microsoft's documentation show why this belongs in the plan from the first day:
- The built-in strength named Phishing-resistant MFA accepts three kinds of method: a FIDO2 passkey or security key, Windows Hello for Business or another platform credential, and multifactor certificate-based authentication. A push notification in Microsoft Authenticator does not satisfy it.
- Authentication strength is evaluated after the first step of sign-in. Users can still be shown a password prompt. Telling people that passwords are gone is a promise the configuration does not keep on its own.
- A Conditional Access policy that targets the registration of security information can block the very registration you are asking users to do. Since 6 July 2026 such policies also apply when Windows Hello for Business and macOS Platform SSO credentials are set up.
Requiring a method that part of the population cannot yet use locks those people out. Not requiring it at all leaves the project without an effect. The sequence between the two is the actual design work.
3. Where it works
A passkey works where the application and the sign-in flow support it. Not every place your people sign in does.
For hybrid environments Microsoft lists scenarios where signing in with a security key is not supported, among them Remote Desktop, virtual desktops, Citrix, signing in to a server and “Run as”. Outlook and Teams on Android need a broker app on the phone before a passkey can be used there.
None of this is a reason to stop. It is a reason to know, before the rollout, which people work in those places, because each of those groups needs a decision: another credential, another way of working, or a documented exception. Found during the pilot, that is a design task. Found in the last week of January, it is an outage.
4. How people get in, and how they get back
Two moments are not covered by “the user has a passkey”.
The first day. A new employee has no method yet, so cannot prove who they are in order to register one. Entra ID has an answer for this, the Temporary Access Pass, but somebody has to decide who issues it, after which identity check, and what it is allowed to open.
The bad day. A phone is lost, a laptop is replaced, a password expires. In Microsoft's own table of methods, none of the passkey types and neither Windows Hello for Business can be used for self-service password reset. The methods that can are the ones a passkey project sets out to retire, plus a few it rarely plans for.
In a hybrid environment an expired password blocks sign-in with a passkey until the password is reset. If the passkey is the only method the user has left, they cannot reset it themselves. Every such user is a helpdesk call, and the cause was a scope decision made months earlier.
Recovery is not a follow-up item. It is part of the same design as the credential.
5. Who keeps it that way
The project ends. The environment does not.
People join and leave. Devices are replaced. An exclusion added to a policy “for two weeks” during the pilot is still there a year later. A group that was exempt in January is forgotten in June. Removing the old method from an account is a separate decision from adding the new one, and somebody has to own it per group.
An identity configuration that is correct on the day of handover and unowned afterwards drifts back, quietly, one exception at a time.
What changes when you name it correctly
| A passkey project | An Entra ID project | |
|---|---|---|
| Scope | The authentication method | Methods, policies, applications, recovery |
| Finished when | Users have registered | The required method is in use and the old one is handled |
| Conditional Access | Out of scope | Designed and sequenced with the rollout |
| Applications that cannot use it | Found during rollout | Known beforehand, with a decision per group |
| Lost phone, new employee | Helpdesk works it out | A defined path, tested in the pilot |
| After the deadline | Nobody owns it | A named owner and a regular review |
The second column is not a larger budget for the same thing. It is the same deadline with the questions asked in advance.
How we run it
Our three passkey offers follow this shape, and so does what comes after them.
- Assessment We record the current state of authentication in your tenant, not only who still uses SMS: which methods are enabled, registered and actually used, how the methods policy and the passkey profiles are set, which Conditional Access policies and authentication strengths apply, and how self-service password reset is configured.
- Migration Each user group gets a method that fits how it works. We pilot it with real users and agree what “done” means before the rollout starts: the new method is in use and the old methods are handled.
- Guided enrollment We move the users and prove from sign-in data that the new method is in use.
- Managed Entra ID We keep the configuration under control after the project, including the Conditional Access lifecycle. See Managed Entra ID →
The assessment is a picture of what exists. How a new employee is verified and who helps on the bad day stay your organisation's decisions. The assessment shows the configuration those decisions have to work with.
If you only read one section
Ask five questions about your own plan:
- Which passkey types can our users register, and who decided that?
- Which policy will require the new method, for whom, and from what date?
- Which people sign in where a passkey does not work, and what happens to them?
- How does a new employee get a first method, and how does someone with a lost phone get back in?
- Who owns this configuration on 2 February 2027?
If the plan answers only the first, it is a passkey project.
Want to go through the five questions for your tenant? Tell us how many users you have and how they sign in today. In a 30-minute call we go through the five questions with you and tell you where an assessment would start. Request a call →
