SSPR accepteert vanaf 9 november geen ongeregistreerde telefoonnummers en e-mailadressen meer

Microsoft heeft dit aangekondigd op de Microsoft Entra blog en in Message Center als MC1325414. De tijdlijn is twee keer verschoven en is elders al goed beschreven, dus kort: het oorspronkelijke Message Center-bericht uit mei noemde een registratiecampagne op 6 juli en handhaving op 7 september. Daarom kom je nog steeds blogs tegen die september noemen. In de update van augustus schoof de campagne naar 5 oktober en de handhaving naar 9 november, met een uitrol tot half november. In de tekst van datzelfde Message Center-bericht staat dat de handhaving op 7 november begint, met 6 november als act-by-datum. Ik zou zaterdag de 7e dus als echte start aanhouden, en 9 november als de datum waarop elke tenant het kan verwachten. Het Learn-artikel over het vooraf vullen van authentication contact info noemt de twee datums op dit moment precies andersom (handhaving op 5 oktober, campagne op 9 november); ga uit van het Message Center-bericht.

De scope is iedere gebruiker in een tenant waar SSPR aan staat, beheerders inbegrepen. Microsoft noemt de directory-eigenschappen mobilePhone, businessPhones en otherMails: heeft de gebruiker dat nummer of adres nooit als authenticatiemethode geregistreerd, dan gebruikt SSPR het niet meer om de gebruiker te verifiëren. Volgens Microsoft gebruikt zo'n 86% van de SSPR-verificaties al geregistreerde methoden. Omgekeerd betekent dat dat ongeveer één op de zeven resets vandaag op directorydata leunt.

Microsoft heeft dit gedocumenteerd als manier om SSPR op gang te helpen. Hetzelfde Learn-artikel beschrijft hoe Microsoft Entra Connect de on-premises attributen telephoneNumber en mobile koppelt aan Office phone en Mobile phone, en stelt dat gebruikers met een gevuld Mobile phone of Alternate email die waarden direct kunnen gebruiken om hun wachtwoord te resetten, ook als ze zich nooit hebben geregistreerd. De SSPR FAQ zegt hetzelfde van de andere kant: gebruikers hoeven zich niet te registreren als jij genoeg authenticatiegegevens namens hen invult.

Wat dit riskant maakt, is waar die data staat en wie erin kan schrijven. Geregistreerde authenticatiemethoden staan in afgeschermde velden die volgens de FAQ alleen de gebruiker zelf en Privileged Authentication Administrators kunnen zien, en gebruikers voegen ze toe via Security info na een MFA-prompt. mobilePhone, businessPhones en otherMails zijn gewone profieleigenschappen. Iedere gebruiker in de tenant kan ze lezen, en in de lijst met sensitive actions zie je welke beheerrollen ze mogen wijzigen; Microsoft behandelt ze juist als gevoelig omdat SSPR erop leunt. Voor gesynchroniseerde gebruikers is Active Directory de echte bron, en daar is de kring van schrijvers meestal veel groter: servicedesk-delegaties op OU's met gebruikers, HR-connectoren, IAM-tooling, en het account zelf (het AD-schema noemt als update privilege voor mobile de domain administrator of de account owner).

Tel dat bij elkaar op en je hebt een resetpad dat alles omzeilt wat je voor MFA-registratie hebt ingericht. Wie mobile op een AD-account kan schrijven, zet daar zijn eigen nummer in, wacht de volgende synccyclus af en doorloopt, als je SSPR-beleid mobiele telefoon toestaat, een SSPR-flow die maar één methode vraagt met een SMS naar dat nummer. Password writeback zet het nieuwe wachtwoord vervolgens ook in AD. Voor een aanvaller die al een wachtwoord heeft gephisht, is het eigen nummer in het profiel van het slachtoffer persistentie die de volgende wachtwoordwijziging overleeft. En ook zonder aanvaller veroudert HR-data: nummers van ingeleverde zakelijke telefoons, nummers die mensen jaren geleden hebben meegenomen, nummers die een provider inmiddels aan iemand anders heeft uitgegeven.

