Risicobeleid uit ID Protection naar Conditional Access vóór 1 oktober

De legacy policies waren eenvoudig, en daardoor mis je bij het migreren makkelijk iets. Elke policy had een gebruikerstoewijzing (alle gebruikers of geselecteerde groepen, met uitsluitingen), één risicodrempel en één control: blokkeren, of toestaan met een wachtwoordwijziging (user risk) of MFA (sign-in risk). Geen app-targeting, geen andere condities, geen session controls, geen report-only, alleen een schakelaar Enforce policy. De drempels waren cumulatief ("Medium and above"), terwijl je in Conditional Access losse niveaus aanvinkt. Een legacy "Medium and above" wordt dus Medium plus High, en vergeten High aan te vinken is precies het soort fout dat ik deze maand in meer dan één tenant verwacht tegen te komen.

Een legacy policy staat ook niet op het tabblad Conditional Access van een sign-in event. Hij verschijnt in authenticationRequirementPolicies van de sign-in, als tenantSessionRiskPolicy of accountCompromisePolicies. Microsoft documenteert niet welke legacy policy bij welke waarde hoort; afgaand op de namen is de eerste de sign-in risk policy en de tweede de user risk policy. Daar komen we straks op terug om de legacy policies te vinden.

De configuratiehandleiding zegt expliciet dat je user risk en sign-in risk niet in één Conditional Access policy moet combineren. Condities worden met EN gecombineerd, dus een samengevoegde policy gaat alleen af als beide tegelijk verhoogd zijn. Twee legacy policies worden minstens twee Conditional Access policies.

In Conditional Access is "require MFA" een eis aan het token, en dat betekent niet dat de gebruiker altijd een prompt krijgt. De ID Protection FAQ zegt het letterlijk: een sign-in risk policy die MFA eist, stelt alleen een nieuwe challenge als er nog geen MFA-claim op het bestaande token zit. Op een Windows-apparaat met een PRT die een MFA-claim draagt, of in een browsersessie die een uur geleden MFA deed, voldoet een risicovolle sign-in aan de policy zonder dat de gebruiker iets ziet. Komt het risico van een hergebruikte sessiecookie of een adversary-in-the-middle kit, dan draagt de sessie van de aanvaller diezelfde claim. Microsoft remedieert token theft-detecties zoals Anomalous token en Attacker in the Middle om die reden al niet meer automatisch op basis van een bestaande MFA-claim.

Met sign-in frequency op Every time dwing je een verse authenticatie af zodra de sessie wordt geëvalueerd, en die verse sterke authenticatie is wat het sign-in risk remedieert. De documentatie van Microsoft is het hier niet helemaal met zichzelf eens (de configuratiehandleiding raadt het aan, de FAQ noemt het een kwestie van risicobereidheid en waarschuwt voor MFA-moeheid). Voor risk policies vind ik dat moeheidsargument zwak, omdat de prompt alleen verschijnt als het risico verhoogd is, en dat is precies het moment waarop je hem wilt.

De grant Require password change is een secure password change: de gebruiker doet eerst MFA en kiest dan een nieuw wachtwoord, zonder SSPR. Er zitten beperkingen aan waar je bij een migratie over struikelt. De policy moet All resources targeten, je kunt hem niet combineren met andere grant controls zoals een compliant device, en de enige toegestane condities zijn gebruikers en user risk. Gebruikers die niet voor MFA geregistreerd zijn voordat ze risicovol worden, zijn gewoon geblokkeerd, en voor hybride gebruikers moet password writeback aanstaan.

Die flow gaat ervan uit dat de gebruiker het huidige wachtwoord kent. Wie inlogt met een passkey of Windows Hello for Business en het eigen wachtwoord nooit heeft gekend, loopt vast. Voordat de nieuwe control er was, adviseerde Microsoft zelf om passwordless gebruikers met hoog user risk in een aparte policy te blokkeren en daarna door een beheerder te laten remediëren. (Een reset via SSPR remedieert user risk ook, maar dat is voor een geblokkeerde gebruiker nauwelijks een plan.)

De oplossing is de grant Require risk remediation, sinds november 2025 in public preview en sinds juni 2026 zonder preview-label gedocumenteerd. ID Protection kiest zelf de remediatie. Gaat de detectie over het wachtwoord (leaked credentials, password spray), dan doet de gebruiker een secure password change en worden eerdere sessies ingetrokken. Gaat het niet over het wachtwoord (anomalous token, impossible travel, unfamiliar sign-in properties), dan worden de sessies ingetrokken en logt de gebruiker opnieuw in. Bij een apparaat dat door een aanvaller is toegevoegd, wordt bovendien het Entra device object uitgeschakeld. Kies je deze control, dan worden Require authentication strength en een verplichte Sign-in frequency van Every time automatisch toegevoegd, want sessies intrekken zonder direct een verse sign-in remedieert niets.

Voor een migratie is van belang dat deze control alleen user risk remedieert (je hebt dus nog steeds een sign-in risk policy nodig) en niet werkt voor gasten en externe gebruikers. Valt een gebruiker onder meerdere user risk policies, dan wint Block van alles en wint Require risk remediation van Require password change. De remediatie loopt via een eigen app (93625bc8-bfe2-437a-97e0-3d0060024faa) die door andere Conditional Access policies niet wordt tegengehouden, dus verwacht die in je sign-in logs.

