Passkeys in Microsoft 365 und Entra ID – Passwordless-Sicherheit mit Praxisfokus

Einleitung

Montagmorgen, 8 Uhr im Büro: Die erste Tasse Kaffee dampft, das Telefon der IT-Hotline klingelt Sturm. Eine gestresste Mitarbeiterin meldet sich – schon wieder Passwort vergessen, Konto gesperrt, nichts geht mehr. Kaum beruhige ich sie, blinkt am nächsten Monitor ein Sicherheitsalarm: Verdacht auf eine Phishing-Attacke, ein Benutzer könnte seine Zugangsdaten preisgegeben haben. Willkommen in der Passwort-Hölle!

Dieser Alltag kommt Ihnen sicher bekannt vor. IT-Abteilungen kämpfen stetig mit vergessenen Passwörtern, gesperrten Accounts und der Angst vor Phishing. Nutzer wählen Passwörter, die sie sich leicht merken können – und die Hacker leider ebenso leicht erraten. Notizzettel unter Tastaturen, jahreszeitliche Passwörter à la „Winter2025!“ und minimal abgeänderte Wiederholungen sind an der Tagesordnung. Trotz Schulungen und komplexer Richtlinien bleibt das Passwort das schwächste Glied. Ein unbedachter Klick auf einen falschen Link – und schon haben Angreifer leichtes Spiel.

Als Berater erlebe ich diese Misere ständig. Es kostet Zeit, Nerven und Geld: Passwort-Resets gehören zu den häufigsten Helpdesk-Tickets, und jede Phishing-Mail, die durchkommt, lässt die Alarmglocken schrillen. Aber was wäre, wenn wir Passwörter als Haupt-Einfallstor eliminieren könnten? Genau hier kommen Passkeys ins Spiel.

Passkeys versprechen eine Anmeldung ganz ohne klassische Passwörter. Statt geheimen Worten setzen sie auf kryptografische Schlüssel – viel schwieriger zu stehlen oder zu knacken. In diesem Fachartikel zeige ich Ihnen, wie Passkeys funktionieren, wie Microsoft 365 und Entra ID (vormals Azure AD) diese Form der passwordless Anmeldung unterstützen und – am wichtigsten – wie Sie Passkeys in der Praxis einführen können.

Freuen Sie sich auf einen praxisnahen Rundumschlag: von anschaulichen Grundlagen über konkrete Umsetzungsszenarien bis zu Tipps für Governance und Betrieb. Ich schreibe aus erster Hand – in der Ich-Perspektive eines Beraters, der alle Projekte persönlich begleitet. Locker im Ton, fundiert inhaltlich. Also, schnallen Sie sich an: Es geht raus aus der Passwort-Hölle und hinein in die Passkey-Zukunft!

Grundlagen: Passkeys, FIDO2 und WebAuthn einfach erklärt

Bevor wir in die Details einsteigen, klären wir, was Passkeys eigentlich sind und wie sie funktionieren. Keine Zauberei, sondern clevere Mathematik und offene Standards.

Was ist ein Passkey? Stellen Sie sich einen Passkey als digitalen Sicherheitsschlüssel vor, der anstelle eines Passworts verwendet wird. Technisch basiert das auf offenen Standards namens FIDO2 (Fast IDentity Online) und WebAuthn (Web Authentication). Diese wurden von der FIDO-Allianz mit Unternehmen wie Microsoft, Google und Apple entwickelt, um sichere, passwortlose Logins im Web und in Apps zu ermöglichen.

Public-/Private-Key Prinzip: Das Herzstück von Passkeys ist asymmetrische Kryptografie. Klingt kompliziert, ist aber wie ein Schloss mit zwei Schlüsseln: Bei der Registrierung erzeugt Ihr Gerät ein Schlüsselpaar – einen privaten Schlüssel und einen öffentlichen Schlüssel. Den öffentlichen Schlüssel schickt Ihr Gerät an den Server (z.B. Entra ID), wo er gespeichert wird (quasi das Schloss). Den privaten Schlüssel behält Ihr Gerät geheim und sicher (z.B. im Hardware-Chip wie dem TPM Ihres Laptops oder der Secure Enclave Ihres Smartphones).

Melden Sie sich nun an, passiert Folgendes: Der Server schickt eine Challenge (eine zufällige Zeichenfolge, vergleichbar mit einer einmaligen Aufgabenstellung). Ihr Gerät unterschreibt diese Challenge mit dem privaten Schlüssel. Der Server prüft die Signatur mit dem öffentlichen Schlüssel – passt alles, erhalten Sie Zugriff. Das Geniale: Ihr privater Schlüssel verlässt niemals Ihr Gerät. Ein Hacker, der den Datenverkehr abfängt, sieht nur die Challenge und die Signatur – beides für sich wertlos ohne den privaten Schlüssel. Phishing-Seiten schauen ebenfalls in die Röhre: Der Passkey ist an die echte Anwendung gebunden und gibt nur eine gültige Signatur auf der richtigen Website. Eine gefälschte Seite kann diesen Mechanismus nicht überlisten.

FIDO2 und WebAuthn: FIDO2 ist der Überbegriff für diese passwortlosen Technologien. WebAuthn ist die Web-Komponente davon – ein Standard-API, mit dem Browser und Anwendungen mit Authentifizierungsgeräten sprechen. Moderne Browser (Edge, Chrome, Firefox, Safari) beherrschen WebAuthn. Betriebssysteme bringen oft eigene Authentikatoren mit: Windows z.B. Windows Hello, Apple hat Touch ID/Face ID mit iCloud-Passkeys, Android nutzt seinen Fingerabdrucksensor als FIDO2-Authentifikator. Kurz: Die großen Plattformen unterstützen Passkeys schon heute breit.

Passkeys vs. klassische MFA: Vielleicht denken Sie: „Wir nutzen doch schon MFA (z.B. SMS-TAN oder Authenticator-App). Warum noch Passkeys?“ Herkömmliche MFA ist ein großer Fortschritt gegenüber dem reinen Passwort, aber leider anfällig für ausgeklügeltes Phishing. Angreifer können OTP-Codes und Push-Benachrichtigungen abfangen oder den Nutzer täuschen, diese in Echtzeit einzugeben. Passkeys hingegen sind phishing-resistent: Ohne den privaten Schlüssel auf dem Gerät – der nie herausgegeben wird – kann kein Betrüger eine Anmeldung vortäuschen. Außerdem gelten Passkeys als starke Authentikatoren, weil sie mindestens zwei Faktoren kombinieren: etwas, das Sie haben (das Gerät/den Schlüssel) und etwas, das Sie sind (Biometrie) oder wissen (eine lokale PIN zur Entsperrung). Für den Nutzer läuft es darauf hinaus, dass er z.B. per Fingerabdruck den Passkey freigibt – und sofort angemeldet ist, ohne einen Code abzutippen.

Vorteile von Passkeys: Die Vorteile liegen auf der Hand: – Phishing-Resistenz: Kein Abgreifen von Passwörtern oder TANs mehr möglich. Der Passkey antwortet nur gültig der echten Anwendung – Betrüger schauen in die Röhre. – Benutzerfreundlichkeit: Anstatt sich komplizierte Passwörter zu merken oder ständig Codes einzugeben, entsperren Nutzer den Zugang einfach per Fingerabdruck, Gesicht oder einer kurzen PIN lokal am Gerät. Das geht schnell und reduziert Login-Frust. – Hohe Sicherheit: Keine schwachen oder wiederverwendeten Passwörter mehr. Passkeys sind zufällig, stark und einzigartig pro Dienst. Brute-Force-Angriffe (Passwort-Raten) sind praktisch ausgeschlossen, da der private Schlüssel weder erraten werden kann noch das Gerät verlässt. – Weniger Helpdesk-Aufwand: Vergessene Passwörter und Konto-Sperren gehören großteils der Vergangenheit an. Das entlastet den Helpdesk spürbar – weniger Reset-Anfragen, weniger „Montagsstress“. – Zukunftssicherheit: Passkeys erfüllen moderne Sicherheitsstandards (BSI, NIST) für phishing-resistente MFA. Unternehmen bewegen sich damit Richtung Zero Trust – weg von leicht zu stehlenden Geheimnissen, hin zu hardware-gebundenen Identitäten.

Nachteile und Herausforderungen: Wo Licht ist, ist auch Schatten – ein paar Punkte gilt es zu beachten: – Gerätebindung: Ein Passkey ist meist an ein Gerät gebunden. Das bedeutet, wenn Sie ein neues Gerät nutzen, müssen Sie dort einen Passkey registrieren oder einen externen Schlüssel verwenden. Plattformgebundene Passkeys (z.B. Windows Hello) funktionieren nur auf dem jeweiligen Gerät. Roaming-Passkeys, die über Cloud synchronisieren (z.B. iCloud-Schlüsselbund bei Apple), kommen zwar, sind im Unternehmensumfeld aber noch neu. – Plattformabhängigkeit: Die großen Ökosysteme treiben Passkeys gemeinsam voran, dennoch gibt es Unterschiede. Ein in der Apple-Welt erzeugter Passkey synchronisiert über iCloud auf alle Apple-Geräte des Nutzers – aber nicht ohne Weiteres auf Windows. Microsoft Entra ID unterstützt aktuell (Ende 2025) nur gerätegebundene Passkeys. Wenn ein Nutzer einen Passkey im Microsoft Authenticator auf dem iPhone registriert, ist dieser nicht automatisch auf seinem iPad verfügbar. Dieses fragmentierte Bild wird besser werden, erfordert aber vorerst etwas Planungsaufwand. – Rollout-Komplexität: Die Einführung von Passkeys will gut geplant sein. Es reicht nicht, einfach die Funktion technisch zu aktivieren. Nutzer brauchen Guidance: Wie registriere ich meinen Passkey? Was mache ich, wenn mein Laptop getauscht wird? Solche Fragen müssen im Vorfeld geklärt und per Schulung/Anleitung beantwortet werden. Zudem braucht man Prozesse für den Notfall (etwa wenn ein Anwender alle seine Geräte verliert – Stichwort Temporary Access Pass, dazu später mehr). Auch muss die IT-Infrastruktur (Clients, Browser, eventuelle externe Keys) bereitstehen – eventuell sind Investitionen in Hardware-Keys nötig, sofern nicht jeder ein geeignetes Smartphone oder Laptop hat. – Legacy-Systeme: Nicht alle Anwendungen unterstützen moderne Authentifizierung. In vielen Unternehmen gibt es noch Legacy-Authentifizierung – etwa alte Protokolle wie POP3/IMAP für E-Mail, VPN-Systeme, oder Eigenentwicklungen ohne OAuth-Fähigkeit. Solche Alt-Systeme können mit Passkeys nichts anfangen. Hier braucht es Übergangslösungen: z.B. separate App-Kennwörter für Legacy-Dienste, Updates für diese Anwendungen oder den Einsatz von Azure AD App Proxy und ähnlichen Brückentechnologien, um auch ältere Services ins moderne Authentifizierungsregime einzubinden.

Unterm Strich überwiegen die Vorteile deutlich – vor allem, wenn Sicherheit und Benutzerfreundlichkeit Priorität haben. Der Weg in eine passwortlose Welt erfordert aber Vorbereitung, Aufklärung und die richtigen technischen Weichenstellungen. Genau darüber sprechen wir als Nächstes.

Integration von Passkeys in Entra ID und Microsoft 365

Wie setzt man Passkeys in der Microsoft-Welt konkret um? Entra ID – ehemals Azure Active Directory – ist das Herzstück der Identitätsverwaltung in Microsoft 365. Hier konfigurieren wir, welche Login-Methoden erlaubt sind, unter welchen Bedingungen, und wie wir mit Risiken umgehen. Die wichtigsten Bereiche:

