Entra ID: Neue Conditional Access Policies

Zero Trust, Agenten-Identitäten und NIS2 — warum du deine Richtlinien genau jetzt anfassen musst

Executive Summary

Conditional Access war jahrelang das Werkzeug, mit dem du Menschen von Ressourcen ferngehalten hast. Das reicht nicht mehr. Microsoft hat die Policy-Engine in den vergangenen Monaten an drei Stellen aufgebohrt, und jede einzelne davon zwingt dich, dein Regelwerk anzufassen. Erstens: Die MFA-Erzwingung für Azure ist durch. Phase 1 traf ab Oktober 2024 die Portale, Phase 2 seit dem 1. Oktober 2025 auch Azure CLI, Azure PowerShell, die Azure Mobile App, die REST-API des Control Plane und damit sämtliche Infrastructure-as-Code-Pipelines. Der letzte Aufschub, den du beantragen konntest, ist am 1. Juli 2026 ausgelaufen. Zwölf Tage her. Falls in deiner Pipeline noch ein Benutzerkonto mit Passwort steckt, ist das kein Architekturschuldschein mehr, sondern ein Produktionsausfall mit Termin.

Zweitens: Heute, am 13. Juli 2026, ist der Rollout abgeschlossen, mit dem Conditional Access auch bei der Registrierung von Windows Hello for Business und macOS Platform SSO greift. Bisher liefen diese Flows an deinen Richtlinien vorbei. Es wurde zwar standardmäßig MFA verlangt, aber deine Grant-Controls wie Authentication Strength oder vertrauenswürdiger Standort wurden schlicht ignoriert. Das ist seit dem 6. Juli Geschichte. Wer eine strenge Registrierungsrichtlinie hat und seine Benutzer nicht darauf vorbereitet, produziert ab sofort Tickets im Onboarding.

Drittens, und das ist die eigentliche Zeitenwende: Conditional Access kennt jetzt Agenten. Die Entra Agent ID Plattform ist seit April 2026 allgemein verfügbar, und seit Juni kannst du KI-Agenten in Richtlinien adressieren — einzeln, über Blueprints oder dynamisch über Custom Security Attributes. Neue Bedingungen wie Agent Risk und Agent Execution Environments kommen dazu. Und weil das Timing so schön passt: Das deutsche NIS2-Umsetzungsgesetz gilt seit dem 6. Dezember 2025 ohne Übergangsfrist für rund 29.500 Unternehmen in 18 Sektoren. Die Registrierungsfrist beim BSI lief am 6. März 2026 ab. Was du in Entra baust, ist damit nicht länger nur gute Hygiene, sondern dein Nachweis nach Paragraf 30 BSIG.

Abbildung 1: Alles, was zwischen Oktober 2024 und Ende 2027 auf deine Identitätsplattform einprasselt — inklusive der Fristen, die bereits abgelaufen sind.

Worum geht es im Detail?

Fangen wir mit dem an, was dir bereits um die Ohren fliegt. Die MFA-Pflicht für Azure ist keine Empfehlung und keine Richtlinie, die du in deinem Tenant abschalten kannst. Sie sitzt serverseitig im Azure Resource Manager. Jeder Request gegen management.azure.com, der etwas anlegt, ändert oder löscht, verlangt einen Token mit MFA-Anspruch. Lesezugriffe bleiben verschont. Das klingt harmlos, bis du dir vergegenwärtigst, was in einer durchschnittlichen deutschen IT-Abteilung alles über ein normales Benutzerkonto läuft: der nächtliche Terraform-Run, das PowerShell-Skript von 2019, das niemand mehr anfasst, weil es ja funktioniert, und der Monitoring-Job, dessen Passwort im Klartext in einer Batch-Datei steht, die aus Sicherheitsgründen "final_v3_NEU.bat" heißt.

Workload Identities sind ausgenommen. Managed Identities und Service Principals interessiert die MFA-Pflicht nicht. Genau das ist die Migration, die du eigentlich seit Jahren hättest machen sollen: Benutzerkonten, die als Dienstkonten missbraucht werden, gehören auf Managed Identities umgezogen. Was ebenfalls stirbt, ist der ROPC-Flow, also die Anmeldung per Benutzername und Passwort im Code. Er ist mit MFA grundsätzlich unvereinbar und in praktisch allen MSAL-Bibliotheken sowie den Azure-Identity-Bibliotheken bereits als veraltet markiert. Wenn deine Anwendung Benutzername und Passwort gegen Entra ID schickt, ist sie tot. Sie weiß es nur noch nicht.

