Conditional Access in Microsoft 365: drie basisregels veilig invoeren en beheren

Conditional Access bepaalt onder welke voorwaarden iemand toegang krijgt tot Microsoft 365. Het beleid kijkt bijvoorbeeld naar de gebruiker, de toepassing, het apparaat, de locatie en het aanmeldrisico. Daarna kan Microsoft Entra ID toegang toestaan, extra verificatie vragen of de aanmelding blokkeren.

Voor een MKB-organisatie is dat waardevol omdat één gestolen wachtwoord niet automatisch toegang hoeft te geven tot Outlook, Teams en SharePoint. Tegelijk kan een onzorgvuldig beleid medewerkers, leveranciers of zelfs beheerders buitensluiten. De beste aanpak is daarom niet zoveel mogelijk regels toevoegen. Begin met een kleine, begrijpelijke basis, test de gevolgen en beheer iedere uitzondering alsof het een tijdelijke schuld is.

Deze handleiding behandelt drie basisregels, plus de voorbereiding en beheercontroles die nodig zijn om ze veilig te gebruiken. Wil je eerst weten hoe je huidige Microsoft 365-omgeving ervoor staat? Laat de gratis IT-scan uitvoeren en gebruik de uitkomst als vertrekpunt voor je beveiligingsplan.

Wat Conditional Access wel en niet doet

Een Conditional Access-beleid bestaat in de kern uit twee delen:

1. Toewijzingen: op wie, welke cloudresources en welke omstandigheden is de regel van toepassing?
2. Toegangsbeslissing: welke eis geldt, zoals MFA, een compliant apparaat of blokkeren?

Conditional Access vervangt geen goed identiteitsbeheer. Een oud account dat nog actief is, een te ruime beheerdersrol of een slecht ingericht herstelproces blijft een risico. De regels werken ook pas goed als je weet welke gebruikers, toepassingen, apparaten en technische accounts werkelijk actief zijn.

Microsoft noemt Conditional Access een Zero Trust-beleidsengine. Dat betekent praktisch dat toegang niet alleen wordt vertrouwd omdat iemand een wachtwoord kent of binnen het kantoornetwerk werkt. Iedere relevante toegangsvraag wordt aan het ingestelde beleid getoetst.

Voor Conditional Access is passende Microsoft Entra-licentiëring nodig. Microsoft vermeldt voor deze functie onder meer Microsoft Entra ID P1; die mogelijkheid zit ook in pakketten zoals Microsoft 365 Business Premium. Controleer de actuele productvoorwaarden voor je tenant voordat je een ontwerp baseert op een functie die niet voor alle gebruikers is gelicentieerd.

Bereid de invoering voor zonder je organisatie buiten te sluiten

Maak vóór de eerste beleidswijziging een compact overzicht van de omgeving. Noteer minimaal:

• alle actieve gebruikers, gasten en beheerders;
• de belangrijkste Microsoft 365- en bedrijfsapplicaties;
• apparaten en platformen waarmee medewerkers aanmelden;
• serviceaccounts, scan-to-mail, oudere mailclients en andere technische afhankelijkheden;
• bestaande MFA-instellingen, Security Defaults en oudere per-user MFA-configuratie;
• huidige Conditional Access-regels en hun uitsluitingen;
• wie tijdens de uitrol support kan verlenen en een wijziging mag terugdraaien.

Controleer ook of er minimaal twee cloud-only noodtoegangsaccounts zijn die niet afhankelijk zijn van dezelfde authenticatiemethode of infrastructuur als gewone beheerders. Microsoft adviseert zulke emergency access-accounts om toegang te behouden wanneer federatie, telefoon, netwerk of een fout beleid uitvalt. Beveilig ze sterk, gebruik ze niet voor dagelijks beheer, bewaak iedere aanmelding en test ze periodiek volgens een vastgelegd proces.

Een noodaccount is geen makkelijke achterdeur. Het is een gecontroleerd herstelmiddel. Leg vast wie toegang heeft tot de gegevens, waar die veilig worden bewaard, welke melding afgaat bij gebruik en wanneer de laatste test is uitgevoerd.

Maak daarna een testgroep met verschillende praktijksituaties. Neem bijvoorbeeld een kantoormedewerker, een thuiswerker, een mobiele gebruiker, een beheerder en iemand die met een externe bedrijfsapp werkt. Gebruik geen groep die uitsluitend uit IT-medewerkers bestaat, want die vertegenwoordigt de dagelijkse variatie onvoldoende.

