Passkeys by default: de dingen waar we tegenaan lopen

Sam Kloos
Aug 18, 2026 — Sam Kloos

Microsoft stopt met het zelf leveren van SMS- en Voice-authenticatie in Entra ID. Daar is inmiddels genoeg over geschreven en de tijdlijn is wel bekend, dus die zet ik hieronder kort neer en dan ga ik door naar het deel waar ik zelf de meeste tijd in kwijt was: wat er gebeurt als je dit in een grote omgeving daadwerkelijk gaat uitvoeren.

We zitten er nu middenin, en een aantal dingen werkte anders dan ik vooraf had aangenomen.

Microsoft retirement timeline for SMS and voice authentication in Entra ID

De tijdlijn

  • 1 september 2026: gebruikers met SMS of Voice in de Authentication Methods Policy of in de legacy MFA-instellingen worden automatisch aangezet voor passkeys. De registration campaign gaat naar Microsoft managed en trekt die gebruikers automatisch in scope.
  • 18 september 2026: Microsoft publiceert welke telecomproviders je kunt gebruiken, inclusief prijzen en voorwaarden, via de Security Store.
  • 30 oktober 2026: vanaf deze datum kun je zo'n provider daadwerkelijk selecteren en configureren. Eén per kanaal, dus één voor SMS en één voor Voice.
  • 1 februari 2027: Microsoft-geleverde SMS en Voice zijn weg. Heb je geen eigen telecomprovider geconfigureerd, dan krijgt iedereen die alleen die methodes heeft een blokkerende passkey-registratie voordat hij verder kan. Daar is geen opt-out op, voor geen enkele tenant.
Wat je bij die eerste datum goed moet weten, is wat Microsoft managed precies met je campagne doet. In die stand bepaalt Microsoft de instellingen en kun je ze zelf niet meer aanpassen: de doelmethode wordt passkeys, de snooze-duur gaat naar één dag en het aantal snoozes wordt onbeperkt. Gebruikers kunnen dus tot in het oneindige op Skip for now klikken. Prettig voor je helpdesk, maar het betekent ook dat er tot 1 februari geen enkele druk op je migratie staat.

Wat me nog meer opviel: de targeting verschuift in Microsoft managed van "gebruikers met Voice of SMS" naar alle MFA-capable gebruikers. Dat is breder dan waar deze aankondiging over gaat, dus ga er niet vanuit dat alleen je SMS- en Voice-populatie iets gaat merken.

Nog iets wat in deze periode verandert en wat je uitrol makkelijker maakt: op dit moment moet een gebruiker eerst een andere MFA-methode registreren voordat hij een passkey kan toevoegen, en SMS of Voice is precies wat daar vaak voor gebruikt wordt. Met MC1450133 vervalt die eis. Synced passkeys, Entra-passkeys en FIDO2 volgen tussen half oktober en half november 2026, Windows Hello, macOS Platform SSO en Authenticator tussen januari en eind februari 2027. Je hoeft er niets voor te doen.

Voor de volledigheid: deze tijdlijn geldt alleen voor de public cloud. Andere cloudomgevingen volgen later op een eigen schema.

Bij Authenticator zagen we weinig prompts, bij passkeys wordt dat anders

Wij hebben de registration campaign niet aan staan. Wat we wel hebben gedaan is uitzoeken hoe het ding zich gedraagt, en dat deden we op de Authenticator-campagne, want die bestaat al langer. In onze enterprise omgeving bleef het daar opvallend stil: we zouden bij die campagne maar weinig prompts zien, om twee redenen die je gewoon in de documentatie terugvindt.

De eerste staat in de FAQ en is kort: "The nudge doesn't trigger if the user is already signed in with SSO." In een omgeving met Windows Hello for Business is dat zo'n beetje de standaardsituatie. Je logt 's ochtends aan met Hello, hebt daarmee een MFA-claim in je token en loopt via SSO door naar je resources. Je doet nergens meer een interactieve MFA, en dat is nou juist het moment waar die nudge achter hangt.