Auch Break-Glass-Konten sind nicht ausgenommen, und das ist die Stelle, an der erfahrungsgemäß der kalte Schweiß ausbricht. Dein Notfallkonto, das du bewusst aus allen Conditional-Access-Richtlinien ausgeschlossen hast, muss trotzdem MFA können. Microsofts Empfehlung lautet Passkey nach FIDO2 oder zertifikatsbasierte Authentifizierung, weil beide Verfahren den MFA-Anspruch erfüllen, ohne dass jemand ein Mobiltelefon zücken muss. Ein Notfallkonto, das im Ernstfall an einer SMS hängt, die niemand empfängt, ist kein Notfallkonto. Das ist ein Denkmal.

Der zweite Punkt ist subtiler und deshalb gefährlicher. Bis vor Kurzem galt: Wenn ein Benutzer Windows Hello for Business einrichtet oder auf dem Mac Platform SSO registriert, wurde zwar MFA verlangt, aber die Conditional-Access-Richtlinie mit der User Action "Sicherheitsinformationen registrieren" wurde in diesem Flow überhaupt nicht ausgewertet. Deine schöne Richtlinie "Registrierung nur aus dem Firmennetz und nur mit phishing-resistenter MFA" galt für Windows Hello einfach nicht. Seit dem 6. Juli 2026 wird sie ausgewertet, seit heute ist der Rollout abgeschlossen. Wer die Grant-Controls nicht erfüllt, schließt die Registrierung nicht ab. Punkt.

Sicherheitstechnisch ist das goldrichtig. Die Registrierung eines Anmeldeverfahrens ist der Wurzelmoment jeder Identität. Wer sie kompromittiert, muss danach nie wieder ein Passwort stehlen, weil er sich einfach seinen eigenen zweiten Faktor einträgt. Operativ ist es trotzdem ein Minenfeld. Der Klassiker: Der neue Kollege im Homeoffice packt den Laptop aus, will Windows Hello einrichten, und deine Named-Location-Richtlinie sagt Nein, weil er nicht im Büro sitzt. Vorher lief das durch. Ab heute nicht mehr.

Und jetzt der spannende Teil. Entra Agent ID ist seit April 2026 allgemein verfügbar und bringt KI-Agenten als vollwertige Identitäten ins Verzeichnis, mit OAuth 2.0, MCP und A2A als Protokollen. Ein Agent ist damit kein Skript mehr, das im Kontext eines armen Kollegen mitläuft, sondern ein eigenständiges Sicherheitsobjekt mit Lebenszyklus. Seit Juni kannst du diese Objekte in Conditional Access adressieren.

Dabei musst du zwei Dinge sauber auseinanderhalten, sonst reißt du dir ein Loch in die Baseline. Es gibt die Agenten-Identität, mit der ein Agent im eigenen Namen auf Ressourcen zugreift. Und es gibt das Benutzerkonto eines Agenten, derzeit in der Vorschau. Der entscheidende Satz aus der Dokumentation lautet: Richtlinien, die auf "Alle Benutzer" zielen, erfassen die Benutzerkonten von Agenten nicht. Lies den Satz ruhig noch einmal. Deine Baseline, auf die du so stolz bist, greift bei Agenten nicht automatisch.

Adressieren kannst du Agenten einzeln, über Blueprints — dann sind auch alle künftig daraus abgeleiteten Agenten automatisch erfasst, was der einzig skalierbare Weg ist — oder dynamisch über Custom Security Attributes. Als Bedingungen stehen Agent Risk aus ID Protection zur Verfügung, dazu Agent Execution Environments, Gerätecompliance, Filter for Devices und Compliant Network über den Global Secure Access Client. Bei den Controls wird es interessant: Für reine Agenten-Identitäten gibt es genau eine Option, nämlich Block. Kein MFA, kein Grant, keine Verhandlung. Ein Agent kann sich nicht ausweisen und kein Passwort zurücksetzen, also existiert kein interaktiver Remediationspfad. Nur bei Agenten-Benutzerkonten kannst du zusätzlich Grant mit "Gerät muss als kompatibel markiert sein" verlangen. Das setzt aber voraus, dass der Agent auf einem verwalteten Endpunkt läuft, etwa einem Windows 365 Cloud PC for Agents.

Abbildung 2: Wie die Policy-Engine 2026 tatsächlich arbeitet — und warum Agenten-Benutzerkonten aus deiner "Alle Benutzer"-Richtlinie herausfallen.

Den regulatorischen Rahmen liefert Berlin. Das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz ist am 6. Dezember 2025 in Kraft getreten, ohne Übergangsfrist, für rund 29.500 Unternehmen in 18 Sektoren, mit der Schwelle bei 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz. Die Registrierung beim BSI über das neue Melde- und Informationsportal war bis zum 6. März 2026 fällig. Paragraf 30 BSIG verlangt Risikomanagementmaßnahmen und nennt Zugriffskontrolle und Multifaktorauthentifizierung ausdrücklich. Paragraf 38 nimmt die Geschäftsleitung persönlich in die Pflicht, Paragraf 65 stellt Bußgelder bis zu 10 Millionen Euro in Aussicht. Der Prüfer wird dich nicht fragen, ob du Zero Trust gut findest. Er wird nach dem Nachweis fragen.

