Conditional Access und Passwordless: Die zwei Bausteine moderner Zugriffssteuerung

Multi-Faktor-Authentifizierung galt lange als der Sicherheitsstandard, der Phishing-Angriffe wirkungslos macht. Diese Annahme stimmt nicht mehr uneingeschränkt: Adversary-in-the-Middle-Angriffe fangen heute nicht das Passwort ab, sondern das fertige Sitzungstoken nach erfolgreicher MFA – und Microsofts eigene Bedrohungsdaten zeigen KI-gestützte Phishing-Kampagnen mit Klickraten von bis zu 54 Prozent, gegenüber rund 12 Prozent bei klassischem Phishing. Die Antwort darauf sind zwei Bausteine, die zusammen die moderne Zugriffssteuerung in Microsoft Entra ID bilden: Conditional Access als Entscheidungsmaschine, die jeden Zugriff kontextabhängig bewertet, und Passwordless-Authentifizierung, die das eigentliche Angriffsziel – das Passwort – möglichst ganz aus der Gleichung nimmt. Dieser Artikel geht beide im Detail durch, inklusive der Umstellung, die Microsoft gerade konzernweit ausrollt.

Conditional Access: Die Entscheidungsmaschine

Conditional Access bewertet jeden Anmeldeversuch anhand mehrerer Signale, bevor Zugriff gewährt wird: Benutzeridentität und Gruppenzugehörigkeit, Zielanwendung, Standort, Geräte-Compliance-Status und das von Entra ID berechnete Anmelderisiko. Aus diesen Signalen ergibt sich eine Entscheidung – Zugriff erlauben, zusätzliche Authentifizierung verlangen, oder blockieren.

Ein zentrales Werkzeug dabei ist Authentication Strength: Eine Richtlinie legt fest, welche Kombinationen von Authentifizierungsmethoden für den Zugriff auf eine bestimmte Ressource ausreichen. Für sensible Anwendungen lässt sich festlegen, dass ausschließlich phishing-resistente Methoden akzeptiert werden, während für weniger kritische Ressourcen auch schwächere MFA-Kombinationen wie Passwort plus SMS zulässig bleiben. Diese Abstufung erlaubt es, den Sicherheitsaufwand dort zu konzentrieren, wo das Risiko am größten ist, statt pauschal für alle Ressourcen denselben Standard zu erzwingen.

Im März 2026 hat Microsoft eine wichtige Lücke bei der Durchsetzung geschlossen: Richtlinien, die auf „Alle Ressourcen“ zielen, wurden bislang teilweise umgangen, wenn eine Anmeldung nur minimale OpenID-Connect- oder Verzeichnis-Scopes anfragte – ein Muster, das bei manchen Legacy- und Individualanwendungen vorkommt. Seit der schrittweisen Einführung zwischen März und Juni 2026 werden auch solche minimalen Anfragen konsequent gegen die Conditional-Access-Richtlinien geprüft. Für Umgebungen mit älteren oder selbst entwickelten Anwendungen kann das dazu führen, dass bislang unbemerkt durchgerutschte Anmeldungen plötzlich MFA- oder Compliance-Prüfungen auslösen.

Token Protection: Schutz gegen gestohlene Sitzungen

Selbst eine erfolgreiche MFA-Anmeldung schützt nicht automatisch vor Kompromittierung, wenn ein Angreifer das anschließend ausgestellte Sitzungstoken erbeutet. Genau das ist die Masche bei Adversary-in-the-Middle-Angriffen: Eine gefälschte Anmeldeseite leitet die Anmeldedaten und das MFA-Verfahren transparent an den echten Dienst weiter, fängt aber das danach ausgestellte Token ab. Der Angreifer benötigt sich nicht erneut anzumelden – er verwendet das gestohlene Token direkt und umgeht damit MFA vollständig, obwohl sie technisch korrekt durchlaufen wurde.

Token Protection, eine neuere Conditional-Access-Funktion, bindet ausgestellte Tokens kryptografisch an das Gerät, auf dem die ursprüngliche Anmeldung stattgefunden hat. Wird ein gebundenes Token auf einem anderen Gerät wiederverwendet, schlägt die Validierung fehl – der Diebstahl allein reicht dem Angreifer nicht mehr. Vorausgesetzt wird dafür, dass das Windows-Gerät Entra-ID-verbunden oder hybrid-verbunden und zusätzlich in Intune verwaltet beziehungsweise mindestens als compliant markiert ist; macOS und iOS unterstützen die Funktion aktuell in der Public Preview, Android und Linux werden bislang nicht unterstützt. Unterstützte Browser sind Edge und Chrome mit der entsprechenden Entra-Erweiterung.