De tweede is dat Authenticator-campagnes helemaal niet werken op mobiele devices. Daarmee valt in één klap een flink deel van je aanmeldingen af.

Waar ik voor wil waarschuwen is dat je die ervaring niet één op één kunt doortrekken naar 1 september. De passkey registration campaign is namelijk een ander verhaal dan de Authenticator-campagne. Microsoft managed zet je campagne om naar passkeys, en die variant gedraagt zich op een paar punten anders. Weinig prompts bij Authenticator betekent dus niet dat het bij passkeys ook stil blijft.

Het belangrijkste verschil zit precies op dat tweede punt: passkey-campagnes werken wél op mobiel, zowel in de browser als in native iOS-apps. Native Android-apps nog niet. Dat is dus een kanaal dat bij de Authenticator-campagne volledig dicht zat en dat straks opengaat.

Daar staat een onderdrukking tegenover die er bij Authenticator niet was. Mijn aanname was dat de campagne kijkt of iemand een passkey heeft, en dat is niet zo: hij kijkt of er voor jouw combinatie van besturingssysteem en browser een bruikbare lokale passkey aanwezig is. Windows Hello for Business onderdrukt de nudge op Windows in elke browser, iCloud Keychain doet dat op Mac en iOS, een passkey in de Authenticator-app telt alleen op iOS en Android, en Linux-gebruikers worden volgens de documentatie helemaal niet genudged. Dezelfde gebruiker kan dus op zijn laptop niets zien en op zijn Mac wel. Microsoft heeft de volledige matrix gepubliceerd en die is het bekijken waard voordat je je uitrol plant.

De SSO-regel geldt overigens voor beide campagnetypes, dus dat deel blijft gewoon staan.

En dan is er nog een rij situaties waarin de prompt simpelweg niet verschijnt:
  • als het passkey-profiel van de gebruiker een restrictie heeft: alleen synced, alleen device-bound, attestation afgedwongen of een AAGUID-filter
  • als Conditional Access op Register security information de pagina blokkeert, of als je registratie hebt beperkt tot een vertrouwde locatie of een compliant device
  • als er tijdens de aanmelding een terms of use-scherm langskomt
  • bij Conditional Access custom controls, al is dat een aflopende zaak: die worden per 30 september 2026 niet meer aanpasbaar en gaan in mei 2027 helemaal weg (MC1422061)
  • in out-of-the-box experiences en in browservensters die in Windows-instellingen zijn ingebed
  • als de toggle Allow self-service setup in je passkey-configuratie uit staat, want dat is een voorwaarde voor de hele campagne
Twee groepen verdienen aparte aandacht. Gebruik je AAGUID-targeting in je passkey-policy, dan schakelt Microsoft managed de doelmethode juist níet om naar passkeys. Wil je die mensen toch nudgen, dan moet je de campagne op Enabled zetten en het zelf inrichten. En je gastgebruikers worden op dit moment helemaal niet genudged voor passkeys, want passkey-ondersteuning voor guests bestaat nog niet. Microsoft zegt dat die eind 2026 komt en zegt er tegelijk bij dat B2B-gebruikers wél in scope zitten van de retirement. Dat is dus een populatie die nu nergens in je cijfers opduikt en op 1 februari 2027 alsnog tegen dezelfde muur loopt.

Wat al die situaties gemeen hebben: straks kun je niet afgaan op wat je ziet gebeuren. Weinig prompts en weinig helpdeskvragen betekent hier niet dat je er klaar voor bent, en dat maakt het lastig sturen.

De opt-out via Graph

Bij ons staat de campagne dus niet aan, en met de tijdelijke opt-out die begin augustus beschikbaar kwam houden we dat op 1 september ook zo. Eén call, met Policy.ReadWrite.AuthenticationMethod: 
PATCH https://graph.microsoft.com/beta/policies/authenticationmethodspolicy
Content-Type: application/json