Authentication Methods Policy (Authentifizierungsmethoden-Richtlinie)

In Entra ID gibt es eine zentrale Richtlinie zur Verwaltung der Authentifizierungsmethoden. Dort legen Sie fest, welche Methoden (Passwort, FIDO2-Passkeys, SMS, App etc.) für welche Benutzer zugelassen sind. Für Passkeys bedeutet das: Sie müssen die FIDO2-Passkey-Methode für Ihre Nutzer aktivieren. Im Entra-Portal findet sich diese Einstellung unter Schutz > Authentifizierungsmethoden. Typische Konfigurationen:

• Zielgruppe: Zunächst aktivieren viele Passkeys nur für Pilotnutzer oder bestimmte Gruppen. Später kann man es für alle freigeben.
• Zulässige Authentifikatoren: Standardmäßig sind alle FIDO2-Geräte zugelassen. Optional können Sie bestimmte Gerätehersteller oder Typen (über die AAGUID Kennung) einschränken, wenn Sie z.B. nur firmeneigene Keys zulassen wollen. In den meisten Fällen lässt man alle gängigen Keys zu.
• Registrierung: Benutzer können ihre Passkeys selbst im Mein Konto-Portal registrieren (aka.ms/mysecurityinfo). Dabei wird zur Sicherheit meist eine MFA-Bestätigung gefordert. Für komplett neue Benutzer ohne Passwort kann ein Temporary Access Pass (TAP) genutzt werden, um die Erstanmeldung zu ermöglichen (mehr dazu gleich).
• Lizenzbedarf: Die Verwaltung der Authentifizierungsmethoden erfordert Entra ID Premium P1 (enthalten in Microsoft 365 E3). Ohne P1 können Nutzer zwar ggf. Passkeys hinzufügen, aber Sie haben weniger Steuerungsmöglichkeiten. Für ein unternehmensweites Deployment ist P1 praktisch Voraussetzung.

Conditional Access (Bedingter Zugriff)

Conditional Access ist das Werkzeug, um Zugriffe in Entra ID situativ zu steuern. Hier einige Einsatzmöglichkeiten im Kontext Passkeys:

• MFA-/Passkey-Zwang: Sie können eine CA-Policy erstellen, die für bestimmte Nutzer oder alle verlangt: „Erlaube Login nur mit MFA oder starken Methoden.“ Ein Passkey-Login zählt dabei bereits als MFA (da zwei Faktoren in einem). So stellen Sie sicher, dass ein reines Passwort nicht mehr akzeptiert wird.
• Authentifizierungsstärke erzwingen: Entra ID bietet vordefinierte Stärkestufen, z.B. Phishing-resistente MFA. Damit können Sie z.B. für Admin-Accounts fordern, dass nur Passkeys, Windows Hello oder vergleichbar sichere Methoden genutzt werden (kein SMS, kein OTP). So erhalten besonders kritische Konten den höchsten Schutz.
• Legacy Authentifizierung blockieren: Eine der wichtigsten Maßnahmen begleitend zur Passkey-Einführung: Abschalten veralteter Protokolle (IMAP, POP, alte Office-Authentifizierungen), die keine MFA unterstützen. CA kann solche Logins generell blockieren. Damit verhindern Sie, dass Angreifer mit geleakten Passwörtern über Hintertüren ins System kommen. (Microsoft deaktiviert Legacy Auth in M365 ohnehin zunehmend standardmäßig.)
• Ausnahmen (Break Glass): Denken Sie daran, für Notfälle Accounts von strikten Policies auszunehmen. Typischerweise richtet man 1-2 globale Admin-Konten als „Break Glass“ ein, die nicht Passkey- oder MFA-zwangsbeglückt werden – streng geschützt und nur für den Notfall.

Kurzum, mit Conditional Access steuern Sie, wer sich wann und wie anmelden darf. In Kombination mit der Authentifizierungsmethoden-Richtlinie können Sie Passkeys gezielt einführen und unsichere Methoden eliminieren.

Identity Protection (Risikobasierte Erkennung)

Identity Protection (Entra ID P2 / in M365 E5 enthalten) überwacht Anmeldeaktivitäten auf Risiken wie ungewöhnliche Orte, bekannte Leaks oder atypisches Verhalten. Wie passt das zu Passkeys?

• Durch Passkeys sinkt die Wahrscheinlichkeit von Account-Kompromittierungen drastisch (Phishing greift ins Leere). Identity Protection wird also seltener Alarm schlagen wegen gestohlener Anmeldedaten.
• Dennoch bleibt es relevant: Wenn sich z.B. jemand plötzlich mit Passkey aus einem ungewöhnlichen Land anmeldet, wird das System „hohes Risiko“ signalisieren. Mit Identity Protection können Sie Richtlinien definieren, die bei hohem Risiko den Zugriff blockieren oder zusätzliche Verifizierungen verlangen.
• Insgesamt harmoniert Identity Protection gut mit Passkeys: weniger False Positives durch abgefangene Passwörter, aber immer noch ein Sicherheitsnetz für auffälliges Verhalten. P2 ist kein Muss für Passkeys, erhöht aber die Automatisierung der Abwehr (Risikologins automatisch abblocken etc.).

Plattform- und Geräteunterstützung

Passkeys lassen sich auf diversen Plattformen einsetzen – wichtig ist, dass die Umgebung WebAuthn/FIDO2 unterstützt:

• Windows 10/11: Voll unterstützt. Nutzer können Windows Hello for Business einrichten (PIN oder Biometrie am Gerät) oder externe FIDO2-Keys per USB/NFC nutzen. Azure AD-verbundene Windows-Geräte erlauben die Anmeldung mit Sicherheitsschlüssel direkt am Login-Bildschirm. (Voraussetzung: aktuelle Windows-Version und Browser für Web-Logins).
• iOS/iPadOS (Apple): Safari und die Microsoft-Apps unterstützen Passkeys. Praktisch läuft es oft über die Microsoft Authenticator App als Vermittler: Ist ein Passkey im Authenticator registriert, kann Outlook/Teams auf dem iPhone sich damit anmelden (Face ID oder Touch ID zur Bestätigung). iPhones ab iOS 14.3 unterstützen WebAuthn; mit iOS 17 hat Microsoft die Passkey-Funktion im Authenticator (Preview) eingeführt.
• Android: Ähnlich wie iOS. Mit einem aktuellen Android (Version 14+) und neuester Microsoft Authenticator oder Unternehmensportal-App können Passkeys genutzt werden. Der Fingerabdruck oder die Gerätesperre dient zur Freigabe. Chrome auf Android unterstützt WebAuthn ebenfalls, sodass auch webbasierte Logins mit Passkey möglich sind.
• macOS: Macs ab macOS 11+ unterstützen Passkeys in Safari, Chrome, Edge etc. Mit Touch ID am MacBook oder einer Apple Watch als Authentifizierer kann man sich passwortlos anmelden. Apple synchronisiert Passkeys über iCloud zwischen eigenen Geräten – doch Entra ID erkennt diese plattform-synchronisierten Passkeys aktuell noch nicht. Daher müssen Apple-Nutzer ggf. auf jedem Gerät ihren Entra-ID-Passkey einmal registrieren (oder den Umweg über den Authenticator nehmen). Diese Einschränkung dürfte verschwinden, sobald Microsoft auch „Roaming Passkeys“ unterstützt.
• Linux & Sonstiges: Moderne Linux-Distributionen mit Chrome/Firefox unterstützen FIDO2 prinzipiell, aber ohne native biometrische Integration. In der Praxis nutzen Linux-User meist einen externen Sicherheitsschlüssel. Ältere Geräte und OS (z.B. Windows 7) bleiben außen vor – ein gewisses Modernisierungslevel der IT ist Voraussetzung für Passkeys.

Wichtig ist: Browser-Unterstützung (WebAuthn) und gerätespezifische Broker-Apps (wie der Authenticator) sorgen dafür, dass Passkeys heute auf fast allen gängigen Endgeräten funktionieren. Eventuelle kleine Einschränkungen (z.B. kein NFC-Support in Safari) kann man im Rollout berücksichtigen, spielen aber für die meisten Nutzer keine große Rolle.

Integration in Anwendungen (Teams, Exchange, Office, PowerShell)

Funktionieren Passkeys auch in der täglichen Nutzung aller Microsoft-Dienste? Größtenteils ja:

• Office 365 Apps (Teams, Outlook, Word etc.): Die aktuellen Desktop- und Mobil-Apps unterstützen moderne Authentifizierung. Das heißt, wenn Passkeys für den Account aktiviert sind, bieten die Apps diese Anmeldung an. Beispiel: Öffnet man Teams am PC und gibt seine Mailadresse ein, erkennt Entra ID „User hat Passkey“ und fordert zur Schlüssel-PIN oder Windows Hello auf, statt ein Passwort zu verlangen. In mobilen Apps übernimmt der Authenticator-Broker nahtlos den Prozess. Voraussetzung ist, dass die Office-Apps auf dem neuesten Stand sind (ältere Versionen von Office 2016 o.ä. könnten Probleme haben).
• Outlook & E-Mail-Programme: Outlook Web Access und Outlook Mobil/Desktop funktionieren passwortlos wie oben beschrieben. Andere Mailprogramme, die Modern Auth (OAuth2) können, sollten auch klarkommen. Programme, die nur IMAP/POP mit Passwort kennen, werden hingegen blockiert sein, wenn man Legacy Auth abstellt. Die Empfehlung ist, auf unterstützte Clients umzusteigen oder im Notfall spezielle App-Kennwörter für solche Einzelfälle zu nutzen (und diese Zugriffe streng zu limitieren).
• PowerShell und Admin-Tools: Administratoren müssen sich umgewöhnen, da automatisierte Skripte nicht mehr einfach Benutzername+Passwort nutzen können. Interaktive Logins in PowerShell (z.B. mit Connect-ExchangeOnline) öffnen nun einen Browser-Flow, den man mit Passkey bestätigen kann. Für vollautomatische Abläufe sollte man auf App-Registrierungen mit Zertifikaten umstellen (also dienstliche Zugriffe über eigene Service-Principals, nicht mehr über menschliche Konten). In der Praxis bedeutet das etwas Anpassungsarbeit an bestehenden Scripts. Aber moderne Module und Tools unterstützen passwordless schon gut – man muss nur den Schalter -UseDeviceAuthentication oder ähnliche Mechanismen verwenden. Wichtig: Admins sollten keine Hintertür mit statischen Passwörtern offenlassen, sondern auch hier die neuen Methoden einsetzen.
• Externe Anwendungen: SSO-fähige Drittanwendungen (über SAML/OAuth via Entra ID integriert) profitieren automatisch von Passkeys, da Entra ID den Login steuert. Legacy-Anwendungen, die eigene Loginfelder haben, profitieren nicht direkt – für die muss man separate Lösungen finden (siehe Legacy-Abschnitt oben). Wo möglich, sollte man solche Apps auch auf Azure AD SSO umstellen, damit die Benutzer nur noch dem passwortlosen Azure Login begegnen.

Im Großen und Ganzen gilt: Alles, was heute schon mit Azure AD MFA funktioniert, wird auch mit Passkeys funktionieren – nur eben bequemer und sicherer. Einige Spezialfälle (ältere Protokolle, bestimmte Admin-Skripte) erfordern Anpassung, aber dafür gibt es Workarounds und Alternativen.

Lizenzierung: Unterschiede E3, E5, P1, P2

Zum Schluss noch ein Wort zu den Lizenzen, da sich hier oft Fragen stellen:

• Entra ID P1 (z.B. in M365 E3) enthält bereits alles Wesentliche, um Passkeys einzuführen: Authentication Methods Policy, Conditional Access, auch TAP (Temporary Access Pass) gehört dazu. Damit können Sie passwortlose Anmeldung managen und erzwingen.
• Entra ID P2 (z.B. in M365 E5) bringt zusätzliche Features wie Identity Protection (Risikoerkennung) und längere Log-Aufbewahrung. Diese sind hilfreich, um den Security-Blick zu schärfen, aber nicht zwingend erforderlich für die Passkey-Loginfähigkeit an sich. Wenn Sie E5 haben, nutzen Sie die Vorteile (automatische Risikoabblockung etc.), wenn nicht, geht es auch ohne – dann müssen Sie eben etwas manuelles Monitoring betreiben.
• Ohne Premium-Lizenzen: Theoretisch lässt sich FIDO2 auch im Azure AD Free oder reinen Office 365 Plan nutzen (Benutzer können einen Schlüssel registrieren und sich anmelden). Praktisch fehlt Ihnen dann aber die Steuerung per CA und Policy, was den Rollout unsicher und unkomfortabel macht. Für ein Unternehmen, das flächendeckend auf Passkeys setzen will, führt kaum ein Weg an mindestens P1 vorbei.

In der Regel sind Unternehmen, die Wert auf Security legen, ohnehin mindestens mit E3/P1 ausgestattet. Stellen Sie also sicher, dass die relevanten Nutzer die benötigten Lizenzen haben (z.B. Admins vielleicht P2). Die gute Nachricht: Sie müssen keine extra Lizenz „für Passkeys“ kaufen – es fällt unter die bestehenden Identity Security Features.

Praxisnahe Einführungs-Szenarien

Kein Unternehmen ist gleich, und so gibt es unterschiedliche Herangehensweisen, um Passkeys einzuführen. Ich stelle Ihnen fünf Szenarien vor, die verschiedene Ausgangslagen abdecken – von der Absicherung einzelner Konten bis zum flächendeckenden Rollout. Zu jedem Szenario skizziere ich die Ausgangslage, das Zielbild, die Umsetzung (technisch und organisatorisch), mögliche Stolperfallen und bewährte Best Practices.

Szenario 1: Admin-Konten

Ausgangslage: Administrator-Konten sind die Kronjuwelen der IT. Sie verwenden bisher komplexe Passwörter plus MFA, sind aber dennoch ein beliebtes Ziel von Angreifern (Spear-Phishing, Passwort-Sprays). Ein erfolgreicher Angriff auf einen Admin hätte gravierende Folgen. Daher soll die Absicherung hier als erstes auf das höchste Niveau gehoben werden.

Zielbild: Alle privilegierten Admin-Accounts sollen sich ohne Passwort anmelden – ausschließlich via Passkey (z.B. FIDO2-Sicherheitsschlüssel oder Windows Hello). Das Risiko von Phishing oder Passwortdiebstahl soll gegen Null gehen. Gleichzeitig braucht es Notfallmechanismen (Backup-Keys, Break-Glass-Accounts), damit bei Verlust eines Schlüssels oder technischen Problemen niemand dauerhaft ausgesperrt ist.

Vorgehen: – Technische Umsetzung: In Entra ID wird die FIDO2-Authentifizierungsmethode zunächst gezielt für die Admin-Gruppe aktiviert. Jeder Administrator registriert mindestens zwei Passkeys (z.B. zwei physische Keys, oder Key + Windows Hello) – einen Hauptschlüssel und einen Ersatz. Anschließend wird per Conditional Access eine Policy eingerichtet, die für diese Admin-Accounts phishing-resistente MFA erzwingt. Damit akzeptiert das System für Admins nur noch Passkey/Hello-Anmeldungen, kein Passwort + OTP mehr. Parallel richten wir ein Break-Glass-Konto ein (vom CA-Zwang ausgenommen, mit sicher verwahrtem Passwort), um im äußersten Notfall administrative Zugriffsmöglichkeiten zu behalten. – Organisatorische Schritte: Die Admins werden in die Änderungen eingeweiht und ggf. geschult (wie registriere ich meinen Key, was tun bei Verlust etc.). Wichtig ist, Verantwortlichkeiten festzulegen: Wer darf im Notfall einen Temporary Access Pass ausstellen, wer verwaltet die Backup-Keys? Prozesse für den Verlust eines Admin-Keys werden definiert (z.B. sofort Security informieren, Key aus Azure AD entfernen, neuen registrieren). Zudem sollte die Sicherheitsrichtlinie formal angepasst werden: Admins dürfen keine Passwörter mehr nutzen, sondern nur noch genehmigte Passkey-Geräte.

Stolperfallen: Bei der Umstellung können ein paar Dinge schiefgehen: – Wenn ein Admin seinen einzigen Schlüssel verliert und keinen Ersatz hat, steht er zunächst vor verschlossener Tür. Daher sind zwei Keys pro Admin Pflicht. – Gewisse ältere Admin-Tools oder Skripte unterstützen Passkeys nicht (z.B. ein altes RDP auf einen Domain-Controller). Hier muss man vorab prüfen und ggf. Ausnahmen schaffen (oder bessere Alternativen einführen, etwa RDP nur über Jump Host mit Azure AD Auth). – Achtung bei Conditional Access: Man darf den Break-Glass-Account nicht versehentlich mit einschränken – sonst sperrt man sich selbst aus. Vor Rollout sollte man alle Policies gründlich testen.

Best Practices: – Hochwertige Keys verwenden: Für Admins nur Security-Keys verwenden, die MFA in sich bieten (z.B. mit Fingerabdrucksensor). Diese verlangen neben Besitz des Sticks auch Biometrie, was die Sicherheit weiter steigert. – Backup und Dokumentation: Jeden Admin zwei Keys halten lassen; Seriennummern/Key-IDs sollte die IT dokumentieren, um verlorene Keys gezielt deaktivieren zu können. – Temporary Access Pass einplanen: Vorab die Möglichkeit schaffen, Admins im Notfall per TAP wieder ins System zu lassen (TAP ausstellen können z.B. zwei dafür befugte Kollegen). – Skripte anpassen: Administrative Automatisierungen möglichst auf App-Registrierungen umstellen (Service Principals mit Zertifikat), damit keine Passwort-Accounts in Skripten schlummern. – Kommunikation & Durchsetzung: Den Wechsel klar kommunizieren und zügig vollziehen – halbe Sachen (parallel noch Passwörter zulassen) verlocken sonst doch wieder zum Unsicheren. Sobald die Admins ihre Keys haben, sollte das Passwort wirklich tabu sein.

Szenario 2: Vorstand und kritische VIP-Nutzer

Ausgangslage: Vorstände und andere hochrangige Personen (C-Level, Bereichsleiter) haben Zugriff auf vertrauliche Daten und sind beliebte Ziele von Angriffen. Gleichzeitig legen sie Wert auf Komfort: Sicherheitslösungen, die ihren Arbeitsfluss stören, stoßen auf wenig Gegenliebe. Aktuell nutzen sie vielleicht SMS oder Token-MFA und empfinden dies mitunter als lästig. Die IT möchte diese VIP-Konten besser schützen, aber so, dass es für die Betroffenen möglichst reibungslos abläuft.

Zielbild: Die VIPs sollen sich passwortlos und bequem anmelden können – idealerweise durch etwas, das sie ohnehin täglich nutzen, wie ihren Fingerabdruck oder Gesichtsscan, und ohne zusätzliche Geräte herumtragen zu müssen. Phishing-Angriffe auf diese Accounts sollen praktisch unmöglich werden. Wichtig: Die Umstellung muss geräuschlos erfolgen, ohne dass die Vorstandsetage Frust schiebt.

Vorgehen: – Technische Umsetzung: Für die VIP-Gruppe werden Passkeys aktiviert – vorzugsweise mittels plattformgebundener Methoden, die sie kennen. Beispielsweise richten die Vorstände auf ihren Windows-Laptops Windows Hello ein (Gesichtserkennung/Fingerabdruck) und auf ihren iPhones den Microsoft Authenticator mit Passkey. So können sie sich an ihren Geräten per Biometrie anmelden, ohne etwas Neues lernen zu müssen. Falls einzelne keine dienstlichen Smartphones haben, könnte man alternativ FIDO2-Keys austeilen, aber meist setzt man bei VIPs auf vorhandene Hardware. Anfangs lässt man auch noch das klassische Login zu, um niemanden akut auszuschließen. – Betreuung und Change Management: Hier zieht man alle Register eines VIP-Service. Die IT oder der Berater richtet jedem Vorstandsmitglied in einer persönlichen Session die passwortlose Anmeldung ein. Das wird als Upgrade verkauft: „Ab sofort entfällt das lästige Passwort, Sie melden sich einfach mit Fingerabdruck an.“ Man begleitet sie durch die Registrierung und testet auf allen ihren Geräten (viele haben Laptop, Tablet, Smartphone – alle sollten Passkeys bekommen). Zudem werden Assistenten und Sekretariate mit ins Boot geholt, damit sie im Tagesgeschäft unterstützen können (falls z.B. eine Anmeldung mal nicht sofort klappt). – Policy und Rollout: Anders als bei den Admins wird hier behutsam vorgegangen. Man könnte zunächst Passkey-Login erlauben, aber Passwort noch nicht sperren. Wenn die VIPs merken, dass die neue Methode einfacher ist, werden sie freiwillig umsteigen. Nach einer kurzen Übergangsphase kann man dann per CA-Policy erzwingen, dass z.B. außer im Firmennetz nur noch Passkey akzeptiert wird. Schließlich – in Absprache mit dem CIO – wird das Passwort ganz deaktiviert. Diese schrittweise Herangehensweise stellt sicher, dass es keinen Aufschrei gibt.

Stolperfallen: – VIPs haben oft viele Geräte (Privatphone, Dienstphone, Tablet, Home-Laptop…). Man muss darauf achten, dass für jedes wichtige Gerät eine Anmeldemethode bereitsteht. Sonst kommt der Vorstandschef im Urlaub nicht an seine Mails, weil auf dem iPad kein Passkey registriert ist – unbedingt vermeiden durch vorausschauendes Setup. – Biometrie kann im Einzelfall zicken (z.B. erkennt Face ID jemanden mit Sonnenbrille nicht). Die Nutzer sollten wissen, dass sie immer alternativ eine PIN am Gerät eingeben können, falls der Fingerabdruck mal nicht erkannt wird. Diese kleinen Usability-Dinge muss man proaktiv kommunizieren („Falls Face ID nicht will, einfach Gerätecode eingeben, dann klappt es trotzdem“). – Manche VIPs sind technikskeptisch. Hier hilft es, den Rückhalt von oben zu haben – etwa wenn der CEO selbst begeistert mitmacht und es vorlebt. Dann ziehen die anderen eher mit.

Best Practices: – Persönlicher Support: VIPs erwarten (und brauchen) bei solchen Umstellungen individuelle Betreuung. Bieten Sie White-Glove-Service: Vor-Ort-Einrichtung, Hotline für die ersten Tage, etc. Das verhindert Frust und sorgt für Akzeptanz. – Kommunikation in deren Sprache: Kein Technik-Kauderwelsch, sondern Nutzen betonen: „Schneller Zugang, weniger Unterbrechungen, höchste Sicherheit für Ihre Daten.“ Vielleicht auch erwähnen, dass große Player wie Google & Co. intern längst auf solche Schlüssel setzen – das schafft Vertrauen. – Mehrere Geräte ausstatten: Soweit möglich gleich alle Devices eines VIP mit passwortloser Anmeldung einrichten. Dann merkt er unterwegs gar nicht, dass etwas „fehlt“. – Rückfallebene planen: Für den seltenen Fall, dass doch etwas nicht klappt (z.B. neues Handy, altes verloren), sollte der IT-Support priorisiert reagieren (VIP-Profil). Evtl. hält man für die Assistenz ein Notfall-Passwort bereit oder einen Weg, temporär doch Zugang zu geben, um Ausfallzeiten der VIPs zu vermeiden. – Vorbildfunktion nutzen: Wenn die Geschäftsleitung passwortlos arbeitet, kann man das intern ruhig kommunizieren („Unsere Chefs machen es vor – Sicherheit und Komfort für alle!“). Das motiviert auch den Rest der Belegschaft und zeigt, dass das Unternehmen hinter der Technologie steht.

