Mohamed ZagoudiAdelix Automation

Security

Conditional Access met resource-uitsluitingen: strengere handhaving vanaf 15 juni 2026

Vanaf 15 juni 2026 handhaaft Entra ID beleid op 'Alle resources' ook bij aanmeldingen met alleen OIDC- of basisscopes, zelfs met uitsluitingen. Wat verandert.

Abstracte technische illustratie bij het artikel over Conditional Access en resource-uitsluitingen
In dit artikel
  1. Hoe Conditional Access beslist
  2. Het huidige gedrag
  3. Wie er iets van merkt
  4. Eigen toepassingen
  5. Beoordeling en instellingen
  6. De juni-agenda
  7. Bronnen

Over vier dagen, op 15 juni 2026, begint Microsoft met een wijziging in de manier waarop Microsoft Entra Conditional Access bepaalde aanmeldingen beoordeelt. De wijziging is klein in omschrijving en groot in principe: beleid dat op "Alle resources" is gericht maar een of meer resources uitsluit, gaat ook gelden voor aanmeldingen waarbij een toepassing alleen om basisscopes vraagt. Tot nu toe werden die aanmeldingen in die situatie niet gehandhaafd.

De aankondiging verscheen op 28 januari 2026 op het Microsoft Entra-blog, geschreven door Swaroop Krishnamurthy, en werd een dag later als bericht MC1223829 in het Message Center gepubliceerd. De oorspronkelijke datum, 13 mei, is bij een update op 14 mei verschoven naar 15 juni. Vanaf die datum rolt de handhaving geleidelijk uit over enkele weken.

Hoe Conditional Access beslist

Om de wijziging te kunnen plaatsen, is het nuttig het basismodel kort te herhalen. Conditional Access is een beleidsmotor die bij elke aanmelding drie dingen combineert:

  1. Signalen – wie meldt zich aan, vanaf welk apparaat, vanuit welke locatie, naar welke toepassing of resource, en met welk risico.
  2. Toewijzingen – op welke gebruikers, groepen, resources en omstandigheden het beleid van toepassing is. Hier zitten ook de uitsluitingen: gebruikers of resources die bewust buiten het beleid vallen.
  3. Toegangsbeheer – wat er moet gebeuren als het beleid van toepassing is: toegang blokkeren, of toegang toestaan onder voorwaarden zoals multifactor-authenticatie of een compliant apparaat.

De keuze "Alle resources" onder toewijzingen betekent dat het beleid geldt voor elke toepassing waarvoor een token wordt aangevraagd. Resource-uitsluitingen worden in de praktijk gebruikt om bijvoorbeeld het Intune-inschrijvingsproces of een specifieke toepassing buiten een strenge regel te houden.

Een aanmelding bij Entra ID gaat altijd gepaard met een verzoek om scopes: de rechten die een toepassing vraagt. Een deel daarvan zijn de OpenID Connect-scopes openid, profile, email en offline_access; daarnaast bestaan er beperkte directoryscopes zoals User.Read, waarmee een toepassing alleen het profiel van de aangemelde gebruiker kan lezen. Een toepassing die uitsluitend deze scopes vraagt, wil in wezen alleen weten wie de gebruiker is.

Het huidige gedrag

Tot de wijziging geldt: als een toepassing bij het aanmelden alleen die OIDC-scopes of alleen zo'n beperkte set directoryscopes vraagt, en er is een Conditional Access-beleid dat op "Alle resources" is gericht met een of meer resource-uitsluitingen, dan wordt dat beleid voor die aanmelding niet gehandhaafd. De gebruiker krijgt geen MFA-uitdaging en geen apparaatcontrole, ook al lijkt het beleid op papier op iedereen en alles van toepassing.

Beleid op "Alle resources" zonder uitsluitingen wordt wel gehandhaafd. De lacune zit uitsluitend in de combinatie van basisscopes en een beleid met uitsluitingen.

Wat er precies verandert

Vanaf 15 juni 2026 worden Conditional Access-beleidsregels die op "Alle resources" zijn gericht ook gehandhaafd voor aanmeldingen met alleen OIDC-scopes of beperkte directoryscopes, óók wanneer het beleid resource-uitsluitingen bevat. Microsoft plaatst de wijziging in het kader van het Secure Future Initiative en spreekt van "defense-in-depth": beleid doet wat het beleid zegt, ongeacht welke scopes een toepassing vraagt.