Het gaat om gebruikers die voor SSPR zijn ingeschakeld, niet genoeg geregistreerde methoden hebben voor je SSPR-beleid, en wel contactgegevens in de directory hebben. In de praktijk zie ik een paar groepen steeds terugkomen. Gesynchroniseerde gebruikers in organisaties waar HR of AD altijd mobiele nummers heeft gevuld en waar SSPR jaren geleden is uitgerold op basis van precies die data. Gebruikers wier MFA via een externe partij loopt, via federatie of external MFA: dat telt allemaal niet als SSPR-methode, dus voor hen was het mobiele nummer in de directory vaak het enige resetpad dat er ooit was. En cloud-only accounts die door een onboardingscript zijn aangemaakt dat mobilePhone vulde en het daarbij liet.

Daarnaast is er een nieuwere groep: gebruikers die alleen passwordless credentials hebben. Het overzicht van methoden noemt passkeys (device-bound en synced), Windows Hello for Business en Temporary Access Pass als niet bruikbaar voor SSPR. Microsoft duwt SMS- en Voice-gebruikers sinds 1 september richting passkeys, dus die groep groeit elke week, en voor hen was het mobiele nummer in de directory vaak de enige terugvaloptie.

De registratiecampagne die op 5 oktober begon, moet deze gebruikers opvangen, maar het Learn-artikel koppelt die aan de SSPR-instelling die gebruikers verplicht te registreren bij het aanmelden. Heb je die ooit uitgezet (gebeurt vaak in tenants die zijn overgestapt op combined registration en eigen nudges), controleer dan of je gebruikers überhaupt een prompt hebben gezien.

In het admin center staat dit onder Entra ID > Authentication methods > User registration details (filter op SSPR enabled en SSPR capable). Dat vertelt je wie niet kan resetten, maar niet waarom. Nuttiger is een lijst die het userRegistrationDetails-rapport combineert met de directory-attributen, zodat je precies ziet wie nu nog op mobilePhone, businessPhones of otherMails drijft:

Voor het rapport heb je AuditLog.Read.All nodig en een rol als Reports Reader of Global Reader. Twee kanttekeningen uit de documentatie van Authentication Methods Activity: het rapport kan tot 36 uur achterlopen, en uitgeschakelde gebruikers staan er niet in. Controleer een paar resultaten handmatig op de Authentication methods-pagina van de gebruiker voordat je iemand gaat mailen. De kolom IsAdmin staat erin omdat de wijziging ook voor beheeraccounts geldt.

De voor de hand liggende oplossing is deze gebruikers het nummer te laten registreren dat al in hun profiel staat. De SSPR-registratiepagina toont die directorywaarden aan de gebruiker, die ze kan bevestigen of aanpassen, dus met de campagne is het snel geregeld. Dat zou ik niet doen. MC1426371 zet de door Microsoft geleverde SMS en Voice op 1 februari 2027 uit (op 1 juli 2027 voor Global Administrators en externe gebruikers), en de FAQ bij die uitfasering zegt expliciet dat dit voor heel Microsoft Entra geldt, SSPR inbegrepen. Een telefoonnummer dat deze week wordt geregistreerd, werkt dus nog geen drie maanden, tenzij je via Microsoft Security Store een telefonieprovider contracteert. (Wat die uitfasering voor SSPR betekent, heb ik uitgebreider beschreven in Passkeys by default: de dingen waar we tegenaan lopen.)

Wat wel telt voor SSPR: Microsoft Authenticator (push of code), software- en hardware-OATH-tokens, email OTP, en SMS en Voice zolang die er nog zijn. Beveiligingsvragen bestaan nog voor gebruikers zonder adminrol, maar Microsoft faseert ze in maart 2027 uit, dus daar bouw je ook niet op. Let op dat Authenticator en OATH-tokens voor SSPR samen als één methode tellen. Vraagt je beleid één methode, dan dekt Authenticator dat. Vraagt het er twee, dan is Authenticator plus email OTP na februari zo ongeveer de enige combinatie die overblijft zonder telefonieprovider. Denk dan wel na over welk adres gebruikers registreren: een werkmailbox waar je niet bij kunt als je buitengesloten bent, heeft weinig zin.

