Continuous Access Evaluation (CAE) erklärt – Echtzeit statt Token-Ablauf

Die unbequeme Wahrheit klassischer Token: Wenn du einen Mitarbeiter sperrst, bleibt er trotzdem drin – bis sein Access Token irgendwann von selbst abläuft, typischerweise nach rund einer Stunde. CAE schließt genau diese Lücke, indem Ressourcen auf kritische Ereignisse nahezu in Echtzeit reagieren. Aber CAE ist kein Allheilmittel: Es funktioniert nur dort, wo Client UND Ressource mitspielen.

Ohne CAE bleibt ein gesperrter Nutzer bis zum Token-Ablauf drin – mit CAE fliegt er in Minuten.

Das Problem, das CAE löst

Entra ID (früher Azure AD) arbeitet wie die meisten modernen Identitätssysteme mit kurzlebigen Access Tokens. Ein Token gilt standardmäßig etwa 60 bis 90 Minuten. Solange es gültig ist, fragt die Ressource – etwa Exchange Online – nicht beim Identitätsanbieter nach, ob der Nutzer noch berechtigt ist. Das ist gewollt: Ständiges Nachfragen wäre lahm und teuer.

Der Haken: Sperrst du ein Konto, änderst das Passwort oder stuft Identity Protection das Konto als hochriskant ein, während ein gültiges Token im Umlauf ist, ändert das erstmal nichts. Der Nutzer arbeitet munter weiter, bis sein Token verfällt. In einem echten Sicherheitsvorfall ist eine Stunde eine Ewigkeit.

Token-Ablauf vs. CAE: der Unterschied in der Praxis

Der Kerngewinn von CAE liegt nicht darin, dass Token kürzer leben – im Gegenteil. Der Gewinn ist, dass ein laufendes Token sofort wertlos wird, wenn etwas Kritisches passiert. Das ist der Sprung von 'irgendwann läuft es ab' zu 'jetzt ist Schluss'.

Bei einem kritischen Ereignis signalisiert Entra der Ressource den Widerruf – der Client wird sofort herausgeworfen.

Welche Ereignisse lösen das aus? Konto deaktiviert oder gelöscht, Passwort geändert oder zurückgesetzt, Token explizit widerrufen, MFA für den Nutzer aktiviert, und – mit Entra ID P2 – ein durch Identity Protection erkanntes hohes Benutzerrisiko. Zusätzlich kann CAE Conditional-Access-Bedingungen wie Standort (Named Locations) nahezu in Echtzeit durchsetzen.

Wo CAE wirkt – und wo eben nicht

Hier trennt sich Marketing von Realität. CAE klingt nach 'Sicherheit in Echtzeit für alles', ist es aber nicht. Es braucht zwei Voraussetzungen gleichzeitig: einen CAE-fähigen Client UND eine CAE-fähige Ressource. Fehlt eine Seite, fällt der Zugriff auf das klassische Token-Verhalten zurück.

CAE liefert schnellen Widerruf bei kritischen Ereignissen, ersetzt aber keine durchdachte Token- und Client-Strategie.

Strict Location Enforcement – die schärfere Stufe

Standardmäßig arbeitet CAE im Modus, der bei einem IP-Wechsel außerhalb erlaubter Named Locations eine Neuauthentifizierung verlangt, dem Token aber für kurze Zeit noch traut, um Fehlalarme bei wechselnden IPs zu vermeiden. Wer es strenger will, kann 'Strictly enforce location policies' über eine Conditional-Access-Policy aktivieren – dann wird ein Token sofort verworfen, sobald die IP nicht mehr passt.

Umsetzung: CAE-Status prüfen und steuern

CAE ist für die meisten Tenants automatisch aktiv, lässt sich aber über Conditional Access gezielt steuern und für Pilotgruppen testen. Per Microsoft Graph PowerShell siehst du, welche CA-Policies CAE konfigurieren.

Im Sign-in-Log erkennst du an der Eigenschaft 'Is CAE Token', ob eine Anmeldung über CAE läuft. Das ist der schnellste Weg, um zu prüfen, ob deine Clients CAE überhaupt nutzen – falls dort überall 'No' steht, redet ihr über ein Feature, das bei euch gar nicht greift.