Passwordless und Passkeys: Der Umbruch 2026

Parallel zur Absicherung der Anmeldesitzung verschiebt sich die eigentliche Anmeldung selbst weg vom Passwort. Microsoft hat angekündigt, dass ab dem 1. September 2026 Passkeys zur Standard-Authentifizierungsmethode in Entra ID werden. Nutzer, die aktuell für SMS- oder Sprachauthentifizierung freigeschaltet sind, werden im Rahmen des schrittweisen Rollouts automatisch für Passkeys aktiviert und bei der nächsten MFA-Anmeldung zur Registrierung aufgefordert. Ab dem 1. Februar 2027 stellt Microsoft die eigene Telekommunikationsanbindung für SMS- und Sprachauthentifizierung komplett ein; Organisationen, die weiterhin SMS oder Anrufe benötigen, müssen ab Oktober 2026 einen Drittanbieter dafür konfigurieren.

Passkeys basieren auf Public-Key-Kryptografie statt auf einem geteilten Geheimnis wie einem Passwort oder Einmalcode. Dadurch sind sie inhärent phishing-resistent: Es gibt schlicht kein Geheimnis, das eine gefälschte Anmeldeseite abgreifen könnte. Entra ID unterstützt dabei mehrere Ausprägungen – geräteintern gespeicherte (device-bound) Passkeys etwa im Windows-Hello-Container, synchronisierte Passkeys, die über einen Passwortmanager zwischen Geräten geteilt werden, sowie klassische FIDO2-Sicherheitsschlüssel.

Ergänzend rollt Microsoft ein System-Preferred-Authentication-Verfahren aus, das automatisch die jeweils stärkste registrierte Methode eines Nutzers zuerst vorschlägt. Die interne Rangfolge lautet: Temporary Access Pass, Passkey (FIDO2), zertifikatsbasierte Authentifizierung, Microsoft Authenticator, externe MFA-Anbieter, zeitbasierte Einmalcodes, Telefonie, QR-Code, Passwort. Nutzer mit registriertem Passkey sehen den Passwort-Bildschirm im Regelfall gar nicht mehr – sie werden direkt mit der stärkeren Methode angesprochen.

Ab Oktober 2026 können Nutzer außerdem direkt einen Passkey oder eine passwortlose Anmeldung als ihre erste MFA-Methode registrieren, ohne vorher eine schwächere Methode wie SMS einrichten zu müssen. Das senkt die Einstiegshürde für phishing-resistente Authentifizierung erheblich, weil Administratoren Nutzer nicht mehr über einen Umweg über schwächere Verfahren führen müssen.

Wie beide Bausteine zusammenspielen

Conditional Access und Passwordless-Authentifizierung sind keine getrennten Projekte, sondern greifen ineinander. Eine Authentication-Strength-Richtlinie, die für den Zugriff auf sensible Ressourcen ausschließlich phishing-resistente Methoden erlaubt, funktioniert nur dann reibungslos, wenn die Nutzer tatsächlich mit Passkeys oder anderen phishing-resistenten Verfahren ausgestattet sind – sonst führt sie zu Zugriffsverweigerungen und Support-Tickets. Umgekehrt entfaltet eine Passkey-Einführung ihre volle Wirkung erst, wenn Conditional-Access-Richtlinien sie auch tatsächlich für die kritischen Ressourcen erzwingen, statt sie als optionale, parallel verfügbare Methode neben dem weiterhin gültigen Passwort stehen zu lassen.

Ab Oktober 2026 erkennt Entra ID zudem Windows Hello for Business und macOS Platform SSO als eigenständige MFA-Faktoren an, sodass Nutzer die MFA-Anforderung ohne zusätzliche Passkey-Registrierung erfüllen können, sofern das Gerät bereits entsprechend eingerichtet ist – ein weiteres Beispiel dafür, wie Geräte-, Authentifizierungs- und Zugriffsrichtlinien zunehmend als ein zusammenhängendes System behandelt werden statt als separate Kontrollen.

Praxisszenarien

Abgestufte Authentication Strength für Finanz- und Standardanwendungen: Ein Unternehmen konfiguriert für den Zugriff auf das Finanzsystem eine Richtlinie, die ausschließlich Passkeys oder zertifikatsbasierte Authentifizierung zulässt, während der Zugriff auf interne Wissensdatenbanken weiterhin mit Microsoft Authenticator oder klassischer MFA möglich bleibt. Das Sicherheitsniveau richtet sich nach der Kritikalität der Ressource, nicht nach einer unternehmensweiten Einheitsregel.

