Bildquelle: extern
Continuous Access Evaluation verkürzt das Fenster zwischen Kontosperre und weiterlaufender Sitzung
Viele Sicherheits- und IAM-Teams kennen das Problem, sprechen aber selten offen darüber: Ein Benutzerkonto ist gesperrt, das Passwort wurde zurückgesetzt oder ein hohes Risiko wurde erkannt, und trotzdem laufen einzelne SaaS-Sitzungen noch weiter. Der Grund ist meist banal. Der Zugriff hängt noch an gültigen Access Tokens, deren Laufzeit nicht sofort endet. Solange Anwendungen und Ressourcen nur auf Token-Ablauf warten, bleibt zwischen Sicherheitsereignis und tatsächlichem Zugriffsstopp ein operatives Fenster. Genau dort entstehen unnötige Risiken, aber auch viele Missverständnisse zwischen Identity-Team, Service Desk, Security Operations und Fachbereichen.
Continuous Access Evaluation, kurz CAE, setzt genau an dieser Stelle an. Hinter dem Begriff steckt kein weiterer Identity-Marketingsatz, sondern ein Betriebsprinzip. Der Token-Aussteller, die angebundene Anwendung und die geschützte Ressource sollen sicherheitsrelevante Änderungen nicht erst beim nächsten Refresh bemerken, sondern deutlich früher verarbeiten. Der OpenID-Standard CAEP, also das Continuous Access Evaluation Profile, beschreibt dafür Ereignisse wie Session Revoked, Token Claims Change, Credential Change, Assurance Level Change oder Device Compliance Change. Das zugehörige Shared Signals Framework beschreibt, wie solche Signale zwischen kooperierenden Parteien übertragen und verwaltet werden.
Für den IT-Betrieb ist daran nicht die Spezifikation das Entscheidende, sondern die Auswirkung: Zugriffsentzug wird von einer passiven Wartezeit zu einem aktiven Prozess. Microsoft beschreibt diesen Effekt in Entra bereits sehr konkret. Dort soll Continuous Access Evaluation auf kritische Ereignisse wie deaktivierte Benutzer, Passwortwechsel, aktivierte MFA, explizit widerrufene Refresh Tokens oder hohes Benutzerrisiko in nahezu Echtzeit reagieren. Das Ziel ist also nicht, Tokens pauschal immer kürzer zu machen. Im Gegenteil: Microsoft nennt für unterstützte APIs sogar längere Token-Laufzeiten, wenn Anwendungen CAE sauber verarbeiten. Die Sicherheit entsteht dann nicht mehr durch grobe Verfallsfristen, sondern durch bessere Signale.
Token-Ablauf ist kein Incident-Prozess
Gerade in SaaS-Landschaften wurde der Umgang mit Sitzungen lange als technisches Detail behandelt. Ein Token läuft nach einer Stunde ab, dann wird eben neu bewertet. Für normale Nutzung war das pragmatisch. Für Sicherheitsvorfälle, Offboarding oder kompromittierte Konten ist diese Denke aber zu träge. Wenn der Service Desk meldet, dass ein externes Gerät weiter auf Mail, Dateien oder Chats zugreifen kann, obwohl das Konto bereits deaktiviert wurde, hilft der Hinweis auf die Token-Lebensdauer niemandem. Aus Sicht des Betriebs liegt dann ein Kontrollproblem vor, kein Schönheitsfehler.
Genau deshalb ist Continuous Access Evaluation auch kein reines IAM-Feature. Es verändert, wie schnell Sicherheitsmaßnahmen in echten Geschäftsanwendungen ankommen. Wer CAEP oder vendor-spezifische CAE-Funktionen einführt, baut nicht nur Identity-Logik um, sondern verkürzt Reaktionszeiten in Incident-, Insider-Risk- und Offboarding-Prozessen. Das Thema gehört daher nicht nur in Architekturdiagramme, sondern in Betriebsnachweise und Service-Runbooks.
Der Standard wirkt nur als Kette aus Sender, Empfänger und App-Verhalten
Die Spezifikation wirkt auf den ersten Blick elegant, aber ihre Betriebslogik ist anspruchsvoller, als viele Projekte annehmen. CAEP definiert Event-Typen. Das Shared Signals Framework beschreibt Sender, Empfänger, Event Streams und Management-APIs. In der Praxis müssen diese Rollen aber mit echten Produkten, Verantwortlichen und Vertrauensbeziehungen gefüllt werden. Ein Identitätsanbieter muss ein relevantes Signal erzeugen können. Eine Ressource oder Anwendung muss dieses Signal abonnieren oder die daraus abgeleiteten Claims auswerten. Und der Client muss auf Rückmeldungen korrekt reagieren, statt stumpf mit einem eigentlich bereits entwerteten Token weiterzuarbeiten.
Microsoft macht diesen Punkt in der Anwendungsdokumentation erfreulich klar. Wenn eine Ressource CAE verwendet und eine Anwendung angibt, dass sie CAE-fähig ist, muss sie 401-Antworten mit WWW-Authenticate-Header, insufficient_claims und Claims Challenge korrekt verarbeiten. Tut sie das nicht, kann sie gültig aussehende, aber inhaltlich bereits widerrufene Tokens immer wieder verwenden und damit genau die Lücke offenhalten, die CAE eigentlich schließen soll.
Für IT-Organisationen folgt daraus eine sehr einfache Governance-Regel: CAE-Unterstützung darf nie nur als Häkchen am Identity Provider betrachtet werden. Inventarisiert werden müssen immer mindestens drei Dinge, nämlich signalgebende Quelle, geschützte Zielressource und das Verhalten der betroffenen Clients oder Integrationen. Erst diese Dreiersicht zeigt, ob ein Zugriffspfad wirklich schneller entzogen werden kann.
Kritische Ereignisse müssen in Betriebszuständigkeiten übersetzt werden
Besonders nützlich ist Continuous Access Evaluation dort, wo heute noch mehrere Teams versetzt handeln. Ein Passwort-Reset ist zunächst ein IAM-Ereignis. Ein deaktivierter Benutzer ist oft ein HR-, IAM- oder Security-Ereignis. Ein Risk-Flag kommt womöglich aus einem Detection-System. Für den Anwender und für den Service Desk zählt aber am Ende nur, ob die Sitzung noch funktioniert oder nicht. Genau an dieser Schnittstelle gehen Verantwortlichkeiten oft verloren.
Deshalb sollten Teams die relevanten Ereignisse nicht nur technisch lesen, sondern betrieblich übersetzen. Wer löst die Kontosperre aus. Welche Anwendungen müssen darauf in Minuten reagieren. Welche Ausnahmen sind tolerierbar. Wann wird ein Vorfall eröffnet, wenn ein kritischer Zugriff trotz Sperre weiterläuft. Welche Nachweise braucht ein Administrator, wenn er alle Refresh Tokens eines Benutzers widerruft. Und wie wird dokumentiert, dass eine Ressource das Signal tatsächlich verarbeitet hat.
Gerade in hybriden SaaS-Umgebungen ist das wichtig. Nicht jede Anwendung unterstützt dieselbe Tiefe von CAE oder CAEP. Manche Ressourcen reagieren auf Netzwerkstandort sofort, andere nur auf bestimmte kritische Events, wieder andere gar nicht. Wer diese Unterschiede nicht sauber dokumentiert, verkauft Fachbereichen eine Gleichförmigkeit, die es im Betrieb gar nicht gibt.
Offboarding, Incident Response und Support brauchen neue Runbooks
Der größte Mehrwert liegt selten in der Spezifikation selbst, sondern in den Runbooks drumherum. Offboarding ist ein gutes Beispiel. Viele Organisationen prüfen dort noch immer nur, ob ein Konto deaktiviert, ein Passwort zurückgesetzt und vielleicht Geräte zurückgegeben wurden. Mit Continuous Access Evaluation kommt eine neue Kontrollfrage hinzu: Welche produktiven Anwendungen beenden aktive Sitzungen tatsächlich zeitnah, und wie wird das verifiziert? Ohne diese Frage bleibt Offboarding formal sauber, operativ aber lückenhaft.
Ähnlich ist es im Incident Response. Wenn ein kompromittiertes Konto erkannt wird, reicht es nicht, nur IdP-Maßnahmen auszulösen. Das SOC oder IAM-Team sollte wissen, welche kritischen SaaS-Ressourcen CAE-fähig sind, welche Clients Claims Challenges korrekt behandeln und bei welchen Anwendungen noch klassische Restlaufzeiten gelten. Erst daraus ergibt sich eine realistische Aussage über die tatsächliche Eindämmung.
Auch der Support gewinnt durch klarere Runbooks. Statt vager Aussagen wie „der Zugriff sollte bald enden“ können Teams präziser arbeiten: Signal ausgelöst um 10:14 Uhr, betroffene Dienste mit CAE-Unterstützung neu bewertet, nicht unterstützte Anwendungen auf Beobachtung oder manuelle Abmeldung gesetzt, Anwenderkommunikation aktualisiert. Diese Präzision ist im Alltag viel wert, weil sie aus einem Identitätsthema einen steuerbaren Serviceprozess macht.
Ohne Tests und Observability bleibt CAE nur ein Architekturversprechen
Viele Identity-Funktionen scheitern nicht am Design, sondern an fehlender Verifikation im Regelbetrieb. Continuous Access Evaluation ist dafür besonders anfällig, weil sich der Nutzen erst im Grenzfall zeigt. Solange keine Kontosperre, kein Risk-Signal und kein Claims-Challenge-Pfad praktisch geprüft werden, bleibt unklar, wie schnell die Reaktion wirklich ist. Microsoft nennt als Ziel für kritische Ereignisse eine nahezu Echtzeit-Reaktion, weist aber zugleich darauf hin, dass Event-Propagation Zeit kosten kann. Genau deshalb braucht der Betrieb eigene Messpunkte.
Sinnvoll sind hier wenige, klare Testszenarien: Benutzer deaktivieren, Passwort ändern, Refresh Tokens widerrufen, Standortwechsel auslösen, Risikoereignis simulieren, und danach je Anwendung messen, wann die Sitzung tatsächlich nicht mehr verwendbar ist. Zusätzlich sollte protokolliert werden, ob die Ressource ein Claims-Challenge-401 geliefert hat, ob der Client korrekt neu angefordert hat und ob im Fehlerfall nachvollziehbar bleibt, warum ein Zugriff noch bestand.
Wer diese Messpunkte nicht hat, kann weder Security noch Revision belastbar erklären, was „nahezu Echtzeit“ im eigenen Betrieb wirklich bedeutet. Observability für CAE ist deshalb weniger ein Luxus als eine Voraussetzung für ehrliche Zusagen gegenüber Fachbereichen und Prüfern.
Wo der pragmatische Einstieg beginnt
Niemand muss die gesamte SaaS-Landschaft auf einmal umstellen. Praktischer ist ein enger Einstieg entlang besonders kritischer Zugriffspfade. Dazu zählen in der Regel Mail, Kollaboration, Dateizugriff, Administrationsoberflächen und Systeme mit hohem Datenabflussrisiko. Für diese Dienste lässt sich zuerst inventarisieren, welche Ereignisse unterstützt werden, wie die Reaktionskette aussieht und welche Restlücken bleiben.
Danach lohnt sich ein zweiter Blick auf Anwendungsentwicklung und Integrationen. Eigene Clients, Skripte oder Middleware-Komponenten, die geschützte APIs nutzen, müssen Claims Challenges sauber verarbeiten. Genau hier entstehen sonst stille Schwachstellen. Die Infrastruktur unterstützt CAE vielleicht bereits, aber eine interne Anwendung ignoriert 401-Antworten mit zusätzlichen Claims und baut sich durch Retry-Logik ihren eigenen Bypass. Solche Fehler wirken unscheinbar, sind betrieblich aber hochrelevant.
Der pragmatische Einstieg besteht deshalb aus Inventar, Priorisierung und Tests, nicht aus einer neuen Folienserie. Wer zuerst die kritischen Anwendungen identifiziert, Ereignisse und Zuständigkeiten kartiert und dann gezielt die Claims-Challenge-Pfade prüft, bekommt schnell einen echten Sicherheitsgewinn.
Fazit
Continuous Access Evaluation ist für den Unternehmensbetrieb vor allem deshalb interessant, weil es ein altes Grundproblem sauber adressiert: Zwischen Identitätsentscheidung und wirksamem Zugriffsentzug liegt oft zu viel Zeit. CAEP und das Shared Signals Framework liefern dafür den Standardrahmen, große Plattformen wie Microsoft Entra zeigen die praktische Richtung. Der eigentliche Reifeunterschied entsteht aber erst im Betrieb. Nur wenn IdP, Ressourcen, Anwendungen, Runbooks und Messpunkte zusammenspielen, wird aus einem Identity-Feature ein verlässlicher Kontrollmechanismus. Dann hängt Zugriffsentzug nicht mehr an der Token-Uhr, sondern an einem bewusst gestalteten Sicherheitsprozess.
