Microsoft Entra pusht Passkeys und verschärft die Identitätssicherheit
Phishing-resistente Authentifizierung wird zur Pflicht – was bis Juli 2026 zu tun istConsulting Briefing
05.06.2026 • boddenberg.de
__________________________________________________________________________________________
|
SECURITY & COMPLIANCE |
|---|
Microsoft Entra pusht Passkeys und verschärft die Identitätssicherheit
Executive Summary
Microsoft dreht bei Entra ID an der Identitätsschraube – und zwar fester, als es vielen lieb sein wird. Im Sommer 2026 wird phishing-resistente MFA von der netten Empfehlung zur faktischen Pflicht. Passkeys laufen jetzt auch auf unverwalteten Windows-Rechnern und sogar auf Linux-Desktops, und eine ganze Reihe von Stichtagen im Juli und September sorgt dafür, dass das Thema von der „machen wir mal“-Liste auf den Schreibtisch wandert.
Die Kernbotschaft für dich als Entscheider: Das Passwort ist endgültig auf dem Abstellgleis. Wer seine Anmeldung nicht bis Mitte Juli auf phishing-resistente Verfahren umstellt, riskiert entweder ausgesperrte Nutzer oder ein Sicherheitsniveau, das jeder halbwegs ambitionierte Angreifer im Vorbeigehen aushöhlt. Die gute Nachricht: Microsoft liefert die Werkzeuge gleich mit – device-bound Passkeys, synchronisierte Passkeys im Authenticator, Registration Campaigns, die Nutzer beim Anmelden sanft schubsen, und mit Global Secure Access das passende Zero-Trust-Netzwerkfundament obendrauf.
|
AUF DEN PUNKT Bis 13. Juli 2026 muss phishing-resistente MFA stehen, sonst wird es teuer – entweder an Sicherheit oder an Nerven. Plane das Rollout jetzt, nicht im Juli. |
|---|
Worum geht es im Detail?
Fangen wir beim Kern an: dem Passkey. Hinter dem hübschen Marketingwort steckt der FIDO2-Standard mit WebAuthn – also asymmetrische Kryptografie statt geteiltem Geheimnis. Bei deinem alten Passwort kennen zwei Parteien dasselbe Geheimnis: du und der Server. Geht es irgendwo verloren, ist es offen. Beim Passkey erzeugt dein Gerät ein Schlüsselpaar. Der private Schlüssel verlässt das Gerät niemals, nur der öffentliche landet beim Dienst. Anmelden heißt: Der Dienst schickt eine Challenge, dein Gerät signiert sie nach Freigabe per Gesicht, Fingerabdruck oder PIN. Es gibt schlicht kein Geheimnis mehr, das man abphishen, mitschneiden oder per Datenbank-Leak erbeuten könnte.
Der eigentliche Clou ist das sogenannte Origin Binding. Der Passkey ist kryptografisch an die echte Domain gebunden, etwa login.microsoftonline.com. Landet ein Nutzer auf einer täuschend echten Phishing-Seite, verweigert der Browser schlicht die Signatur, weil die Adresse nicht passt. Damit fallen genau die Angriffe weg, die heute den Großteil der Kontodiebstähle ausmachen – auch die fiesen Adversary-in-the-Middle-Proxys, die SMS-Codes und klassische MFA-Abfragen einfach durchreichen.
Microsoft unterscheidet dabei zwei Geschmacksrichtungen. Der device-bound Passkey lebt fest in einem Gerät – im Windows-Hello-Container oder auf einem FIDO2-Sicherheitsschlüssel. Neu in 2026: Das funktioniert jetzt auch auf unverwalteten Windows-PCs, ganz ohne Entra-Geräteregistrierung. Der synchronisierte Passkey dagegen liegt im Microsoft Authenticator und wandert verschlüsselt über deine Geräte. Neues Handy? Nach dem Login ist der Passkey wieder da, ohne Neuregistrierung. Beide sind gleichermaßen phishing-resistent – der Unterschied ist Komfort versus maximale Gerätebindung.