Token Protection für Administratorzugriffe auf Azure Resource Manager: Eine IT-Abteilung mit mehreren Cloud-Administratoren aktiviert Token Protection für alle Zugriffe auf Azure Resource Manager über unterstützte Browser. Selbst wenn ein Administratorlaptop kompromittiert und ein Sitzungstoken exfiltriert wird, kann der Angreifer es auf einem anderen Gerät nicht verwenden – ein Schutzmechanismus, der speziell auf die höchste Risikogruppe im Unternehmen zugeschnitten ist.

Stolperfallen in der Praxis

Authenticator-Telefonanmeldung wird mit Passkey verwechselt. Die klassische Anmeldebestätigung per Push-Nachricht in Microsoft Authenticator ist ein anderes Verfahren als ein in Authenticator gespeicherter Passkey und zählt nicht zur eingebauten phishing-resistenten Authentifizierungsstärke. Wer eine Authentication-Strength-Richtlinie auf phishing-resistente Methoden festlegt, sollte genau prüfen, welches der beiden Verfahren die Nutzer tatsächlich einsetzen.

Token Protection scheitert an Plattformlücken. Die Funktion setzt aktuell primär auf Windows-Geräten voll und unterstützt macOS und iOS nur als Preview, Android und Linux gar nicht. Eine Richtlinie, die Token Protection unternehmensweit erzwingt, ohne die tatsächliche Geräteflotte zu berücksichtigen, sperrt einen Teil der Belegschaft faktisch aus.

Die Enforcement-Lücke bei minimalen Scopes überrascht Legacy-Anwendungen. Anwendungen, die bislang unbemerkt von „Alle Ressourcen“-Richtlinien durchgerutscht sind, weil sie nur minimale Berechtigungen anfragten, werden seit der schrittweisen Schließung dieser Lücke plötzlich regulär geprüft. Ohne vorheriges Testing über die Conditional-Access-Insights-Berichte kann das zu unerwarteten Anmeldeproblemen führen.

Die SMS/Voice-Ablösung wird zu spät geplant. Die automatische Passkey-Aktivierung für SMS- und Sprachnutzer ab September 2026 und die endgültige Abschaltung der Microsoft-eigenen Telefonie-Zustellung im Februar 2027 wirken wie ferne Termine, betreffen aber Nutzergruppen, die häufig noch keine Alternative registriert haben – etwa Mitarbeiter ohne firmeneigenes Smartphone. Diese Gruppen brauchen eine gezielte Vorbereitung, keine automatische Umstellung im Vorbeigehen.

Abgrenzung und Limitierungen

Conditional Access ersetzt keine vollständige Identity-Governance. Wer-hat-wann-worauf-Zugriff-Fragen im Sinne von Zugriffsüberprüfungen und Lifecycle-Management gehören in ein eigenständiges Governance-Konzept, nicht in einzelne Zugriffsrichtlinien.

Passkeys lösen das Phishing-Problem beim Anmeldevorgang, aber nicht jedes Sicherheitsproblem rund um Identität. Kompromittierte Geräte, Insider-Bedrohungen oder fehlerhaft konfigurierte Berechtigungen bestehen unabhängig von der Stärke des Anmeldeverfahrens weiter.

Token Protection schützt vor Diebstahl und Wiederverwendung auf einem anderen Gerät, verhindert aber nicht jede Form von Session-Missbrauch – etwa wenn ein Angreifer bereits direkten Zugriff auf das Ursprungsgerät selbst hat. Die Funktion ist ein zusätzlicher Baustein, kein Ersatz für Endpunktschutz.

Lizenz- und Voraussetzungsfragen

Token Protection setzt Entra-ID-P2-Lizenzen für alle betroffenen Nutzer voraus, enthalten sowohl in Microsoft 365 E5 als auch als eigenständige Entra-ID-P2-Lizenz. Passkeys und grundlegende Conditional-Access-Richtlinien sind bereits mit Entra ID P1 nutzbar, wobei einzelne fortgeschrittene Funktionen wie granulare Authentication-Strength-Konfigurationen ebenfalls P1 oder höher voraussetzen. Für die Absicherung von KI-Agenten über Conditional Access ist inzwischen eine eigene Lizenzkomponente vorgesehen: entweder Microsoft 365 E7 inklusive Agent 365 und Microsoft Entra Suite, oder Microsoft Agent 365 in Kombination mit mindestens Entra ID P1 beziehungsweise Microsoft 365 E3 – ein Hinweis darauf, dass Zugriffssteuerung zunehmend auch nicht-menschliche Identitäten mit einbezieht.