Szenario 3: Breiter Rollout für die Belegschaft

Ausgangslage: Angenommen, das Unternehmen hat einige tausend Mitarbeiter in verschiedenen Abteilungen und Standorten. Viele nutzen bereits MFA (Authenticator oder SMS), aber das Passwort ist immer noch allgegenwärtig. Das Ziel ist nun, unternehmensweit auf passwordless umzustellen, um sowohl die Sicherheit zu erhöhen als auch langfristig Aufwand und Kosten (Passwort-Resets etc.) zu senken. Herausforderung: Eine heterogene Nutzerschaft (von IT-affin bis „Technik-muffelig“) und unterschiedliche Arbeitsplätze (Büro-PCs, mobile Geräte, ggf. Shared PCs).

Zielbild: Die Mehrheit der Mitarbeiter loggt sich im Alltag passwortfrei ein. Passwörter sollen nur noch ein Notfall-Backup sein und im Tagesgeschäft keine Rolle mehr spielen. Damit würden Phishing-Risiken massiv sinken und die Benutzerfreundlichkeit steigen. Erfolgskriterien könnten sein: z.B. >80% aller Login-Vorgänge erfolgen per Passkey, die Anzahl der Passwort-Reset-Tickets sinkt um X%.

Vorgehen: – Pilotphase: Zuerst wird mit einer überschaubaren Gruppe getestet – z.B. technikaffine Mitarbeiter aus IT oder freiwillige aus verschiedenen Abteilungen (50-100 Personen). Diese Pilotnutzer dürfen Passkeys registrieren und im Alltag ausprobieren. Ihr Feedback (Was lief gut? Wo hakte es?) wird gesammelt, um den großen Rollout vorzubereiten. – Kommunikation: Parallel startet eine Informationskampagne unternehmensweit. Ankündigung im Intranet, vielleicht ein Motto („Passwortlos glücklich!“), FAQs, kurze Videos – die Belegschaft wird auf die Neuerung eingestimmt. Wichtig: Positiv framing („Ihr Login wird schneller und sicherer“), nicht nur als Sicherheitsdogma. – Schulung & Support: Der Helpdesk wird vorab geschult, damit er bei Fragen zu Passkey-Registrierung und -Login sofort helfen kann. Man benennt pro Abteilung ggf. „Key User“, die Kollegen unterstützen können. Ggf. bietet die IT in den ersten Wochen offene Sprechstunden oder einen Chat-Kanal für Fragen an. – Stufenweiser Rollout: Statt alle auf einmal umzustellen, geht man in Wellen vor. Z.B. nach Abteilungen oder Standorten rollt man die Funktion aus. Jede Welle erhält rechtzeitig Info: „Ab nächster Woche können Sie passwortlos anmelden – so geht’s…“ mit Anleitung. Die Entra-ID-Policy wird dann jeweils erweitert, um diese Gruppen einzuschließen. Anfangs bleibt das Passwort noch als Fallback aktiv, aber die Nutzer werden angehalten, den Passkey zu nutzen. – Neue Mitarbeiter und TAP: Für Neuzugänge stellt man den Onboarding-Prozess um: Sie erhalten kein Initial-Passwort mehr, sondern z.B. einen Temporary Access Pass oder QR-Code am ersten Tag, um damit direkt ihren Passkey (z.B. via Authenticator) einzurichten. So kommt die nächste Generation Mitarbeiter gleich ohne jemals ein Passwort zu sehen ins Unternehmen. – Durchsetzung: Hat eine ausreichende Zahl der User einen Passkey eingerichtet (z.B. nach ein paar Monaten Rollout), kann man beginnen, den Passwortlogin abzuschalten oder stark einzuschränken. Per Conditional Access könnte man z.B. den Zugriff mit Passwort blockieren, sobald ein Nutzer einen Passkey hat (Microsoft bietet auch „System-preferred Authentication“ an, das die Benutzer automatisch zum stärkeren Faktor lenkt). Spätestens zu diesem Zeitpunkt werden auch die letzten Zögerer gezwungen, umzusteigen. Wichtig ist, dies mit Vorlauf anzukündigen („ab Datum X kein Login mit Passwort mehr möglich“).

Stolperfallen: – Widerstand und Gewohnheit: Manche Mitarbeiter werden den Wechsel scheuen oder aus Bequemlichkeit ihr Passwort weiter nutzen, solange es geht. Hier helfen gezielte Ansprachen – z.B. personalisierte Erinnerungen an jene, die noch keinen Passkey registriert haben, oder das Aufzeigen von Vorteilen (vielleicht auch kleine Incentives). – Technische Probleme bei Einzelnen: In einer großen Umgebung gibt es sicher Einzelfälle: ein altes Betriebssystem, das FIDO2 nicht unterstützt, ein Browser-Plugin, das stört, etc. Diese gilt es im Pilot zu identifizieren. Für einzelne inkompatible Altsysteme braucht man eventuell Interimslösungen (z.B. eine Handvoll Nutzer darf noch ein Passwort behalten, bis die Anwendung abgelöst ist). – Zeitplan slippage: Ein Massenrollout muss realistisch geplant sein – besser in machbaren Etappen mit Puffer. Wenn man versucht, 5000 Leute in zwei Wochen umzustellen, ist die Überforderung vorprogrammiert. Hier lieber schrittweise und aus den Erfahrungen lernen. – Externe und Sondernutzer: Nicht vergessen: Dienstleister, Praktikanten, Partner mit Accounts – diese Gruppen müssen mitbedacht werden, sonst hat man später Lücken (siehe Szenario 5).

Best Practices: – Metrics tracken: Während und nach dem Rollout kontinuierlich messen (Azure AD Sign-In Reports), wie die Nutzung aussieht. So kann man Erfolge kommunizieren („Schon 70% der Logins sind passwortfrei!“) und gezielt nachsteuern, wo es hakt. – Feiern und motivieren: Einen solchen Wechsel kann man ruhig intern feiern – z.B. ein „Passwordless Day“, wenn das alte Passwort endgültig abgeschaltet wird. Das schafft Aufmerksamkeit und nimmt die Veränderung positiv auf. – Helpdesk stärken: In der heißen Phase ruhig extra Ressourcen im Support einplanen. Erfahrungsgemäß gehen nach ersten Mitteilungen viele ähnliche Fragen ein – ein vorbereitetes FAQ und geschulte Agents können 80% davon routiniert beantworten. Nach kurzer Zeit flaut das ab und der Supportaufwand sinkt insgesamt deutlich. – Dokumentation & Policies anpassen: Alle Änderungen (z.B. dass die Passwort-Änderungsrichtlinie entfällt, weil keine Passwörter mehr genutzt werden) sollten in den Sicherheitsrichtlinien dokumentiert werden. Auch Nutzer-Richtlinien (z.B. Acceptable Use Policy) können angepasst werden, um die Verantwortlichkeiten beim Umgang mit Passkeys festzuhalten. – Längerer Parallelbetrieb für Notfälle: Es kann sinnvoll sein, das Passwort nicht sofort für alle zu deaktivieren, sondern erst einmal still im Hintergrund zu belassen, während niemand es mehr nutzt. So hat man für den Extremfall (Systemstörung o.ä.) eine Rückfallebene. Dies aber nur sehr restriktiv und kurzfristig – Ziel bleibt die vollständige Abschaffung des Nutzer-Passworts im Alltag.

Szenario 4: Hybrid- und Legacy-Umgebungen

Ausgangslage: Das Unternehmen betreibt eine gemischte Infrastruktur. Neben Microsoft 365 in der Cloud existiert eine traditionelle Active Directory (AD) On-Premises mit einigen lokal gehosteten Anwendungen und Dateiservern. Nutzer haben oft noch AD-Konten und melden sich an Windows-PCs mit ihrem Domänenpasswort an. Legacy-Protokolle (NTLM, Kerberos) und alte Anwendungen (ohne moderne Auth) sind im Spiel. Die Herausforderung: Passwordless einzuführen, ohne die Anbindung an klassische On-Prem-Systeme zu verlieren.

Zielbild: Mitarbeiter sollen sich auch in dieser Hybridwelt passwortlos anmelden können – und trotzdem nahtlos auf On-Prem-Ressourcen zugreifen. Ideal: Ein Nutzer loggt sich morgens an seinem Windows-Gerät per Passkey/PIN ein und hat dann Single Sign-On sowohl zu Cloud-Apps als auch zu Dateiablagen oder Intranet-Seiten im lokalen Netz. Passwörter sollen auch hier weitgehend verschwinden, soweit technisch möglich. Natürlich kann man nicht alle Altanwendungen über Nacht modernisieren, also müssen Übergangslösungen her.

Vorgehen: – Windows Hello for Business einführen: Für domänenverbundene Windows-10/11-Clients wird Windows Hello for Business (WHfB) ausgerollt (per GPO oder Intune). Jeder Nutzer richtet also an seinem AD-joined Gerät eine PIN oder Biometrie ein. Mit der neuen Cloud Trust-Methode von WHfB sorgt Azure AD dafür, dass ein Benutzer nach Hello-Login automatisch auch ein Kerberos-Ticket für die lokale AD-Domain erhält. (Voraussetzung: aktuelle Domain Controller und Azure AD Connect entsprechend konfiguriert.) Ergebnis: Der Nutzer meldet sich am PC passwortlos an und kann Netzlaufwerke, legacy Websites etc. ohne extra Passwort nutzen – SSO funktioniert, als hätte er sich mit Passwort angemeldet. – FIDO2-Keys für spezielle Fälle: Zusätzlich kann man FIDO2-Sicherheitsschlüssel für die Anmeldung an Azure AD nutzen, was z.B. an gemeinsam genutzten Rechnern hilfreich ist. Allerdings unterstützen rein lokal AD-gebundene Systeme die FIDO-Anmeldung nicht ohne Weiteres. Daher fokussiert man für normale Mitarbeiter auf WHfB (das sowohl Cloud als auch AD bedient) und nutzt FIDO-Keys eher für reine Cloud-Anmeldungen oder Admin-Zwecke. – Legacy-Systeme einbinden: Man identifiziert, welche Anwendungen kein Azure AD SSO können. Für einige gibt es Lösungen: Webanwendungen kann man ggf. hinter den Azure AD App Proxy hängen und mit Azure AD verbinden, sodass der Nutzer sich dort auch passwortlos anmelden kann. Andere Fälle (z.B. ein sehr altes ERP mit eigenem Login) muss man zunächst ausnehmen – hier behalten die betreffenden Nutzer vielleicht noch ein separates Passwort, bis eine bessere Lösung gefunden ist. Wichtig ist, die Anzahl solcher Ausnahmen klein zu halten und mit längerfristigem Ablöseplan zu versehen. – Policies und Synchronisation: Die Sicherheitsrichtlinien werden so angepasst, dass auf modernen Clients die Passwortanmeldung nach Einführung von Hello deaktiviert wird (z.B. per GPO „Nur Smartcard/Hello erlauben“). Gleichzeitig muss sichergestellt sein, dass Azure AD und AD gut synchronisiert bleiben (Azure AD Connect), insbesondere was Account-Status angeht. Ein kompromittiertes Konto soll z.B. sowohl in der Cloud als auch on-prem schnell gesperrt werden – die Prozesse dafür anpassen. – Team-Koordination: Die Einführung erfordert enge Zusammenarbeit zwischen dem Cloud-Team und dem klassischen AD-Team. Alle müssen verstehen, wie WHfB und FIDO zusammenspielen. Eventuell sind Schema- oder Domain-Controller-Updates nötig – diese rechtzeitig einplanen.