Abb. 1: Device-bound versus synchronisierter Passkey – zwei Wege, ein Sicherheitsniveau.
Dazu kommt die Verwaltungsseite. Das Limit für Passkey-Profile pro Tenant steigt von drei auf zehn, und die FIDO2-Authentifizierungsrichtlinie bekommt dedizierte 20 KB Speicher – klingt nach Kleinkram, ist aber genau das, was größere Organisationen mit unterschiedlichen Schlüsselherstellern bisher ausgebremst hat. Die Registration Campaigns unterstützen jetzt Passkeys: Beim Anmelden wird der Nutzer freundlich, aber bestimmt aufgefordert, einen Passkey einzurichten. System-preferred Authentication wählt zudem automatisch die jeweils sicherste verfügbare Methode aus.
Und Microsoft denkt endlich über den Windows-Tellerrand hinaus: Phishing-resistente MFA gibt es jetzt auch auf Linux-Desktops über den Microsoft Identity Broker – konkret für Ubuntu 24.04 und 26.04 sowie RHEL 8, 9 und 10. Damit ziehen Linux-Arbeitsplätze mit Windows und macOS gleich. Für Entwickler- und Engineering-Teams, die bisher gern als Sonderfall mit Sonderregeln durchgerutscht sind, schließt sich diese Lücke.
Ein kleines Beispiel aus der Praxis, damit das nicht so abstrakt bleibt: Bei einem Maschinenbauer mit rund 800 Mitarbeitern hat genau dieser Linux-Sonderfall ein Jahr lang jede Zero-Trust-Diskussion abgewürgt. Die CAD- und Simulationsleute saßen auf RHEL, fielen aus jeder MFA-Richtlinie heraus, und niemand wollte ihnen ein zweites Notebook nur fürs Anmelden hinstellen. Mit dem Identity Broker war die Ausrede über Nacht weg – und plötzlich war die Frage nicht mehr „ob“, sondern „in welcher Reihenfolge“. Solche Restposten sind in der Realität fast immer das, was ein sauberes Projekt verzögert, nicht die Technik im Kern.
|
HINTERGRUND: WARUM JETZT? Der Druck kommt nicht aus dem Nichts. Token-Diebstahl und AiTM-Phishing haben klassische MFA in den letzten Jahren regelrecht entwertet – ein abgefangener Code oder ein gestohlenes Session-Cookie reichte. Phishing-resistente Verfahren sind die einzige Antwort, die das Problem an der Wurzel kappt, statt nur eine weitere Hürde aufzustellen. |
|---|
Der zweite große Block ist das Netzwerk. Mit Global Secure Access – dem Dach über Entra Internet Access und Entra Private Access – liefert Microsoft seine Security-Service-Edge-Lösung. Internet Access ist ein identitätsbasiertes Secure Web Gateway, das schadhaften Verkehr und unsichere Inhalte filtert. Private Access ist ein echter VPN-Ersatz nach dem Zero-Trust-Network-Access-Prinzip: Nutzer erreichen interne Ressourcen ohne klassisches VPN, egal von wo. Das Ganze läuft über Microsofts globales Netz mit rund 70 Regionen und 190 Edge-Standorten. Identität und Netzwerkzugriff wachsen damit zusammen – genau das, was Zero Trust eigentlich immer meinte.

