Conditional Access invoeren zonder jezelf buiten te sluiten

3 mei 2026

Voer Conditional Access veilig in met een pilot, noodaccounts, rapportmodus, sterke MFA en een aantoonbare controlecyclus.

Conditional Access bepaalt onder welke voorwaarden iemand toegang krijgt tot Microsoft 365. Je kunt er bijvoorbeeld multifactor-authenticatie mee afdwingen, verouderde aanmeldmethoden blokkeren en beheerders extra beschermen. Dat maakt het een van de belangrijkste beveiligingslagen in Microsoft Entra ID.

Dezelfde kracht brengt een risico mee. Een te brede of verkeerd geteste regel kan legitieme medewerkers, beheerders of automatisering blokkeren. In het slechtste geval kan niemand de fout nog herstellen. Een veilige invoering draait daarom niet alleen om drie goede regels. Je hebt ook noodtoegang, een representatieve pilot, rapportmodus, logcontrole en een vaste beheercyclus nodig.

Deze gids helpt een MKB-organisatie om Conditional Access beheerst in te voeren. Het koopmotief is praktisch: minder accountmisbruik en minder herstelwerk, zonder dat de IT-manager continu uitzonderingen hoeft op te lossen. Wil je weten welke identiteitsrisico's en beheerhiaten nu in je Microsoft 365-omgeving zitten? Laat je omgeving controleren met de SCAV-IT IT-scan.

Wat Conditional Access wel en niet doet

Conditional Access beoordeelt signalen rond een aanmelding en past daarna toegangsregels toe. Denk aan de gebruiker, de gebruikte toepassing, de locatie, het apparaat, het risiconiveau en de gekozen authenticatiemethode. Een regel kan toegang toestaan, blokkeren of een extra voorwaarde eisen.

Het is geen vervanging voor goed accountbeheer. Een oud account dat actief blijft, een beheerder met te veel rechten of een verkeerd ingerichte herstelprocedure blijft een risico. Combineer Conditional Access daarom met periodieke controles van accounts, rollen en aanmeldingen. De handleiding over MFA instellen voor Microsoft 365 legt de basis voor normale gebruikers uit. Voor tijdelijke beheerdersrechten is Privileged Identity Management voor beheerders de relevante vervolgstap.

Voor eigen Conditional Access-beleid is Microsoft Entra ID P1 nodig. Dat zit onder meer in Microsoft 365 Business Premium. Controleer licenties voordat je beleid ontwerpt. Een technisch werkende regel is niet automatisch licentietechnisch passend.

Begin met twee onafhankelijke noodaccounts

Microsoft adviseert twee of meer emergency access-accounts, vaak noodaccounts of break-glassaccounts genoemd. Ze zijn uitsluitend bedoeld voor situaties waarin normale beheerders niet kunnen aanmelden of hun rol niet kunnen activeren. Voorbeelden zijn een storing bij een identiteitsprovider, verloren MFA-apparaten, een fout in Conditional Access of een vastgelopen PIM-goedkeuring.

Richt deze accounts anders in dan normale beheerders:

maak ze cloud-only in het onmicrosoft.com-domein;
synchroniseer of federeer ze niet vanuit een lokaal systeem;
wijs Global Administrator permanent en actief toe, niet alleen eligible via PIM;
gebruik een phishingbestendige methode, bij voorkeur een FIDO2-beveiligingssleutel;
gebruik niet dezelfde authenticatieafhankelijkheid als bij normale beheerders;
koppel ze niet aan een persoonlijke telefoon van een medewerker;
bewaar sleutels of andere benodigdheden beveiligd op gescheiden locaties;
zorg dat credentials, sleutels en accounts niet verlopen of automatisch worden opgeschoond;
registreer wie toegang mag krijgen en wanneer gebruik is toegestaan.

Microsoft adviseert om noodaccounts uit te sluiten van Conditional Access-beleid dat aanmelden blokkeert of beperkt. Dat voelt tegenstrijdig, maar een noodaccount dat een compliant apparaat, beschikbaar bedrijfsnetwerk of werkende telefoon nodig heeft, kan juist tijdens een storing onbruikbaar zijn. De bescherming komt dan uit phishingbestendige authenticatie, veilige opslag, beperkte bekendheid en directe bewaking van ieder gebruik.

Gebruik bij voorkeur één beveiligingsgroep voor de noodaccounts en sluit die groep bewust uit van blokkerend of beperkend beleid. Rapport-onlybeleid blokkeert niets en heeft daarom geen uitsluiting nodig. Noteer de uitsluiting bij iedere regel. Zo voorkom je dat een latere beheerder de groep verwijdert omdat de reden onbekend is.