Stolperfallen: – Nicht unterstützte Szenarien: Einige Dinge gehen (noch) nicht passwortlos: z.B. direkte RDP-Logins auf Server mit einem FIDO-Key oder alte Linux-Services mit NTLM. Hier muss man temporär mit Passwort weiterleben oder Alternativen schaffen (z.B. RDP nur über einen zwischengeschalteten modernen Host). – Offline-Login: Benutzer ohne Internetverbindung können sich mit Hello am Gerät weiterhin anmelden (Windows cached das). Brauchen sie aber Zugriff auf Cloud-Ressourcen ohne Internet – das geht per Definition nicht. Praktisch relevant ist das selten, aber z.B. Piloten oder Außendienstler auf Reisen könnten Sonderfälle sein (ggf. hält man für sie ein Notfallpasswort bereit, falls sie offline arbeiten müssen). – Komplexität: Die Hybrid-Einrichtung (Kerberos-Trust etc.) ist technisch anspruchsvoll. Wenn sie falsch konfiguriert ist, könnten User sich zwar anmelden, aber keine Ressourcentickets bekommen – was dann Supportaufwand erzeugt. Daher unbedingt vorher in einer Testumgebung durchspielen. – Gewohnheiten im Unternehmen: Manche Administratoren im On-Prem-Umfeld sind skeptisch gegenüber solchen Änderungen. Hier hilft es, sie von Anfang an einzubeziehen, Schulungen anzubieten und klarzumachen, dass Passwordless nicht nur ein „Cloud-Ding“ ist, sondern auch on-prem Vorteile bringt (z.B. keine Supporttickets mehr für abgelaufene Domänen-Passwörter).

Best Practices: – Stück für Stück umstellen: Eventuell zuerst die rein Cloud-arbeitenden Mitarbeiter umstellen (Szenario 3) und parallel die technischen Grundlagen für Hybrid schaffen. Dann in Phase 2 die restlichen on-prem Nutzer migrieren, wenn WHfB/Hybrid Trust bereit steht. – Praxistests mit Pilot-Nutzern: Einige wenige Mitarbeiter aus der IT, die sowohl Cloud als auch on-prem intensiv nutzen, als Piloten einsetzen. Mit deren Feedback erkennt man Lücken (z.B. „Anwendung X fragt doch noch nach Passwort“) und kann nachbessern, bevor alle umgestellt werden. – Clear fallback path: Für AD-Admins vielleicht ein, zwei Konten belassen, die sich klassisch anmelden können, bis wirklich alles reibungslos läuft – diese jedoch gut sichern und nach Erfolg der Umstellung abschaffen. – Legacy-Ablöse planen: Die Einführung von Passwordless kann zum Anlass genommen werden, Altanwendungen zu modernisieren. Wenn z.B. eine Eigenentwicklung kein modernes Login kann, sollte auf Management-Ebene entschieden werden, ob dieses System ersetzt oder aufgerüstet werden kann. So stellen Sie sicher, dass „Passwordless“ nicht an ein paar alten Anwendungen stoppt. – Dokumentation & Wissen: Das Zusammenspiel Azure AD <-> AD mit Passwordless sollte gut dokumentiert werden (v.a. für die Admin-Teams). Wer unterstützt was, welche Zertifikate/Keys sind wo hinterlegt, was ist zu tun bei Änderungen. So vermeiden Sie Wissenslücken im Betriebsalltag.

Szenario 5: Externe Partner und B2B-Zugänge

Ausgangslage: Ihr Unternehmen arbeitet mit externen Partnern, Lieferanten oder Freelancern zusammen, die Zugriff auf gewisse Ressourcen (z.B. Teams-Bereiche, SharePoint oder spezifische Applikationen) bekommen. In Microsoft 365 werden solche Personen oft als B2B-Gäste ins Azure AD eingeladen. Sie melden sich in der Regel mit den Konten ihres eigenen Unternehmens oder einem Microsoft-Account an. Die Schwierigkeit: Wie erzwingt man bei fremden Benutzern eine sichere Authentifizierung? Man hat ja keine Hoheit über deren Passwörter oder MFA-Einstellungen.

Zielbild: Auch externe Zugriffe sollen soweit möglich phishing-resistent sein. Mindestens sollen alle externen Benutzer MFA nutzen müssen, besser noch Passkeys, wenn verfügbar. Gleichzeitig darf die Zusammenarbeit nicht unnötig erschwert werden – im Spannungsfeld zwischen Sicherheit und Usability muss man eine praktikable Balance finden.

Vorgehen: – Conditional Access für Gäste: Zunächst richtet man eine CA-Policy ein, die für alle externen Benutzer mindestens MFA erforderlich macht. Das bedeutet, wenn ein Partner sich bei Ihren Ressourcen anmeldet, muss sein Heimat-Tenant bestätigen, dass MFA gemacht wurde – oder (bei Microsoft-Accounts) wird er aufgefordert, einen zweiten Faktor einzugeben. Damit ist schon mal sichergestellt, dass kein Gast nur mit Benutzername+Passwort hereinkommt. – Phishing-resistente MFA für Gäste: Man kann CA noch strikter konfigurieren und z.B. für besonders schützenswerte Anwendungen fordern, dass auch Gäste phishing-resistente Methoden verwenden. Praktisch würde das Gäste ausschließen, die nur SMS/OTP-MFA haben. Diese Option sollte man mit Bedacht einsetzen – etwa für Admin-Zugriffe von externen Dienstleistern. In solchen Fällen kann man mit dem Partner konkret vereinbaren, dass sie FIDO2 einsetzen müssen. Alternativ könnte man externen Admins ein internes Konto geben, das voll Ihrer Policy unterliegt. – Cross-Tenant Access Settings: Azure AD bietet Einstellungen, um eingehende Gäste aus bestimmten Organisationen zu behandeln. Man kann z.B. Partner-Tenants als „vertrauenswürdig“ einstufen, wenn man weiß, dass sie vergleichbare Sicherheitsstandards haben. Oder umgekehrt, allen Fremd-Tenants Ihre MFA-Regeln aufzwingen. Diese Einstellungen kann man nutzen, um z.B. zu sagen: „Akzeptiere Gast-MFA nur, wenn der Partner FIDO2/Hello genutzt hat“ – was aber im Moment noch exotisch ist. Eher gängig: „Vertraue dem MFA des Partners oder fordere sonst eine zusätzliche MFA über Microsoft an“. – Externe Konten vs. lokale Konten: Für wichtige externe Benutzer, die oft zugreifen, kann es sich lohnen, statt B2B ein lokales Gastkonto in Ihrem Tenant anzulegen (also als regulärer Cloud-Benutzer mit Gastrolle). Diesem können Sie dann direkt einen Passkey zuweisen und Ihre Policies greifen 1:1. Das macht etwas mehr Aufwand (Lizenz und Verwaltung pro externer Person), wird aber manchmal für z.B. externe Administratoren oder Berater gemacht, die tief im System arbeiten. – Kommunikation an Partner: Informieren Sie externe Partner frühzeitig über neue Anforderungen. Z.B.: „Unsere Organisation schreibt ab Datum X MFA für alle externen Logins vor; idealerweise nutzen Sie bitte einen FIDO2-Sicherheitsschlüssel oder die Authenticator-App.“ Viele externe IT-Abteilungen werden Verständnis dafür haben – Sie können ggf. Hilfestellung anbieten (Empfehlung, wie ein Microsoft-Konto um einen Passkey ergänzt werden kann etc.).

Stolperfallen: – Blockierte Zusammenarbeit: Zieht man die Daumenschrauben für Gäste zu stark an, kann es passieren, dass ein Partner nicht mehr reinkommt (weil sein Admin es nicht erlaubt oder technisch nicht kann). Das kann Projekte stocken lassen. Deshalb hier unbedingt Einzelfälle im Blick behalten und im Zweifel temporär Ausnahmen zulassen, bis eine Lösung gefunden ist. – Intransparenz für Gäste: Ein externer Benutzer versteht vielleicht nicht, warum er plötzlich anders (oder öfter) authentifizieren muss als sonst. Das kann zu Verwirrung und Support-Aufwand führen. Daher bei wichtigen Partnern persönlich ankündigen oder eine kurze Anleitung mitschicken („So melden Sie sich künftig bei uns an…“). – Technische Grenzen: Derzeit können B2B-Gäste keinen Passkey in Ihrem Tenant hinterlegen – sie bringen immer ihre eigene Authentifizierung mit. Wenn deren Identity-Provider schwach ist, haben Sie begrenzt Einfluss. Hier hilft nur: im Zweifel den Zugang beschränken oder wie gesagt eigene Konten vergeben. – Lizenzthema: Viele Gäste lassen sich ohne Zusatzkosten mit den Azure AD Free Funktionen abwickeln. Sobald Sie aber anfangen, externe mit eigenen Accounts auszustatten und P1/P2-Policies drauf anzuwenden, brauchen diese möglicherweise entsprechende Lizenzen (Microsoft verlangt prinzipiell eine Lizenz pro aktiver externer Benutzer pro Monat bei Premium-Funktionen, wobei ein Pooling-Modell existiert). Das sollten Sie im Blick haben, ist aber bei < Gästeanzahl meist vernachlässigbar.

Best Practices: – Klare Sicherheitsanforderungen vertraglich festhalten: Wenn Partnerschaften kritisch sind, schreiben Sie in Verträgen oder NDAs, dass Partner bestimmte MFA-Standards erfüllen müssen. So haben Ihre Ansprechpartner dort ein Mandat, das umzusetzen. – Gast-Reviews durchführen: Führen Sie regelmäßige Überprüfungen durch, welche Gastkonten überhaupt noch benötigt werden. Weniger Gäste = weniger Risiko. Löschen Sie alte Einladungen und nicht mehr aktive Partneruser. – Granulare Steuerung: Nutzen Sie die Möglichkeiten von Azure AD: z.B. bestimmte besonders schützenswerte Inhalte nur Nutzern aus spezifischen Partner-Tenants freigeben, die bekannt sicher sind. Und für generelle Kollaboration setzen Sie „nur MFA“ als Standard, was schon einen Großteil der Opportunisten abhält. – Alternative Zugangswege: Wenn ein Partner technisch nicht in der Lage ist, Ihr gefordertes Level zu erfüllen, wägen Sie ab: Vielleicht kann er Daten anders bekommen (z.B. über einen sicheren Link oder separat bereitgestellte Accounts für die Dauer eines Projekts). Wichtig ist, keine Schatten-IT entstehen zu lassen, weil Nutzer versuchen, unsichere Workarounds zu finden. – Gute UX für Gäste: Versuchen Sie, trotz aller Sicherheit, den Anmeldeprozess für Gäste so einfach wie möglich zu gestalten. Features wie One-Time-Passcode per E-Mail für Gäste (falls aktiviert) können eine Notlösung sein, um Gelegenheitsgäste nicht an komplizierten Setups scheitern zu lassen – allerdings sind diese Codes phishbar, daher nur für Low-Risk-Szenarien einsetzen.

In diesem Szenario sieht man: Bei externen Identitäten hat man nicht die vollständige Kontrolle, kann aber durch Policies und bewusste Entscheidungen das Risiko deutlich reduzieren. Oft ist es ein Kompromiss – aber einer, den man bewusst gestalten sollte, statt ihn zu ignorieren.

Roadmap, Governance und Betriebsmodell

Ein Wechsel zur passwortlosen Authentifizierung sollte strategisch geplant und langfristig eingebettet werden. Hier die wichtigsten Aspekte:

Ist-Analyse & Strategie: Am Anfang steht die Bestandsaufnahme. Wie viele Logins erfolgen noch mit Passwort? Welche Anwendungen unterstützen moderne Auth? Wo gab es Sicherheitsvorfälle durch Passwörter? Auf Basis der Analyse wird eine Strategie formuliert – beispielsweise zunächst kritische Konten und Pilotnutzer umstellen, dann stufenweise den Rest, mit dem Ziel in 1-2 Jahren das Unternehmen möglichst passwortfrei zu haben. Diese Strategie sollte in die übergeordnete IT- und Sicherheitsstrategie (Stichwort Zero Trust) eingebettet werden und vom Management mitgetragen sein.

Projektphasen: Das Vorhaben gliedert sich in klare Phasen mit Meilensteinen. Typischer Ablauf: 1) Pilot (begrenzte Nutzergruppe, Feedback sammeln), 2) Rollout-Vorbereitung (Policies finalisieren, Support schulen, Kommunikation starten), 3) Gestaffelter Rollout (z.B. pro Abteilung/Welle, mit Monitoring der Fortschritte), 4) Abschluss (Passwort-Login deaktivieren, Altlasten bereinigen). Parallel dazu laufen möglicherweise technische Teilprojekte (z.B. Hybrid-Konfiguration aus Szenario 4). Jede Phase sollte Kriterien haben, wann sie als erfolgreich abgeschlossen gilt (z.B. „100 Pilotnutzer erfolgreich umgestellt“). Ein realistischer Zeitplan (lieber moderat starten und ggf. beschleunigen) und Puffer für unerwartete Hürden gehören zur Planung dazu.

Governance & Zuständigkeiten: Es muss klar sein, wer das Thema federführend betreut. In der Regel übernimmt die IT-Security-Abteilung oder das Identity & Access Management Team die Projektleitung. Wichtig ist, dass verbindliche Richtlinien erstellt werden: z.B. eine Policy „Passwortlose Anmeldung – Standard für alle Mitarbeiter, Ausnahmen nur mit CISO-Freigabe“. Diese Policy sollte offiziell verabschiedet werden. Zudem braucht es im laufenden Betrieb Rollen: Wer genehmigt Ausnahmen? Wer erstellt im Notfall einen Temporary Access Pass? Wie werden neue Mitarbeiter eingebunden? Definieren Sie diese Prozesse und Verantwortlichkeiten im Voraus. Auch der Helpdesk spielt eine Schlüsselrolle – er muss vorbereitet sein und eventuell zeitweise personell verstärkt werden.

Monitoring & KPIs: „You can’t improve what you don’t measure.“ Legen Sie Kennzahlen fest, um den Erfolg zu messen. Beispiele: Anteil der Anmeldungen mit Passkey vs. Passwort, Zahl der zurückgesetzten Passwörter pro Monat, Zahl der Phishing-Zwischenfälle. Azure AD bietet Sign-In Reports, die man auswerten kann. Vielleicht richten Sie ein Dashboard ein, das den Fortschritt zeigt (für das Management oder als motivierende Info für alle). Auch nach dem Rollout sollte regelmäßig geprüft werden, ob noch Benutzer am Passwort festhalten (dann gezielt nachhaken) oder ob Sicherheitsvorfälle zurückgegangen sind. Erfolge dürfen ruhig sichtbar gemacht werden – z.B. „Seit Einführung von Passkeys keine Kontoübernahmen mehr durch Phishing“.

Geräteverlust & Notfall-Prozesse: Trotz aller Maßnahmen wird es Fälle geben, wo ein User sein Gerät oder seinen Schlüssel verliert, oder sich aus Versehen selbst aussperrt. Dafür braucht es definierte Prozesse. Etwa: „Mitarbeiter meldet Verlust sofort der IT-Security. Diese sperrt den Passkey in Entra ID und stellt einen Temporary Access Pass (TAP) aus, gültig z.B. 8 Stunden, damit der Mitarbeiter einen neuen Passkey registrieren kann.“ Solche Prozeduren sollten den Mitarbeitern bekannt gemacht werden (z.B. in einem IT-Notfallhandbuch oder Intranet-FAQ). Ebenso sollten ausreichend Admins berechtigt sein, TAPs zu erstellen, damit Hilfe zeitnah erfolgen kann. Für sehr kritische Fälle behält man die eingangs erwähnten Break-Glass-Konten bereit (mit klassischer Authentifizierung), die aber streng verwaltet und idealerweise nie benutzt werden müssen.

Policies, Schulung & Offboarding: Passen Sie alle relevanten Richtlinien und Dokumentationen an. Die Passwort-Richtlinie (Passwortlänge, Ablauf etc.) kann z.B. entfallen oder auf ein Minimum reduziert werden, wenn niemand mehr regulär Passwörter nutzt. Schulungsmaterial (für Security-Awareness) sollte aktualisiert werden: Der Fokus verlagert sich darauf, wie man sicher mit seinem Passkey-Gerät umgeht (z.B. Laptop nicht unbeaufsichtigt lassen, Key nicht verleihen) anstatt auf Passwortregeln. Beim Offboarding von Mitarbeitern ist nun sicherzustellen, dass neben dem Account auch alle registrierten Passkeys deaktiviert werden – in Entra ID passiert das automatisch beim Account-Löschen, aber wenn physische Sicherheitsschlüssel Firmen-Equipment waren, sollten diese zurückgefordert werden. Auch hier gilt: Prozesse anpassen, sodass die neuen Authentifizierungsformen berücksichtigt werden.

Mit einer durchdachten Roadmap, klarer Governance und einem gut vorbereiteten Betriebsmodell stellen Sie sicher, dass Passkeys nicht nur als einmalige Aktion eingeführt, sondern dauerhaft erfolgreich gelebt werden. Es handelt sich um einen fortlaufenden Verbesserungsprozess – die Technologie entwickelt sich weiter, und Ihr Governance-Modell sollte mitwachsen (z.B. auf dem Laufenden bleiben, wenn Microsoft neue Features wie Cloud-synced Passkeys einführt, und diese gegebenenfalls adaptieren).

FAQ – Häufige Fragen aus der Praxis

In diesem Abschnitt beantworte ich 15 häufig gestellte Fragen, die in Diskussionen rund um Passkeys, Microsoft 365 und Entra ID immer wieder auftauchen. Die Antworten sind praxisnah und sollten einige der brennendsten Unsicherheiten klären.

Frage 1: Brauche ich überhaupt noch ein Passwort, wenn ich Passkeys nutze?
Antwort: Im Idealfall nein – das Ziel ist ja, Passwörter komplett loszuwerden. In der Praxis behalten Sie oft noch ein hinterlegtes Passwort als Fallback, nutzen es aber im Alltag nicht mehr. Bei einigen Diensten (vor allem ältere) kann es sein, dass ein Passwort vorerst noch nötig ist. Aber für die normalen Logins in Microsoft 365 können Sie das Passwort nach Einführung von Passkeys quasi vergessen. Einige Organisationen deaktivieren die Kennworte sogar komplett, sobald alle auf Passkeys umgestellt sind. Kurz gesagt: Das Passwort wandert in Rente, Passkey übernimmt.

Frage 2: Wie sicher ist ein Passkey wirklich? Kann der nicht auch gehackt werden?
Antwort: Passkeys gelten als sehr sicher. Die privaten Schlüssel verlassen nie Ihr Gerät und sind dort oft in spezieller Hardware geschützt. Selbst wenn jemand Ihren Laptop stiehlt, braucht er noch Ihren Fingerabdruck oder PIN, um den Passkey zu nutzen. Phishing-Angriffe, die bei normalen MFA gerne mal funktionieren, haben gegen Passkeys keine Chance, weil man nichts Preisgebendes eintippt. Natürlich gibt es kein 100% absolut sicher – wenn Ihr Gerät komplett kompromittiert würde (z.B. durch Malware mit Adminrechten), könnte theoretisch auch ein Passkey missbraucht werden. Aber das ist ein viel höheres Niveau an Angriff, weit weg von den meisten Hackern. In Summe: Passkeys sind derzeit der Goldstandard der Anmeldungssicherheit.

Frage 3: Was passiert, wenn ich mein Gerät oder meinen Security Key verliere? Bin ich dann ausgesperrt?
Antwort: Keine Panik! Unternehmen planen für solche Fälle vorausschauend. Wenn Sie z.B. Ihren Laptop mit Windows Hello verlieren, melden Sie das der IT. Diese kann den hinterlegten Passkey sofort deaktivieren. Dann nutzen Sie einen Temporary Access Pass (TAP) oder ein anderes registriertes Gerät, um sich einzuloggen und gleich einen neuen Passkey einzurichten. Viele geben ihren Nutzern auch von Anfang an zwei Keys: einen Haupt- und einen Ersatzschlüssel. So sind Sie nicht auf ein Gerät allein angewiesen. Wichtig ist, Verluste direkt zu melden, damit kein Unbefugter eine Chance hat. Aber ausgesperrt auf Nimmerwiedersehen ist niemand – es gibt immer Wege, den Zugang wiederherzustellen.

Frage 4: Können Passkeys auch von Hackern phishing-umgangen werden, z.B. mit Man-in-the-Middle Attacken?
Antwort: So gut wie nicht. Genau das ist der Clou: Bei einer klassischen Man-in-the-Middle-Phishingattacke lockt der Hacker Sie ja auf eine gefälschte Seite und leitet alles an die echte weiter. Würden Sie dort Passwort oder SMS-Code eingeben, könnte er den mitlesen und direkt missbrauchen. Bei Passkeys jedoch bindet Ihr Gerät die Signatur an die Origin der Website. Heißt: Wenn es nicht die echte Microsoft-Seite ist, unterschreibt der Passkey nicht gültig. Selbst wenn der Hacker den Web-Traffic mitliest und ihre Signatur stiehlt, nützt sie ihm nichts, weil er sie nicht reproduzieren oder woanders verwenden kann (ein sogenannter „Replay“ ist dank Challenge unique). Lange Rede, kurzer Sinn: Phishing hat gegen Passkeys sehr sehr schlechte Karten. Natürlich muss man als Nutzer trotzdem aufpassen, wo man klickt, aber die Anmeldedaten kann der Angreifer nicht einfach abgreifen wie früher.

Frage 5: Kann ich einen Passkey auf mehreren Geräten nutzen?
Antwort: Ja, aber es hängt vom Typ des Passkeys ab. Ein Hardware-Token (USB/NFC Key) können Sie natürlich an verschiedenen Geräten verwenden, das ist ja sein Zweck – Sie tragen ihn mit und stecken ihn ein, wo Sie ihn brauchen. Plattform-Passkeys (z.B. Windows Hello oder ein in Ihrem Smartphone gespeicherter Schlüssel) sind pro Gerät erstellt. Sie können aber auf jedem Ihrer Geräte jeweils einen Passkey für Ihr Konto registrieren. Also z.B. auf Ihrem Laptop Windows Hello einrichten und auf Ihrem Smartphone einen Passkey in der Authenticator-App. Dann funktionieren beide. Die Industrie arbeitet auch an Roaming-Passkeys, die sich automatisch auf Ihre Geräte verteilen (Apple iCloud macht das in der Apple-Welt schon). In Microsofts Entra ID war das noch in Vorbereitung – Stand jetzt registrieren Sie pro Gerät. Aber unterm Strich: Sie können und sollten auch mehrere Passkeys haben, sodass Sie von allen wichtigen Geräten passwortlos reinkommen.

