Entra Telephony Providers: What Changes for SMS MFA

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.

At a glance
  • 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 roleImpactAction
Workforce users, including internal guestsNative SMS/voice retires February 1, 2027, except the populations below.Replace the dependency or migrate the documented exception.
Global Administrators and external usersNative delivery retires July 1, 2027.Track separately; do not classify every guest by its user-type label alone.
SSPR usersNative SMS/voice retirement includes password reset.Test reset as well as sign-in.
External ID or Azure AD B2C tenantsThis 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.

Three-stage telephony delivery path: Entra ID policies, an Azure routing function, then provider delivery.
Keep policy ownership, Azure routing and provider delivery separate in your support plan.

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

Watch out: A provider does not preserve SMS sign-in as a primary authentication method. That scenario needs a supported replacement, not this delivery exception.

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.

Pro tip: The activity report can lag by up to 36 hours and excludes disabled and soft-deleted users. Recheck the reporting timestamp before treating a missing registration as a failed pilot.

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.

Bottom line

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


Discover more from Cloud Osprey

Subscribe to get the latest posts sent to your email.

Recent Articles

Related Stories