Maak eerst een aanmeldinventaris

Voordat je regels activeert, moet je weten wat er werkelijk aanmeldt. Breng minimaal het volgende in kaart:

Onderdeel	Te controleren
Medewerkers	Normale gebruikers, directie, buitendienst en tijdelijke krachten
Beheerders	Permanente en tijdelijke rollen, partnerbeheer en serviceaccounts
Apparaten	Beheerd, privé, mobiel, gedeeld en apparaten zonder Intune-inschrijving
Toepassingen	Microsoft 365, Azure, SaaS-koppelingen en bedrijfskritische cloudapps
Locaties	Kantoor, thuiswerk, buitenland, vaste uitgaande IP-adressen en VPN
Automatisering	SMTP, scanners, scripts, back-up, integraties en oudere clients
Gasten	Leveranciers, klanten en andere externe gebruikers

Bekijk de aanmeldlogboeken over een representatieve periode. Neem daarin ook maandafsluiting, thuiswerk, reizen en terugkerende automatisering mee. Eén rustige werkdag is geen betrouwbare basis.

Let vooral op legacy authentication. Oudere protocollen ondersteunen moderne toegangscontroles en MFA vaak niet goed. Blokkeren is wenselijk, maar inventariseer eerst scanners, multifunctionals, applicaties en mailboxkoppelingen die er nog van afhankelijk zijn. Plan voor iedere afhankelijkheid een moderne route of een expliciet uitfaseringsbesluit.

Ontwerp drie basisregels met duidelijke scope

Een bruikbare eerste set bestaat uit drie afzonderlijke regels. Houd ze gescheiden, zodat effect, uitzondering en storing per doel te onderzoeken zijn.

Regel 1: legacy authentication blokkeren

Blokkeer verouderde aanmeldprotocollen voor alle relevante gebruikers. Test eerst welke processen nog geraakt worden. Los afhankelijkheden structureel op in plaats van brede permanente uitzonderingen te maken.

Regel 2: MFA voor normale toegang

Eis MFA voor gebruikers die Microsoft 365 en andere relevante cloudapps openen. Kies doelgroepen en uitzonderingen expliciet. Service-identiteiten horen niet zonder analyse in een gebruikersbeleid. Moderne workload identities vragen een eigen beheerroute.

Regel 3: phishingbestendige MFA voor beheerders

Beheerders zijn extra waardevolle doelwitten. Microsoft Entra biedt een ingebouwde Phishing-resistant MFA strength. Die accepteert methoden zoals FIDO2-passkeys, Windows Hello for Business en multifactor certificate-based authentication. Een pushmelding in Microsoft Authenticator is wel MFA, maar voldoet niet aan deze phishingbestendige sterkte.

Activeer de benodigde authenticatiemethoden eerst voor de pilotgroep. Laat beheerders registreren en testen voordat je de regel afdwingt. Combineer in dezelfde regel niet zowel Require multifactor authentication als Require authentication strength. Microsoft documenteert die combinatie als niet ondersteund, omdat de MFA authentication strength al het bijbehorende grant control vertegenwoordigt.

Gebruik rapportmodus als meetfase

Zet nieuwe regels eerst op report-only. In die stand beoordeelt Entra wat de regel zou doen, zonder toegang daadwerkelijk te blokkeren. Bekijk daarna de Conditional Access-resultaten in de aanmeldlogboeken.

Controleer niet alleen hoeveel aanmeldingen zouden slagen. Onderzoek juist:

welke gebruikers zouden worden geblokkeerd;
welke applicaties of clients veroorzaken de blokkade;
welke gebruikers vallen door een uitsluiting buiten de regel;
welke authenticatiemethoden worden werkelijk gebruikt;
welke apparaten niet aan de gewenste voorwaarden voldoen;
of noodaccounts buiten blokkerend beleid blijven;
of serviceprocessen onbedoeld als gebruiker worden behandeld;
welke landen, IP-adressen en gebruiksmomenten onverwacht zijn.

Leg per uitzondering vast: zakelijke reden, eigenaar, exacte scope, goedkeurder en einddatum. Gebruik geen brede groep met de naam exclude zonder context. Een uitzondering zonder herbeoordelingsdatum wordt meestal een permanent gat.

Microsoft biedt de What If-tool om beleid voor een voorbeeldsituatie te evalueren. Gebruik die naast de echte logboeken. Een simulatie bewijst het ontwerp, maar alleen werkelijke aanmeldingen tonen onbekende clients, oude integraties en afwijkend gebruikersgedrag.

Activeer in kleine ringen

Ga van report-only naar handhaving via beperkte groepen:

begin met IT-beheerders en testaccounts die snel ondersteuning kunnen krijgen;
voeg een representatieve groep toe met verschillende functies, apparaten en werklocaties;
beoordeel blokkades, helpdeskvragen en uitzonderingen;
breid pas daarna uit naar de rest van de organisatie;
plan een terugvalroute en leg vast wie een regel mag uitschakelen.

Activeer niet meerdere nieuwe regels op hetzelfde moment voor de hele organisatie. Als er dan problemen ontstaan, is onduidelijk welke voorwaarde de oorzaak is. Kleine wijzigingen maken diagnose sneller en verkleinen operationele impact.

Plan de handhaving tijdens een bemand wijzigingsvenster. De verantwoordelijke beheerder moet toegang hebben tot de aanmeldlogboeken, de betreffende policy en het terugvalplan. Controleer vooraf dat beide noodaccounts werken, maar gebruik ze niet voor de normale wijziging.

Test de volledige toegangsketen

Een geslaagde test is meer dan één succesvolle browseraanmelding. Test minimaal:

een normale gebruiker op een beheerd bedrijfsapparaat;
een normale gebruiker op een privéapparaat als dat scenario is toegestaan;
een beheerder met de vereiste phishingbestendige methode;
een mobiele Microsoft 365-app;
een kritieke bedrijfstoepassing;
een gastgebruiker als gasten toegang hebben;
een bekend legacy protocol dat geblokkeerd moet worden;
een toegestane en een bewust geweigerde aanmelding;
de helpdeskprocedure voor iemand die de vereiste methode nog niet heeft;
de waarschuwingsroute bij gebruik van een noodaccount.

Leg per test datum, accounttype, apparaat, toepassing, verwacht resultaat en werkelijk resultaat vast. Bewaar geen wachtwoorden of tokens in het testverslag.

Test noodaccounts minimaal iedere 90 dagen en ook na relevante wijzigingen, bijvoorbeeld wisseling van IT-personeel, aanpassing van Entra-abonnementen, wijziging van authenticatiemethoden of grote herziening van Conditional Access. Controleer beide accounts afzonderlijk. Open geen productieve beheeractie als alleen aanmelden hoeft te worden bewezen.

Bewaak ieder gebruik van noodtoegang

Een noodaccount hoort vrijwel nooit te worden gebruikt. Iedere succesvolle of mislukte aanmelding verdient daarom snelle aandacht. Microsoft beschrijft monitoring via Entra-aanmeldlogboeken, auditlogboeken en Azure Monitor-alerting.

Richt een melding in naar meerdere bevoegde ontvangers en een bewaakte support- of securityqueue. Controleer dat de melding echt aankomt. Leg ook vast wat de ontvanger doet:

verifieer of een geautoriseerde noodsituatie loopt;
controleer tijdstip, IP-adres, apparaat en uitgevoerde beheeracties;
beperk toegang als gebruik niet verklaard kan worden;
onderzoek mogelijke account- of sleutelcompromittering;
documenteer oorzaak, acties en resultaat;
vervang credentials of sleutels wanneer vertrouwelijkheid niet zeker is;
beoordeel welke normale beheerroute faalde en herstel die.

Alleen een e-mailalert instellen is niet genoeg. Een niet-bewaakte mailbox, één ontvanger met vakantie of een regel zonder periodieke test geeft schijnzekerheid.

Beheer Conditional Access als continu proces

Cloudtoegang verandert. Nieuwe medewerkers, apps, apparaten, licenties en authenticatiemethoden maken een eenmalige configuratie snel verouderd. Gebruik daarom een vast beheerinterval.

Frequentie	Controle
Dagelijks	Onverwachte noodaccountmeldingen en kritieke aanmeldproblemen
Wekelijks	Blokkades, helpdesksignalen en nieuwe legacy authentication-pogingen
Maandelijks	Uitsluitingen, report-onlyresultaten en regels zonder duidelijke eigenaar
Per kwartaal	Beide noodaccounts, authenticatiemethoden, rollen en volledige policyset
Bij grote wijziging	Pilot, What If-analyse, logreview, noodtoegang en terugvalplan

Verwijder dubbele of verouderde regels. Gebruik duidelijke namen waarin doel en doelgroep herkenbaar zijn. Documenteer eigenaar, wijzigingsdatum en zakelijke reden. Controleer of een regel nog dezelfde gebruikers, apps en voorwaarden raakt als bij de oorspronkelijke goedkeuring.

Een auditbaar proces helpt ook bij ISO 27001 en NIS2. Bewaar bewijs van policyreviews, testresultaten, uitzonderingsbesluiten, noodaccountcontroles en incidentopvolging. Het gaat niet alleen om de aanwezigheid van techniek, maar om aantoonbaar beheer.