Basisregel 1: vereis MFA voor alle interactieve gebruikers

De eerste basisregel vereist multifactorauthenticatie voor alle gebruikers en alle relevante resources. Hiermee voorkom je dat een wachtwoord alleen voldoende is voor toegang tot bedrijfsgegevens.

Het veilige ontwerp is breed van opzet en beperkt in uitzonderingen:

Onderdeel	Praktische keuze
Gebruikers	Alle gebruikers, inclusief beheerders en waar passend gasten
Resources	Alle resources, zodat nieuwe toepassingen niet onbedoeld buiten scope vallen
Uitsluitingen	Alleen gecontroleerde noodtoegangsaccounts en aantoonbaar noodzakelijke uitzonderingen
Toegangsvoorwaarde	MFA of een passende authentication strength
Startstatus	Report-only tijdens de testfase

Een authentication strength bepaalt welke combinaties van authenticatiemethoden aan de eis voldoen. Daarmee kun je voor gevoelige rollen bijvoorbeeld phishingbestendige methoden verlangen, terwijl je voor algemene gebruikers een bredere MFA-set gebruikt. Voer zo'n strengere eis pas in nadat geschikte methoden daadwerkelijk zijn geregistreerd en het herstelproces is getest.

MFA registreren en MFA afdwingen zijn verschillende zaken. Een medewerker kan Microsoft Authenticator hebben ingesteld zonder dat ieder relevant toegangspad MFA vereist. Omgekeerd kan een beleid MFA eisen terwijl de medewerker nog geen bruikbare methode heeft, met extra supportdruk als gevolg. De actuele handleiding MFA beheerst instellen in Microsoft 365 helpt om registratie, methodenbeleid, uitrol en herstel op elkaar af te stemmen.

Vermijd een algemene uitzondering voor serviceaccounts. Bepaal eerst of het werkelijk om een niet-interactieve workload-identiteit gaat, of om een normaal gebruikersaccount dat jarenlang technisch is gebruikt. Moderniseer waar mogelijk naar een geschikte beheerde identiteit of applicatie-identiteit. Als een tijdelijke uitzondering onvermijdelijk is, geef die een eigenaar, reden en einddatum.

Basisregel 2: blokkeer verouderde authenticatie

Oudere authenticatieprotocollen ondersteunen moderne beveiligingsmaatregelen vaak niet goed. Microsoft noemt onder meer oudere Office-clients en protocollen zoals POP, IMAP en SMTP als scenario's die je zorgvuldig moet inventariseren. Een beleid dat legacy authentication blokkeert, verkleint de kans dat een aanvaller een zwakker toegangspad gebruikt om MFA te omzeilen.

Blokkeer niet blind. Onderzoek eerst de aanmeldlogboeken en breng iedere getroffen toepassing of workflow in kaart. Denk aan multifunctionals die e-mail versturen, oude boekhoudsoftware, scanners, archiefkoppelingen en mobiele mailapps. Niet ieder gebruik van IMAP of SMTP is automatisch hetzelfde; kijk naar de gebruikte authenticatieroute en de technische vervangingsmogelijkheid.

Werk per afhankelijkheid naar één van deze uitkomsten:

• de toepassing gebruikt moderne authenticatie;
• de workflow verhuist naar een ondersteunde verzend- of integratieroute;
• de oude toepassing wordt vervangen;
• er komt een nauw begrensde tijdelijke uitzondering met eigenaar en einddatum.

Zet de blokkeerregel eerst in Report-only en beoordeel representatieve werkdagen. Neem ook maandafsluiting, salarisverwerking of andere periodieke processen mee. Een toepassing die maar één keer per maand aanmeldt, blijft anders tijdens een korte test onzichtbaar.

Basisregel 3: vereis een compliant apparaat voor gevoelige toegang

MFA controleert vooral de identiteit. Het zegt niet automatisch dat het gebruikte apparaat wordt beheerd, versleuteld, bijgewerkt en vrij van bekende risico's gehouden. Voor gevoelige gegevens kan een derde basisregel daarom eisen dat toegang vanaf een compliant apparaat komt.

Een apparaat wordt niet compliant door alleen registratie in Intune. Het moet worden beoordeeld tegen een compliancebeleid, bijvoorbeeld voor versleuteling, ondersteunde besturingssysteemversie en beveiligingsinstellingen. Richt daarom eerst apparaatinschrijving en nalevingsbeleid goed in. De handleiding Intune-nalevingsbeleid voor Windows instellen beschrijft hoe je signalering en blokkering gefaseerd opbouwt.

