Wer sich mit aktuellen Angriffen auf Microsoft 365 befasst, landet früher oder später bei gestohlenen Tokens. In Projekten erlebe ich immer wieder, dass sich nach der MFA-Einführung ein trügerisches Gefühl von Sicherheit einstellt. Die Angriffe der letzten zwei Jahre haben aber deutlich gezeigt, wie leicht sich Session-Tokens auf kompromittierten Systemen auslesen lassen. Dagegen richtet sich Token Protection, eine Sitzungssteuerung im Conditional Access. Sie bindet das signierte Token an das Gerät und verhindert, dass es auf einem anderen Endpunkt verwendet wird. In vielen Tenants, die ich betreue, ist Token Protection längst kein Zukunftsthema mehr, sondern läuft im Produktivbetrieb.

Token Protection setzt auf eine feste Bindung an das Gerät

Das Prinzip ist schnell erklärt. Meldet sich ein Nutzer an einem unterstützten Gerät bei Microsoft 365 an (derzeit Windows 10/11, Entra-joined oder Hybrid-joined), wird das Session-Token kryptografisch an dieses Gerät gebunden. Liest ein Angreifer das Token aus, kann er es nicht ohne Weiteres in einer anderen Umgebung wiederverwenden. Klassische Pass-the-Token-Methoden laufen damit ins Leere. Eingerichtet wird das unter Entra admin center → Entra ID → Conditional Access → Neue Richtlinie → Sitzungen. Dort wählt ihr bei den Sitzungssteuerungen die Option „Token Protection für Anmeldesitzungen erforderlich“. Wichtig zu wissen: Die Richtlinie wirkt nur, wenn Client und Ressource Token Protection gleichermaßen unterstützen. Exchange Online, SharePoint Online, Microsoft Teams und die Microsoft-365-Desktop-Apps sind bereits abgedeckt, allerdings nur auf unterstützten Windows-Geräten.

Bevor ihr die Funktion aktiviert, lest bitte die offizielle Dokumentation (Überblick über Token Protection). Dort findet ihr auch die jeweils aktuellen Einschränkungen.

Im Alltag stößt Token Protection schnell an seine Grenzen

In der Praxis merkt man bald, dass Token Protection nicht jeden Angriffsweg schließt. Browser-Zugriffe, Android- und iOS-Geräte, Mac-Clients und viele Legacy-Anwendungen werden bis heute nicht unterstützt. Auch unter Windows funktioniert die Bindung nur, wenn die Clients Entra-joined oder Hybrid-joined sind und mit der aktuellen Version des Microsoft Authenticator bzw. der Desktop-Apps arbeiten. Klassische Browser-Sitzungen fallen ganz heraus. Hier müssen weiterhin die übrigen Conditional-Access-Kontrollen, MFA und starke Authentifizierungsmethoden vor Token-Diebstahl schützen. Welche Szenarien unterstützt werden, beschreibt Microsoft Learn recht übersichtlich (Sitzungssteuerungen im Kontext).

Bei den Ressourcen sieht es ähnlich aus. Token Protection greift für Exchange Online, SharePoint Online und Teams, aber nicht für andere SaaS-Anwendungen oder Drittanbieter-Apps, die über Entra ID angebunden sind. Wer auf einen Rundumschutz hofft, sollte außerdem wissen, dass sich die Funktion nicht für Service Principals und Workload Identities eignet. Mehr dazu steht in meinem Beitrag über Conditional Access für Workload-Identitäten.

Der Report-only-Modus macht den Pilotbetrieb risikoarm

Wie bei Conditional Access üblich, beginnt die Einführung im eigenen Tenant mit Report-only-Richtlinien. So seht ihr, was die Richtlinie bewirken würde, ohne echte Anmeldungen zu blockieren. Für den Start empfehle ich eine Richtlinie für „alle Benutzer“ mit der Bedingung „Windows-Geräte (Hybrid/Entra-joined)“ und Ressourcen wie Exchange Online oder Teams, die zunächst im Report-only-Modus läuft. Die Ergebnisse prüft ihr am einfachsten in den Conditional Access Insights oder direkt in den Anmeldeprotokollen (Entra admin center → Entra ID → Überwachung → Anmeldeprotokolle).