Abb. 2: Origin Binding in Aktion – der Phishing-Proxy läuft beim Passkey ins Leere.
Quellen: https://www.helpnetsecurity.com/2026/06/02/microsoft-entra-latest-security-updates/ https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2
Was sind Chancen? Was sind Risiken?
Die Chancen liegen offen auf dem Tisch. Phishing-resistente MFA schaltet die mit Abstand häufigste Angriffsklasse aus – das ist kein inkrementelles Plus, sondern ein qualitativer Sprung. Nutzer profitieren obendrein: Kein Passwort merken, kein Code abtippen, ein Blick in die Kamera reicht. Wer Anmeldung schlanker macht, senkt nicht nur das Risiko, sondern auch die Zahl der Helpdesk-Tickets rund um vergessene Passwörter – und das ist in vielen Häusern ein erstaunlich großer Posten. Dass Passkeys jetzt auf unverwalteten und Linux-Geräten laufen, macht ein lückenloses Rollout erstmals realistisch.
Strategisch wertvoll ist die Verzahnung mit Global Secure Access. Wer Identität und Netzwerkzugriff aus einer Hand bezieht, spart sich das Flickwerk aus Einzellösungen und bekommt durchgängige Conditional-Access-Richtlinien – vom Login bis zur konkreten Anwendung. Das ist die Sorte Vereinfachung, die Sicherheit und Betrieb gleichzeitig glücklich macht.
|
WARNUNG: DIE KLASSISCHEN STOLPERFALLEN Der gefährlichste Moment ist die Wiederherstellung. Wenn der Passkey weg ist und das Fallback ein schwacher Self-Service-Reset per SMS bleibt, hast du die Vordertür verriegelt und die Hintertür offen gelassen. Angreifer lieben genau diese Lücke. Ein zweiter Klassiker: ein einziger Sicherheitsschlüssel ohne Ersatz – geht der verloren, steht der Nutzer draußen. |
|---|
Bei den Risiken lohnt der nüchterne Blick. Synchronisierte Passkeys sind komfortabel, aber ihre Sicherheit hängt am Schutz des zugrunde liegenden Anbieterkontos und dessen Backup-Mechanismus – ist das schwach abgesichert, wandert das Vertrauen mit. Device-bound Passkeys sind härter, dafür ist der Geräteverlust schmerzhafter. In stark regulierten Umgebungen kann genau diese Unterscheidung zum Politikum werden, also kläre früh, welcher Typ wo erlaubt ist.
Das größte Projektrisiko ist aber schlicht der Faktor Mensch und Zeit. Die Deadlines sind hart, und ein überhastetes Rollout zwei Tage vor dem Stichtag produziert garantiert die Sorte Chaos, die man später teuer aufräumt. Wer Nutzer ohne Vorlauf und ohne saubere Wiederherstellungsmethode auf Passkeys umstellt, tauscht ein Sicherheitsproblem gegen ein Verfügbarkeitsproblem.
Wie das konkret aussieht, durfte ich bei einem Mittelständler beobachten, der MFA „mal eben“ am Freitagnachmittag scharf geschaltet hat. Am Montag standen 60 Außendienstler ohne registrierte Methode da, der einzige verfügbare Helpdesk-Mitarbeiter ertrank in Anrufen, und der Vertriebsleiter telefonierte direkt mit der Geschäftsführung. Das Sicherheitsniveau war an dem Tag hervorragend – nur konnte eben niemand mehr arbeiten. Die Lehre daraus ist unspektakulär, aber teuer erkauft: Ein Rollout ist erst dann fertig geplant, wenn auch der Tag danach geplant ist.
Quellen: https://www.helpnetsecurity.com/2026/06/02/microsoft-entra-latest-security-updates/ https://learn.microsoft.com/en-us/entra/global-secure-access/overview-what-is-global-secure-access
Was müssen wir jetzt schon vorbereiten?
Der Kalender diktiert das Tempo, also schauen wir zuerst auf die Stichtage. Ab dem 6. Juli 2026 greift Conditional Access für die Windows-Hello- und macOS-SSO-Registrierung, und die Registration Campaign läuft an. Am 13. Juli 2026 folgt die volle Erzwingung: Für das Anlegen passwortloser Anmeldedaten wird MFA verbindlich. Ab 7. September 2026 akzeptiert der Self-Service-Passwortreset nur noch zuvor registrierte Methoden. Und im November 2026 verabschiedet sich die SAP-Basic-Authentifizierung – wer dort hängt, muss auf Workload Identity umstellen.

