Microsoft hat die Learn-Dokumentation zu Conditional Access mit Resource Exclusions am 8. Oktober 2026 aktualisiert. Wichtig ist die Änderung für Mandanten, die Richtlinien auf „All resources“ anwenden und einzelne Ressourcen ausschließen. Baseline Scopes wie openid, profile oder User.Read wurden in solchen Konstellationen früher automatisch nicht erzwungen. Microsoft beschreibt nun ein verbessertes Enforcement-Modell: Anmeldungen, die nur diese Baseline Scopes anfordern, werden als Directory Access bewertet und können Conditional-Access-Anforderungen auslösen.
Warum diese Änderung für KMU zählt
In Unternehmen mit 10 bis 250 Arbeitsplätzen sind Conditional-Access-Regeln oft über Jahre gewachsen. Ein typisches Muster ist eine breite Richtlinie für alle Ressourcen, ergänzt um Ausnahmen für Fachanwendungen, ältere Clients oder Administrationspfade. Genau dort kann sich das Verhalten ändern: Wenn ein Client nur Baseline Scopes anfordert, kann nun eine MFA-, Geräte- oder App-Schutz-Anforderung greifen, obwohl der Zugriff bisher ohne Challenge funktioniert hat.
Das ist sicherheitlich sinnvoll, weil Microsoft eine Lücke zwischen ausgeschlossenen Ressourcen und Directory-Zugriff schließt. Für den Betrieb zählt aber die Vorbereitung. Ein Helpdesk sollte wissen, ob Visual Studio Code, Azure CLI, interne Webanwendungen oder ISV-Apps plötzlich zusätzliche Anforderungen anzeigen können.
Welche Konstellationen betroffen sind
Microsoft nennt drei Bedingungen, die zusammen erfüllt sein müssen. Der Mandant hat Conditional-Access-Richtlinien mit „All resources“. Diese Richtlinien enthalten Resource Exclusions. Außerdem melden sich Nutzer über Anwendungen an, die nur Baseline Scopes anfordern.
- OIDC-Baseline-Scopes wie
email,offline_access,openidundprofile, - Directory-Scopes wie
User.Read,User.Read.All,People.ReadoderGroupMember.Read.All, - Public Clients wie Desktop-Apps, die nur solche Scopes anfordern,
- Confidential Clients, die aus einer All-Resources-Richtlinie ausgeschlossen sind und nur Baseline Directory Scopes verwenden.
Für ein Conditional-Access-Konzept heißt das: Ausnahmen dürfen nicht nur nach Anwendungsname betrachtet werden. Entscheidend ist auch, welche Scopes ein Client tatsächlich anfordert.
Fristen und Rollout richtig einordnen
Microsoft schreibt, dass der Rollout des Enforcement-Modells für Baseline Scopes am 15. Juni 2026 begonnen hat. Die Learn-Seite wurde am 8. Oktober 2026 aktualisiert und beschreibt die Änderung als tenantweit angewendetes Verhalten. Wenn keine Einstellung geändert wurde, wird das neue Enforcement automatisch aktiv; nach der Anwendung erscheint laut Microsoft keine Auswahl mehr in den Baseline-Scope-Einstellungen, weil das Verhalten dann der Standard ist.
Das ist keine Lizenz- oder Beschaffungsfrage, sondern eine technische Betriebsprüfung. Wer Disable Enforcement oder Customize Behavior nutzt, behält laut Microsoft die konfigurierte Abweichung, sollte diese aber bewusst dokumentieren. Microsoft empfiehlt die Ausrichtung am neuen Enforcement-Modell und beschreibt Customize Behavior nur für spezifische Szenarien, in denen Legacy-Verhalten erforderlich bleibt.
Welche Auswirkungen Nutzer sehen können
Die sichtbare Folge hängt von den Grant Controls ab. Eine Richtlinie kann MFA, ein compliant device, App Protection oder andere Anforderungen erzwingen. Microsoft nennt als Beispiele Visual Studio Code mit openid und profile, Azure CLI mit User.Read sowie ausgeschlossene Webanwendungen mit User.Read und People.Read. Vor der Änderung konnte die Anmeldung ohne MFA durchlaufen; danach kann Conditional Access gegen Windows Azure Active Directory als Zielressource auswerten.
Nicht betroffen sind Anwendungen, die zusätzlich zu Baseline Scopes weitere Ressourcen-Scopes anfordern, etwa Mail.Read oder Files.Read. Solche Zugriffe wurden bereits über die jeweilige Ressource bewertet. Für Microsoft-365-Beratung und Betrieb ist deshalb eine saubere Trennung wichtig: Nicht jede App ist betroffen, aber betroffene Ausnahmen können sehr geschäftskritisch sein.
Konkrete nächste Schritte
Ein pragmatischer Check lässt sich ohne große Umbauten starten:
- Richtlinien ermitteln, die „All resources“ einschließen und Ressourcen ausschließen.
- Mit der von Microsoft genannten Graph-Abfrage betroffene Policies inventarisieren.
- Sign-in-Logs auf Anwendungen prüfen, die nur Baseline Scopes verwenden.
- Tenant-eigene Apps testen, ob sie Conditional-Access-Challenges sauber verarbeiten.
- ISV-Apps mit Baseline Directory Scopes beim Anbieter klären.
Temporäre Abweichungen sollten eng dokumentiert werden: Welche Richtlinie, welche Anwendung, welcher Grund und welcher Termin für die erneute Prüfung. Dauerhafte globale Deaktivierung ist laut Microsoft nicht empfohlen, weil sie Lücken in der Conditional-Access-Abdeckung schaffen kann.
Offizielle Microsoft-Quellen
- Microsoft Learn: Enforcement for baseline scopes in Conditional Access
- Microsoft Learn: Targeting resources in Conditional Access policies
- Microsoft Learn: Developer guidance for Conditional Access
Wenn Sie prüfen möchten, ob Ihre Conditional-Access-Ausnahmen noch sauber funktionieren, analysieren wir Richtlinien, Sign-in-Logs und App-Verhalten in einem Microsoft Security Assessment – sprechen Sie uns an.
Was bedeutet das für Ihre Umgebung?
Ordnen Sie das Thema im Kontext Ihrer Microsoft-365-Umgebung ein und legen Sie einen sinnvollen nächsten Schritt fest.
Sie sprechen direkt mit Sebastian Kerssen – seit 2014 im Microsoft-Umfeld, mit persönlicher Beratung und direktem Ansprechpartner.