Aus Erfahrung: Behaltet vor allem Pilotnutzer mit älteren Geräten oder ungewöhnlichen Setups im Auge. In gemischten Umgebungen (z. B. mit RDS, Citrix, VDI) kann es zu Anmeldeproblemen kommen, wenn der Client nicht alle Voraussetzungen erfüllt.

Die Anmeldeprotokolle verraten, ob die Token-Bindung gegriffen hat

Ist Token Protection aktiv, liefert das Anmeldeprotokoll die wichtigsten Hinweise. Im Abschnitt „Conditional Access“ taucht dann ein zusätzlicher Eintrag auf, der zeigt, ob die Token-Bindung funktioniert hat oder ob eine Richtlinienverletzung vorlag. Bei einem unerlaubten Versuch, etwa wenn jemand das Token auf einem anderen Gerät wiederverwendet, wird der Zugriff verweigert und das Ereignis protokolliert. Wer gezielt danach suchen will, filtert die Anmeldeprotokolle nach dem Kontrolltyp „Token Protection“. Für Berichte auf Tenant-Ebene genügt meist das Portal. Größere Auswertungen erledigt man besser über einen Export in einen Log Analytics Workspace (Voraussetzung: P1- oder P2-Lizenz, Diagnostic Setting) und fragt die Daten dort mit KQL ab.

Eine einfache KQL-Abfrage in Log Analytics sieht so aus (Rollen: Globaler Leser oder Security Reader):

SigninLogs
| where ConditionalAccessStatus == "failure"
| where ConditionalAccessPolicies contains "TokenProtection"
| project UserPrincipalName, DeviceDetail, ConditionalAccessPolicies, ResultDescription, TimeGenerated

Ausführen unter Log Analytics Workspace → Logs.

Token Protection ist eine Antwort auf die Zunahme von Token-Diebstahl

In Security-Reviews der letzten Monate kam Token Protection häufig zur Sprache, auch weil klassische MFA-Umgehungen und Token-Diebstahl derzeit wieder zunehmen. Wie solche Angriffe ablaufen und welche weiteren Kontrollen helfen, beschreibe ich ausführlich in meinem Beitrag Token-Diebstahl in Microsoft 365 erkennen und verhindern.

Den Ablauf von Token Protection habe ich in einem einfachen Flussdiagramm skizziert:

flowchart TD
    Anmeldung["Anmeldung am Windows-Gerät"]
    TokenAnfordern["Token wird ausgestellt"]
    Bindung["Token an Gerät gebunden"]
    Nutzung["Nutzung Token auf demselben Gerät"]
    FremdNutzung["Token auf anderem Gerät nutzen"]
    ZugriffErlaubt["Zugriff erlaubt"]
    ZugriffVerweigert["Zugriff verweigert"]

    Anmeldung --> TokenAnfordern --> Bindung --> Nutzung --> ZugriffErlaubt
    Bindung --> FremdNutzung --> ZugriffVerweigert

Abbildung: Token Protection bindet das Token an das Gerät, auf fremden Geräten wird es blockiert.

Token Protection gehört in jede Security-Baseline, löst aber nicht alles

Wer eine einheitliche Windows-Geräteflotte betreibt, kommt an Token Protection nicht vorbei. Aus meiner Microsoft-365-Security-Baseline für 2026 ist die Funktion nicht mehr wegzudenken. Weil sie sich im Conditional Access einfach aktivieren und vorab im Report-only-Modus testen lässt, ist die Einführung inzwischen recht risikolos. Voraussetzung ist allerdings, dass ihr die nicht unterstützten Plattformen kennt und für Browser-Zugriffe und mobile Geräte Alternativen einplant. Gegen viele Angriffswege ist Token Protection ein dringend nötiger Baustein. Ein Gesamtkonzept aus starker Authentifizierung, Prüfung des Gerätezustands und klassischen Conditional-Access-Kontrollen ersetzt sie aber nicht. Wer sich gegen modernes Session Hijacking wappnen will, sollte sich jetzt mit Token Protection beschäftigen und den Rollout nicht weiter aufschieben.