Microsoft Entra adaugă o metodă la nivel de tenant prin care utilizatorii passwordless pot seta o parolă nouă fără să o știe pe cea veche și fără SSPR. Sună contradictoriu, dar pentru organizațiile blocate încă pe câteva aplicații vechi, rezolvă o problemă foarte reală de suport.
Scenariul practic este simplu. Utilizatorul se autentifică zilnic cu passkey, cheie FIDO2 sau Windows Hello for Business. Apoi o aplicație internă veche încă cere parolă. După câteva luni, utilizatorul nu și-o mai amintește, nu s-a înscris în self-service password reset, iar helpdesk-ul ajunge să rezolve o problemă care n-ar trebui să mai existe în 2026.
Schimbarea asta îi oferă o ieșire în My Sign-Ins.
Ce se schimbă în Microsoft Entra?
Conform anunțului din Message Center prezentat în sursă, lansarea începe la final de octombrie 2026, ajunge la GA în aceeași lună și vine dezactivată implicit. Când este activată, utilizatorii eligibili pot intra în My Sign-Ins, aleg Change password, își dovedesc identitatea cu o metodă passwordless înregistrată și setează o parolă nouă fără să introducă parola veche.
Metodele pe care Microsoft le poziționează în Entra ca phishing-resistant includ Windows Hello for Business, passkeys și cheile FIDO2. Partea asta este rezonabilă. Dacă utilizatorul poate demonstra puternic cine este folosind una dintre aceste metode, obligația de a-și aminti o parolă folosită rar este în mare parte doar formalitate.
Ce nu face această funcție este să elimine parolele din cont. De fapt, face opusul: ușurează întreținerea unei parole care există încă fiindcă o dependență veche nu a ținut pasul. Dacă construiți Microsoft Copilot și AI agents sau fluxuri mai largi de automatizare, exact acest tipar apare des: modelul modern de identitate este bun, dar o integrare veche ține în viață secretul vechi.
De ce modelul de rollout contează mai mult decât funcția
Problema este scopul. Microsoft spune că setarea este tenant-wide. Fără grup pilot. Fără targetare per utilizator. Fără rollout gradual.
Asta este partea care m-ar interesa cel mai mult.
Pentru majoritatea organizațiilor, nu este o regresie mare de securitate. Utilizatorul tot își dovedește identitatea cu o metodă phishing-resistant. Dar controalele tenant-wide sunt incomode operațional. Dacă doar un subset de utilizatori are dependențe vechi, nu poți activa funcția doar pentru ei și să-i lași pe ceilalți în pace. Ori expui opțiunea tuturor utilizatorilor eligibili, ori nimănui.
Asta contează pentru că astfel de decizii de produs schimbă și proprietarul deciziei. Nu mai este un experiment local de admin, ci o alegere de identity governance. Dacă aveți deja un proces formal de audit pentru AI și automatizare sau de revizuire a identității, aici îi este locul: ca setare de tenant, nu ca ajustare de helpdesk.
Ce aș verifica înainte să o activez
Mai întâi, aflați dacă aveți cu adevărat o problemă care merită rezolvată.
Dacă utilizatorii passwordless sunt deja înscriși în SSPR și tichetele către helpdesk sunt puține, funcția este utilă, dar nu urgentă. Dacă aveți utilizatori pe Windows Hello for Business sau passkeys care încă intră în aplicații vechi și uită parolele, devine mai interesantă.
În al doilea rând, revizuiți sistemele care încă cer parole. Funcția asta este un pansament pentru debt tehnic. Uneori este perfect acceptabil. Dar dacă lista aplicațiilor dependente de parolă este mai lungă decât vă așteptați, investiția mai bună poate fi eliminarea acelor dependențe sau mascarea lor prin ceva mai modern, inclusiv custom MCP servers sau alte straturi de integrare, unde arhitectura chiar are sens.
În al treilea rând, pregătiți comunicarea către utilizatori. Pentru că setarea este tenant-wide, utilizatorii vor vedea o cale nouă în My Sign-Ins în ziua în care o activați. Acesta este genul de schimbare tăcută de UI care produce confuzie inutilă dacă nimeni nu explică de ce a apărut.
Părerea mea
Este o schimbare bună și întârziată. Nu pentru că schimbă strategia de autentificare, ci pentru că elimină un caz stupid de suport creat de starea intermediară în care trăiesc multe tenant-uri: passwordless pentru utilizator, dar parolă încă necesară undeva în infrastructură.
Totuși, nu-mi place deloc caracterul de totul-sau-nimic al setării. Microsoft a rezolvat fricțiunea pentru utilizator, dar nu și fricțiunea de rollout. Într-un tenant mare, asta nu este o omisiune minoră.
Recomandarea mea este simplă: tratați asta ca pe o setare de identitate la nivel de tenant, nu ca pe un toggle de comoditate. Verificați aplicațiile care încă depind de parole, estimați câți utilizatori passwordless ar vedea opțiunea și decideți dacă rezolvați o durere operațională reală sau doar mai adăugați încă o opțiune într-un portal de cont deja aglomerat.
