Wat de migratie naar passkey profiles doet met je bestaande FIDO2-beleid

De bron is MC1221452, voor het eerst gepubliceerd op 23 januari en deze week opnieuw bijgewerkt. Wereldwijd worden passkey profiles en synced passkeys van begin tot eind maart 2026 als GA uitgerold. Tenants die dan nog niet zelf zijn overgestapt, worden van begin april tot eind mei 2026 naar het profielmodel gemigreerd (GCC, GCC High en DoD volgen later, met de migratie in juni). Alleen tenants waar de Passkey (FIDO2)-methode al aanstaat, worden geraakt. De tijdlijn is elders al goed beschreven, dus ik houd het hier bij de mechaniek.

De migratie neemt de tenant-brede FIDO2-instellingen die je nu hebt en zet die in een profiel met de naam Default passkey profile. Je bestaande include targets worden aan dat profiel gekoppeld, je key restrictions (de allow- of blocklist met AAGUID's) gaan mee, en de nieuwe instelling voor het passkey-type wordt afgeleid van één bestaande schakelaar:

• Enforce attestation op Yes wordt alleen device-bound passkeys.
• Enforce attestation op No wordt device-bound én synced passkeys.

Ik verwacht dat die tweede regel veel tenants gaat verrassen. In de omgevingen die ik zie staat attestation vaak uit, om redenen die destijds logisch waren: een security key-pilot die snel is opgezet, of passkeys in Microsoft Authenticator waarvoor attestation in eerste instantie uit moest. Combineer dat met All users als include target, wat veel voorkomt omdat de FIDO2-methode alleen registratie toestaat en niets afdwingt, en na de migratie kan elke gebruiker een passkey registreren in iCloud Keychain, Google Password Manager, 1Password of Bitwarden, zonder dat iemand een instelling heeft aangepast.

Key restrictions dempen dit, maar alleen in één richting. Gebruik je een allowlist met je security key-modellen, dan staan synced providers daar niet op en komen ze er niet in (met een kanttekening over AAGUID's waar ik zo op terugkom). Gebruik je een blocklist, bijvoorbeeld om Authenticator-passkeys buiten de deur te houden tijdens een pilot, dan staan synced providers daar ook niet op en komen ze er dus wel in.

Beide typen zijn phishing-resistent, en voor de meeste gebruikers is een synced passkey een flinke stap vooruit. Het verschil zit in waar de private key staat. Een device-bound passkey blijft op de security key of in Authenticator. Een synced passkey wordt versleuteld opgeslagen bij de passkey provider en is bruikbaar op elk apparaat dat met dat provider-account is aangemeld. Voor veel gebruikers is dat een persoonlijk Apple- of Google-account dat je niet beheert en waarvan je geen inventaris hebt.

Voor beleid is attestation het grotere verschil. Synced passkeys ondersteunen geen attestation, en de documentatie over passkey profiles is duidelijk over de consequentie: met Enforce attestation op No kan Entra ID geen enkel kenmerk van een passkey garanderen, ook niet of hij synced of device-bound is, of welk merk, model of welke provider, zelfs niet als je op specifieke AAGUID's target. Zonder attestation zijn de AAGUID en de indeling in synced of device-bound gewoon wat de authenticator over zichzelf meldt. Microsoft adviseert zelf om AAGUID-lijsten in dat geval als beleidsrichtlijn te zien en niet als securitymaatregel.

Hetzelfde geldt voor Conditional Access. De ingebouwde authentication strength voor phishing-resistant MFA behandelt Passkeys (FIDO2) als één methode, dus een synced passkey voldoet daar net zo goed aan als een FIDO2 security key. Een custom authentication strength kan filteren op AAGUID, maar Microsoft documenteert niet hoe die filter bij het aanmelden wordt geëvalueerd. Voor zover ik kan zien kan hij alleen werken met de AAGUID die Entra bij registratie heeft vastgelegd, en bij een passkey zonder attestation heeft de authenticator die waarde zelf opgegeven. Leunt je beheerdersbeleid op "phishing-resistant MFA" en vallen je beheerders onder een profiel dat synced passkeys toestaat, dan kan de sterkste credential van een beheerdersaccount in een persoonlijk consumentenaccount in de cloud terechtkomen.

Eén asymmetrie is belangrijk als je later wilt aanscherpen. Attestation wordt alleen bij registratie gecontroleerd: passkeys die zonder attestation zijn geregistreerd, blijven werken als je het later alsnog afdwingt. Het passkey-type wordt bij het aanmelden gecontroleerd: haal je Synced uit een profiel, dan kunnen gebruikers in dat profiel niet meer aanmelden met een synced passkey die ze al hadden. Sta je een paar weken synced passkeys toe en trek je ze daarna weer in, reken dan op servicedeskmeldingen van iedereen die in die periode een synced passkey heeft geregistreerd.

Een gebruiker kan onder meer dan één profiel vallen, en registratie of aanmelding lukt als de passkey volledig voldoet aan minstens één daarvan. Er is geen volgorde of voorrang. Een gebruiker uitsluiten van de FIDO2-methode blokkeert passkeys helemaal, dus uitsluiten per profiel kan niet. De documentatie noemt daarnaast een maximum van drie profielen inclusief het Default-profiel, dat je niet kunt verwijderen, en een maximale grootte van 20 KB voor het beleid.

Een strenger profiel voor beheerders doet dus niets als je beheerders ook lid zijn van All users en All users naar een Default-profiel wijst dat synced passkeys toestaat. Het ontwerp dat met deze regels werkt: maak het Default-profiel het strenge profiel (device-bound, attestation afgedwongen, eventueel een allowlist) en voeg een tweede profiel toe dat synced passkeys toestaat, gericht op een groep zonder beheerdersaccounts. Dan houd je één plek over, bijvoorbeeld voor een Authenticator-pilot.

MC1221452 wijzigt ook de registration campaign voor tenants waar de campaign in de status Microsoft managed staat, Passkey (FIDO2) aanstaat, passkey profiles zowel device-bound als synced passkeys toestaan, attestation niet wordt afgedwongen en er geen AAGUID-restricties zijn. Microsoft managed heet in Graph default, en dat is de status van elke tenant die nooit aan de campaign heeft gezeten. Voor die tenants:

• De doelmethode gaat van Microsoft Authenticator naar passkeys (FIDO2).
• Days allowed to snooze gaat van 3 naar 1 en is niet meer instelbaar.
• Limited number of snoozes gaat van Enabled naar Disabled, ook niet meer instelbaar.
• De doelgroep wordt breder: van gebruikers die MFA via SMS of Voice doen naar alle MFA-capabele gebruikers.

Elke MFA-capabele gebruiker in scope krijgt dus na MFA eenmaal per dag een passkey-prompt, en kan die eindeloos overslaan. Wil je de campaign wel, maar op je eigen voorwaarden, dan is het goed om te weten dat de registration campaign-API in de status Enabled op dit moment alleen microsoftAuthenticator als doelmethode accepteert. Je opties zijn nu: Microsoft managed (passkeys, met Microsofts instellingen), Enabled (Authenticator, met jouw instellingen) of Disabled.

Passkey profiles zitten voorlopig in het beta-endpoint van Graph. Vóór de migratie zijn isAttestationEnforced, keyRestrictions en includeTargets de velden die de uitkomst voorspellen; na opt-in of migratie zie je ook passkeyProfiles, elk met passkeyTypes (bijvoorbeeld deviceBound,synced) en attestationEnforcement (disabled of registrationOnly). Let op: in Graph is de property meervoud, terwijl het Message Center-bericht het over passkeyType heeft.

Wil je zien wat je beheerders al hebben geregistreerd, dan geeft het fido2Methods-endpoint per gebruiker aaGuid, attestationLevel en in beta ook passkeyType terug:

• Welke groepen synced passkeys krijgen, en of er een beheerders- of ander geprivilegieerd account lid is van een groep die uiteindelijk in een profiel met synced passkeys valt.
• Of attestation voor jou belangrijk is. Moet je merk en model kunnen vaststellen (gecertificeerde keys, eisen uit regelgeving, AAGUID-filters waar je echt op leunt), dwing het dan af in het strenge profiel en accepteer dat bestaande registraties zonder attestation blijven staan.
• Wat de registration campaign moet doen: Microsoft managed iedereen richting passkeys laten duwen, onder Enabled op Authenticator laten staan, of uitzetten tot je servicedesk en eindgebruikersinstructies klaar zijn.
• Of je zelf overstapt. De documentatie beschrijft nog een opt-out, maar ik zou de opt-in als eenrichtingsverkeer behandelen.

Draai deze week de twee queries hierboven en noteer isAttestationEnforced, de modus van je key restrictions, de include targets en de status van de campaign. Staat daar "false, geen, all_users, default", stap dan vóór april zelf over op passkey profiles en zet het Default-profiel op de configuratie die je voor je beheerders wilt.

Update april 2026: Op 15 april heeft Microsoft MC1221452 bijgewerkt: de automatische migratie voor wereldwijde tenants loopt nu van begin mei tot eind juni 2026, en de wijziging van de registration campaign schuift mee. Die campaign-wijziging geldt nu alleen voor tenants met minstens één gebruiker die zowel synced als device-bound passkeys mag gebruiken, en alleen die gebruikers zonder profielrestricties (attestation of AAGUID) krijgen de prompt. Zie de versiegeschiedenis van MC1221452.

Update juli 2026: Op 13 juli kondigde Microsoft in MC1426371 aan dat passkeys vanaf 1 september 2026 de standaard worden: gebruikers die voor SMS of Voice zijn ingeschakeld, krijgen automatisch passkeys, in een profiel dat alle passkey-typen toestaat, en de registration campaign gaat naar Microsoft managed met passkeys als doel. In dezelfde aankondiging faseert Microsoft de eigen levering van SMS en Voice uit. Het profielontwerp hierboven geldt daardoor voor een veel grotere groep.

• MC1221452: passkey profiles and synced passkeys, inclusief versiegeschiedenis
• MC1426371: passkeys by default en uitfasering van Microsoft-geleverde SMS en Voice
• How to enable passkeys (FIDO2) in Microsoft Entra ID: passkey profiles
• Synced passkeys in Microsoft Entra ID
• Passkeys (FIDO2) authentication method in Microsoft Entra ID
• Custom authentication strengths: advanced options for FIDO2 security keys
• Run a registration campaign to set up a passkey or Microsoft Authenticator
• Microsoft Graph: fido2AuthenticationMethodConfiguration resource type (beta)
• Microsoft Graph: fido2AuthenticationMethod resource type (beta)
• Passkeys by default and retirement of Microsoft-provided SMS and voice authentication