{ "optOutSettings": { "passkeyDynamicMigration": true } }
Daarmee valt je tenant tot 1 februari 2027 buiten de automatische passkey-enablement en de registration campaign.

De reden dat wij dat hebben gedaan is niet dat we de migratie willen uitstellen, maar dat we niet wilden dat iemand onverwacht die pop-up krijgt (bijvoorbeeld bij een aanmelding buiten je SSO-sessie om, op een device zonder bruikbare lokale passkey) voordat we met medewerkers hebben gecommuniceerd. Zonder die call bepaalt het toeval wanneer de eerste medewerker hem ziet, en dat wil je niet.

De einddatum hoef je niet zelf te verzinnen, die staat vast op 1 februari 2027. Wat je wel moet vastleggen is wie er eigenaar van is en wanneer je hem zelf weer uitzet, want dat moment wil je ruim vóór de deadline hebben en niet erop.

SSPR loopt sneller vast dan MFA

Dit is het stuk waar ik het minst over terugzie en waar wij het meeste werk aan hadden. De retirement geldt Entra-breed, dus ook voor self-service password reset.

Bij ons stond SMS al uit voor SSPR (staat dat bij jou nog aan, doe dat sowieso) en het aantal vereiste methodes staat op twee. Wat je dan overhoudt:
  • Authenticator push en de code in diezelfde app. Dat lijken twee opties, maar het is één methode en dus één gate. Microsoft staat expliciet niet toe dat Authenticator plus één andere methode je enige twee opties zijn.
  • Third-party software OATH, dus een TOTP-code uit een andere app dan Authenticator. Dat is wél een aparte methode en dus een echte tweede gate. Je rolt er alleen een tweede app voor uit naast Authenticator, en je herstelpad blijft een code die iemand kan phishen.
  • Voice, precies wat we uit willen hebben en wat per 1 februari 2027 verdwijnt tenzij je het terugkoopt.
  • E-mail OTP, in de praktijk een extern adres.
  • Security questions, niet beschikbaar voor accounts met een adminrol en alleen nog te beheren in de legacy SSPR-policy.
Extern e-mail is in een enterprise-omgeving geen serieus herstelkanaal, en security questions kun je meteen doorstrepen: Microsoft heeft aangekondigd dat die in maart 2027 voor SSPR worden uitgefaseerd. Een maand na de SMS- en Voice-deadline valt er dus nóg een methode uit dit rijtje weg.

En er loopt nog iets parallel: vanaf 7 september 2026 accepteert SSPR alleen nog methodes die expliciet geregistreerd zijn (MC1325414). Telefoonnummers en alternatieve e-mailadressen die alleen als directory-attribuut op het account staan, tellen dan niet meer mee. Microsoft schat dat dat zo'n 14 procent van de gebruikers raakt. Leunt je herstelpad op een alternatief e-mailadres uit AD, controleer dan eerst of dat überhaupt een geregistreerde methode is.

Hardware OATH-tokens staan wel in de SSPR-lijst, maar dat is voor de meeste organisaties geen antwoord: of je hebt ze al liggen, of je gaat hardware uitgeven aan al je medewerkers. Daar komt bij dat die ondersteuning nog steeds als preview in de documentatie staat, en dat wil je niet als fundament onder je herstelproces.

Je tweede gate wordt daarmee het probleem, en dat is iets anders dan een methode vervangen.