Abb. 3: Die vier Stichtage, die über ein ruhiges oder ein hektisches zweites Halbjahr entscheiden.
Konkret heißt das: Inventarisiere zuerst, wer womit anmeldet. Welche Nutzer hängen noch an SMS-Codes, welche Geräte sind verwaltet, welche nicht, und wo sitzen die Linux- und Mac-Sonderfälle? Erst danach legst du fest, welche Passkey-Variante für welche Gruppe gilt. Parallel gehört die Wiederherstellung auf den Prüfstand – das ist der Punkt, an dem die meisten Projekte später bluten. Definiere mindestens zwei phishing-resistente Methoden pro Nutzer, etwa Passkey im Authenticator plus einen physischen Sicherheitsschlüssel als Backup.
|
TIPP: DER PRAGMATISCHE FAHRPLAN Starte mit einer Pilotgruppe aus IT und Power-Usern, schalte die Registration Campaign im Ankündigungsmodus, und nutze die Wochen bis Juli als Eingewöhnung. Roll dann gruppenweise aus – nicht alle auf einmal. Und teste die Wiederherstellung mit einem echten verlorenen Gerät, bevor es ernst wird. |
|---|
Technisch solltest du Conditional Access frühzeitig auf phishing-resistente Authentifizierung scharf stellen – erst im Report-only-Modus, um zu sehen, wer durchs Raster fällt, dann erzwingend. Prüfe, ob die FIDO2-Richtlinie mit dem neuen 20-KB-Budget und den zehn Profilen eure Schlüsselhersteller abdeckt. Wer Global Secure Access einführen will, beginnt mit Private Access für ein, zwei kritische interne Anwendungen als VPN-Ersatz und erweitert von dort. Und nicht zuletzt: Kommunikation. Ein Passkey-Rollout scheitert selten an der Technik, fast immer an Nutzern, die nicht verstehen, warum ihr vertrautes Passwort plötzlich nicht mehr reicht.
Vergiss bei alldem die Notfall- und Dienstkonten nicht – die Break-Glass-Accounts, die niemand anfasst, bis es brennt. Genau die werden bei Passkey-Projekten gern übersehen und sperren sich dann im dümmsten Moment selbst aus. Lege für sie früh fest, mit welcher unabhängigen, ebenfalls phishing-resistenten Methode du im Ernstfall noch hineinkommst, und teste das nicht erst, wenn das Rechenzentrum schon raucht. Eine halbe Stunde Vorbereitung hier erspart dir später den Anruf beim Support, den niemand führen will.
Wer das ernst nimmt, hat bis Juli ein ruhiges Projekt. Wer es aussitzt, hat im Juli ein Incident-Ticket mit dem Titel „Halbe Belegschaft kommt nicht mehr rein“. Die Wahl ist erstaunlich frei.
Quellen: https://www.helpnetsecurity.com/2026/06/02/microsoft-entra-latest-security-updates/ https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-admin-phish-resistant-mfa
Häufig gestellte Fragen
Brauche ich für Passkeys zwingend ein neues, verwaltetes Gerät?
Nein. Seit Mitte 2026 funktionieren device-bound Passkeys im Windows-Hello-Container auch auf unverwalteten Windows-PCs, ganz ohne Entra-Geräteregistrierung. Für maximale Flexibilität kannst du zusätzlich synchronisierte Passkeys im Microsoft Authenticator nutzen, die über mehrere Geräte hinweg verfügbar sind.
Was passiert, wenn ein Nutzer sein Gerät mit dem Passkey verliert?
Entscheidend ist eine vorab definierte Wiederherstellung. Hat der Nutzer einen synchronisierten Passkey, ist dieser nach Anmeldung am neuen Gerät wieder verfügbar. Bei reinen device-bound Passkeys brauchst du mindestens eine zweite registrierte phishing-resistente Methode, etwa einen physischen Sicherheitsschlüssel, sonst steht der Nutzer draußen.
Sind synchronisierte Passkeys genauso sicher wie device-bound Passkeys?
In Sachen Phishing-Resistenz ja – beide nutzen FIDO2 mit Origin Binding und sind gegen klassisches Phishing und Adversary-in-the-Middle-Angriffe immun. Der Unterschied liegt im Vertrauensmodell: Beim synchronisierten Passkey hängt die Sicherheit zusätzlich am Schutz des Anbieterkontos und dessen Backup, beim device-bound Passkey an der physischen Gerätebindung.
Bis wann muss phishing-resistente MFA bei uns stehen?
Die kritischen Stichtage liegen im Juli 2026: Ab dem 6. Juli greift Conditional Access für die Registrierung, ab dem 13. Juli wird MFA für das Anlegen passwortloser Anmeldedaten vollständig erzwungen. Ab 7. September akzeptiert der Self-Service-Passwortreset nur noch registrierte Methoden – plane das Rollout also mit Puffer davor.
Ersetzt Microsoft Entra Private Access unser klassisches VPN?
Für viele Szenarien ja. Private Access ist Microsofts Zero-Trust-Network-Access-Lösung und gibt Nutzern Zugriff auf interne Ressourcen ohne klassisches VPN, abgesichert über dieselben Identitäts- und Conditional-Access-Richtlinien. Sinnvoll ist ein schrittweiser Umstieg, beginnend mit einzelnen kritischen Anwendungen.








