Microsoft makes passkeys the default sign-in experience for affected users on September 1, 2026, and retires Microsoft-provided SMS and voice authentication on February 1, 2027.

Move users off SMS and voice sign-in before Microsoft does it for them.

Microsoft 365 Passkey Migration Sprint

The users still on SMS or voice are identified, the authentication method policy is configured, a pilot ring completes registration, adoption is measured against the affected population, and every exception is recorded with an owner.

Price

Fixed price confirmed before work begins

Delivery window

The fixed proposal contains the delivery calendar and the completion date.

The price is agreed in writing before any work begins and before any access is granted. Nothing is billed for the scoping conversation that sets it. What moves the number:

  • · 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

Done when the affected-user count is zero, or every remaining account holds a recorded exception with an owner, a compensating control, and a review date.

Plan the Passkey Rollout →

No tenant access, credentials, or sensitive files are requested through this website.

One Microsoft 365 tenantClient owns end-user supportHardware keys quoted separately

What happened

Two dates are now fixed. From September 1, 2026 Microsoft begins prompting affected users to register a passkey by default, and from February 1, 2027 Microsoft-provided SMS and voice authentication retires with no opt-out from the February behaviour. Most tenants cannot currently answer the first question either date asks: which people are still on a phone code, and what happens to them on the morning the prompt appears.

Sources: Microsoft Entra: SMS and voice authentication retirement

Nobody can produce the list of users whose only registered sign-in method is a text message or an automated phone call, so the size of the population the September default will reach is a guess. Shared tills, kiosk logins and field staff without a company phone sit somewhere inside that list with no exception path written down, and the authentication methods policy is still in whatever state it was left in.

The observable symptoms

Checkable in your own environment today, before any conversation.

  • 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

What happens if it is left as it is

  • From September 1, 2026 Microsoft's default sign-in experience begins prompting affected users to register a passkey, so the business learns which of its people are affected as those people meet the prompt at their own sign-in.
  • Microsoft-provided text-message and voice-call codes retire on February 1, 2027, so an account whose only registered method is a phone code reaches a sign-in it cannot complete, and restoring access takes an administrator at the moment somebody is trying to work.
  • A shared till, a kiosk login or a member of field staff without a company phone meets the same registration prompt as everyone else, and with no exception path agreed beforehand the decision about what that account registers gets made at the counter by whoever is standing there.
  • A shared or device-less account needs an approved alternative and a compensating control agreed by somebody with the authority to accept it, and that approval is a conversation, not a configuration change, so it takes as long as the people involved take.
  • Self-service password reset that depends on a phone code stops being a route back in for the same accounts on the same date, so the fallback and the primary method fail together rather than one covering the other.

What changes in production

Not findings. These are the things that are different afterwards.

  1. 1The affected population is enumerated from the tenant: every user whose only registered method is SMS or voice, plus the accounts that would be locked into a registration wall.
  2. 2The authentication methods policy is configured for the agreed target methods, with the legacy methods staged for retirement rather than switched off underneath people.
  3. 3A pilot ring registers first, and the defects that only appear with real users — shared devices, kiosk accounts, field staff without a company phone — are found there rather than in the full rollout.
  4. 4Registration 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.
  5. 5Accounts that genuinely cannot hold a passkey get a documented exception with an owner, a compensating control, and a review date.

Definition of done

The engagement ends when all of these are true and demonstrable.

  • 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 compensating control, and a review date

What you provide

Named up front, because these are the things that stall an engagement when nobody owns them.

  • 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

What moves the price

The figure comes from what is actually in the environment. Headcount is one input among several, and rarely the one that matters most.

  • 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

Not included

Stated so the scope means the same thing to both parties on the last day as it did on the first.

  • 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

How change is staged and reversed

Production work carries risk. This is the method, not a reassurance.

  • 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.

Evidence and handover

Yours to keep whatever happens next, including handing it to your own team or another provider. The documents are what prove the work happened; they are not the thing being bought.

  • The affected-user list, as it stood at kickoff and at handover
  • The authentication methods policy, before and after
  • Registration coverage measured against the affected population
  • The exception register, with owners and review dates
  • The communications actually sent, and when

You may not need this engagement

  • The tenant already enforces passkeys or FIDO2 keys and the affected-user count is already zero
  • A current provider owns authentication policy and can already name the affected population, the enforcement date, and the exception path
  • 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 questions a careful buyer should ask

Why would the current MSP or internal team not just do this?

Often they can. Enumerating the affected users and staging the methods policy is standard administrative work. What usually goes missing is the exception design for shared and device-less accounts and a rollout measured against the affected list, because both take dedicated time a bench rarely has. A team that can name its affected population and owns a tested exception path does not need this engagement.

What exactly changes in production?

The authentication methods policy, and nothing else. Target methods are enabled first, legacy methods are retired only after the pilot ring has registered, and every other workload is untouched.

What could expand the scope?

Hardware security keys, guest accounts brought into scope, more rollout rings than the population supports, and shared-device groups larger than the inventory suggested. Each arrives as a written change order before it is worked, or it is not worked.

What access is required?

Read access to authentication methods reporting to build the affected list, and policy write access during agreed change windows. Access is time-limited, protected with MFA, and removed at handover.

How is rollback handled?

The previous policy state is captured before the first change and can be re-applied within one change window. Enforcement dates are set only after the emergency-access accounts are confirmed excluded and alerting.

Is this another report, with the real work quoted afterwards?

It may sound like a consultant will inspect the environment, hand over a document, and then quote a second project. That is not the default here. Where the outcome can be scoped safely from a short working call, the implementation is sold directly, as this page does. Separate paid planning is used only where genuine complexity prevents a responsible fixed price, and where it is used the page says so plainly.

Plan the Passkey Rollout

Describe what is happening, what has to be working differently, and any deadline behind it. A reply comes within one business day with the most direct next step, or a clear answer that AZ Innovations is not the right fit.

Plan the Passkey Rollout →