Zover ik het kan overzien heb je vier routes, en geen ervan is prettig:
  • SSPR uitzetten en terugvallen op wachtwoordreset via de servicedesk. Werkt altijd, maar je verplaatst het probleem naar je servicedesk en je identificatieproces aan de telefoon wordt daarmee je beveiliging. Bij een paar honderd gebruikers te overzien, bij een paar duizend een echte kostenpost.
  • Terug naar één gate. Snel geregeld en de minste hinder voor gebruikers, en de Authenticator-app wordt dan in de praktijk die ene gate. Dat mag ook: op de Authentication methods policy kan Authenticator prima die ene gate zijn. Let op: die ene gate is niet per se Authenticator. Gebruikers kunnen elke SSPR-methode gebruiken die ze hebben geregistreerd, dus als Voice of SMS nog aan staat, is dat vanaf dat moment op zichzelf genoeg om een wachtwoord te resetten. Zet die methodes dus uit voordat je naar één gate gaat, niet erna. En je verlaagt bewust het niveau van precies het proces waarmee iemand een wachtwoord kan resetten.
  • Twee gates houden met een methode die je eigenlijk niet wilt. E-mail OTP, een third-party TOTP-app of hardware-tokens uitrollen, en dat over een jaar weer afbouwen. Dubbel werk, en je zet iets neer waarvan je nu al weet dat het weg moet.
  • Versnellen naar passwordless. Pakt het probleem bij de kern aan, maar let op: passkeys en Windows Hello for Business zijn zelf geen SSPR-methodes. Zolang er voor legacy applicaties wachtwoorden blijven bestaan, heb je nog steeds een reset- en herstelpad nodig. En in een grote omgeving krijg je dit niet even voor 1 februari geregeld.
Wat mij het meest logisch lijkt is die laatste vastleggen als het doel waar je naartoe werkt, en bewust een van de andere drie kiezen als tijdelijke situatie. Met een einddatum eraan, en met de reden erbij opgeschreven, want die keuze ga je een keer moeten uitleggen aan iemand die ernaar vraagt.

Waar dat allemaal naartoe wijst is dat je je herstelproces opnieuw moet bekijken in plaats van er een methode in te ruilen. Als je toch naar passwordless gaat, is een Temporary Access Pass met een geverifieerd identificatieproces bij de servicedesk inhoudelijk sterker dan een SMS naar een nummer dat je niet beheert. Microsoft komt hier zelf ook in beweging: in MC1437671 is aangekondigd dat gebruikers met een passwordless credential vanaf eind oktober 2026 hun wachtwoord kunnen wijzigen in My Sign-Ins zonder het huidige wachtwoord te kennen. Let wel op dat die functie standaard uit staat, dat je hem expliciet moet aanzetten en dat het tenant-breed is, zonder scoping op gebruiker of groep.

De betaalde telecomprovider

Vanaf 18 september weet je welke providers er zijn en wat het kost, vanaf 30 oktober kun je er een configureren. De kosten zijn doorgaans per bericht en verschillen per provider en regio. SMS als primaire aanmeldmethode komt sowieso niet terug, ook niet met een eigen provider.

Wat in de meeste stukken hierover ontbreekt: de integratie loopt via een routing function die je zelf in je eigen Azure-subscription deployt. Die stuurt de authenticatieverzoeken vanuit Entra ID door naar je provider. Je koopt dus niet alleen berichten per stuk in, je zet er ook een stuk infrastructuur naast dat je moet beheren en monitoren. De Azure-kosten daarvan zijn volgens Microsoft beperkt vergeleken met wat de provider rekent, maar het is wel iets wat iemand in beheer moet nemen. Er is een evaluation mode waarmee je kunt controleren of de routing werkt zonder dat je gebruikers er iets van merken: die blijven ondertussen berichten krijgen via het kanaal dat nu actief is.

Wij zien dit vooral als achtervang. Je koopt een methode terug die Microsoft laat vallen omdat hij zwak is. Dat is verdedigbaar voor een afgebakende groep met een aantoonbare regulatoire of operationele eis, mits je die eis ook echt vastlegt, maar niet als tenant-breed vangnet. Voice hebben we sowieso liever helemaal uit, dus dat gaan we niet doorbetalen.

Vergeet je beleid en je documentatie niet

Dit blijft bij een technische migratie standaard liggen, terwijl dit vanaf 1 februari 2027 werkelijkheid wordt voor iedereen die dan nog op SMS of Voice zit.