Veelgemaakte fouten

Alle gebruikers en apps worden direct geraakt

Een brede eerste uitrol kan bedrijfsprocessen stilleggen. Gebruik report-only, pilots en gefaseerde uitbreiding.

Het enige beheeraccount valt onder de nieuwe regel

Als registratie of beleid fout gaat, kan herstel onmogelijk worden. Richt eerst minimaal twee onafhankelijke noodaccounts in.

Noodaccounts gebruiken dezelfde telefoonroute

Bij verlies, storing of uitdiensttreding faalt dan zowel normale als noodtoegang. Gebruik een onafhankelijke phishingbestendige methode.

Uitsluitingen hebben geen eigenaar

Tijdelijke workarounds blijven jarenlang bestaan. Geef iedere uitzondering een reden, eigenaar en einddatum.

Alleen de What If-tool wordt gebruikt

Een simulatie kent niet ieder werkelijk gebruikspatroon. Combineer deze met report-onlygegevens en echte pilottests.

Een MFA-push wordt phishingbestendig genoemd

Normale MFA verlaagt risico, maar is niet automatisch phishingbestendig. Gebruik voor beheerders een passende authentication strength en ondersteunde methode.

Noodaccountalerts worden nooit getest

Een ingestelde regel zonder geslaagde melding en opvolging is geen werkende controle.

Veelgestelde vragen

Hoeveel noodaccounts hebben we nodig?

Microsoft adviseert twee of meer. Twee accounts beperken het risico dat één sleutel, account of opslaglocatie onbruikbaar is.

Moeten noodaccounts MFA gebruiken?

Microsoft adviseert tegenwoordig een passwordless, phishingbestendige methode, bij voorkeur een FIDO2-passkey of certificate-based authentication als daar al een geschikte PKI voor bestaat. Kies een methode zonder dezelfde afhankelijkheid als normale beheerders.

Moeten noodaccounts worden uitgesloten van alle Conditional Access-regels?

Sluit ze uit van beleid dat aanmelden blokkeert of beperkt. Report-onlybeleid blokkeert niet en vereist geen uitsluiting. Documenteer de keuze per regel en controleer de effectieve scope.

Is Global Administrator permanent nodig voor een noodaccount?

Microsoft adviseert voor noodaccounts een actieve permanente Global Administrator-toewijzing in plaats van een eligible PIM-toewijzing. Zo is noodtoegang niet afhankelijk van een goedkeuringsketen die zelf kan uitvallen.

Hoe lang moet report-only actief blijven?

Er is geen universeel aantal dagen. De meetperiode moet representatieve werkpatronen bevatten. Kijk naar maandafsluiting, reizen, thuiswerk en periodieke processen voordat je handhaaft.

Vervangt Conditional Access Security Defaults?

Het zijn verschillende beheerbenaderingen. Zodra je eigen Conditional Access-beleid ontwerpt, moet je de totale bescherming bewust beoordelen. Voorkom een overgang waarbij bestaande basisbescherming verdwijnt voordat vervangend beleid aantoonbaar werkt.

Kunnen we noodaccounts voor dagelijks beheer gebruiken?

Nee. Gebruik ze alleen wanneer normale beheeraccounts of rolactivatie niet beschikbaar zijn. Dagelijks gebruik vergroot blootstelling en maakt een echte noodmelding minder opvallend.

Hoe vaak moeten we alles herbeoordelen?

Controleer noodaccounts minimaal iedere 90 dagen. Bekijk daarnaast policyresultaten en uitzonderingen maandelijks, en voer na grote wijzigingen opnieuw een pilot en logreview uit.

Gebruikte Microsoft-bronnen

De aanbevelingen over noodaccounts, Conditional Access, authentication strengths, monitoring en testen zijn op 26 oktober 2026 gecontroleerd tegen deze Microsoft Learn-bronnen zonder trackingparameters:

Microsoft kan portaalnamen, licentievoorwaarden en ondersteunde methoden wijzigen. Controleer de actuele documentatie en je eigen tenant voordat je beleid activeert.

Van losse regels naar aantoonbaar toegangsbeheer

Veilige Conditional Access bestaat uit meer dan drie policy's. Het is een cyclus van inventariseren, simuleren, testen, handhaven en opnieuw beoordelen. Noodaccounts zorgen dat herstel mogelijk blijft. Report-only en pilots beperken verstoring. Monitoring en periodieke controles maken misbruik en veroudering zichtbaar.

Met die combinatie verlaag je het risico op accountovername zonder nieuwe beheerdruk te creëren. De IT-manager krijgt duidelijke uitzonderingen, meetbare controles en een terugvalroute voor het moment dat normale toegang faalt.