Passkey rollout in Microsoft 365
Keep everyone signing in after phone codes stop.
The people still signing in with a phone code are found and moved to an approved method. A small group goes first. Take-up is measured against the list, and every exception is written down with an owner.
- What you get
- Configured sign-in policies, an agreed passkey rollout and operating instructions with an owned exception register.
- How it starts
- A free scope call. The price is fixed in writing before anyone is given access.
- When it is done
- The agreed pilot sign-in tests pass, registration is measured against the rollout list, and remaining exceptions have a safeguard, owner and review date.
Illustrative sample · constructed example
Registration and a usable sign-in are separate checks.
Pilot cohorts · employee and shared device
Selected check
Can the shared-device group complete the intended sign-in?
Pilot cohorts · employee and shared device
Hold that cohort. Results apply to the named sample checks below.
| Test case | Expected behavior | Sample review |
|---|---|---|
| Employee laptop | Register and complete the supported sign-in. | Registration recorded |
| Shared front desk | Test the agreed device and account model. | Method untested |
| Recovery | Confirm how the affected user regains access. | Separate recovery check |
| Exception owner | Retain the owner and review date for the shared-device case. | Owner needed |
Registration, successful sign-in and recovery remain separate acceptance checks.
- Evidence
- Employee pilot registers; shared-device method has not been tested.
- Decision
- Hold that cohort
- Next action
- Assign the shared-device exception to an owner; agree the method and safeguard.
Illustrative sample. A registration report alone does not establish lockout or successful sign-in.
Open the complete illustrative document to inspect its fields and print a copy.
Open the sample documentWhy now
The work starts here.
Microsoft began enabling passkeys and registration prompts for SMS/voice-enabled users from September 1, 2026. Microsoft-provided SMS and voice delivery retires on February 1, 2027 for most users, including internal guests. Global Administrators and external users follow on July 1, 2027.
Related source documentation
Microsoft Entra: SMS and voice retirement · checked September 19, 2026Scope at a glance
- One Microsoft 365 tenant
- Client owns end-user support
- Hardware keys quoted separately
If nobody acts
What waiting costs
From September 1, 2026 Microsoft starts prompting affected people to register a passkey. So the business finds out who is affected as each person meets the prompt at their own sign-in, one at a time.
Microsoft stops providing text and phone-call codes for most users on February 1, 2027; Global Administrators and external users follow on July 1, 2027. An account with only a phone code then reaches a sign-in it cannot finish. Getting that person working again needs an administrator, at the moment they are trying to work.
A shared till, a kiosk login, or field staff with no company phone meets the same prompt as everyone else. With no exception agreed beforehand, what that account registers gets decided at the counter, by whoever is standing there.
A shared account, or one on a device that cannot hold a passkey, needs another way in and a second safeguard around it. Someone with authority has to accept that. It is a conversation rather than a setting, so it takes as long as the people involved take.
Password-reset methods and dependencies need their own checks so the recovery route remains usable when sign-in methods change.
Check your own environment
Sounds like you?
- Nobody can produce the list of users whose only sign-in method is a text or a phone call
- The authentication methods policy has not been reviewed since it was first configured
- Shared tills, kiosks, or field staff sign in with codes sent to one person’s phone
- Self-service password reset falls back to the same phone number that signs people in
- No written exception path exists for accounts that cannot hold a passkey
Save yourself the call
Not for you if
- The tenant already enforces passkeys or FIDO2 keys and the affected-user count is already zero
- A current provider owns sign-in policy and can already name who is affected, the deadline, and what happens to the exceptions
- Only a handful of users are affected and internal IT can walk each one through registration individually
- The requirement is help-desk registration support on rollout day, which stays with the client in this engagement
The work
What is different when we hand over
AZ combines registration and usage reports with policy and device checks to build an affected-user list. Registration data alone does not prove that a user will be locked out. The agreed list becomes the rollout checklist.
The sign-in settings are set to the methods you agreed. The old ones are phased out on a schedule, not switched off underneath people.
A small test group goes first. The problems that only show up with real people, such as shared devices, front-desk accounts and field staff with no company phone, are found there, not in the full rollout.
Registration is driven through the agreed communications and measured against the affected list until the remaining gap is a named set of people, not a percentage.
Accounts that genuinely cannot hold a passkey get a written exception, with an owner, a second safeguard in place of the missing one, and a date to look at it again.
Acceptance
Checks before handover
Done when nobody is left on a phone code, or every account still on one has a written exception with an owner, a second safeguard, and a review date.
The affected-user list is produced from the tenant and agreed as the denominator
The authentication methods policy is in its approved enforcement state
The pilot ring has completed registration and its defects are closed
Registration is measured against the affected list, with the remaining gap named person by person
Every exception carries an owner, a reason, a second safeguard, and a date to review it
A fair question
Can we not just tell everyone to install the Authenticator app?
You can, and for some people that is the whole fix. It stops working as a plan at the point where you have to prove it. Nobody can currently say which accounts are still phone-only, whether an announcement reached them, or what happens to the ones who ignored it. That list, and the check that it reached zero before the deadline, is the work here.
Price and calendar
Scope, price and project calendar
Engagement price
Price fixed after a short scope call.
The price is agreed in writing before any work starts and before anyone is given access. The call itself costs nothing. What moves the number:
What determines the scope
- How many users are still registered on SMS or voice
- Number of pilot and rollout rings
- Whether hardware security keys are procured and enrolled as part of the work
- Whether external and B2B guest accounts are in scope
- Number of shared, kiosk, or device-less accounts needing an exception path
Delivery calendar
Microsoft-provided SMS and voice retire on February 1, 2027 for most users; Global Administrators and external users follow on July 1, 2027. The project calendar is agreed separately before work starts.
How engagements workScope & responsibilities
What is and is not included
The exclusions, what we need from you, how change is staged and reversed, and what is handed over at the end.
Exclusions
- Hardware security key purchase
- Help desk and end-user registration support
- Third-party MFA or identity-provider migration
- Broad Conditional Access redesign: that is MFA & Conditional Access Hardening
- Any guarantee about Microsoft’s own timelines, which are Microsoft’s to change
What we need from you
- Distribute the registration communications
- Own the help desk and end-user support through the rollout
- Approve the pilot ring and the enforcement date
- Procure hardware security keys where the design calls for them
- Nominate an owner for every exception that stays open
Change and rollback method
- The methods policy is staged: target methods enabled first, legacy methods retired only after the pilot ring is registered.
- Rollback is the previous policy state, captured before the first change and re-appliable within one change window.
- Emergency-access accounts are confirmed excluded and alerting before any enforcement date is set.
What you keep at handover
- A System guide: the configuration as delivered, the checks that were run and the unresolved list
- The affected-user list, as it stood at kickoff and at handover
- The authentication methods policy, before and after
- Take-up measured against the list of people affected
- The exception register, with owners and review dates
- The communications actually sent, and when
Access, acceptance and support arrangements
How you know the work is good
Judge it by what you can inspect.
The method is written down, the sample records open and the demo can be broken on purpose. Read it the way your technical owner would.
- 01How a project runs
A first conversation, free. An agreed scope with a named technical lead in the proposal. The price fixed in writing before we are given access. Checks before handover.
How we work- 02What is checked
Release checks, access test matrices and ownership maps. Constructed inspection records on the service pages show the standard before you buy.
See sample deliverables- 03What you keep
A System guide: what was agreed, what changed, what was tested and what remains open. With it, the scripts and check results behind the work.
Next step
Start with a free scope call.
Tell us what needs to change, what must keep working and the deadline. The call is free, and the price is fixed in writing before anyone is given access.
Price the passkey rolloutOr write to [email protected]