Abbildung 3: Was das Gesetz verlangt, was du dafür in Entra konfigurierst und was am Ende im Auditordner liegen muss.

Was sind Chancen? Was sind Risiken?

Die größte Chance ist banal und wird trotzdem systematisch verschenkt: Du bekommst gerade einen Compliance-Nachweis geschenkt, für den du sonst hättest kämpfen müssen. Jede Conditional-Access-Richtlinie ist exportierbares JSON. Jeder Anmeldevorgang landet im Sign-in-Log mitsamt der Angabe, welche Richtlinie gegriffen hat. Der Report-only-Modus liefert dir eine Wirkungsanalyse, bevor du erzwingst. Das ist ein prüffähiger Auditpfad ab Werk. Wer das geschickt aufbereitet, füllt die halbe NIS2-Risikomanagement-Dokumentation mit Material, das ohnehin schon da ist.

Die zweite Chance heißt Passkeys. Microsoft schiebt mit aller Kraft in Richtung phishing-resistenter Verfahren: Registrierungskampagnen unterstützen jetzt Passkeys, die systembevorzugte Authentifizierung greift inzwischen auch beim ersten Faktor — Benutzer mit starken Anmeldeinformationen können sich also ganz ohne Passwort anmelden — und der Speicherplatz für Passkey-Richtlinien wurde auf eigene 20 Kilobyte erhöht, die Zahl der Passkey-Profile von drei auf zehn. Übersetzt heißt das: Microsoft räumt dir die technischen Hürden weg, damit du endlich das Passwort loswirst. Ein Benutzer mit Passkey erfüllt die MFA-Pflicht ohne einen einzigen zusätzlichen Klick. Das ist der seltene Fall, in dem mehr Sicherheit weniger Reibung bedeutet.

Dritte Chance, gerade massiv unterschätzt: Entra Backup and Recovery sichert automatisch und täglich die kritischen Verzeichnisobjekte, inklusive Conditional-Access-Richtlinien, Named Locations und Agent IDs, bei P1 oder P2 mit sieben Tagen Aufbewahrung. Du kannst Snapshots vergleichen und gezielt zurückrollen. Wer schon einmal um drei Uhr nachts rekonstruiert hat, welcher Kollege welche Richtlinie "nur ganz kurz zum Testen" verändert hat, weiß, was das wert ist.

Die operativen Risiken sind unspektakulär, aber teuer. Erstens die Selbstaussperrung: Wer eine Richtlinie erzwingt, ohne vorher Report-only zu fahren, und dabei sein eigenes Administratorkonto miteinschließt, hat den Tenant zugesperrt und den Schlüssel innen liegen lassen. Zweitens die Registrierungsblockade, die seit heute scharf ist. Drittens die Automatisierung, die leise stirbt: kein Alarm, kein roter Balken im Monitoring, nur ein nächtlicher Job, der plötzlich einen Fehler bekommt, den niemand liest, bis vier Wochen später die Datenbank nicht mehr gesichert ist. Und viertens der Klassiker jeder Migration, die Gäste: B2B-Benutzer müssen MFA erfüllen, entweder im Ressourcentenant oder über sauber konfigurierte Cross-Tenant-Einstellungen aus ihrem Heimattenant. Wenn dein wichtigster Lieferant seine MFA-Ansprüche nicht korrekt weiterreicht, steht er ab sofort vor verschlossener Tür — und ruft nicht bei Microsoft an, sondern bei dir.

Was müssen wir jetzt schon vorbereiten?

Die Reihenfolge ist nicht beliebig. Wer anfängt, Agenten zu governen, während die Break-Glass-Konten noch an einer SMS hängen, hat die Prioritäten verwechselt. Diese Liste arbeitest du von oben nach unten ab.

Break-Glass-Konten auf Passkey oder zertifikatsbasierte Authentifizierung umstellen. Zwei Konten, unterschiedliche Verfahren, Zugangsdaten physisch getrennt verwahrt, halbjährlicher Test mit Protokoll. Der Test ist kein Formalismus, sondern dein Beleg gegenüber dem Prüfer.

Benutzerkonten identifizieren, die in Wahrheit Dienstkonten sind. Sign-in-Logs nach den App-IDs von Azure CLI und Azure PowerShell filtern, jedes Ergebnis einem Verantwortlichen zuordnen, dann konsequent auf Managed Identity oder Service Principal migrieren. Seit dem 1. Juli 2026 gibt es keinen Aufschub mehr, an dem du dich festhalten könntest.