Loop na waar SMS en Voice in je papieren staan. Je authenticatiebeleid en je MFA-standaard, je onboardingproces en de instructie voor nieuwe medewerkers, de werkinstructies bij je servicedesk, je herstel- en noodprocedures, en je ISMS-documentatie als je met ISO 27001 of NIS2 te maken hebt. In veel van die documenten staat nog letterlijk dat MFA via SMS verloopt, en dat klopt straks niet meer.

Reken er ook op dat je identificatieproces bij de servicedesk zwaarder gaat wegen. Wanneer SMS en Voice OTP wegvalt en je herstel op een TAP gaat leunen, is de manier waarop je iemand aan de telefoon identificeert ineens de zwakste schakel in de keten. Dat is een procesbeslissing en geen instelling in Entra.

Waar ik zou beginnen

  1. Inventariseer wie er nog op SMS of Voice zit. Microsoft heeft daar een script voor: entra-sms-voice-usage-analyzer op GitHub. Elk niet-nul resultaat betekent dat je in scope zit.
  2. Scope SMS en Voice naar de groep die het echt gebruikt. Trek uit je sign-in logs wie er de afgelopen 90 dagen daadwerkelijk met SMS of Voice heeft geauthenticeerd, en zet de methode alleen voor die groep aan in plaats van voor iedereen. Dat verkleint je blootstelling meteen, en je houdt een scherpe lijst over voor je communicatie en voor de vraag of je straks überhaupt een telecomprovider nodig hebt.
  3. Zet de opt-out aan als je nog niet klaar bent om te communiceren, en leg vast wie hem weer uitzet en wanneer. Op 1 februari 2027 vervalt hij hoe dan ook en gaat de passkey-enablement alsnog aan voor je gebruikers.
  4. Kijk of er restricties op je passkey-profiel staan en of Allow self-service setup aan staat. Met attestation of AAGUID-filters gaat deze campagne je niets opleveren en heb je een eigen uitrolpad nodig.
  5. Pak SSPR voordat je naar MFA kijkt. Daar loop je het snelst vast.
  6. Test de aanmeldpaden waar geen SSO-sessie en geen lokale passkey is, en niet alleen je standaard beheerde Windows-laptop. Let op: incognito haalt je SSO-sessie weg, maar niet je Windows Hello for Business. Op Windows blijft de nudge daardoor gewoon onderdrukt. Test dus een combinatie waar geen bruikbare lokale passkey staat: een browser-aanmelding op een Mac, of op een telefoon zonder passkey. Daar krijgen je gebruikers de nudge echt.
  7. Zet je gastgebruikers apart op je lijst. Ze worden nu niet genudged, maar ze zitten wel in scope.
  8. Werk je beleid, procedures en servicedeskinstructies bij.
  9. Communiceer voordat de campagne aan gaat, en niet pas naar aanleiding van de eerste helpdeskvraag.

Tot slot

Voor de duidelijkheid: ik vind dit een goede beweging. SMS en Voice behoren al jaren tot de zwakste methodes die we hebben, SIM-swap en doorschakelen zijn geen theoretische risico's, en passkeys zijn zowel veiliger als prettiger in gebruik. Dat Microsoft er een streep door zet valt goed te verdedigen.

Wat me wel bezighoudt is hoe breed dit uitwaaiert. Dit is niet één instelling die je omzet: het raakt je MFA-methodes, je SSPR-inrichting, je herstelproces, je servicedesk, je gastgebruikers, je beleid en je communicatie naar medewerkers, en op een paar van die punten zijn de details bij Microsoft zelf nog niet af. Daar komt bij dat de mechaniek van de nudge het lastig maakt om te zien hoe ver je eigenlijk bent.

De harde datum is 1 februari 2027 en dat lijkt ver weg. Maar alles wat je voor die tijd moet regelen begint bij weten wie er in scope zit, dus als je één ding uit dit verhaal meeneemt: draai dat script deze week nog.

Bronnen

Blijf op de hoogte

Schrijf je in voor onze nieuwsbrief en ontvang een seintje wanneer we een nieuw artikel publiceren of nieuws te delen hebben.