Wie er iets van merkt

Volgens zowel de blogpost als het Message Center-bericht is in de meeste gevallen geen actie nodig. De redenering: bijna alle toepassingen vragen meer dan alleen de basisscopes, en voor die toepassingen wordt het beleid vandaag al gehandhaafd. De wijziging raakt uitsluitend aanmeldingen die tot nu toe door de lacune vielen.

Concreet kunnen gebruikers na 15 juni bij een klein aantal toepassingen ineens een MFA-verzoek of een controle op apparaatcompliance krijgen waar ze dat eerder niet zagen. Dat is geen fout: het beleid dat de organisatie zelf heeft ingericht, wordt nu ook daar toegepast. Een servicedesk die hierop is voorbereid, herkent het patroon sneller dan een servicedesk die het als een storing behandelt.

Wat de wijziging niet doet: bestaande uitsluitingen zelf worden niet ongedaan gemaakt. Een resource die is uitgesloten, blijft uitgesloten. Het gaat om aanmeldingen bij niet-uitgesloten resources die tot nu toe door hun beperkte scopeverzoek buiten de handhaving bleven.

Eigen toepassingen

De groep die wél iets moet doen, bestaat uit organisaties met eigen toepassingen die bewust alleen de basisscopes vragen. Zo'n toepassing gebruikt Entra ID puur als identiteitsprovider en haalt verder geen gegevens op. Na de wijziging kan zo'n toepassing tijdens het aanmelden een Conditional Access-uitdaging tegenkomen, bijvoorbeeld een MFA-verzoek of een claims challenge.

Een toepassing die via een standaardbibliotheek zoals MSAL aanmeldt en de interactieve aanmeldstroom correct afhandelt, verwerkt dit doorgaans zonder aanpassing. Toepassingen die zelf een tokenverzoek opbouwen of die alleen op de stille (silent) stroom leunen, kunnen op een fout stuiten. Microsoft verwijst hiervoor naar de developer guidance voor Conditional Access, waarin staat hoe een toepassing een challenge moet herkennen en opnieuw interactief moet aanmelden.

De controlevraag voor ontwikkelteams is dus eenvoudig te formuleren: kan deze toepassing omgaan met een Conditional Access-uitdaging tijdens het aanmelden? Als het antwoord ja is, is er niets te doen.

Beoordeling en instellingen

Het Message Center-bericht verwijst naar aka.ms/BaselineScopesSettings voor uitleg en beoordeling, en naar aka.ms/BaselineScopesSettingsUX voor de bijbehorende instellingen in de beheerportal (met een aparte variant voor de Amerikaanse overheidscloud). De blogpost zelf verwijst naar aka.ms/CAforLowValueScopes voor de gedetailleerde toelichting. Organisaties die willen weten welke aanmeldingen in hun tenant onder de huidige lacune vallen, vinden daar het startpunt; het bericht kondigt daarnaast aan dat er twee weken vóór de uitrol een notificatie volgt.

De juni-agenda

Voor beheerders komt het neer op drie punten in de komende weken:

  • Vooraf: het overzicht van Conditional Access-beleid nalopen op regels die op "Alle resources" staan en uitsluitingen bevatten. Dat zijn de regels waarvan de reikwijdte feitelijk groter wordt.
  • Rond 15 juni: de servicedesk informeren dat een enkele toepassing een extra MFA-verzoek kan gaan tonen, en dat dit verwacht gedrag is.
  • Bij eigen toepassingen met alleen basisscopes: nagaan of de aanmeldstroom een Conditional Access-uitdaging aankan.

Wie de basisinrichting van Conditional Access nog eens wil nalezen, vindt die in de documentatie van Microsoft Entra. De wijziging van 15 juni verandert niets aan die basis; ze zorgt ervoor dat de basis overal wordt toegepast.

Bronnen

Over de auteur

Mohamed Zagoudi

Freelance systeembeheerder & ICT-coördinator

Dit artikel is gebaseerd op eigen praktijkervaring in ICT-beheer en automatisering en bevat geen verwijzingen naar specifieke klanten.

Vragen over dit onderwerp?

Stuur me gerust een bericht. Ik reageer zelf.