Begin bij de beheerders en dwing via Conditional Access de ingebouwde authentication strength Phishing-resistant MFA af. Die staat uitsluitend Windows Hello for Business of een platformcredential toe, een FIDO2 security key, of Entra certificate-based authentication (multifactor). Sms en push-goedkeuringen voldoen voor die accounts niet meer aan het beleid op de resources die het afdekt, al blijft de wachtwoordprompt bestaan (zie Wat er misgaat).
Waarom beheerders als eerste
Het authenticatie-overzicht van Microsoft stelt dat MFA op basis van sms, e-mail-OTP of authenticator-apps gevoelig is voor phishing op afstand, waarbij aanvallers wachtwoorden of eenmalige codes buitmaken zonder het apparaat van de gebruiker aan te raken. Microsoft adviseert in plaats daarvan Windows Hello for Business, passkeys (FIDO2), FIDO2 security keys of certificate-based authentication. Bij een beheerdersaccount kost een gestolen code het meest, en een klein team heeft er slechts een handvol om over te zetten.
Wees voorzichtig met de middelste ingebouwde optie. Volgens de documentatie over authentication strengths omvat de strength Passwordless MFA ook inloggen met Microsoft Authenticator op de telefoon. De strength Phishing-resistant doet dat niet.
Het tenant voorbereiden
Passkeys (FIDO2) zijn beschikbaar in alle Entra ID-edities zonder extra licentie. Voor Conditional Access hebt u Entra ID P1 nodig.
De instellingen vindt u onder Entra ID > Security > Authentication methods > Policies > Passkey (FIDO2). U hebt minimaal de rol Authentication Policy Administrator nodig. Drie details zijn van belang:
- Kiezen voor passkey profiles is onomkeerbaar. U kunt daarna niet meer terug en uw huidige globale instellingen gaan over naar een Default-profiel. Er worden maximaal drie profielen ondersteund, inclusief Default.
- Allow self-service set up moet op Yes staan, anders kunnen gebruikers geen passkey registreren via Security info. Dit is een globale instelling, geen instelling per profiel.
- Voor registratie is MFA nodig die in de afgelopen vijf minuten is voltooid.
Voor beheerders is het eigen voorbeeld uit de documentatie een profiel met passkey type Device-bound en Enforce attestation op Yes. Device-bound betekent dat de private key nooit het fysieke apparaat verlaat, zoals een security key of Microsoft Authenticator. Gesynchroniseerde passkeys ondersteunen geen attestation, en Microsoft zegt dat u ze als phishing-resistent moet beschouwen, maar met het beveiligingsniveau van andere authenticators zonder attestation. De NIST-tekst vereist op AAL3, het hoogste niveau, een phishing-resistente authenticator met een niet-exporteerbare sleutel. Device-bound keys komen daar dus het dichtst bij van de opties in Entra.
Afdwingen met een authentication strength
Maak een Conditional Access-beleid aan, richt het op uw beheerdersrollen of -groep en kies onder grant controls Require authentication strength. Selecteer Phishing-resistant MFA. U kunt dit niet combineren met Require multifactor authentication in hetzelfde beleid, omdat de ingebouwde MFA-strength gelijkstaat aan die control.
Ingebouwde strengths kunt u niet aanpassen en Microsoft werkt ze bij wanneer er nieuwe methoden verschijnen. Hebt u een vaste set toegestane methoden nodig, maak dan een custom strength.
U hoeft sms niet voor iedereen uit te schakelen. De strength ligt bovenop het Authentication methods-beleid en vernauwt dat voor een bepaald scenario. Medewerkers kunnen voor gewone resources een wachtwoord en push-goedkeuring blijven gebruiken, terwijl voor beheerders het strengere beleid geldt.
Wat er misgaat
Een beheerder typt nog steeds eerst een wachtwoord. Conditional Access wordt pas na de eerste authenticatie beoordeeld, dus de strength eist pas daarna een phishing-resistente methode.
Als een gebruiker inlogt met een wachtwoord als primaire methode en de strength Windows Hello for Business vereist, krijgt de gebruiker daar geen prompt voor. Die moet de sessie opnieuw starten, Sign-in options selecteren en de vereiste methode kiezen. Neem dat op in uw instructies voor beheerders.
Twee controls werken op verschillende momenten. Enforce attestation geldt alleen bij registratie, dus een passkey die zonder attestation is geregistreerd, wordt bij het inloggen niet geblokkeerd zodra u de instelling inschakelt. Registreer beheerderssleutels daarna opnieuw. Sleutelbeperkingen op basis van AAGUID gelden zowel bij registratie als bij inloggen, dus als u een eerder toegestane AAGUID verwijdert, sluit u iedereen buiten die dat model heeft geregistreerd.
Overlap tussen profielen is ruimhartig en werkt door in registratie en inloggen op het niveau van het passkey-beleid. Valt een gebruiker onder meerdere profielen, dan is een passkey toegestaan als die volledig aan minstens één ervan voldoet, in willekeurige volgorde. Een beheerder die ook in een groep "alle gesynchroniseerde of device-bound passkeys" zit, kan dus een gesynchroniseerde passkey registreren en gebruiken voor zover het passkey-beleid betreft. De bronnen geven niet aan of de Conditional Access-strength die accepteert, dus test dit geval.
Controleer na het opt-in het Default-profiel onder Enable and target. Als het doel All users is en het gesynchroniseerde passkeys toestaat, richt het dan opnieuw op groepen waarin uw beheerders niet zitten. Sluit beheerders niet uit in het Passkey (FIDO2)-beleid: een uitgesloten groep wordt volledig geblokkeerd voor FIDO2-registratie en -inlog, en dat gaat boven elke insluiting.
Sign-in frequency en strength kunnen op verschillende momenten worden voldaan. Met een passkey-strength en een sign-in frequency van 1 uur voldoen een passkey-login van 24 uur geleden plus een Windows Hello-ontgrendeling van vandaag aan beide. Als u voor beheerders op korte frequenties vertrouwt, test dan dit geval.
Temporary Access Pass komt voor in de MFA-strength, maar niet in de phishing-resistente. Onze eigen conclusie, die de bronnen niet vermelden: een herstel- of bootstrapflow op basis van een Temporary Access Pass voldoet niet aan het beleid en heeft dus een uitsluiting of een apart beleid nodig. Beslis dat voordat u gaat afdwingen, niet tijdens het incident.
Waar te beginnen
- Maak een lijst van alle accounts met een beheerdersrol en kies er twee of drie voor de pilotgroep.
- Kies voor passkey profiles, controleer het doel van het Default-profiel, maak een beheerdersprofiel met Device-bound en Enforce attestation op Yes, en richt dat alleen op de pilotgroep.
- Registreer per pilotbeheerder minstens twee authenticators, bijvoorbeeld een security key en Windows Hello, en controleer dat inloggen met elk ervan werkt.
- Maak het Conditional Access-beleid met de strength Phishing-resistant MFA voor de pilotgroep. Als algemene werkwijze (de hier gebruikte Microsoft-pagina's behandelen break-glass-accounts niet): sluit noodtoegangsaccounts uit en geef elk account een eigen FIDO2-key.
- Breid uit naar alle beheerders. Verwijder passkeys die vóór het afdwingen van attestation zijn geregistreerd pas nadat elke beheerder een key met attestation opnieuw heeft geregistreerd, zodat niemand buitengesloten raakt.
- Laat het resultaat testen. Ons consultingteam kan het beleid beoordelen en een penetratietest laat zien of een beheerderspad nog een zwakkere methode accepteert.