Frage 6: Benötige ich spezielle Hardware, um Passkeys nutzen zu können?
Antwort: Nicht zwingend. Oft lässt sich vorhandene Hardware nutzen: – Ihr Smartphone kann mit der Microsoft Authenticator App als Passkey-Device dienen – die meisten modernen Handys haben Fingerprint oder Gesichtserkennung, das reicht. – Ihr Laptop: Wenn er Windows 10+ und ein TPM hat (das haben die meisten Business-Notebooks), können Sie Windows Hello (PIN/Fingerprint) verwenden. – Externe Keys: Nur falls Sie kein geeignetes Gerät haben (oder aus Richtliniengründen höhere Sicherheit wollen) kommen diese ins Spiel. Das wären z.B. YubiKeys, Feitian oder andere FIDO2-Sticks. Die kosten je nach Modell 20-50 Euro. Viele Firmen beschaffen ein Kontingent davon für bestimmte Nutzergruppen (z.B. Admins, die hardcore Sicherheit brauchen, oder Mitarbeiter ohne Diensthandy). In Summe: Mit einem halbwegs aktuellen PC oder Handy sind Sie schon gerüstet. Spezielle Hardware ist nice-to-have für bestimmte Fälle, aber nicht generell nötig.

Frage 7: Funktioniert passwortlos auch mit älteren Anwendungen und Systemen?
Antwort: Jein. Direkt in wirklich alten Systemen (die nur Passwort-Login kennen) kann ein Passkey nicht „magisch“ wirken. Allerdings gibt es oft Workarounds, um solche Systeme einzubinden. Viele Legacy-Webanwendungen lassen sich z.B. über Azure AD Application Proxy oder ähnliche Lösungen vorschalten, sodass der Nutzer letztlich via Entra ID (und damit passwortlos) reinkommt, während Azure AD die Backend-Anmeldung übernimmt. Andere legacy Systeme – etwa ein sehr altes Mailprotokoll (POP/IMAP) oder ein Mainframe-Terminal – werden weiterhin ein Passwort erwarten. Hier bleibt in der Übergangszeit nichts anderes übrig, als diese speziellen Konten mit einem herkömmlichen Passwort zu betreiben, bis man das System ablösen oder modernisieren kann. Wichtig ist, dass man solche Ausnahmen erkennt und möglichst isoliert: z.B. separate Konten, die nur für diese Legacy-App gelten, und diese mit strengen Policies umgeben (kein Internetzugriff, nur interne Verwendung etc.). Langfristig sollte das Ziel sein, möglichst alle Anwendungen an moderne Authentifizierung anzubinden – dann profitieren sie automatisch von den passwortlosen Logins.

Frage 8: Wie aufwändig ist die Einführung von Passkeys für unsere IT-Abteilung?
Antwort: Es ist ein überschaubares Projekt, aber kein Knopfdruck. Technisch ist vieles schon da (Azure AD kann Passkeys, viele Geräte können es), aber der Aufwand liegt in Koordination und Change Management. Die IT muss: – Einstellungen in Entra ID setzen (einmalig, relativ einfach). – Ggfs. Geräte konfigurieren (Windows Hello via Intune/GPO ausrollen – etwas Aufwand). – Vor allem Benutzer schulen, unterstützen, Richtlinien anpassen. Das ist eher organisatorischer Aufwand. Rechnen Sie je nach Firmengröße mit einigen Wochen bis wenigen Monaten Projektzeit, plus etwas laufender Betreuung. Anfänglich hat der Helpdesk ein paar mehr Tickets („Wie registriere ich…“), aber danach sinkt der Aufwand drastisch, weil Passwort-bezogene Tickets wegfallen. In Zahlen: Ein Team von 3-5 Leuten kann in einem Unternehmen mit ein paar tausend MA so ein Rollout stemmen, neben dem normalen Geschäft, wenn es gut geplant ist. Bei kleineren Firmen (<500 MA) ist es fast Tagesgeschäft – ein Admin kann das nebenbei konfigurieren. Der meiste Aufwand ist Kommunikation, weniger die Technik an sich.

Frage 9: Was kostet uns das – müssen wir neue Lizenzen kaufen?
Antwort: Wenn Sie bereits Microsoft 365 E3 oder höher haben, sind Sie lizenziert, um Passkeys zu nutzen. Azure AD Premium P1 ist da enthalten, und das braucht man für die Feinsteuerung. Falls Sie bisher nur E1 oder gar die freie Variante nutzen, müssten Sie auf P1 upgraden, um z.B. Conditional Access Policies einsetzen zu können. In E5 (oder P2) ist noch Identity Protection dazu, das ist nützlich aber kein Muss. An Hardwarekosten fallen ggf. FIDO-Keys an, wenn Sie die verteilen wollen – rechnen Sie grob mit 30€ pro Key. Sie können aber auch erst mal ohne neue Hardware starten (über Handy/Laptop). Summiert: Die meisten zahlten schon für die Features mit ihren M365-Lizenzen, daher keine Extra-Lizenzkosten. Hardware nach Bedarf, und Projektaufwand wie oben. Manchmal investiert man noch in Schulungsmaterial oder externe Beratung (😉 hallo!), aber das hält sich im Rahmen verglichen mit den Sicherheitsgewinnen.

Frage 10: Ist ein Passkey dasselbe wie eine Smartcard oder Zertifikat?
Antwort: Verwandt, aber nicht identisch. Smartcards mit Zertifikaten gibt es seit Jahrzehnten – das sind auch zwei-Faktor-Authentifizierungen (Karte + PIN) und sehr sicher. Passkeys erfüllen einen ähnlichen Zweck, nutzen aber modernere Protokolle (FIDO statt klassische PKI) und sind einfacher ins Web und die Cloud integrierbar. Man kann sagen: Ein Passkey ist wie eine Smartcard, nur dass das „Zertifikat“ (bzw. Schlüssel) nicht von einer Firmen-PKI ausgestellt werden muss, sondern beim Registrieren erstellt wird und vom Azure AD anerkannt wird. Windows Hello for Business z.B. kann intern entweder auf Zertifikaten beruhen oder keys (Cloud trust). Der Vorteil von Passkeys gegenüber klassischen Smartcards: kein komplexes Zertifikatsmanagement mit eigener CA nötig, und universeller einsetzbar (Websites, Apps). Wer heute schon Smartcards nutzt: Gratulation, dann haben Sie quasi das hohe Sicherheitsniveau schon – Passkeys sind dann eher eine Ergänzung, um z.B. auf dem Smartphone oder in der Cloud leichter damit zu arbeiten.

Frage 11: Wie unterscheidet sich Windows Hello von einem FIDO2-Sicherheitsschlüssel?
Antwort: Windows Hello for Business ist Microsofts passwortlose Methode für Windows-Geräte: Dabei wird pro Gerät ein Schlüsselpaar erstellt und im geschützten Speicher (TPM) abgelegt. Der Nutzer meldet sich lokal mit PIN oder Biometrie an, und Windows nutzt den privaten Schlüssel im Hintergrund für die Anmeldung bei Entra ID und – in Hybrid-Umgebungen – auch für AD-Dienste. Es ist gerätegebunden (funktioniert nur auf dem jeweiligen Laptop/Tablet), bietet dafür aber nahtloses SSO auf diesem Gerät. Ein FIDO2-Sicherheitsschlüssel hingegen ist ein portabler Passkey: ein externes Gerät (USB/NFC-Stick), das man an beliebige kompatible Geräte anschließen kann, um sich zu authentifizieren. Beide erfüllen denselben Zweck (starke, phishing-sichere Authentifizierung), aber Windows Hello ist an ein Gerät gebunden und vor allem für den täglichen PC-Login gedacht, während ein physischer FIDO2-Key universeller einsetzbar ist (z.B. auch mal an einem fremden Rechner oder gemeinsam genutzten PC). In vielen Fällen nutzt man eine Kombination: Hello für die persönlichen Firmen-Laptops und ein FIDO2-Token als ergänzende Option (oder Backup) für andere Situationen.

Frage 12: Können wir Passkeys testweise einführen, ohne gleich alles umzustellen?
Antwort: Absolut. Man kann klein anfangen. Zum Beispiel aktivieren Sie Passkeys für die IT-Abteilung oder eine freiwillige Pilotgruppe und sammeln erst mal Erfahrungen. Der Rest der Nutzer merkt davon nichts, bis Sie bereit sind, breiter auszurollen. Azure AD lässt sich sehr gezielt konfigurieren – Sie können sagen „nur Gruppe X darf Passkeys registrieren“. Sie müssen auch nicht sofort Passwörter deaktivieren. D.h. in der Pilotphase arbeiten die Tester halt parallel: mal mit Passwort, mal mit Passkey. Das ist okay, wenn man es kommuniziert. Wichtig ist, eine Testphase zu haben, um firmeninterne Fragen zu klären (z.B. „Wie machen wir’s mit unserem Zeiterfassungsterminal?“). Also ja, es ist sogar empfehlenswert, stufenweise vorzugehen. Danach kann man immer noch entscheiden, ob man den großen Schalter umlegt oder erst mal Hybrid-Betrieb macht. Die Systeme unterstützen das Nebeneinander.

Frage 13: Wie läuft das Onboarding neuer Mitarbeiter ohne Passwort konkret ab?
Antwort: Das klassische Szenario: Bisher kriegt der neue Kollege einen Zettel „Initial-Passwort: Willkommen123“. Künftig: Er bekommt z.B. einen Temporary Access Pass (TAP) oder einen einmaligen QR-Code beim Onboarding. Damit loggt er sich am ersten Tag ein. Das System fragt sofort nach starker Authentifizierung – je nach Setup muss er dann z.B. die Authenticator-App koppeln oder gleich einen FIDO-Key anstecken. Mit dem TAP kann er diesen ersten sicheren Registrierungsschritt tun, ohne je ein richtiges Passwort zu wissen. Manche Firmen machen Onboarding-Workshops: alle Neuen einer Woche kommen zusammen, die IT erklärt kurz und jeder richtet unter Anleitung direkt seinen Passkey ein (Handy zücken, scannen, fertig). Danach nutzen die Neuen ihr Gerät nur noch mit Hello/PIN und kennen es gar nicht anders. Das Schöne: Man spart sich das ganze Initialpasswort-Handling, was ja oft unsicher war (Zettel, Mail). Der TAP läuft nach ein paar Stunden ab, somit ist das auch kein bleibendes Geheimnis. So holt man direkt alle Neuankömmlinge ins Boot, während man Altmitarbeiter parallel umstellt.

Frage 14: Was ist, wenn ein externer Partner keinen Passkey nutzt? Kommt der dann nicht mehr in unser System?
Antwort: Standardmäßig sollten externe Partner in Ihrem Tenant mindestens MFA verwenden müssen (das lässt sich per Conditional Access erzwingen). Das heißt, ohne zweiten Faktor kommt kein Gast rein. Wollen Sie es noch sicherer, könnten Sie von Partnern auch phishing-resistente Methoden verlangen. Praktisch muss man hier oft Kompromisse eingehen: Nicht jeder externe Partner kann sofort Passkeys einsetzen. Wichtig ist aber, dass kein externer Zugriff allein mit einem einfachen Passwort möglich ist. Im Zweifel sollten Sie Gäste immer zu einer zusätzlichen Verifizierung zwingen (z.B. Code-Eingabe). Für besonders sensible externe Zugriffe (etwa Dienstleister mit Adminrechten) lohnt es sich, individuelle Lösungen zu finden – z.B. dem Partner einen separaten Account in Ihrem System zu geben, der Ihren strengen Policies (inkl. Passkey-Pflicht) unterliegt. Kurz gesagt: Ganz ohne MFA geht niemand extern mehr rein; ob Sie darüber hinaus Passkeys verlangen, können Sie je nach Sicherheitsbedarf gestalten und mit den Partnern abstimmen.