Begin deze regel niet direct met alle gebruikers en alle toepassingen. Kies eerst een gevoelige resource of een goed beheerde gebruikersgroep. Test zakelijke Windows-apparaten, mobiele toegang, browsergebruik en ondersteunde uitzonderingssituaties. Bepaal ook hoe medewerkers handelen als hun apparaat ineens non-compliant wordt. Een blokkade zonder zichtbaar herstelpad verandert een beveiligingsmaatregel in een supportincident.

Voor privételefoons kan een volledige apparaateis te zwaar of niet passend zijn. Microsoft Intune App Protection kan zakelijke data in ondersteunde apps beschermen zonder het hele privéapparaat als bedrijfsapparaat te beheren. Lees voor die afweging Intune App Protection voor BYOD.

Gebruik Report-only als meetfase, niet als eindstation

Report-only laat zien wat een Conditional Access-regel bij een aanmelding zou hebben gedaan, zonder de toegangsbeslissing werkelijk af te dwingen. Dat maakt de modus geschikt voor impactanalyse, maar alleen als iemand de resultaten beoordeelt en een besluitdatum vastlegt.

Microsoft adviseert geplande beleidswijzigingen eerst in Report-only te zetten. Gebruik daarna de aanmeldlogboeken en, waar beschikbaar, de Conditional Access insights and reporting workbook. Controleer per testscenario:

• welk beleid van toepassing zou zijn;
• of het verwachte toegangsresultaat verschijnt;
• waarom een gebruiker wel of niet geraakt wordt;
• welke authenticatiemethode of apparaatstatus beschikbaar was;
• of een bestaande regel hetzelfde of een tegenstrijdig effect heeft;
• of onverwachte toepassingen of locaties zichtbaar worden.

Report-only is geen bewijs dat de regel actief beschermt. Een beleid dat maanden in deze stand blijft staan, levert analyse op maar dwingt niets af. Geef iedere test een eigenaar, startdatum, beslisdatum en acceptatiecriteria. Activeer in kleine golven en houd tijdens iedere golf een rollbackbesluit en supportkanaal beschikbaar.

Voorkom conflicten tussen losse regels

Conditional Access beoordeelt meerdere toepasselijke beleidsregels samen. Een gebruiker hoeft dus niet aan één gekozen regel te voldoen, maar aan de gecombineerde eisen van alle regels die op de aanmelding van toepassing zijn. Dat is krachtig, maar maakt ongepland stapelen riskant.

Houd daarom een beleidsregister bij met minimaal:

Veld	Waarom het nodig is
Beleidsnaam en doel	Maakt duidelijk welk risico de regel behandelt
Eigenaar	Voorkomt beleid zonder verantwoordelijke
Doelgroepen en resources	Laat overlap en gaten zien
Uitsluitingen	Maakt uitzonderingen controleerbaar
Start- en wijzigingsdatum	Ondersteunt wijzigingsbeheer
Testbewijs	Toont welke scenario's zijn gecontroleerd
Herbeoordelingsdatum	Voorkomt vergeten tijdelijke keuzes
Rollbackroute	Versnelt herstel bij onverwachte blokkade

Gebruik duidelijke namen, bijvoorbeeld CA-BASIS-01-Alle-gebruikers-MFA, en wijzig niet meerdere brede regels tegelijk. Als na een wijziging aanmeldingen mislukken, moet je snel kunnen vaststellen welke aanpassing de oorzaak is.

Maak Conditional Access onderdeel van dagelijks IT-beheer

Een eenmalige inrichting veroudert zodra medewerkers, apparaten en toepassingen veranderen. Neem daarom vaste controles op in het beheerproces.

Wekelijks bij een actieve uitrol: beoordeel mislukte aanmeldingen, nieuwe uitzonderingen, supportmeldingen en Report-only-resultaten.

Maandelijks in regulier beheer: controleer beleidsdekking, gebruikers en groepen in uitsluitingen, legacy authentication-signalen, non-compliant apparaten en wijzigingen in beheerdersrollen.

Per kwartaal: herzie het volledige beleidsregister, test noodtoegang, controleer licenties en verwijder verlopen uitzonderingen.

Bij iedere grote verandering: voer een gerichte impactanalyse uit bij een nieuwe applicatie, fusie, tenantmigratie, nieuw apparaatplatform of gewijzigde authenticatiemethode.