Ausblick

Die Kombination aus verpflichtender Passkey-Einführung und der Ausweitung von Token Protection zeigt, dass Microsoft nicht mehr auf freiwillige Adoption phishing-resistenter Verfahren setzt, sondern die Standardeinstellungen aktiv in diese Richtung verschiebt. Für IT-Abteilungen bedeutet das: Wer die Migration jetzt aktiv steuert – mit eigener Rollout-Planung, gezielter Kommunikation an betroffene Nutzergruppen und getesteten Conditional-Access-Richtlinien –, vermeidet die unkontrollierte automatische Umstellung, die Microsoft ab September 2026 ohnehin schrittweise durchsetzt.

Training im Fokus

Azure – SC-100 – Microsoft Cybersecurity Architect (SC-100T00)

Kurzbeschreibung

Der Microsoft Cybersecurity Architect entwirft und entwickelt Sicherheitslösungen, die Unternehmensprozesse umfassend schützen. Er sammelt Geschäfts- und Sicherheitsanforderungen, übersetzt sie in Architekturen, die Risiken minimieren, Compliance- und Datenschutzanforderungen erfüllen sowie Vertraulichkeit, Integrität und Verfügbarkeit sicherstellen.

Seminarinhalte

Entwerfen von Lösungen, die an den bewährten Sicherheitsmethoden und Prioritäten ausgerichtet sind

• Einführung in Zero Trust und Frameworks bewährter Methoden
• Entwerfen von Lösungen, die an Cloud Adoption Framework (CAF) und Well-Architected Framework (WAF) ausgerichtet sind
• Entwerfen von Lösungen, die an der Microsoft Cybersecurity Reference Architecture (MCRA) und dem Microsoft Cloud Security Benchmark (MCSB) ausgerichtet sind
• Entwerfen einer Resilienzstrategie für Ransomware und andere Angriffe auf der Grundlage bewährter Sicherheitsmethoden von Microsoft
• Fallstudie: Entwerfen von Lösungen, die an den bewährten Sicherheitsmethoden und Prioritäten ausgerichtet sind

Entwerfen von Funktionen für Sicherheitsvorgänge, Identität und Compliance

• Entwerfen von Lösungen für die Einhaltung gesetzlicher Bestimmungen
• Erstellen von Lösungen für die Identitäts- und Zugriffsverwaltung
• Entwerfen von Lösungen zum Schutz des privilegierten Zugriffs
• Entwerfen von Lösungen für Sicherheitsvorgänge
• Fallstudie: Entwerfen von Funktionen für Sicherheitsvorgänge, Identität und Compliance

Entwerfen von Sicherheitslösungen für Anwendungen und Daten

• Entwerfen von Lösungen zum Schutz von Microsoft 365
• Entwerfen von Lösungen zum Schutz von Anwendungen
• Entwerfen von Lösungen zum Schutz der Daten einer Organisation
• Fallstudie: Entwerfen von Sicherheitslösungen für Anwendungen und Daten

Entwerfen von Sicherheitslösungen für die Infrastruktur

• Entwerfen einer Strategie zum Schutz von SaaS-, PaaS- und IaaS-Diensten
• Entwerfen von Lösungen für die Verwaltung des Sicherheitsstatus in Hybrid- und Multicloudumgebungen
• Entwerfen von Lösungen zum Schutz von Server- und Clientendpunkten
• Entwerfen von Lösungen für die Netzwerksicherheit
• Fallstudie: Entwerfen von Sicherheitslösungen für die Infrastruktur

Zielgruppe

Erfahrene Cloudsicherheits-Techniker, die bereits eine Zertifizierung im Portfolio „Sicherheit, Compliance und Identität“ erworben haben.

Voraussetzungen

Bevor sie an diesem Kurs teilnehmen, sollten die Teilnehmenden:

• Fortgeschrittene Erfahrung und Kenntnisse in den Bereichen Identitäts- und Zugriffsmanagement, Plattformschutz, Sicherheitsoperationen, Datensicherheit und Anwendungssicherheit mitbringen.
• Erfahrung mit hybriden und Cloud-basierten Implementierungen haben.

Lernziele

Online buchbarAuf AnfrageGarantietermin

Kursdauer

4 Tage

Kurspreis (zzgl. MwSt.)

2.690,00 €

Verfügbare Termine

126 Termine

Durchführungsart (en)

Vor Ort & Live-Online

Zum Kurs