Mijn advies voor deze week is daarom een passkey voor het aanmelden plus de Authenticator-app voor push of code als SSPR-methode, met een privé e-mailadres als tweede methode waar je beleid er twee vraagt. Voor gebruikers die volledig passwordless werken, zet je Allow password change after secure sign-in aan bij de Password-methode in de Authentication methods policy (MC1437671, uitrol vanaf eind oktober, P1 of P2 nodig, geldt voor de hele tenant). Daarmee kunnen ze na een passwordless aanmelding via Security info een nieuw wachtwoord instellen, wat een groot deel van de redenen wegneemt waarom ze anders SSPR nodig hadden.

Gebruikers die helemaal niets bruikbaars hebben, geef je een Temporary Access Pass. Eén detail uit de beperkingen van TAP: gebruikers die onder het SSPR-registratiebeleid vallen en met een TAP aanmelden, komen in de interrupt mode van combined registration terecht, en die ondersteunt geen registratie van passkeys. Laat ze daar Authenticator registreren (dat is toch de SSPR-methode die je wilt) en de passkey daarna in Security info toevoegen.

Gebruikers zonder geregistreerde methode krijgen de melding dat ze contact moeten opnemen met hun beheerder, dus de telefoontjes komen bij de servicedesk binnen, waarschijnlijk op de eerste maandag na de handhaving. Drie dingen om vooraf met ze af te spreken. Kijk hoe ze bellers verifiëren: als de procedure is dat ze terugbellen naar het mobiele nummer uit de directory, bouw je precies de zwakte na die Microsoft net heeft gedicht. Kijk naar hun rollen: Helpdesk Administrator en Password Administrator kunnen wachtwoorden resetten, maar voor een TAP heb je Authentication Administrator nodig (of Privileged Authentication Administrator voor beheerders). En zorg dat niemand de achterstand wegwerkt door met een script mobilePhone massaal naar telefoonmethoden te kopiëren. Voor zover ik kan zien telt een door een beheerder toegevoegde telefoonmethode als geregistreerd, maar je importeert dan opnieuw data die niemand heeft gecontroleerd, en die stopt op 1 februari toch met werken.

otherMails wordt overigens niet zinloos: SSPR stuurt de meldingen over een wachtwoordreset nog steeds naar het primaire en het alternatieve e-mailadres. Reden genoeg om dat attribuut actueel te houden.

Vóór zaterdag: draai het script hierboven, splits de uitkomst in gesynchroniseerde en cloud-only gebruikers, stuur de gesynchroniseerde groep een gericht bericht met een verwijzing naar Security info voor Authenticator, en controleer dat de SSPR-instelling voor registratie bij het aanmelden aan staat, zodat de campagne ze vóór maandag ook echt bereikt.

• Microsoft Entra blog: Microsoft Entra ID security updates, what organizations need to do now
• MC1325414: SSPR vereist expliciet geregistreerde authenticatiemethoden
• Authentication contact info voor SSPR vooraf vullen
• Self-service password reset FAQ
• Wie gevoelige gebruikerseigenschappen mag wijzigen (sensitive actions)
• Active Directory-schema: attribuut Phone-Mobile-Primary (mobile)
• Authenticatiemethoden in Microsoft Entra ID
• userRegistrationDetails resource type (Microsoft Graph)
• Authentication Methods Activity: user registration details
• MC1426371: uitfasering van door Microsoft geleverde SMS- en Voice-authenticatie
• FAQ over de SMS- en Voice-uitfasering: wat betekent het voor SSPR
• How it works: Microsoft Entra self-service password reset
• MC1437671: Microsoft Entra passwordless password change in My Sign-Ins
• Configure Temporary Access Pass