Voorwaardelijk toegangsbeleid in Microsoft Entra ID evalueert identiteitssignalen, apparaatstatus en risicocontext bij elke aanmelding en verleent, blokkeert of beperkt vervolgens toegang op basis van regels die u definieert. Ze vormen de identiteitslaag van een Zero Trust architectuur. Maar identiteitslaagcontroles dekken slechts de helft van het toegangsoppervlak. De andere helft, toegang op netwerkniveau tot interne applicaties, on-premise bronnen en niet-Microsoft services, valt onder het ZTNA-platform van SASE. Voor IT-teams in het middensegment met 50 tot 400 gebruikers is de strategische vraag in 2026 hoe beide lagen te coördineren, zodat een enkele identiteitscontext elke toegangsbeslissing stuurt, van Microsoft 365 tot uw on-premise ERP, zonder twee losgekoppelde beleidssets te onderhouden.
Wat zijn beleidsregels voor voorwaardelijke toegang in 2026?
Beleidsregels voor voorwaardelijke toegang zijn if-then regels in Microsoft Entra ID die signalen evalueren (gebruikersidentiteit, groepslidmaatschap, apparaatconformiteit, locatie, aanmeldingsrisico) en controles afdwingen (MFA vereisen, apparaatconformiteit vereisen, toegang blokkeren, sessieduur beperken) voordat toegang wordt verleend tot cloudapplicaties en -bronnen. In 2026 heeft voorwaardelijke toegang zich uitgebreid van statische regelevaluatie tot AI-ondersteunde beleidsoptimalisatie, gefaseerde uitrolmogelijkheden en handhaving van beleidsregels tegen AI-agent-identiteiten. Het toepassingsgebied is uitgebreid, maar de kernlogica blijft: signalen verzamelen, evalueren aan de hand van beleid, een beslissing afdwingen. Wat voorwaardelijke toegang niet dekt, is toegang op netwerkniveau. Toepassingen die zich achter uw firewall bevinden, industriële besturingssystemen, aangepaste webtoepassingen op privé-infrastructuur en legacy services die dateren van voor de cloud-identiteit vereisen allemaal een aanvullende handhavingslaag die op netwerkniveau werkt.
Grondbeginselen voor voorwaardelijke toegang
De motor voor voorwaardelijke toegang werkt in drie fasen. Ten eerste het verzamelen van signalen: Entra ID verzamelt identiteitssignalen (gebruiker, groep, rol), apparaatsignalen (conformiteitsstatus van Intune, OS-versie, versleutelingsstatus), locatiesignalen (IP, genoemde locaties), toepassingscontext (welke bron wordt benaderd) en risicosignalen (aanmeldingsrisico en gebruikersrisico van Entra ID Protection). Ten tweede, beleidsevaluatie: alle toepasselijke beleidsregels worden tegelijkertijd geëvalueerd. Als een gebruiker onder meerdere beleidsregels valt, moet aan elke voorwaarde worden voldaan. Een beleid dat MFA vereist en een apart beleid dat een apparaat vereist dat aan de eisen voldoet, betekent dat de gebruiker aan beide moet voldoen voordat toegang wordt verleend. Ten derde, handhaving: de engine blokkeert de toegang, verleent toegang met controles (MFA, apparaatconformiteit, authenticatiesterkte) of past sessiecontroles toe (beperkte sessieduur, app-geforceerde beperkingen, continue toegangsevaluatie).
Voor specifieke instellingen, licentiegegevens en stapsgewijze configuratie blijft Microsoft Learn de gezaghebbende bron. Deze gids richt zich op de coördinatiearchitectuur waar de documentatie van Microsoft zelf niet op ingaat: hoe voorwaardelijke toegang werkt naast ZTNA op het SASE-platform om eenduidige beleidshandhaving te leveren op identiteits- en netwerklagen.
Het landschap van voorwaardelijke toegang in 2026
Drie ontwikkelingen tussen januari en mei 2026 hebben opnieuw vorm gegeven aan wat voorwaardelijke toegang kan doen.
De Conditional Access Optimization Agent is nu algemeen beschikbaar via Microsoft Security Copilot. De agent scant continu je tenant, identificeert gebruikers, applicaties en AI-agent-identiteiten die niet worden gedekt door bestaande beleidsregels en stelt gerichte oplossingen voor. De agent evalueert of MFA wordt afgedwongen, of apparaatgebaseerde controles actief zijn, of verouderde verificatie wordt geblokkeerd en of soortgelijke beleidsregels kunnen worden geconsolideerd. Elke scan verbruikt minder dan één security compute unit. Ondersteuning voor gefaseerde uitrol betekent dat u beleidswijzigingen geleidelijk over gebruikersgroepen kunt uitrollen in plaats van ze in één stap in de hele huurder door te voeren. Een passkey-adoptiecampagne beoordeelt of apparaten en gebruikers klaar zijn voor phishingbestendige verificatie en genereert een uitrolplan. Voor de Optimization Agent is minimaal Entra ID P1 vereist. Voor volledige risicogebaseerde beleidsmogelijkheden is P2 of Microsoft 365 E5 vereist.
De all-resources handhavingswijziging sluit een omzeiling uit die jarenlang heeft bestaan. Wanneer een voorwaardelijk toegangsbeleid gericht was op “Alle bronnen” met een of meer uitsluitingen van bronnen, werden aanmeldingen die alleen basis OIDC scopes (openid, profiel, e-mail) of beperkte directory scopes (User.Read) aanvroegen stilzwijgend vrijgesteld van beleidshandhaving. Hulpmiddelen zoals Azure CLI, Visual Studio Code en aangepaste toepassingen die deze minimale scopes gebruikten, omzeilden MFA- en apparaatnalevingscontroles volledig. Microsoft kondigde de fix aan in januari 2026, begon met de handhaving op 13 mei 2026 en zal de geleidelijke uitrol halverwege de zomer van 2026 voltooien. IT-teams met aangepaste applicaties die alleen basisscopes aanvragen, moeten controleren of deze applicaties voorwaardelijke toegangsproblemen aankunnen voordat de handhaving hun huurders bereikt.
AI-agent-identiteiten zijn nu eersteklas actoren in het Entra ID ecosysteem. Microsoft Entra Agent ID biedt registratie, levenscyclusbeheer en governance voor AI-agenten die namens gebruikers optreden. Voorwaardelijk toegangsbeleid kan zich richten op deze identiteiten via on-behalf-of flows, waarbij dezelfde controles worden toegepast (MFA, apparaatcompliance, risicobeoordeling) die gelden voor menselijke gebruikers. De Optimization Agent controleert agent-identiteiten op overmatige machtigingen en beveelt aanpassingen aan met de laagste rechten. Voor organisaties die Microsoft 365 Copilot, aangepaste AI-assistenten of agentframeworks van derden implementeren, is het beheren van deze identiteiten via voorwaardelijke toegang niet langer optioneel.
Het beleid met de grootste impact voor teams in het middensegment van de markt
Voor organisaties met 50 tot 400 gebruikers levert een klein aantal goed geconfigureerde beleidsregels de meeste risicovermindering op. Complexiteit is de vijand van beveiliging in het middensegment van de markt en een wildgroei aan beleidsregels creëert meer gaten dan dat het gaten dicht.
Phishing-resistente MFA voor alle gebruikers. De basislijn van 2026 zijn passkeys of FIDO2-beveiligingssleutels, geen pushmeldingen via sms of authenticatie-apps. Adversary-in-the-middle (AiTM)-aanvallen onderscheppen traditionele MFA-tokens in realtime. Phishing-resistente methoden elimineren deze vector volledig. De Optimization Agent kan beoordelen in hoeverre uw huurder er klaar voor is en een gefaseerd uitrolplan genereren.
Verouderde authenticatieprotocollen blokkeren. IMAP, POP3 en SMTP basisauthenticatie ondersteunen geen MFA en blijven primaire doelwitten voor wachtwoordspraying. Een enkel beleid dat deze protocollen blokkeert voor alle gebruikers sluit een van de eenvoudigste aanvalspaden af.
Apparaten vereisen die compatibel zijn met bedrijfsgegevens. Koppel toegang tot Microsoft 365-bronnen (SharePoint, Teams, Outlook, OneDrive) aan de compliance-status van Intune. Alleen apparaten met de huidige OS-versies, actieve schijfversleuteling en actieve endpointbeveiliging krijgen toegang. Dit voorkomt het lekken van gegevens naar onbeheerde persoonlijke apparaten zonder BYOD volledig te blokkeren, omdat browsergebaseerde toegang met sessiebeperkingen beschikbaar blijft als fallback.
Op risico gebaseerde controles voor bevoorrechte accounts. Global Administrators, Security Administrators en andere bevoorrechte rollen vereisen MFA bij elke aanmelding en automatische blokkering wanneer Entra ID Protection een verhoogd gebruikersrisico detecteert. Scheid deze in een speciaal beleid in plaats van te vertrouwen op het basis MFA-beleid.
Blokkeer de toegang vanuit niet-vertrouwde regio’s. Een locatiebeleid dat aanmeldingen beperkt tot landen waar je organisatie actief is, filtert een aanzienlijk deel van het geautomatiseerde aanvalsverkeer. IP-gebaseerde locatie is niet waterdicht, maar het verhoogt de kosten van misbruik van aanmeldingen aanzienlijk.
Bescherm administratieve portalen. Toegang tot de Azure Portal, Entra Admin Center en Microsoft 365 Admin Center verdient een eigen beleid dat zowel een apparaat dat aan de eisen voldoet als phishing-resistente MFA vereist. Administratieve interfaces zijn hoogwaardige doelen die strengere controles rechtvaardigen dan algemene gebruikerstoegang.
Het licentieniveau is belangrijk. Microsoft 365 E3 bevat Entra ID P1, dat voorwaardelijke toegang biedt met apparaatcompliance, MFA-handhaving en locaties op naam. Microsoft 365 E5 voegt Entra ID P2 toe, dat op risico gebaseerde beleidsregels (aanmeldingsrisico en gebruikersrisico), de volledige mogelijkheden van de Optimization Agent en Entra ID Protection mogelijk maakt. Voor organisaties die risicogebaseerde controles, tokenbescherming en volledige AI-ondersteunde optimalisatie nodig hebben, biedt E5 zinvolle beveiligingswaarde boven E3.
Veelgemaakte fouten en hoe ze te vermijden
Blokkering door te brede blokkering. Een beleid dat is ingesteld op “Alle gebruikers, Alle bronnen, Blokkeren” zonder uitsluitingen sluit iedereen uit als MFA-diensten een storing hebben of als een configuratiefout alle beheerders treft. Houd ten minste twee accounts voor noodtoegang (break-glass accounts) die zijn uitgesloten van alle beleidsregels voor voorwaardelijke toegang. Deze accounts gebruiken extreem lange, unieke wachtwoorden die fysiek offline worden opgeslagen en worden bewaakt via Entra ID auditlogs voor elke aanmeldactiviteit.
Uitzondering wildgroei. Beleidsregels stapelen in de loop van de tijd uitsluitingen op: een aannemer die tijdelijk toegang nodig had, een legacy applicatie die niet met MFA overweg kon, een service account die niemand documenteerde. Elke uitsluiting is een onbewaakt toegangspad. De Optimization Agent identificeert deze hiaten automatisch, maar je hebt nog steeds een driemaandelijks controleproces nodig dat elke uitsluiting onderzoekt en verwijdert of de zakelijke rechtvaardiging documenteert.
Chaos bij het benoemen. Wanneer 30 beleidsregels namen hebben als “Test MFA-beleid” en “Nieuw beleid – kopiëren”, wordt het oplossen van problemen giswerk. Gebruik een gestructureerde naamgevingsconventie: CA[number]-[scope]-[action]-[condition]. Bijvoorbeeld: CA001-AllUsers-RequireMFA-PhishingResistant. Gebruik de modus Report-only minstens een week voordat u een nieuw beleid afdwingt en bekijk het werkboek Conditional Access Insights om de impact te begrijpen voordat u overgaat op afdwinging.
Ontbrekende evaluatie van continue toegang. Een token dat om 9:00 wordt uitgegeven met een levensduur van een uur geeft een aanvaller die dat token steelt een vol uur toegang. Continue toegangsevaluatie (CAE) maakt herroeping in bijna-realtime mogelijk wanneer kritieke gebeurtenissen plaatsvinden: wachtwoord opnieuw instellen, account uitschakelen, netwerklocatie wijzigen of compliance-status wijzigen. Controleer of CAE is ingeschakeld voor uw kritieke beleidsregels in plaats van alleen te vertrouwen op tokenlevensduurcontroles.
Voorwaardelijke toegang en ZTNA: complementaire beleidslagen
Dit is waar de meeste richtlijnen stoppen en waar de coördinatiekloof begint. Voorwaardelijke toegang controleert de identiteitslaag: het beslist of een gebruiker met een specifiek apparaat in een specifieke context toegang krijgt tot een Microsoft 365-applicatie of een geregistreerde SaaS-service. ZTNA van het SASE-platform controleert de netwerklaag: het beslist of diezelfde gebruiker een interne applicatie, een private webservice, een databaseserver of een OT-beheerinterface kan bereiken.
Beide lagen gebruiken dezelfde identiteitscontext. Jimbers SASE-platform authenticeert tegen Entra ID als de identiteitsprovider. Dezelfde gebruikersidentiteit, groepslidmaatschap en apparaatcompliance die voorwaardelijke toegang evalueert op de Microsoft 365-grens, bepaalt ook de ZTNA-toegangsbeslissingen op de netwerkgrens. Er is geen aparte identiteitsopslag die moet worden onderhouden, geen synchronisatie van referenties die moet worden beheerd en geen dubbele beleidsregels die op elkaar moeten worden afgestemd.
De praktische coördinatie werkt als volgt. Voorwaardelijke toegang is van toepassing op Microsoft 365 en geregistreerde SaaS-applicaties. Wanneer een IT-manager zich aanmeldt bij Teams, evalueert Entra ID het beleid voor voorwaardelijke toegang. Jimber’s ZTNA regelt interne applicaties, private webservices en lokale bronnen. Wanneer dezelfde IT-manager verbinding maakt met het on-premise ERP-systeem, evalueert het SASE-platform de Entra ID identiteitscontext en past het zijn eigen toegangsbeleid toe. Beide beslissingen verwijzen naar dezelfde apparaat compliance status van Intune. Als een laptop de nalevingscontrole niet doorstaat, blokkeert voorwaardelijke toegang de toegang tot Teams en blokkeert het SASE platform tegelijkertijd de toegang tot ERP. Geen gat, geen inconsistentie.
Deze coördinatie strekt zich uit tot logging en audit trails. Entra ID logt gebeurtenissen op identiteitsniveau: wie heeft zich geauthenticeerd, welke MFA-methode is gebruikt, welke risicosignalen waren aanwezig, welk beleid heeft toegang verleend of geblokkeerd. Het Jimber-platform logt gebeurtenissen op netwerkniveau: welke interne applicatie werd benaderd, vanaf welk bron-IP, via welke ZTNA-verbinding, met welke encryptieparameters. Gecombineerd bieden deze logs een compleet toegangsbeeld dat geen van beide systemen alleen levert.
Voor organisaties die agentloze apparaten, printers, IoT-sensoren en industriële apparatuur beheren, heeft de coördinatie een derde dimensie. Deze apparaten kunnen niet deelnemen aan Entra ID-authenticatie. De NIAC-hardware van Jimber biedt inline isolatie op netwerkniveau en dwingt toegangscontroles af voor apparaten die volledig buiten de voorwaardelijke-toegangsgrens vallen. De identiteitslaag behandelt gebruikers en beheerde eindpunten. Het SASE-platform handelt al het andere af.
NIS2-auditbewijs van voorwaardelijke toegang en SASE
Artikel 21 van NIS2 vereist “passende en evenredige technische, operationele en organisatorische maatregelen” voor risicobeheer, waaronder uitdrukkelijk toegangscontrolebeleid, multifactorauthenticatie en voortdurende monitoring. Voorwaardelijke toegang levert direct bewijs voor verschillende van deze vereisten.
Documentatie over toegangscontrole is afkomstig van exports van beleidsregels voor voorwaardelijke toegang die de handhaving van de laagste rechten laten zien: welke gebruikers hebben toegang tot welke bronnen onder welke voorwaarden. Bewijs voor handhaving van MFA komt uit Entra ID aanmeldlogboeken die bevestigen dat multifactorauthenticatie vereist en voltooid was voor elke toegang tot systemen binnen het bereik. Toegangscontroles voor de toeleveringsketen zijn afkomstig van het toegangsbeleid voor gasten dat de machtigingen voor externe partners beperkt en apparaatcompliance afdwingt voor B2B-samenwerking.
Waar bewijs voor voorwaardelijke toegang tekortschiet is op netwerkniveau. NIS2 vereist ook netwerksegmentatie, mogelijkheden voor incidentdetectie en -respons en bewaking van zijwaartse bewegingen. Dit zijn netwerklaagcontroles die Entra ID niet biedt. Een SASE-platform vult deze gaten. De gecentraliseerde logging van Jimber legt toegangsgebeurtenissen op netwerkniveau vast naast gebeurtenissen op identiteitsniveau en biedt zo het gecombineerde controlespoor dat NIS2-inspecteurs verwachten. Verificatie van de apparaatstatus, netwerksegmentatie door middel van microsegmentatie en incidentafsluiting door inline isolatie genereren allemaal compliance-bewijsmateriaal dat voorwaardelijke toegang alleen niet kan produceren.
Voor Belgische organisaties die zich voorbereiden op de CyberFundamentals-verificatie is de combinatie bijzonder relevant. CyFun-controles onder de Protect-functie zijn direct gekoppeld aan apparaatposture-checks, identiteitsgebaseerde toegang en netwerksegmentatie. De NIS2 compliance checklist voor IT-managers bevat wat het Centre for Cybersecurity Belgium verwacht te zien.
Waar voorwaardelijke toegang naartoe gaat in 2026
Continue toegangsevaluatie wordt het standaard sessiemodel. In plaats van te vertrouwen op tokenlevensduren gemeten in uren, maakt CAE bijna onmiddellijke beëindiging van sessies mogelijk wanneer zich beveiligingsrelevante gebeurtenissen voordoen. De window of opportunity voor aanvallers die gestolen tokens gebruiken, krimpt van 60 minuten naar seconden.
Het gebruik van passkeys en FIDO2 versnelt in het middensegment van de markt, ondersteund door de campagnes van de Optimization Agent om passkeys in te zetten. Aangezien phishingbestendige authenticatie de bodem in plaats van het plafond wordt, zullen traditionele MFA-methoden (SMS, pushmelding) steeds vaker als ontoereikend worden beschouwd voor gereguleerde omgevingen.
AI-ondersteund beleidsbeheer via de Optimization Agent zal verder gaan dan het identificeren van hiaten en zal leiden tot voorspellende beleidsaanbevelingen op basis van analyse van aanmeldingspatronen en informatie over bedreigingen. De verbeteringen van maart 2026 omvatten al contextbewuste aanbevelingen, diepgaande gap-analyse en Zero Trust posture rapportage.
Convergentie van identiteit en netwerkbeleid is het traject voor de langere termijn. Het onderscheid tussen “is de identiteitscontrole geslaagd” en “is het netwerkpad veilig” is een implementatieartefact, geen beveiligingsprincipe. Platformen die beide evaluaties verenigen tegen een enkele identiteitscontext, waarbij voorwaardelijke toegang wordt toegepast aan de cloudgrens en ZTNA aan de netwerkgrens, leveren de architectuur die de volgende generatie toegangscontrole vereist. Voor IT-managers die hun beveiligingsarchitectuur voor 2026 evalueren, is de vraag niet of ze voorwaardelijke toegang of ZTNA moeten inzetten. Beide zijn noodzakelijk. De Zero Trust architectuurgids laat zien hoe deze lagen in elkaar passen in een uitgebreid model.
Veelgestelde vragen
Wat zijn beleidsregels voor voorwaardelijke toegang in 2026?
Beleidsregels voor voorwaardelijke toegang zijn if-then regels in Microsoft Entra ID die identiteitssignalen, apparaatstatus en risicocontext evalueren bij aanmelding en vervolgens controles afdwingen zoals MFA, apparaatcompliance of sessiebeperkingen voordat toegang wordt verleend tot cloudapplicaties en -bronnen. In 2026 omvatten ze ook AI-agent-identiteiten en profiteren ze van AI-ondersteunde optimalisatie via de Conditional Access Optimization Agent.
Wat is de Conditional Access Optimization Agent?
De Optimization Agent is een AI-agent in Microsoft Security Copilot die voortdurend uw Entra ID-tenant scant op hiaten in het beleid, onbedekte gebruikers, toepassingen en AI-agent-identiteiten. De agent beveelt nieuw beleid aan, stelt consolidatie van bestaand beleid voor, ondersteunt een gefaseerde uitrol van wijzigingen en kan adoptiecampagnes met pasklare sleutels genereren. Het vereist minimaal Entra ID P1 en verbruikt beveiligingscomputereenheden.
Hoe werkt voorwaardelijke toegang met SASE-platforms zoals Jimber?
Voorwaardelijke toegang regelt de toegang tot Microsoft 365 en geregistreerde SaaS-applicaties op de identiteitslaag. Jimbers SASE-platform regelt de toegang tot interne toepassingen, privébronnen en agentless apparaten op de netwerklaag. Beide maken gebruik van dezelfde Entra ID identiteitscontext, zodat apparaatcompliance en gebruikersidentiteit op consistente wijze toegangsbeslissingen bepalen voor cloud- en lokale bronnen zonder afzonderlijke beleidssets te hoeven onderhouden.
Wat is er veranderd voor de handhaving van voorwaardelijke toegang in 2026?
Microsoft is vanaf 13 mei 2026 begonnen met het afdwingen van beleid voor voorwaardelijke toegang tegen aanmeldingen die alleen basis-OIDC-scopes (openid, profiel, e-mail) en beperkte directory-scopes (User.Read) gebruiken. Voorheen omzeilden deze aanmeldingen beleidsregels die gericht waren op “Alle bronnen” wanneer er resource-uitsluitingen aanwezig waren. De wijziging sluit een al lang bestaand handhavingsgat waardoor tools zoals Azure CLI de MFA-vereisten konden omzeilen.
Voldoet voorwaardelijke toegang aan de vereisten van artikel 21 van NIS2?
Voorwaardelijke toegang biedt bewijs voor identiteitsgebaseerde toegangscontrole en MFA-handhaving, wat expliciete NIS2-vereisten zijn. Het voldoet niet aan vereisten op netwerkniveau, zoals netwerksegmentatie, bewaking van laterale bewegingen en het indammen van incidenten. Om aan de volledige reikwijdte van Artikel 21 te voldoen, moeten identiteitslaagcontroles worden gecombineerd met netwerklaagcontroles van een SASE-platform.
Voorwaardelijke toegang vs ZTNA: zijn ze hetzelfde?
Ze zijn complementair, niet identiek. Voorwaardelijke toegang evalueert identiteit en apparaatcontext op de grens van de cloudapplicatie. ZTNA evalueert de identiteitscontext aan de netwerkgrens, waarbij per applicatie toegang wordt verleend tot interne bronnen zonder het bredere netwerk bloot te stellen. Voorwaardelijke toegang beslist of je Teams kunt openen. ZTNA beslist of je de on-premise ERP-server kunt bereiken. Beide dwingen Zero Trust principes af op verschillende lagen van de access stack.
Ben je er klaar voor om te zien hoe identiteitsgebaseerde toegang in de cloud en op locatie wordt gecoördineerd voor jouw omgeving? Boek een demo en bekijk hoe Jimbers SASE-platform samenwerkt met Microsoft Entra ID om uniforme beleidshandhaving te leveren zonder identiteitsbeheer te dupliceren.