Beispiel aus der Praxis

Die Sparfuchs & Partner Steuerberatungs GmbH (kleiner Dienstleister, knappes Budget) entlässt kurzfristig einen Mitarbeiter. Der Admin deaktiviert das Konto sofort im Entra-Portal und fühlt sich sicher. Eine halbe Stunde später fällt auf, dass der Ex-Mitarbeiter noch in Outlook seine Mails lesen konnte.

Der Grund: Sein Outlook war zwar CAE-fähig, aber er nutzte auf dem Privatrechner einen älteren Mail-Client über IMAP – und der versteht weder moderne Authentifizierung noch CAE. Das deaktivierte Konto wurde dort erst beim nächsten regulären Token-Refresh wirksam. Die Lehre für Sparfuchs: CAE ist großartig, aber nur für CAE-fähige Zugänge. Die echte Absicherung war, Legacy-Authentifizierung per Conditional Access komplett zu blockieren – danach gibt es schlicht keinen Weg mehr, CAE zu umgehen. Ein gesperrtes Konto ist dann auch wirklich gesperrt.

Verwandte Artikel

Häufige Fragen (FAQ)

Frage 1: Brauche ich für CAE eine spezielle Lizenz?

Antwort: Die grundlegende Continuous Access Evaluation ist Teil von Entra ID und auch ohne Premium-Lizenz für die unterstützten Microsoft-365-Workloads aktiv. Risikobasierte Auslöser – etwa hohes Benutzerrisiko aus Identity Protection – setzen jedoch Entra ID P2 voraus, weil das Risiko-Signal selbst ein P2-Feature ist.

Frage 2: Macht CAE meine Token sicherer, weil sie kürzer leben?

Antwort: Im Gegenteil – CAE erlaubt sogar längere Sessions, weil ein Token jederzeit widerrufbar wird. Der Sicherheitsgewinn liegt nicht in der kürzeren Lebensdauer, sondern darin, dass kritische Ereignisse wie Kontosperrung oder Passwortwechsel nahezu in Echtzeit durchschlagen, statt auf den Token-Ablauf zu warten.

Frage 3: Welche Ereignisse lösen einen CAE-Widerruf aus?

Antwort: Kontodeaktivierung oder -löschung, Passwortänderung oder -reset, expliziter Token-Widerruf, Aktivierung von MFA für den Nutzer und – mit P2 – ein erkanntes hohes Benutzerrisiko. Zusätzlich kann CAE Standortbedingungen über Named Locations nahezu in Echtzeit durchsetzen.

Frage 4: Warum konnte ein gesperrter Nutzer trotz CAE noch zugreifen?

Antwort: Mit großer Wahrscheinlichkeit, weil entweder der Client oder die genutzte Ressource nicht CAE-fähig war. Ältere Mail-Clients über IMAP/POP, Legacy-Authentifizierung und viele Drittanbieter-Apps unterstützen CAE nicht und fallen auf klassisches Token-Verhalten zurück. Legacy-Auth zu blockieren schließt diese Lücke.

Frage 5: Was ist Strict Location Enforcement und sollte ich es aktivieren?

Antwort: Es ist die strenge CAE-Variante, die ein Token sofort verwirft, sobald die IP eine erlaubte Named Location verlässt – ohne Toleranzfenster. Sehr wirksam, aber riskant, wenn deine ausgehenden IPs nicht lückenlos als Named Locations gepflegt sind. Erst die Standorte sauber definieren, dann mit einer Pilotgruppe ausrollen.

Frage 6: Wie sehe ich, ob CAE in meinem Tenant überhaupt greift?

Antwort: Im Sign-in-Log gibt es die Eigenschaft 'Is CAE Token'. Steht dort bei euren Anmeldungen überall 'No', nutzen eure Clients CAE nicht – dann ist das Feature faktisch wirkungslos, egal was im Portal konfiguriert ist. Das ist der erste Check vor jeder CAE-Diskussion.

Wie geht es weiter?