Schimbarea din Microsoft Entra ID SSPR de la 7 septembrie 2026 este simplă, dar importantă operațional: verificarea pentru resetarea parolei va accepta doar registered authentication methods explicite. Dacă încă te bazezi pe numere de telefon sau adrese de email păstrate în atribute de director, asta nu va mai funcționa.
Este o schimbare corectă din punct de vedere al securității. Un flux de recovery ar trebui să folosească metode validate de utilizator, nu orice există în mobilePhone, businessPhone sau otherMails. Dar impactul pentru administrare este real: utilizatorii care nu au suficiente metode înregistrate la momentul enforcement nu își vor putea reseta parola și vor ajunge la helpdesk.
Ce se schimbă în SSPR?
Astăzi, SSPR poate permite utilizatorilor să își verifice identitatea folosind informații de contact stocate în atributele de director, chiar dacă acele date nu au fost niciodată înregistrate explicit ca authentication methods. Microsoft elimină acest comportament.
Din 7 septembrie 2026:
- Doar registered authentication methods explicite vor fi acceptate pentru verificarea SSPR.
- Informațiile de contact din director nu vor mai conta dacă nu au fost înregistrate.
- Utilizatorii fără suficiente metode înregistrate nu vor putea finaliza resetarea parolei.
- Acești utilizatori vor fi invitați să își înregistreze metodele sau să contacteze un administrator.
Microsoft spune că aproximativ 86% din verificările SSPR folosesc deja registered methods astăzi. Sună liniștitor, dar exact în diferența rămasă apare durerea: cazuri speciale, procese de onboarding vechi, utilizatori pe dispozitive shared, frontline workers, contractori și admini care au presupus că datele din director sunt suficiente.
Când începe enforcement?
Rollout-ul este etapizat:
- 6 august 2026: campania de înregistrare SSPR începe să îi invite pe utilizatori și administratori să își înregistreze metodele dacă nu au suficiente.
- 7 septembrie 2026: începe enforcement.
- General Availability pentru Worldwide, GCC și GCC High rulează de la începutul lui septembrie 2026 până la mijlocul lui septembrie 2026.
Schimbarea se aplică tuturor utilizatorilor, inclusiv administratorilor, din tenant-urile cu SSPR activat. Afectează Public cloud și US Government clouds, inclusiv GCC, GCC High și DoD.
De ce este o schimbare bună și unde este riscul
Din perspectiva securității, este greu de contestat. O cale de recovery pentru identitate este o cale privilegiată. Faptul că atribute de director neînregistrate erau tratate ca dovadă acceptabilă a fost mereu mai slab decât ar fi trebuit.
Problema mai mare este de guvernanță. Multe organizații vor descoperi că nu au construit niciodată un proces de înregistrare solid pentru că vechiul comportament acoperea discret lipsa. Acesta este efectul de ordinul doi: ceea ce părea doar un setting de identitate devine o problemă de service desk, onboarding și accountability.
Pentru majoritatea tenant-urilor, este posibil să nu existe o întrerupere majoră. Dar dacă ai procese de joiner prea relaxate, ai sărit peste enforcement pentru registration sau ai oferit excepții largi pentru admini, verifică acum. Un agent, un workflow sau un proces de administrare nu ar trebui să primească cec în alb în tenant, iar metodele de recovery nu ar trebui tratate ca simple date de profil. Este exact zona de control care merită revizuită într-un audit de AI și automatizare.
Ce ar trebui să facă administratorii acum?
Începe cu acoperirea, nu cu mesajele către utilizatori.
Intră în Microsoft Entra admin center, apoi Authentication methods, apoi User registration details. Verifică dacă utilizatorii, inclusiv administratorii, au cel puțin o authentication method înregistrată care satisface politica ta de SSPR.
Apoi:
- Permite sau activează campania de înregistrare SSPR.
- Planifică fallback pentru utilizatorii care nu se pot autoînregistra.
- Pregătește procese de helpdesk-assisted registration.
- Comunică utilizatorilor că ar trebui să se înregistreze prin My Security Info.
Dacă automatizezi onboarding sau operațiuni de identitate cu PowerShell, Azure Functions, Logic Apps, ServiceNow sau n8n automation, acesta este tipul de dependență pe care trebuie să îl mapezi explicit. Schimbările silențioase de platformă sunt gestionabile când procesul este explicit; devin dureroase când te bazezi pe comportament moștenit.
Dacă construiești Microsoft Copilot și AI agents pentru suport pe identitate, aș fi atent să nu promiți rezultate self-service până când acoperirea pentru method registration este curată. Altfel, botul spune da, platforma spune nu, iar helpdesk-ul primește tichetul.
Părerea mea
Este o corecție bună și întârziată din punct de vedere al securității. Capcana este că Microsoft elimină o comoditate pe care multe tenant-uri se bazau implicit. Așadar, munca reală nu este configurația tehnică. Este igiena de registration, design-ul de recovery cu least privilege și verificarea că echipa de suport nu este luată prin surprindere în septembrie 2026.
Dacă deții Entra, nu aștepta prompturile ca să afli că ai un gol. Măsoară acum acoperirea pentru registration, repară fluxul de onboarding și asigură-te că administratorii sunt incluși.