Meet niet alleen hoeveel beleidsregels actief zijn. Betere indicatoren zijn het percentage relevante accounts binnen het MFA-beleid, het aantal uitzonderingen zonder einddatum, het gebruik van legacy authentication, de leeftijd van Report-only-beleid en de tijd die nodig is om een geblokkeerde medewerker veilig te herstellen.

Microsoft Secure Score kan helpen bij prioritering, maar vervangt je eigen bewijs niet. Combineer de score met aanmeldlogboeken, beleidsconfiguratie, apparaatstatus, uitzonderingsregister en testresultaten. De gids Microsoft Secure Score verbeteren laat zien hoe je aanbevelingen naar beheersbare acties vertaalt.

Veelgemaakte fouten

Alles op één dag activeren

Een brede regel kan onverwachte oude toepassingen of gebruikersscenario's raken. Gebruik een representatieve testgroep, Report-only en kleine activeringsgolven.

Een vertrouwde locatie als volledige beveiliging zien

Een kantoor-IP bewijst niet welke persoon of welk apparaat toegang vraagt. Gebruik locatie als één signaal, niet als vervanging voor sterke authenticatie en apparaatcontrole.

Uitzonderingen zonder eigenaar maken

Een tijdelijke uitzondering zonder reden, eigenaar en einddatum wordt meestal permanent. Neem uitzonderingen op in het beleidsregister en herzie ze aantoonbaar.

Noodtoegang nooit testen

Een noodaccount dat alleen op papier bestaat, kan tijdens een storing onbruikbaar blijken. Test gecontroleerd, bewaak het gebruik en leg de uitkomst vast.

Report-only als afgerond project behandelen

Report-only beperkt geen toegang. Het is een meetfase die moet eindigen in aanpassen, activeren of bewust stoppen.

Alleen naar de beleidsnaam kijken

Een duidelijke naam helpt, maar bewijst niet welke groepen, resources en voorwaarden werkelijk zijn ingesteld. Controleer de volledige configuratie en de gezamenlijke werking met andere regels.

Veelgestelde vragen

Kan Conditional Access zonder Microsoft 365 Business Premium?

Dat hangt af van de aanwezige Microsoft Entra-licenties en het gekozen pakket. Microsoft noemt Microsoft Entra ID P1 als relevante licentie voor Conditional Access. Controleer de actuele licentievoorwaarden voor alle gebruikers die onder het beleid vallen.

Moet ik Security Defaults uitschakelen?

Security Defaults en maatwerk met Conditional Access zijn verschillende beheermodellen. Maak eerst een compleet vervangend basisontwerp en controleer licenties, MFA-registratie en noodtoegang voordat je van model wisselt. Laat geen onbedoelde periode zonder passende bescherming ontstaan.

Hoe lang moet een beleid in Report-only blijven?

Er is geen universeel aantal dagen. Test lang genoeg om normale, mobiele en periodieke processen te zien, maar geef de fase vooraf een beslisdatum. Voor maandelijkse processen kan een langere waarneming of een gerichte technische test nodig zijn.

Mag ik noodtoegangsaccounts uitsluiten van alle regels?

Microsoft adviseert noodtoegangsaccounts uit te sluiten van bepaalde Conditional Access-regels om tenantuitsluiting te voorkomen. Beveilig en bewaak deze accounts via een apart, streng proces. Gebruik ze niet voor dagelijks beheer en test ze periodiek.

Is MFA genoeg zonder compliant apparaat?

MFA verkleint het risico van gestolen wachtwoorden, maar beoordeelt niet automatisch de beveiligingsstaat van het apparaat. Voor gevoelige toegang kan een combinatie met apparaatnaleving of passende appbescherming nodig zijn.

Wat doe ik als één oude toepassing wordt geblokkeerd?

Schakel de brede beveiliging niet direct uit. Identificeer het specifieke protocol, account en proces. Kies daarna moderniseren, vervangen of een aantoonbaar tijdelijke, begrensde uitzondering.

Gebruikte Microsoft-bronnen

De productwerking en beheeradviezen zijn op 23 augustus 2026 gecontroleerd tegen deze officiële Microsoft-pagina's:

• Plan your Conditional Access deployment
• Require multifactor authentication for all users
• Block legacy authentication with Conditional Access
• Manage emergency access admin accounts
• Conditional Access insights and reporting workbook