Entra telephony providers give organizations a supported way to keep SMS or voice authentication when Microsoft retires its native delivery service. September 2026 guidance sets October 30, 2026 as the start of provider configuration; this matters to administrators with users who cannot yet move off telephony. Here is what the change covers, what it costs to operate, and what to verify before choosing that exception.
- Move most users to phishing-resistant authentication.
- Use supported telephony for documented exceptions, not the default.
- Separate policy ownership, Azure routing and message delivery.
- Inventory actual usage before buying a provider contract.
What Entra telephony providers are
Choose Your Own Telephony Provider changes who delivers the authentication text or call. Your selected provider handles delivery; Entra ID continues to enforce authentication method policies and coordinate authentication. This is a delivery integration, not a new authentication strength.
The initial private-preview providers are Soprano and Telesign. You select a supported offer through Microsoft Security Store and manage the commercial relationship. An existing SMS supplier is usable only if it is supported. The provider FAQ allows one provider per channel: one for SMS and one for voice, not an unrestricted pool of carriers.
Our recommendation is to keep this exception population small. First ask why a user needs telephony and whether a supported phishing-resistant method meets the requirement. For the broader credential rollout, use our Entra passkey policy guide; buying a carrier contract should not replace that work.
What changed
- September 1, 2026: automatic passkey enablement and registration nudges began for SMS/voice-enabled users. That does not mean those users completed registration.
- September 23, 2026: the updated provider guidance describes the delivery model and names the initial providers.
- October 30, 2026: configuration is documented to begin. Status: private preview, not confirmed GA. The official pages retrieved for this article still say configuration is not available yet while naming this date. Treat it as a planned start and confirm access in your tenant; do not assume the controls have appeared everywhere.
This is a current planning decision because a provider integration includes procurement, Azure deployment and testing, not just an authentication-method toggle. Separate the availability milestone from the retirement deadline for each population below.
Who is affected
The retirement FAQ limits this timeline to public-cloud environments. Do not copy these dates into a sovereign-cloud change plan without its own announcement.
| Plan or role | Impact | Action |
|---|---|---|
| Workforce users, including internal guests | Native SMS/voice retires February 1, 2027, except the populations below. | Replace the dependency or migrate the documented exception. |
| Global Administrators and external users | Native delivery retires July 1, 2027. | Track separately; do not classify every guest by its user-type label alone. |
| SSPR users | Native SMS/voice retirement includes password reset. | Test reset as well as sign-in. |
| External ID or Azure AD B2C tenants | This announcement does not apply; the provider feature is Entra ID only. | Follow the separate product guidance. |
The population-specific retirement dates are not a reason to postpone administrators’ migration. Also, the FAQ describes B2B and internal-guest passkey support as planned by the end of 2026. Verify support for your actual guest scenario before promising that replacement.

Admin controls
Start at Entra admin center > Entra ID > Authentication methods > Activity. The Registration and Usage tabs distinguish methods registered from methods actually used. As of October 2026, Usage and insights requires Entra ID P1 or P2; Reports Reader is among the roles listed with read access. Capture both views, then identify which users lack a tested replacement.
For the passkey track, the documented control is Entra ID > Authentication methods > Registration campaign, managed by an Authentication Policy Administrator. Follow the migration guidance and verify method-policy eligibility before targeting a campaign. A prompt alone is not proof that a user can authenticate from the device they actually use.
For the telephony track, the FAQ places configuration in the Entra admin center but still promises detailed deployment instructions when released. No deeper menu path is documented in the retrieved guidance. Use the published configuration procedure when it appears rather than adapting a generic SMS webhook or inventing a routing deployment.
As of October 2026, the documented cost categories are provider charges plus standard Azure consumption charges for the routing function. Request rates for your countries, channels and expected usage, including the applicable offer terms. Do not describe this as an included Entra license benefit or quote one global per-message price.
Rollout checklist
Use the documented migration sequence as a readiness gate. The following checklist is our recommended evidence to collect before expanding the exception.
- In Activity, compare registered phone methods with usage. Verify each proposed exception has an owner and a documented requirement.
- In Microsoft Security Store, review the supported offers with procurement. Verify coverage, channel support, privacy terms and support contacts for the pilot locations.
- Using the released Entra procedure, configure the supported integration and Azure routing. Verify the intended users/groups and channel before enabling traffic.
- Use evaluation mode first. Verify successful routing results while users retain their currently active delivery experience.
- Enable a small production pilot. Verify message delivery, completed sign-in and password reset, then expand only after resolving failures.
Keep the pilot outcome separate from unrelated hardening changes. Our legacy-authentication blocking runbook covers a different control; changing client restrictions during the delivery pilot makes failures harder to attribute.
Gotchas
Do not confuse the temporary automatic-enablement opt-out with permission to keep native delivery after retirement. Users whose only available MFA is unmigrated Microsoft-provided SMS/voice face a blocking passkey registration prompt at their applicable deadline. Users migrated to a configured provider avoid that retirement prompt.
Write the support handoff before rollout: Microsoft handles Entra platform and routing issues; your organization manages the provider relationship and delivery issues. A successful routing evaluation is useful evidence, but it is not the same as proving a user received a call and completed authentication.
FAQ
Must every SMS user buy a provider service?
No. Phishing-resistant authentication is the recommended migration. Keep telephony only where the requirement survives review, not because a phone number is already registered.
Does moving the delivery service make SMS phishing-resistant?
No. The security rationale distinguishes SMS/voice from passkeys. The provider changes delivery ownership, not the credential’s resistance to phishing.
Is another existing MFA method being retired too?
This announcement targets native SMS/voice delivery, not every MFA method. The FAQ says TOTP remains supported subject to policy, although it is not phishing-resistant. Check the user’s complete method set rather than assuming every phone registration is their only route.
Inventory the real telephony dependency, move most users to phishing-resistant methods, and use a supported provider only for justified exceptions. Make availability, routing evidence and completed user authentication separate approval gates.
Last reviewed: October 2026
Sources
- Choose a telephony provider for SMS and voice authentication (Microsoft Learn)
- Passkeys by default and SMS/voice retirement timeline (Microsoft Learn)
- Telephony provider availability, costs, evaluation and support FAQ (Microsoft Learn)
- Authentication methods activity reports (Microsoft Learn)
- SMS and voice retirement scope and migration FAQ (Microsoft Learn)
Discover more from Cloud Osprey
Subscribe to get the latest posts sent to your email.