De authentication strength die je kiest, bepaalt wie kan remediëren. Kies je Phishing-resistant MFA voor gebruikers die vooral Authenticator push hebben, dan kunnen die niet remediëren en werkt de policy voor hen als een blokkade. Het advies van Microsoft voor sign-in risk volgt dezelfde logica: de ingebouwde strength Multifactor authentication voor iedereen, en een aparte policy met Passwordless MFA of Phishing-resistant MFA voor een passwordless groep. Eén geval zou ik testen voordat ik erop vertrouw in productie: een passwordless gebruiker met een leaked credentials-detectie, want de documentatie zegt alleen dat de flow afhangt van zowel de dreiging als de authenticatiemethode.

Microsoft documenteert hier ook Microsoft-managed policies: Require remediation for high-risk users (met een eigen security group), Block access for high-risk users, en MFA and reauthentication for risky sign-ins. Ze komen binnen in report-only en gaan op zijn vroegst 30 dagen later vanzelf aan, tenzij je ze zelf op On of Off zet. Met die volgorderegels overschrijft een managed blokkeerpolicy die zichzelf aanzet jouw self-remediation policy, dus neem per policy zelf een besluit in plaats van de timer te laten beslissen.

Er gaat niets stuk. Detectie loopt door en sign-ins blijven werken. Volgens de FAQ lost laag user risk zichzelf na zes maanden op, maar medium en hoog user risk worden nooit automatisch opgelost zonder risk policy of een beheerder die het risico wegklikt. Een gebruiker van wie de credentials zijn uitgelekt, blijft gewoon met dat wachtwoord inloggen.

Sign-in risk verbergt het gat goed. In een tenant met een MFA-policy voor alle gebruikers remedieert ID Protection de meeste risicovolle sign-ins automatisch zodra de gebruiker toch al MFA doet, dus het rapport Risky sign-ins ziet er netjes uit. Het gat zie je in Risky users, als een langzaam groeiende lijst gebruikers op High met status At risk. De documentatie zegt ook niet of legacy policies die op 1 oktober nog aanstaan dan stoppen met handhaven of verdwijnen, en een automatische conversie is nergens beschreven. Voor een tenant die niet is gemigreerd, komt het allebei op hetzelfde neer: er wordt geen risk policy meer gehandhaafd.

Ik heb geen ondersteund Graph-endpoint gevonden dat de configuratie van de legacy policies teruggeeft (Microsoft noemt Graph-ondersteuning juist als een van de redenen om over te stappen). In de portal vind je ze onder ID Protection > Dashboard > User risk policy of Sign-in risk policy, en daar kijk je naar Enforce policy. De audit log legt wijzigingen vast als Update Sign-In Risk Policy en Update User Risk and MFA Registration Policy, handig als iemand er recent een heeft uitgezet.

De sign-in logs laten zien wat er echt is afgegaan. Gaan die naar Log Analytics, dan heeft Microsofts workbook Impact analysis of risk-based access policies een sectie voor legacy Identity Protection policies. Voor de kale aantallen gebruik ik mijn eigen query, die op de twee waarden van hierboven zoekt:

Zet daarna de Conditional Access policies in report-only naast de legacy policies die nog aanstaan, en vergelijk beide oordelen voor dezelfde risicovolle sign-ins:

Legacy applied in combinatie met reportOnlyNotApplied is een gat in de dekking, meestal een uitsluitingsgroep of een risiconiveau dat je niet hebt aangevinkt. Wees voorzichtig met reportOnlySuccess: report-only telt een MFA-eis als voldaan als het token al een MFA-claim bevat, dus een policy zonder Every time ziet er in report-only een stuk groener uit dan terecht is.

Uitsluitingen uit de legacy policies gaan niet vanzelf mee, dus bouw ze bewust opnieuw op. Break-glass accounts horen buiten de risk policies, gecombineerd met een alert op elke sign-in van die accounts. Gebruikersaccounts die als serviceaccount dienen, kunnen geen MFA of wachtwoordwijziging doen en worden dus geblokkeerd als ze risicovol worden. Ze uitsluiten laat accounts zonder enige risicocontrole achter; de echte oplossing is ze om te zetten naar managed identities of workload identities. Voor gasten moet je apart een keuze maken, omdat Require risk remediation ze niet ondersteunt.

Risk-based Conditional Access vraagt Microsoft Entra ID P2 (of Entra Suite) voor de gebruikers die eronder vallen, net als de legacy policies. De pagina License usage toont inmiddels "Risk-based Conditional Access users" naast je P2-aantallen, dus een gemigreerde policy op All users maakt een licentietekort snel zichtbaar.

Deze week: draai de eerste query om te zien welke legacy policies echt afgaan, bouw aparte user risk en sign-in risk policies in report-only met de niveaus los aangevinkt en Every time ingesteld, vergelijk een week lang met de tweede query, zet ze dan aan en zet de legacy policies op Disabled. Open daarna Risky users en werk iedereen op High af die nog op At risk staat.

Update september 2026: Microsoft kondigde in MC1476122 (21 september) aan dat de Microsoft-managed policy "Require risk remediation for high-risk users" vanaf de week van 28 september in report-only wordt aangemaakt en na 30 dagen vanzelf op On gaat, tenzij je hem zelf op On of Off zet. Hij werd het eerst gezien in onderwijstenants; controleer je policylijst op deze policy en de bijbehorende security group.

• Configure and enable risk policies
• Risk-based access policies en de control Require risk remediation
• Microsoft Entra ID Protection FAQ
• Remediate risks and unblock users
• Conditional Access grant controls: Require password change
• Conditional Access session lifetime: Require reauthentication every time
• Microsoft-managed Conditional Access policies
• Conditional Access report-only mode
• authenticationRequirementPolicy resource type (Microsoft Graph beta)
• Workbook Impact analysis of risk-based access policies
• Microsoft Entra audit log activities
• License usage insights in Microsoft Entra
• MC1476122: Microsoft-managed policy Require risk remediation for high-risk users