Oprichter van Brainpulse IT en Identity & Endpoint Security Architect in het Microsoft-ecosysteem. Microsoft MVP en Microsoft …
Vijf Conditional Access-regels die elke organisatie nodig heeft
Conditional Access is de plek waar Microsoft Entra ID beslist wie waar bij mag, en onder welke voorwaarden. Het is de policy engine van Zero Trust. Toch treffen wij in veel omgevingen een verzameling regels aan die in de loop der jaren is gegroeid: een uitzondering voor een project, een regel die ooit is aangezet en die niemand meer durft aan te raken.
Dat kan eenvoudiger. Microsoft publiceert zelf sjablonen en richtlijnen voor een veilige basis. In dit artikel zetten wij de vijf regels op een rij die volgens ons in elke organisatie thuishoren. Per regel leest u wat hij doet, waarom hij nodig is en welke valkuilen wij tegenkomen.
Stand per 13 oktober 2026.
Wat heeft u nodig?
Conditional Access vereist Microsoft Entra ID P1. Organisaties met Microsoft 365 Business Premium kunnen het ook gebruiken. Voor de risicogebaseerde regels (regel 5) is Entra ID P2 nodig, omdat die leunen op Microsoft Entra ID Protection. Heeft u geen van beide, dan bieden de security defaults een basisbescherming, waaronder het blokkeren van verouderde authenticatie.
Regel 1: MFA voor alle gebruikers
Wat: één basisregel die voor alle gebruikers en alle resources multifactorauthenticatie (MFA) vraagt. Microsoft beschrijft één basisregel zonder app-uitzonderingen als uitgangspunt voor elke organisatie. Het sjabloon gebruikt daarvoor de ingebouwde authentication strength voor MFA.
Waarom: een wachtwoord alleen is te makkelijk te raden, te lekken of af te vangen. Deze regel is het vangnet onder alle andere regels.
Valkuilen:
- Uitzonderingen voor het kantoornetwerk. Technisch kan dat, maar dan wordt een IP-adres de sleutel. Wij kiezen liever voor MFA overal, gecombineerd met een beheerd apparaat met Windows Hello for Business, zodat aanmelden prettig blijft.
- Uitzonderingen per app die tijdelijk nodig waren en nooit zijn teruggedraaid.
- Het synchronisatieaccount vergeten. Gebruikt u Entra Connect of Cloud Sync, sluit dan de rol Directory Synchronization Accounts uit.
Regel 2: Phishingbestendige MFA voor beheerders
Wat: beheerdersrollen krijgen een strengere eis: de authentication strength Phishing-resistant MFA. Daaronder vallen methoden als Windows Hello for Business, passkeys (FIDO2) en certificate-based authentication. Een code of pushmelding in een app telt niet mee. Het sjabloon somt de rollen op die er minimaal onder vallen, van Global Administrator tot Helpdesk Administrator.
Waarom: een overgenomen beheerdersaccount richt de meeste schade aan, en juist die accounts zijn een geliefd doelwit. Codes en pushmeldingen zijn gevoelig voor phishing op afstand. Phishingbestendige methoden vereisen interactie tussen de aanmeldmethode en het apparaat of de app waarop wordt aangemeld.
Valkuilen:
- Inschakelen voordat beheerders een geschikte methode hebben. Zo sluit u uzelf buiten. Laat beheerders eerst met een Temporary Access Pass een passkey registreren.
- Leunen op aangepaste rollen. Conditional Access dwingt deze regel niet af voor aangepaste rollen of rollen die zijn beperkt tot een administrative unit. Daar ontstaat dan ongemerkt een gat.
Regel 3: Verouderde authenticatie blokkeren
Wat: oude protocollen en clients die geen MFA ondersteunen, zoals Exchange ActiveSync met basisauthenticatie, worden voor alle gebruikers geblokkeerd.
Waarom: volgens de analyse van Microsoft gebruikt meer dan 97 procent van de credential stuffing-aanvallen en meer dan 99 procent van de password spray-aanvallen verouderde authenticatie. Met deze regel sluit u dat kanaal in één keer af.
Valkuilen:
- Blind aanzetten. Kijk eerst in de aanmeldlogs welke clients nog oude protocollen gebruiken, ook bij de niet-interactieve aanmeldingen. Een kant-en-klare werkmap in Entra ID helpt daarbij.
- De uitzondering voor die ene scanner of applicatie. Zulke uitzonderingen blijven vaak jaren staan. Geef ze een eigenaar en een einddatum.
Regel 4: Alleen beheerde apparaten of beschermde apps
Wat: volledige toegang tot bedrijfsgegevens alleen vanaf apparaten die voldoen aan uw Intune-compliancebeleid of hybrid joined zijn. Op iOS en Android vraagt u een app protection policy. Microsoft adviseert daarnaast onbekende of niet-ondersteunde apparaatplatforms te blokkeren.
Waarom: MFA bewijst wie er aanmeldt, niet waarop. Een geldige aanmelding vanaf een onbeheerde of besmette laptop blijft een risico voor uw gegevens. Voor onbeheerde apparaten kiezen wij daarom vaak een beperkte route met de sessiecontrole Use app enforced restrictions. SharePoint, OneDrive en Outlook op het web geven zo’n apparaat dan een beperkte ervaring, bijvoorbeeld werken in de browser zonder bestanden te downloaden.
Valkuilen:
- Compliancebeleid dat niet op orde is. Deze regel is zo sterk als het Intune-beleid eronder.
- Regels met Require approved client app. Sinds 30 juni 2026 staat die controle in alleen-lezen modus. Nieuwe regels bouwt u met Require app protection policy.
- Certificaatmeldingen tijdens de test. In report-only kan een regel die een compliant apparaat vereist op macOS, iOS en Android toch om een certificaat vragen. Sluit die platforms in de testfase daarom uit.
Regel 5: Ingrijpen op risico
Wat: Microsoft Entra ID Protection berekent per aanmelding (sign-in risk) en per gebruiker (user risk) hoe waarschijnlijk het is dat een account wordt misbruikt. De sjablonen vragen MFA bij een gemiddeld of hoog aanmeldrisico, en herstel, zoals een veilige wachtwoordwijziging, bij een hoog gebruikersrisico. Hiervoor is Entra ID P2 nodig.
Waarom: de eerste vier regels zijn statisch. Deze regel reageert op wat er op dat moment gebeurt, zoals een gelekt wachtwoord of een aanmelding die afwijkt van het normale patroon.
Valkuilen:
- Gebruikers zonder geregistreerde MFA. Zij kunnen een risicovolle aanmelding niet zelf oplossen en worden geblokkeerd. Zorg eerst dat iedereen is geregistreerd.
- Beide risico’s in één regel. De documentatie waarschuwt daar expliciet voor: maak voor aanmeldrisico en gebruikersrisico elk een eigen regel.
- De oude risicobeleidsregels in ID Protection. Microsoft noemt 1 oktober 2026 als datum waarop deze worden uitgefaseerd, en die datum is inmiddels verstreken. Staat er bij u nog risicobeleid in ID Protection, zet het dan alsnog over naar Conditional Access.
Het fundament onder de vijf regels
Noodaccounts
Microsoft adviseert minimaal twee noodaccounts (break-glass): cloud-only op het .onmicrosoft.com-domein, beveiligd met een passkey (FIDO2) of certificaat dat verschilt van uw gewone beheerdersaccounts, en uitgesloten van elke regel die aanmelden blokkeert of beperkt. Elk gebruik geeft een melding, en minstens elke 90 dagen test u of de accounts nog werken.
Let op: een regel die u vanuit een sjabloon maakt, sluit alleen het account uit waarmee u hem aanmaakt. Uw noodaccounts voegt u zelf toe.
Eerst report-only
Elke regel start in report-only. De sjablonen doen dat standaard. U ziet in de aanmeldlogs wat de regel zou doen, zonder dat iemand wordt geblokkeerd. Daarna laten wij een regel gefaseerd ingaan: eerst een pilotgroep, dan de rest van de organisatie.
Een vaste structuur en naamgeving
Kies een naamgevingsconventie waaruit doel, doelgroep en scope direct blijken. Een regel heeft geen eigenaarveld, dus legt u de eigenaar vast in de naam en in een register. Wij werken met een vaste opbouw van nummer, doelgroep, toepassing en controle. Zo ziet iedereen in één oogopslag waarvoor een regel bestaat.
Uitzonderingen beheersen
Hier ontstaan de meeste problemen. Een uitzondering is snel gemaakt, maar wordt zelden opgeruimd. Uitgesloten gebruikers weten vaak niet dat ze zijn uitgesloten, iemand kan zichzelf aan een uitsluitingsgroep toevoegen en de reden voor een uitzondering kan allang zijn vervallen.
Ons uitgangspunt: zo min mogelijk uitzonderingen, elk met een eigenaar, een reden en een einddatum. Met access reviews (Entra ID P2 of Entra ID Governance) maakt u periodieke controle aantoonbaar. Bescherm wijzigingen aan de regels zelf met protected actions.
En de Cyberbeveiligingswet?
Artikel 21 van de Cyberbeveiligingswet noemt toegangsbeleid en, waar gepast, multifactorauthenticatie als onderwerpen die uw maatregelen moeten afdekken. Een heldere Conditional Access-architectuur is dus niet alleen veiliger, maar ook beter aan te tonen. Lees meer in ons artikel over de Cyberbeveiligingswet.
Hoe wij kunnen helpen
Oprichter Stefan Dingemanse is al zeven jaar Microsoft MVP, in zowel Security (Intune) als Windows and Devices (Windows 365), en Microsoft Certified Trainer. In veel omgevingen staat Conditional Access vol uitzonderingen die niemand meer kan uitleggen. Met onze consultancy voor Identity Protection ontwerpen wij een architectuur met een vaste structuur en zo min mogelijk uitzonderingen. Wij brengen eerst uw bestaande regels in kaart en voeren het nieuwe ontwerp daarna gefaseerd in, via report-only en zonder verrassingen voor uw gebruikers.
Wilt u eerst weten waar u staat? De Security Health Check meet uw Conditional Access- en MFA-inrichting tegen de CIS-benchmark, de CISA-baselines en Zero Trust, en laat zien waar uw omgeving afwijkt.