Op 15 juni 2026 begint Microsoft volgens de laatste aankondiging met een wijziging in de manier waarop Microsoft Entra Conditional Access een smalle groep 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 OpenID Connect-scopes of een beperkte set directoryscopes vraagt. Tot nu toe werd zo'n beleid voor die aanmeldingen niet gehandhaafd.
De aankondiging verscheen op 28 januari 2026 op het Microsoft Entra-blog, geschreven door Swaroop Krishnamurthy, en werd op 29 januari als bericht MC1223829 in het Message Center gepubliceerd. Microsoft plaatst de maatregel in het kader van het Secure Future Initiative en noemt haar een proactieve stap voor "defense-in-depth". De datum is sindsdien twee keer verschoven.
De tijdlijn
| Moment | Handhavingsdatum volgens Microsoft |
|---|---|
| Message Center, versie van 30 januari 2026 | vanaf 27 maart 2026, geleidelijk over enkele weken tot juni 2026 |
| Tussenliggende versie | 13 mei 2026 (het Message Center noemt deze datum als "previously") |
| Blogpost, laatst bijgewerkt 14 mei 2026 | vanaf 15 juni 2026, met verdere details via het Message Center |
Ook de nieuwe datum is het begin van een geleidelijke uitrol over enkele weken, niet een omslagpunt voor alle tenants tegelijk.
Wat de lacune precies is
De documentatie van Conditional Access beschrijft het gedrag dat nu verandert. Een beleid op "Alle resources" zonder uitsluitingen wordt gehandhaafd voor elk tokenverzoek, inclusief verzoeken aan resources die in de beleidskiezer niet afzonderlijk te selecteren zijn, zoals Windows Azure Active Directory (Azure AD Graph, app-ID 00000002-0000-0000-c000-000000000000).
Zodra een beleid op "Alle resources" één resource uitsluit, werden bepaalde scopes met lage rechten tot nu toe automatisch buiten de handhaving gehouden, om te voorkomen dat gebruikers onbedoeld werden geblokkeerd. Het zijn de scopes die toepassingen bij het aanmelden vragen om basisgegevens over de gebruiker op te halen. Het voorbeeld uit de documentatie: wanneer Outlook een token voor Exchange vraagt, vraagt het ook User.Read om de accountgegevens van de gebruiker te tonen.
De documentatie somt de betreffende scopes op:
- Native clients en single-page applications:
email,offline_access,openid,profileenUser.Read(Azure AD Graph); voor Microsoft Graph daarnaastPeople.Read. - Confidential clients, als ze van een "Alle resources"-beleid zijn uitgesloten: dezelfde scopes plus
User.Read.AllenUser.ReadBasic.All; voor Microsoft Graph ookPeople.Read,People.Read.All,GroupMember.Read.AllenMember.Read.Hidden.
De eerste vier daarvan zijn de OpenID Connect-scopes van het Microsoft identity platform. openid levert de sub-claim en toegang tot het UserInfo-eindpunt, profile en email verrijken het ID-token, en offline_access levert een refresh token. Een toepassing die uitsluitend deze scopes vraagt, wil in wezen alleen weten wie de gebruiker is.
Voor de evaluatie van Conditional Access worden deze scopes behandeld als directorytoegang en toegewezen aan de resource Azure AD Graph. Dat verklaart de formulering in de aankondiging: welke uitdaging een gebruiker krijgt, hangt af van de toegangsbeheerregels in beleid dat op "Alle resources" is gericht óf expliciet op Azure AD Graph.
Wat er verandert
Na de wijziging worden Conditional Access-beleidsregels die op "Alle resources" zijn gericht ook gehandhaafd voor aanmeldingen waarbij de toepassing alleen de bovengenoemde scopes vraagt, óók wanneer het beleid resource-uitsluitingen bevat. Zodra een toepassing één extra scope vraagt, verandert er niets: die aanmelding viel al onder het beleid.
Wie er iets van merkt
De wijziging raakt volgens de blogpost uitsluitend tenants met ten minste één Conditional Access-beleid dat op "Alle resources" is gericht en een of meer resource-uitsluitingen heeft. Die tenants ontvangen het Message Center-bericht; het bericht zelf vermeldt dat het op basis van telemetrie is verstuurd. Tenants zonder zo'n beleidsconfiguratie worden niet geraakt.
Binnen een geraakte tenant is het effect voor gebruikers concreet: bij een aanmelding via een toepassing die alleen de genoemde scopes vraagt, kan nu een Conditional Access-uitdaging verschijnen, zoals multifactor-authenticatie of een controle op apparaatcompliance, waar de toegang eerder zonder handhaving werd verleend. Dat is geen storing: het beleid dat de organisatie zelf heeft ingericht, wordt nu ook op deze aanmeldingen toegepast.
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 deze scopes en vallen daarmee al onder de handhaving. Microsoft geeft daarnaast aan met populaire softwareleveranciers samen te werken waar updates nodig zijn om Conditional Access-uitdagingen goed af te handelen.
Eigen toepassingen
De groep waarvoor Microsoft een beoordeling aanbeveelt, bestaat uit organisaties met eigen geregistreerde toepassingen die bewust alleen deze scopes vragen. Zo'n toepassing gebruikt Entra ID puur als identiteitsprovider. De vraag is of de toepassing een Conditional Access-uitdaging aankan. Kan ze dat al, dan is er niets te doen; kan ze dat niet, dan zijn volgens de aankondiging mogelijk aanpassingen nodig.
De developer guidance voor Conditional Access, waarnaar beide aankondigingen verwijzen, beschrijft hoe zo'n uitdaging eruitziet. In de meeste gevallen verandert Conditional Access niets aan het gedrag van een toepassing; een interactieve aanmelding is dan voldoende om aan het beleid te voldoen. Codewijzigingen zijn volgens die documentatie nodig wanneer een toepassing indirect of stil (silent) een token aanvraagt, in het bijzonder bij de on-behalf-of-stroom, bij toegang tot meerdere resources, bij single-page apps met MSAL.js en bij webapps die een resource aanroepen. Het identity platform antwoordt dan met error=interaction_required (bijvoorbeeld AADSTS50076 voor MFA) en een claims-parameter, die de toepassing aan een nieuw, interactief tokenverzoek toevoegt om de gebruiker de vereiste stap te laten uitvoeren.
Wat verandert voor beheerders
Voor beheerders komt de wijziging neer op drie observaties:
- Het beleid dat groter wordt in reikwijdte is uitsluitend beleid op "Alle resources" mét resource-uitsluitingen, plus beleid dat expliciet Azure AD Graph als resource heeft. Beleid zonder uitsluitingen wordt al volledig gehandhaafd.
- Het zichtbare effect is een extra MFA-verzoek of apparaatcontrole bij een klein aantal toepassingen die alleen aanmeldscopes vragen. De blogpost verwijst voor het beoordelen van de betrokken toepassingen naar de audience reporting in de troubleshooting-documentatie van Conditional Access.
- De datum is 15 juni 2026 als begin van een uitrol over enkele weken; verdere details volgen volgens de blogpost via het Message Center.
De wijziging verandert niets aan het model van Conditional Access zelf. Ze sluit een uitzondering die bestond om gebruikers niet onbedoeld te blokkeren, en past daarmee het bestaande beleid ook toe op de aanmeldingen die tot nu toe door hun beperkte scopeverzoek buiten de handhaving bleven.
Bronnen
- Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions – Microsoft Entra Blog, 28 januari 2026, bijgewerkt 14 mei 2026
- MC1223829 – Message Center – gepubliceerd 29 januari 2026, versie van 30 januari 2026 voor de oorspronkelijke tijdlijn
- Conditional Access: Target resources – legacy behavior when an All resources policy has a resource exclusion – Microsoft Learn
- Developer guidance for Microsoft Entra Conditional Access – Microsoft Learn
- Scopes and permissions in the Microsoft identity platform – OpenID Connect scopes – Microsoft Learn