Frage 15: Wie gehen wir mit Service Accounts oder technischen Accounts um, die keiner Person zugeordnet sind?
Antwort: Für solche „Non-Human Accounts“ eignen sich Passkeys nicht, da kein Mensch verfügbar ist, um z.B. einen Finger aufzulegen. Hier geht man andere Wege: Wo möglich, sollten Sie solche Abläufe auf App-Registrierungen mit Zertifikats- oder Schlüssel-Authentifizierung umstellen. Das heißt, anstatt einen Service mit einem normalen Benutzerkonto (und Passwort) laufen zu lassen, richten Sie in Entra ID eine Anwendung bzw. ein Dienstprinzipal ein, der sich z.B. per Zertifikat oder Client-Secret ausweist. Das entfernt die Notwendigkeit, ein Passwort zu speichern, und lässt sich ebenfalls sicher gestalten. Falls es noch echte Service-User-Konten gibt (etwa für ein altes Script, das sich via IMAP einloggt), können Sie diese vorläufig behalten, sollten sie aber streng einschränken (z.B. nur berechtigte IP-Adressen zulassen) und ein komplexes Zufalls-Passwort setzen, das idealerweise nie verwendet wird. Ziel sollte sein, mittelfristig alle technischen Zugriffe auf moderne Authentifizierung (oder fest hinterlegte Zertifikate) umzustellen, sodass auch hier keine „Passwörter“ im klassischen Sinne nötig sind.

Glossar

• Passkey: Ein passwortloser Anmeldeschlüssel basierend auf FIDO2/WebAuthn (Schlüsselpaar aus privatem und öffentlichem Schlüssel), der das herkömmliche Passwort ersetzt.
• FIDO2: Ein offener Standard der FIDO-Allianz für sichere, passwortlose Authentifizierung (umfasst WebAuthn und zugehörige Protokolle).
• WebAuthn: Die Web-Authentifizierungs-API (W3C-Standard), die es Browsern ermöglicht, Passkeys für Logins zu verwenden.
• Plattform-Passkey: Ein Passkey, der in einem bestimmten Gerät/OS gespeichert ist (z.B. Windows Hello auf einem Laptop) und nicht ohne Weiteres auf andere Geräte übertragen wird.
• Roaming-Passkey: Ein Passkey, der geräteübergreifend nutzbar ist – z.B. auf einem physischen Sicherheitsschlüssel, den man mitnimmt, oder via Cloud-Synchronisierung über verschiedene Geräte hinweg.
• Entra ID: Microsofts Cloud-Verzeichnisdienst (ehemals Azure Active Directory) zur Verwaltung von Benutzern, Anmeldungen und Zugriffsrechten in Microsoft 365.
• Authentication Methods Policy: Richtlinie in Entra ID, mit der festgelegt wird, welche Authentifizierungsmethoden (Passwort, FIDO2, OTP etc.) für welche Benutzer erlaubt oder erforderlich sind.
• Conditional Access: (Bedingter Zugriff) Mechanismus in Entra ID, um anhand von Bedingungen (Benutzer, Gerät, Standort, Risiko) zu steuern, ob und wie ein Zugriff erlaubt wird (z.B. MFA erzwingen oder blockieren).
• Passwordless: Allgemeiner Begriff für Authentifizierungsmethoden, die ohne klassisches Passwort auskommen (z.B. Passkeys, Windows Hello, Authenticator-App Login).
• Phishing-resistent: Bezeichnung für Authentifizierungsverfahren, die nicht durch herkömmliches Phishing ausgetrickst werden können (Passkeys gelten als phishing-resistent, im Gegensatz zu z.B. SMS-Codes).
• Zero Trust: Sicherheitsmodell, das davon ausgeht, keinem Zugriff implizit zu vertrauen – jede Anfrage wird verifiziert. Starke Authentifizierung (wie Passkeys) ist ein wichtiges Element von Zero-Trust-Architekturen.
• AAGUID: „Authenticator Attestation GUID“ – eine eindeutige ID, die den Typ eines FIDO2-Authentifikators identifiziert (wird z.B. genutzt, um bestimmte Schlüsselmodelle in Entra ID zuzulassen oder zu blockieren).
• Windows Hello for Business: Microsofts passwordlose Anmeldelösung für Windows in Unternehmen (Nutzer meldet sich mit PIN oder Biometrie am Gerät an; ein Schlüsselpaar ersetzt das AD-Passwort und ermöglicht auch Zugriff auf AD-Ressourcen).
• MFA: Multi-Faktor-Authentifizierung – eine Anmeldung, die mindestens zwei verschiedene Faktoren kombiniert (z.B. etwas, das man weiß + hat + ist). Passkeys erfüllen MFA-Kriterien, da sie Besitz (Gerät/Schlüssel) mit einem zusätzlichen Faktor (PIN oder Biometrie) kombinieren.
• Self-Service-Registrierung: Möglichkeit für Benutzer, selbst ihre Anmeldemethoden (Passkey, Telefon, E-Mail etc.) im Benutzer-Portal zu registrieren oder zu verwalten, ohne IT-Support (typischerweise über das „Meine Sicherheitsinformationen“ Portal).
• Identity Protection: Entra ID-Funktion (in P2-Lizenz), die Risikoerkennung und -automatisierung bietet – z.B. erkennt unsichere Anmeldeversuche und kann basierend darauf Benutzer blockieren oder zur zusätzlichen Verifizierung zwingen.
• Legacy-Authentifizierung: Veraltete Authentifizierungsverfahren oder Protokolle, die keine modernen Sicherheitsfeatures unterstützen (keine MFA-Unterstützung etc.). Beispiele: Basic Auth bei SMTP/IMAP, ältere Office-Protokolle. Diese gelten als unsicherer und sollten zugunsten moderner Auth (OAuth2, SAML) abgeschaltet werden.

Mein Beratungsangebot

Sie haben nun viel über Passkeys, Entra ID und die praktische Umsetzung gelesen – und vielleicht juckt es Sie in den Fingern, das in Ihrem Unternehmen umzusetzen. Ich würde mich freuen, Sie dabei zu unterstützen. Als Ulrich B. Boddenberg IT-Consultancy biete ich Ihnen meine persönliche Expertise und Begleitung an. Was können Sie konkret von mir erwarten?

• Strategie-Workshops: Gemeinsam entwickeln wir die maßgeschneiderte Passwordless-Strategie für Ihre Organisation. Ob Sie erst klein anfangen wollen oder gleich große Würfe planen – im Workshop erarbeiten wir Ziele, Scope, und einen groben Fahrplan. Sie profitieren von meinen Best Practices und einer unabhängigen Sicht von außen.
• Pilotprojekt-Begleitung: Ich helfe Ihnen, einen erfolgreichen Piloten aufzusetzen. Von der Einrichtung der Entra ID Policies bis zur Auswahl der Pilotnutzer und Erfolgskriterien – ich bin an Ihrer Seite. Falls mal etwas nicht sofort klappt, stehe ich mit pragmatischen Lösungen bereit (oft gesehen, oft gelöst lautet da mein Motto).
• Policy-Design: Conditional Access Regeln, Authentication Method Einstellungen, Compliance-Vorgaben – das alles will gut durchdacht sein. Ich entwerfe mit Ihnen Richtlinien, die sicher, aber auch praxisgerecht sind. Dazu gehört z.B. ein fein austariertes Ausnahmekonzept, damit Sie Sicherheit erhöhen ohne die Organisation lahmzulegen.
• Rolloutplanung: Ein Großprojekt wie ein unternehmensweiter Passkey-Rollout bedarf genauer Planung. Zeitpläne, Ressourcen, Kommunikationsmaßnahmen – ich erstelle mit Ihrem Team den Projektplan und helfe, Meilensteine realistisch zu setzen. Insbesondere die Koordination zwischen verschiedenen Abteilungen (IT, HR, Compliance, Standortverantwortliche) kann ich moderieren.
• Change-Management: Technik ist nur die halbe Miete – die Benutzer müssen mitziehen. Ich unterstütze bei der Erstellung von Schulungsmaterialien, intranet-Artikeln, vielleicht sogar kurzen Erklärvideos. Auf Wunsch führe ich Kickoff-Veranstaltungen durch, um Mitarbeiter für das Thema zu begeistern. Mit meinem lockeren, verständlichen Stil nehme ich den Leuten die Angst vor der Veränderung.
• Audit-Vorbereitung: Steht bei Ihnen ein IT-Security Audit oder eine Zertifizierung an (ISO 27001, BSI Grundschutz, TISAX etc.)? Passkeys können hier ein Pluspunkt sein – aber man muss es den Prüfern richtig darlegen. Ich bereite mit Ihnen die Dokumentation und Nachweise vor. Sei es Richtlinien-Papiere zu aktualisieren oder Reports zu ziehen, die zeigen wie MFA-Quote gestiegen ist. Dank meiner Erfahrung weiß ich, worauf Auditoren schauen.

Das Besondere an meiner Beratung: Sie bekommen mich persönlich. Keine Junior-Consultants, die erst bei Ihnen lernen – ich kümmere mich direkt um Ihre Anliegen. Mit über 20 Jahren Erfahrung in der Microsoft-Welt und etlichen Projekten in Deutschland, Österreich und der Schweiz kenne ich die typischen Hürden und Erfolgsfaktoren. Von der Konzerntochter bis zum Mittelständler habe ich Teams durch die Einführung neuer Security-Technologien geführt.

Ich lege großen Wert darauf, praxisnahe Lösungen zu finden, die zu Ihrer Firmenkultur passen. Theoretische Konzepte gibt es viele, doch am Ende zählt, was umsetzbar ist und von den Mitarbeitern akzeptiert wird. Genau dabei helfe ich – damit Passkeys für Sie nicht nur sicher sind, sondern auch ein Gewinn an Benutzerfreundlichkeit.

Interessiert? Dann zögern Sie nicht, mich anzusprechen. Zusammen machen wir Ihre Passwort-Hölle zur Passwortlos-Himmel. 😉

Fazit

Passkeys sind nicht einfach nur ein neuer Trend, sondern die logische Weiterentwicklung der IT-Sicherheit in Zeiten zunehmender Cyber-Bedrohungen. Klassische Passwörter haben uns lange begleitet – oft genug geärgert – und stoßen nun endgültig an ihre Grenzen. Mit Passkeys, FIDO2 und einer durchdachten Integration in Entra ID schlagen wir ein neues Kapitel auf: eins, in dem Sicherheit und Benutzerkomfort kein Widerspruch mehr sind.

In diesem Artikel habe ich Sie durch die faszinierende Welt der passwordless Authentifizierung geführt – von den Grundlagen über konkrete Umsetzungsszenarien bis hin zu praktischen Tipps für Betrieb und Einführung. Wir haben gesehen, dass Passkeys phishing-resistent, benutzerfreundlich und zukunftssicher sind. Ja, der Weg dorthin erfordert Planung und den Mut, alte Zöpfe abzuschneiden, aber die Belohnung ist es wert: weniger Supportaufwand, weniger Risiko, zufriedenere Nutzer.

Mein Appell an Sie: Überlegen Sie strategisch, wo Ihr Unternehmen in Sachen Identity Security in 3-5 Jahren stehen soll. Viele Anzeichen sprechen dafür, dass Passkeys sich zum Standard entwickeln – sei es durch die großen Tech-Anbieter oder regulatorische Empfehlungen. Wer früh anfängt, sammelt Erfahrung und kann mögliche Stolpersteine elegant umschiffen. Und wer Unterstützung auf diesem Weg braucht, findet sie (zum Beispiel bei mir).

Am Ende des Tages geht es um Vertrauen: das Vertrauen Ihrer Benutzer, dass Sie ihre Accounts bestmöglich schützen, und Ihr Vertrauen in moderne Technologie, die Ihnen dabei hilft. Passkeys sind ein großes Stück dieses Puzzles. Packen wir es an – die Passwort-freie Zukunft wartet!

„Ihr Passwort lautet: <nicht mehr erforderlich>“ – klingt doch gut, oder? 😉