Retragerea autentificării Microsoft Entra prin SMS și apel vocal: ce trebuie să facă administratorii acum

1 februarie 2027 este data dură care contează: livrarea prin SMS și apel vocal oferită de Microsoft în Microsoft Entra ID dispare, iar pentru acea dată nu există opt-out. Dacă încă aveți utilizatori pentru care singura variantă MFA funcțională este un mesaj text sau un apel telefonic, asta nu mai este o curățenie de făcut cândva, ci un proiect de migrare de identitate.

Articolul sursă merge în direcția corectă, iar ghidarea oficială Microsoft face miza și mai clară. Din 1 septembrie 2026, Passkeys devin experiența implicită pentru utilizatorii activați pentru SMS sau voice. Microsoft va activa automat Passkeys pentru acești utilizatori în Authentication Methods Policy, iar registration campaign va trece pentru ei în modul Microsoft-managed. Din acel moment, utilizatorii vor primi prompturi să își înregistreze un passkey când finalizează MFA. Implicit, aceste amânări sunt nelimitate.

Detaliul ăsta contează. Un prompt pe care îl poți amâna la nesfârșit nu este un plan de migrare. Dacă vreți să terminați înainte de deadline, vă trebuie un rollout real: identificați utilizatorii afectați, segmentați-i, comunicați din timp și decideți ce populații chiar au nevoie de fallback telecom.

Ce se retrage de fapt?

Microsoft nu interzice SMS sau voice ca metode în sine. Retrage livrarea telecom oferită de Microsoft pentru aceste metode în Entra ID. Dacă încă aveți nevoie de ele din motive de reglementare, operaționale sau regionale, Microsoft spune că veți putea configura un provider telecom administrat de client prin Microsoft Security Store.

Timeline-ul Microsoft este destul de clar:

Există un opt-out temporar pentru perioada de tranziție dintre septembrie și februarie, dar nu și pentru aplicarea din 1 februarie. După acea dată, dacă un utilizator are disponibil doar SMS sau voice și nu ați configurat un provider, Microsoft spune că promptul de înregistrare Passkey devine blocant.

De ce este decizia corectă

Din perspectivă de securitate, schimbarea este întârziată, nu grăbită. SMS și voice sunt ușor de phish-uit și mai slabe decât Passkeys, Windows Hello for Business sau alte metode rezistente la phishing. Pentru echipele de identitate, Microsoft forțează practic mutarea pe care multe organizații trebuiau deja să o facă.

Aici sunt de acord cu ei.

Partea mai complicată este operațională. Unii utilizatori încă depind de telefonie fiindcă nu vor autentificare de muncă pe telefonul personal, nu au acoperire bună pe dispozitive sau sunt în roluri marginale pentru care nimeni nu a proiectat corect experiența. Acei utilizatori nu dispar doar pentru că în roadmap scrie că Passkeys sunt mai bune. Dacă aveți medii frontline, shared-device sau mulți contractori, verificați acum dacă planul vostru chiar este un plan de Passkeys sau doar optimism.

Dacă aveți nevoie de ajutor pentru migrare, exact aici intră bine un audit de AI și automatizare sau un workstream țintit pentru Microsoft Copilot și agenți AI, mai ales pentru comunicare, reducerea încărcării pe service desk și designul fluxurilor pentru utilizatori. Pentru partea de raportare și remediere în tenant, se potrivește foarte bine și cu automatizare PowerShell și Azure.

Cum găsești utilizatorii care încă se bazează pe metode prin telefon

Cel mai util pas practic este să auditezi tenantul acum.

În Entra admin center, mergi la Authentication methods și apoi la User registration details. Filtrează după metode înregistrate precum mobile phone, office phone și alternate phone.

Pentru raportare repetabilă, PowerShell este mai bun. Microsoft documentează raportul user registration details, inclusiv câmpuri precum methodsRegistered, systemPreferredAuthenticationMethods și metoda MFA preferată a utilizatorului. Un export simplu prin Graph arată așa:

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All"

$uri = "https://graph.microsoft.com/beta/reports/authenticationMethods/userRegistrationDetails"
$results = @()

do {
    $response = Invoke-MgGraphRequest -Method GET -Uri $uri
    $json = $response | ConvertFrom-Json
    $results += $json.value
    $uri = $json.'@odata.nextLink'
} while ($uri)

$phoneUsers = $results | Where-Object {
    $_.methodsRegistered -contains "mobilePhone" -or
    $_.methodsRegistered -contains "officePhone"
}

$phoneUsers |
    Select-Object userPrincipalName,userDisplayName,methodsRegistered,systemPreferredAuthenticationMethods,userPreferredMethodForSecondaryAuthentication |
    Export-Csv .\entra-phone-auth-users.csv -NoTypeInformation

Dacă vrei privilegii minime, Microsoft listează roluri de tip reader precum Reports Reader, Security Reader, Security Administrator și Global Reader pentru raportul de registration details. Nu da acces administrativ larg pentru un exercițiu de raportare când un rol reader este suficient.

Ce aș face eu

În primul rând, aș înceta să mai tratez MFA prin SMS ca pe un fallback inofensiv. În al doilea rând, aș identifica utilizatorii care au metode de telefon înregistrate și i-aș împărți în trei grupuri: migrări simple la Passkeys, utilizatori care pot trece la altă metodă rezistentă la phishing și excepțiile cu adevărat dificile.

Pentru majoritatea organizațiilor, calea inteligentă este să scoată utilizatorii complet din telefonie. Suportul telecom de la terți este util pentru cazuri restrânse, dar prețurile vor varia în funcție de provider și regiune, iar serviciile taxate per mesaj au obiceiul să transforme grupurile de excepție neglijate în costuri permanente. Dacă poți evita să construiești o dependență pe termen lung de SMS plătit, fă asta.

Concluzia mea practică: auditează acum, pilotează Passkeys din timp și păstrează telecom doar pentru utilizatorii care chiar îl pot justifica.