Wachtwoord wijzigen na veilige aanmelding: wat Message Center en Learn elk zeggen

De situatie ken je. Iemand meldt zich elke dag aan met een passkey, typt nooit meer een wachtwoord, en dan vraagt een legacy-applicatie die alleen wachtwoorden kent er toch om. Dat wachtwoord is allang vergeten, dus bleven SSPR of de servicedesk over. Met Allow password change after secure sign-in aan gaat die gebruiker naar Security info (of direct naar https://mysignins.microsoft.com/security-info/password/change), meldt zich aan met een ondersteunde methode, kiest Change naast Password en voert twee keer een nieuw wachtwoord in. Naar het huidige wachtwoord wordt niet gevraagd.

Volgens de pagina over combined registration bestond een deel hiervan al: een gebruiker die zich in Security info aanmeldt met een wachtwoord plus een MFA-methode kan zijn wachtwoord wijzigen zonder het oude in te voeren. Dat is niet wat wij zagen. Bij een eerste snelle test in onze eigen tenant (InPrivate-venster, wachtwoord plus Authenticator-push, direct naar de wijzigpagina) vroeg het venster toch om het huidige wachtwoord. Die zin is dus verouderd, of er geldt een voorwaarde die er niet bij staat. Voor de passwordless gebruiker maakt het niet uit: wie zich met een passkey aanmeldt, heeft niet laten zien dat hij het wachtwoord kent, en moest het daarom tot nu toe altijd invoeren. Dat gat dicht deze functie.

Volgens de Learn-pagina (een nieuw tabblad op "How it works: Microsoft Entra self-service password reset") staat dit los van SSPR: gebruikers hoeven niet voor SSPR geregistreerd te zijn en het aantal vereiste methoden uit je SSPR-policy geldt niet. De instelling zit op de methode Password in de Authentication methods policy, je hebt minimaal Authentication Policy Administrator nodig om hem aan te zetten, en hij geldt voor de hele tenant zonder mogelijkheid om gebruikers of groepen te targeten of uit te sluiten. Gebruikers hebben Entra ID P1 of P2 nodig. In een hybride tenant met password writeback gaat het nieuwe wachtwoord ook naar AD; voor identiteiten die alleen on-premises bestaan kan My Sign-Ins niets.

MC1437671 verscheen op 23 juli en is voor het laatst bijgewerkt op 13 oktober. Onderweg is de functie twee keer hernoemd, van "Passwordless password change in My Sign-Ins" via "Authenticated password change in My Sign-Ins" naar de huidige naam. Het Learn-tabblad ging op 29 oktober live. Leg je ze naast elkaar, dan sluiten ze niet op elkaar aan:

• Aanmeldmethoden. Message Center noemt een passkey, een FIDO2-securitykey en Windows Hello for Business. Learn noemt Microsoft Entra certificate-based authentication, een passkey (FIDO2) en passwordless phone sign-in met Microsoft Authenticator. CBA en phone sign-in staan alleen in Learn, Windows Hello for Business alleen in Message Center.
• Geregistreerd of beschikbaar. Message Center heeft het over gebruikers met een geregistreerde methode. Learn zegt dat een gebruiker een andere manier nodig heeft om het wachtwoord te wijzigen of te resetten als er geen ondersteunde methode beschikbaar is. Dat is logisch zodra CBA op de lijst staat, want een certificaat registreer je niet in Security info.
• Clouds. Message Center noemt de uitrol voor Worldwide en GCC. Learn zegt alle clouds, van eind oktober tot eind november.
• Licentie. Learn vereist P1 of P2 voor de gebruiker. De Message Center-post zegt niets over licenties.
• Aanzetten. Learn geeft een pad in de portal (Entra ID > Authentication methods > Policies > Password > Configure). Jan Bakker (30 oktober) en Tony Redmond (3 november) troffen de instelling nog niet aan in het admin center en zetten hem aan via Graph beta. Kijk wat jouw tenant laat zien; Graph werkt in beide gevallen.

Temporary Access Pass staat op geen van beide lijsten, en de pagina over combined registration is daar duidelijk over: met een TAP kun je je wachtwoord alleen wijzigen als je het bestaande wachtwoord kent.

Dit verschil doet er in de praktijk het meest toe, want in de meeste beheerde Windows-omgevingen die ik zie, melden gebruikers zich met WHfB aan. Volg je Learn-wijzigingen via een diffservice zoals Entradiff, dan zag je het nieuwe tabblad op 29 oktober verschijnen met passkey (FIDO2) of Windows Hello for Business als aanmeldmethoden, en op dezelfde dag een versie met CBA, passkey en Authenticator. Dat lijkt alsof Microsoft WHfB toevoegde en binnen een paar uur weer schrapte, maar de Git-geschiedenis van MicrosoftDocs/entra-docs laat iets anders zien. De eerste versie van het tabblad is op 11 september geschreven en zei inderdaad dat gebruikers zich verifiëren met "a registered passkey (FIDO2) or Windows Hello for Business credential". Drie dagen later, op 14 september, verving een commit met de titel "Clarify passwordless password change methods" dat door de huidige drie methoden. Alles tot en met de uitrolnotitie van 23 oktober is daarna op 29 oktober in één merge naar de publieke repo gesynchroniseerd, en daarom tonen diffservices beide versies op dezelfde dag. (In die eerste versie stond ook dat de functie geen password writeback ondersteunde; dat is in dezelfde reeks op 14 september gecorrigeerd.)

Voor zover ik kan zien heeft de gepubliceerde Learn-pagina WHfB dus nooit genoemd. Het documentatieteam haalde het er bijna een maand vóór de Message Center-updates van oktober al uit, en die noemen het nog steeds. Welke van de twee het echte gedrag beschrijft, weet ik niet. WHfB is in Entra een eigen methode, los van Passkey (FIDO2), ook al werken beide met sleutels en kan Windows Hello ook als FIDO2-authenticator dienen, en in mijn ervaring staat het in de sign-in logs als Windows Hello for Business. Tot we het getest hebben, zou ik gebruikers met WHfB niet vertellen dat dit voor hen werkt.

Staat de instelling nog niet in je admin center, dan doet dit hetzelfde via Graph beta. Je hebt de scope Policy.ReadWrite.AuthenticationMethod nodig en een rol zoals Authentication Policy Administrator:

Ik lees de instelling bewust terug met Invoke-MgGraphRequest. De Beta SDK-cmdlet Get-MgBetaPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration weigert te laden als je module Microsoft.Graph.Authentication een andere versie heeft dan de Beta-module, en ook als hij wel werkt, staat de property alleen onder AdditionalProperties, omdat de SDK hem nog niet als getypte property kent. In onze eigen tenant zag het object er vóór het aanzetten zo uit:

Er staan geen includeTargets of excludeTargets in, terwijl de gedocumenteerde methoden in de policy die wel hebben. De API zegt dus hetzelfde als de documentatie: je kunt dit niet tot een groep beperken. Van state zou ik afblijven. Wat disabled doet, staat nergens beschreven, en dat wil je niet in productie uitzoeken.

Twee dingen uit de test van Tony Redmond: de policywijziging werkte bij hem vrijwel direct, en het aanzetten van de instelling doet niets zolang de uitrol je tenant nog niet heeft bereikt. Hij liep ook tegen één probleem aan. Nadat hij het dialoogvenster voor het wijzigen van het wachtwoord liet verlopen, deed Teams vreemd bij het terugschakelen naar zijn eigen tenant, tot hij het wachtwoord opnieuw instelde en zich in Teams af- en weer aanmeldde. Zijn advies: maak de flow af als je eraan begint.

Op zichzelf is dit een gemaksfunctie. Naast alles wat Microsoft deze winter aan authenticatie verandert, vult het een gat. Sinds 1 september worden gebruikers die voor SMS of Voice aanstaan automatisch ingeschakeld voor passkeys en krijgen ze een nudge van de registratiecampagne. Op 1 februari 2027 stopt Microsoft met het zelf leveren van SMS en Voice (1 juli 2027 voor Global Administrators en externe gebruikers), geldt de tijdelijke opt-out van de automatische passkey-inschakeling niet meer, en moeten gebruikers bij wie SMS of Voice de enige MFA-methode was een passkey registreren voordat ze verder kunnen met aanmelden. Heel veel gebruikers worden dus passkey-first, of hun organisatie dat nu gepland had of niet, en dat zijn precies de gebruikers die hun wachtwoord niet meer typen en het vergeten.

Daar loopt het op SSPR vast, want passkeys en WHfB zijn niet bruikbaar voor SSPR. In de passkeys-blog ben ik de overgebleven SSPR-methoden langsgegaan: Authenticator en OATH-tokens tellen als één methode, SMS en Voice verdwijnen op 1 februari tenzij je een telefonieprovider afneemt, en beveiligingsvragen verdwijnen in maart 2027. Tel daar bij op dat SSPR straks alleen nog geregistreerde methoden accepteert (volgens Message Center vanaf 9 november, volgens Learn sinds 5 november pas vanaf februari 2027), en de groep gebruikers die SSPR daadwerkelijk kan doorlopen wordt steeds kleiner.

Deze functie is de logische volgende stap. Het dagelijkse geval (ik weet wie ik ben, ik kan me aanmelden met mijn passkey, ik weet alleen het wachtwoord voor die ene oude applicatie niet meer) verdwijnt helemaal uit SSPR. Een sterke aanmelding wordt het bewijs dat je een nieuw wachtwoord mag instellen (phishingbestendig bij passkeys en CBA; Authenticator phone sign-in staat ook op de lijst maar is dat niet), en dat is een betere basis dan alleen een Authenticator-code. Voor SSPR blijven dan de echte herstelsituaties over, waarin iemand zich helemaal niet meer kan aanmelden. Dat is een veel kleinere groep, en dat maakt de lastige keuzes over hoeveel methoden je vereist en welke je toestaat een stuk makkelijker.

Het verandert ook wat het wachtwoord is. Het bestaat nog, omdat de legacy-applicaties nog bestaan, maar het is niet langer iets wat de gebruiker moet onthouden: die stelt gewoon een nieuw wachtwoord in als dat nodig is, vanuit een sessie die met een passkey begon. Voor mij is dat in de meeste organisaties op dit moment de eerlijke stand van passwordless. Volledig passwordless is waar we naartoe willen, en ik hoop dat we daar ooit komen, maar zolang er nog één applicatie om een wachtwoord vraagt, is het beste wat je kunt doen het wachtwoord wegwerpbaar maken en het weghouden van je cloudaanmeldingen. Dat laatste moet je zelf regelen: een wachtwoord dat je zo instelt is net zo phishbaar als elk ander, dus het helpt alleen als je Conditional Access een phishingbestendige authentication strength afdwingt voor de cloudapps die dat ondersteunen.

Dit zijn de punten waar de documentatie ruimte laat. We lopen ze allemaal grondig na voordat we conclusies trekken, en de resultaten volgen hier als update:

1. Of een gebruiker die zich met WHfB op Windows heeft aangemeld en via SSO in Security info komt, de wijzigflow krijgt zonder huidig wachtwoord.
2. Of een bestaande sessie genoeg is of dat de flow een nieuwe aanmelding met een van de ondersteunde methoden afdwingt.
3. Hoe de wijziging in de auditlogs terechtkomt, zodat servicedesk en SOC hem kunnen onderscheiden van een SSPR-reset of een reset door een beheerder.
4. In een hybride tenant: wat de gebruiker ziet als het nieuwe wachtwoord bij de writeback wordt geweigerd door de on-premises password policy (geschiedenis, minimale leeftijd).
5. Of de instelling inmiddels in het admin center staat, of nog alleen via Graph kan.

Wil je het voor die tijd zelf proberen, zet het dan eerst aan in een testtenant, meld je aan met elke methode die je gebruikers echt hebben, en noteer wat elke methode oplevert. Omdat je de instelling niet tot een pilotgroep kunt beperken, vertelt die lijst je of aanzetten in productie iedereen helpt of alleen je passkey-gebruikers.

De scripts uit deze blog staan ook op GitHub, in entra-scripts.

• How it works: Microsoft Entra self-service password reset (tabblad "Allow password change after secure sign-in")
• MC1437671: Microsoft Entra, allow password change after secure sign-in with My Sign-Ins
• MicrosoftDocs/entra-docs: geschiedenis van concept-sspr-howitworks.md
• Entradiff: wijzigingen in authenticatie
• Combined registration voor SSPR en MFA: wachtwoord wijzigen in My Sign-Ins
• Jan Bakker: Allow password change after secure sign-in
• Tony Redmond: Entra ID allows users to change passwords without knowing their old password
• Passkeys by default and retirement of Microsoft-provided SMS and voice authentication
• Authentication methods supported by Microsoft Entra ID
• Security questions authentication method
• MC1325414: SSPR requires explicitly registered authentication methods