Jede Richtlinie mit der User Action "Sicherheitsinformationen registrieren" heute prüfen. Report-only aktivieren, eine Woche Daten sammeln, gezielt nach Homeoffice-Onboardings suchen und einen Temporary Access Pass als Ausweg für die Erstregistrierung einplanen.

ROPC ausrotten. Jede Anwendung, die Benutzername und Passwort gegen Entra ID schickt, kommt auf eine Liste mit Verantwortlichem und Zieldatum. Die Bibliotheken sind bereits als veraltet markiert. Das ist keine Meinung mehr, sondern ein Changelog.

Eine eigene Richtlinienebene für Agenten aufbauen, strikt getrennt von den Benutzerrichtlinien, adressiert über Blueprints statt über Einzelobjekte, abgesichert mit der Bedingung Agent Execution Environments gegen Fehlblockaden. Und mit einem menschlichen Verantwortlichen pro Agent, der bei einem Access Review tatsächlich antwortet.

Den Auditpfad einmal komplett zusammenstellen: Richtlinien-Export, Sign-in-Logs, Report-only-Auswertung, Risk Detections, Access Reviews und das Freigabeprotokoll der Geschäftsleitung. Einmal aufgebaut, danach quartalsweise nachziehen. Wer damit erst anfängt, wenn das BSI anruft, hat bereits verloren.

Und noch ein Gedanke für die Runde mit der Geschäftsleitung: Verkaufe das Ganze nicht als Sicherheitsprojekt. Sicherheitsprojekte werden verschoben, das ist Naturgesetz. Verkaufe es als Haftungsprojekt. Paragraf 38 BSIG nimmt die Geschäftsleitung persönlich in die Pflicht, Risikomanagementmaßnahmen zu billigen und ihre Umsetzung zu überwachen. Das Wort "persönlich" wirkt in Vorstandssitzungen erfahrungsgemäß erheblich schneller als jedes Architekturdiagramm. Und ja, du darfst das ruhig ausnutzen.

Häufig gestellte Fragen

Kann ich die MFA-Pflicht für Azure noch aufschieben?

Nein. Die Möglichkeit, den Start der Phase-2-Erzwingung selbst zu verschieben, endete am 1. Juli 2026. Nach Beginn der Erzwingung kann ausschließlich ein globaler Administrator über den Microsoft-Support eine befristete Aussetzung beantragen, und die wird nur bei nachvollziehbaren technischen Hindernissen gewährt. Ein generelles Opt-out gibt es nicht, auch nicht für reine Testtenants.

Gelten meine bestehenden Conditional-Access-Richtlinien automatisch auch für KI-Agenten?

Nur teilweise, und genau darin liegt die Falle. Richtlinien, die auf "Alle Benutzer" zielen, erfassen die Benutzerkonten von Agenten ausdrücklich nicht. Du brauchst eigene Richtlinien, die entweder alle Agenten-Identitäten, alle Agenten-Benutzerkonten oder gezielt einzelne Agenten beziehungsweise deren Blueprints adressieren.

Was passiert mit meinem Break-Glass-Konto, wenn MFA überall erzwungen wird?

Es muss MFA erfüllen können, denn die Systemerzwingung kennt keine Ausnahme für Notfallkonten. Microsoft empfiehlt, diese Konten auf Passkey nach FIDO2 oder auf zertifikatsbasierte Authentifizierung umzustellen, weil beide Verfahren den MFA-Anspruch erfüllen und nicht von einem Mobilgerät, einer Mobilfunkverbindung oder einem einzelnen Menschen abhängen.

Reicht Conditional Access allein für NIS2-Konformität aus?

Nein, aber es deckt einen substanziellen Teil der Maßnahmen aus Paragraf 30 BSIG ab, insbesondere Zugriffskontrolle, Multifaktorauthentifizierung und risikobasierte Steuerung. Was darüber hinaus verlangt wird — Meldeprozesse, Business Continuity, Sicherheit in der Lieferkette und die dokumentierte Beteiligung der Geschäftsleitung — musst du organisatorisch daneben aufbauen.

Warum schlagen bei uns seit Kurzem Windows-Hello-Registrierungen fehl?

Mit hoher Wahrscheinlichkeit, weil Conditional-Access-Richtlinien mit der User Action "Sicherheitsinformationen registrieren" seit dem 6. Juli 2026 auch bei der Registrierung von Windows Hello for Business und macOS Platform SSO ausgewertet werden; der Rollout ist zum 13. Juli 2026 abgeschlossen. Prüfe die betroffene Richtlinie auf Grant-Controls wie vertrauenswürdige Standorte oder eine bestimmte Authentication Strength, die deine Benutzer im Homeoffice schlicht nicht erfüllen können.