Anmeldesicherheit neu denken – Warum Passwörter scheitern und Windows Hello for Business sowie Passkeys die Zukunft sind

Identität ist die neue Angriffsfläche

In klassischen IT-Architekturen stand lange Zeit das Endgerät im Mittelpunkt der Sicherheitsstrategie. Daten wurden lokal gespeichert, und Benutzerinnen und Benutzer trugen vertrauliche Informationen häufig physisch mit sich. Ging ein Notebook verloren oder wurde ein Smartphone entwendet, lag das zentrale Risiko weniger im materiellen Wert des Geräts als im möglichen Verlust sensibler Daten.

Entsprechend konzentrierte sich die Sicherheitsarchitektur stark auf den Schutz des Endgeräts. Technologien wie Datei- und Volumeverschlüsselung, Multifaktor-Authentifizierung zur Gerätefreigabe, Einmalpasswörter oder Smartcards sowie Mobile-Device-Management mit Funktionen zur Fernsperrung oder Remote-Löschung sollten verhindern, dass ein verlorenes oder gestohlenes Gerät unmittelbar zum Datenabfluss führte.

Diese Maßnahmen waren – und sind – technisch sinnvoll. Sie adressieren jedoch primär das Risiko des physischen Geräteverlusts.

Mit der zunehmenden Verlagerung von Anwendungen und Daten in Cloud-Plattformen hat sich dieses Bedrohungsmodell grundlegend verändert. Informationen sind heute kaum noch an ein einzelnes Endgerät gebunden. Cloud-Speicher, SaaS-Dienste und hybride Identitätsplattformen entkoppeln Daten vollständig von der Hardware.

Damit verschiebt sich der eigentliche Werteträger der IT-Sicherheit: Nicht mehr das Gerät schützt den Zugriff auf Informationen – sondern die digitale Identität ermöglicht ihn.

Die Verschiebung der Sicherheitsgrenze

Cloud-Dienste, Remote-Arbeit und hybride IT-Architekturen haben das klassische Perimeter-Modell grundlegend verändert. Während früher Firewalls und Netzwerkgrenzen das Unternehmensnetz schützten, bildet heute zunehmend die digitale Identität die eigentliche Sicherheitsgrenze.

Diese Entwicklung spiegelt sich auch in aktuellen Bedrohungsanalysen wider. Der Microsoft Digital Defense Report dokumentiert eine massive Zunahme identitätsbasierter Angriffe. Weltweit werden täglich Milliarden automatisierter Anmeldeversuche registriert – häufig in Form von Passwort-Spraying, Credential-Stuffing oder gezielten Kontoübernahmen.

Der Grund ist einfach: Sobald Angreifer:innen über gültige Anmeldeinformationen verfügen, verlieren viele klassische Schutzmechanismen ihre Wirkung. Firewalls, VPN-Gateways oder Netzwerksegmentierungen werden umgangen, weil der Zugriff scheinbar legitim über Cloud-Dienste erfolgt – etwa über Plattformen wie Microsoft 365 oder Microsoft Entra ID.

Damit verschiebt sich auch der strategische Schwerpunkt der IT-Sicherheit. Gerätesicherheit bleibt weiterhin ein wichtiger Bestandteil moderner Schutzkonzepte. Entscheidend für das tatsächliche Schutzniveau ist jedoch zunehmend die Stärke der Authentifizierung. In verteilten Cloud-Architekturen bildet sie die zentrale Verteidigungslinie gegen identitätsbasierte Angriffe.

Warum das Passwort strukturell an Grenzen stößt

Das klassische Modell aus Benutzername und Kennwort begleitet die IT seit Jahrzehnten. Trotz zahlreicher technischer Weiterentwicklungen basiert es jedoch auf einem Prinzip, das aus heutiger Sicht sicherheitstechnisch problematisch ist: einem geteilten Geheimnis.

Sowohl der Dienst als auch die Benutzerinnen und Benutzer kennen denselben Authentifizierungswert. Dieses Geheimnis muss bei jeder Anmeldung übertragen, überprüft und erneut verwendet werden. Genau darin liegt die grundlegende Schwäche des Passwortmodells.

Ein Passwort besitzt mehrere Eigenschaften, die es aus sicherheitstechnischer Perspektive anfällig machen: Es ist reproduzierbar, kann gespeichert oder weitergegeben werden und lässt sich grundsätzlich auf beliebigen Systemen erneut verwenden. Selbst wenn serverseitig moderne Schutzmechanismen wie Hashing und Salt-Verfahren eingesetzt werden, bleibt dieses Prinzip unverändert bestehen. Die Authentifizierung basiert weiterhin auf einem statischen Wissensmerkmal, das bei Kenntnis erneut eingesetzt werden kann.

Daraus entsteht ein systemischer Zielkonflikt zwischen Sicherheit und Benutzbarkeit. Ein leicht merkbares Passwort ist in der Regel auch leicht zu erraten. Wird ein Passwort hingegen komplex konstruiert, steigt die Wahrscheinlichkeit, dass Benutzerinnen und Benutzer auf unsichere Hilfsstrategien zurückgreifen – etwa Wiederverwendung, einfache Variationen oder externe Notizen.

Diese strukturelle Begrenzung erklärt, warum viele moderne Identitätsangriffe nicht primär auf technische Schwachstellen von Geräten abzielen, sondern auf das Authentifizierungsmodell selbst. Unabhängig davon, wie gut Endgeräte oder Netzwerke geschützt sind: Solange ein statisches Geheimnis den Zugriff ermöglicht, bleibt es ein attraktives Angriffsziel.

Zero Trust als strategischer Rahmen moderner Identitätssicherheit

Moderne Sicherheitsarchitekturen orientieren sich zunehmend am Konzept von Zero Trust. Dieses Modell basiert auf der Annahme, dass kein Zugriff grundsätzlich vertrauenswürdig ist. Jede Anmeldung muss daher kontinuierlich überprüft werden – unabhängig davon, ob sie aus dem internen Netzwerk, aus der Cloud oder von einem externen Standort erfolgt.

Identität, Gerätezustand und Kontextinformationen werden dabei gemeinsam bewertet. In Microsoft-Umgebungen setzt beispielsweise Microsoft Entra ID dieses Prinzip durch Mechanismen wie Conditional Access, Risikoanalysen und Multi-Faktor-Authentifizierung um. Faktoren wie Gerätestatus, Benutzerverhalten oder Anmelderisiko fließen dynamisch in die Entscheidung ein, ob ein Zugriff gewährt wird.

Diese Architektur erhöht das Sicherheitsniveau erheblich. In vielen Szenarien bleibt jedoch ein zentraler Bestandteil unverändert: Das Passwort fungiert weiterhin als primärer Authentifizierungsfaktor. Zusätzliche Schutzmechanismen können Risiken reduzieren, sie lösen jedoch nicht zwangsläufig die strukturellen Schwächen eines wiederverwendbaren Geheimnisses.

Damit stellt sich für moderne Identitätsarchitekturen eine grundlegendere Frage: Soll das Passwort lediglich durch zusätzliche Schutzschichten abgesichert werden – oder ist es an der Zeit, das Authentifizierungsmodell selbst neu zu denken?

Diese Frage bildet den Ausgangspunkt für die weitere Analyse im folgenden Kapitel.

Das strukturelle Scheitern von Benutzername und Kennwort

Die klassische Anmeldung mit Benutzername und Kennwort folgt einem scheinbar einfachen Prinzip: Sowohl der Dienst als auch die Benutzer:innen verfügen über denselben Authentifizierungswert. Dieses Modell basiert somit auf gemeinsamem Wissen – einem geteilten Geheimnis.

Genau dieses Prinzip erzeugt jedoch ein strukturelles Risiko. Ein Passwort muss zunächst von einem Menschen gewählt werden, anschließend gespeichert oder erinnert werden und bei jeder Anmeldung an den Dienst übermittelt werden. Der Dienst wiederum muss dieses Geheimnis serverseitig prüfen und mit einem gespeicherten Referenzwert vergleichen.

Moderne Systeme speichern Kennwörter zwar nicht mehr im Klartext, sondern als kryptografische Hashwerte, häufig ergänzt durch Salt-Verfahren zum Schutz vor vorberechneten Angriffen. Diese Maßnahmen erhöhen die Widerstandsfähigkeit gegen bestimmte Angriffsszenarien, verändern jedoch nicht das grundlegende Authentifizierungsmodell. Der Dienst prüft weiterhin lediglich, ob der übermittelte Wert mit dem gespeicherten Hash korreliert.

Wird dieses Geheimnis kompromittiert – etwa durch Phishing, Malware oder Datenlecks – kann es unmittelbar erneut eingesetzt werden. Genau darin liegt die systemische Schwäche des Passwortmodells: Das Authentifizierungsmerkmal ist reproduzierbar und nicht an Kontext, Gerät oder Integritätszustand gebunden.

Kryptografische Betrachtung: Ein symmetrisches Modell ohne Gerätebindung

Aus kryptografischer Sicht basiert das Passwort auf einem symmetrischen Authentifizierungsprinzip. Sowohl der Dienst als auch die Benutzer:innen verfügen über denselben Wissensbestand, der zur Authentifizierung verwendet wird. Das System prüft lediglich, ob der übermittelte Wert mit dem gespeicherten Referenzwert übereinstimmt.

Dieses Modell besitzt jedoch mehrere sicherheitsrelevante Eigenschaften. Der Besitz des Geheimnisses allein reicht aus, um eine erfolgreiche Anmeldung durchzuführen. Eine zusätzliche Bindung an ein bestimmtes Gerät oder an einen konkreten Systemzustand existiert nicht. Ebenso fehlt eine kryptografische Struktur, die individuelle Schlüsselpaare oder eine echte Challenge-Response-Authentifizierung auf Basis gerätegebundener Schlüssel nutzt.

Moderne Authentifizierungsarchitekturen verfolgen daher einen anderen Ansatz. Sie setzen zunehmend auf asymmetrische Kryptografie, bei der ein privater Schlüssel ausschließlich lokal erzeugt und gespeichert wird. Dieser Schlüssel verlässt das Gerät niemals und wird lediglich zur Signatur kryptografischer Herausforderungen verwendet.

Beim Passwort hingegen muss das Geheimnis – direkt oder in Form eines abgeleiteten Werts – zur Überprüfung an den Dienst übermittelt werden. Genau diese Übertragbarkeit macht das Modell anfällig für Angriffe wie Phishing, Credential-Theft oder Wiederverwendung kompromittierter Zugangsdaten.

Diese Architektur entstand in einer Zeit, in der IT-Systeme zentral, lokal und vergleichsweise überschaubar waren. In global vernetzten Cloud-Umgebungen mit verteilten Identitätsplattformen treten ihre strukturellen Schwächen jedoch deutlich zutage.

Angriffsdynamik in realen Umgebungen

Die strukturelle Schwäche des Passwortmodells wird besonders deutlich, wenn man reale Angriffsmuster moderner IT-Umgebungen betrachtet. Da ein Passwort ein wiederverwendbares Geheimnis darstellt, genügt seine Kenntnis grundsätzlich für eine erfolgreiche Authentifizierung – unabhängig davon, von welchem Gerät oder Standort aus der Zugriff erfolgt.

In der Praxis haben sich mehrere typische Angriffsmethoden etabliert:

Diese Angriffe lassen sich weitgehend automatisieren und in großem Maßstab durchführen. Ihr Ziel ist nicht primär das Endgerät, sondern das zugrunde liegende Authentifizierungsmodell. Sobald ein Passwort erfolgreich validiert wurde, erscheint der Zugriff aus Sicht des Dienstes legitim.

In Cloud- und Hybridumgebungen bedeutet dies konkret: Der Angreifer tritt gegenüber dem Dienst als regulär authentifizierte Identität auf.

Damit verschiebt sich auch die sicherheitstechnische Perspektive. Die zentrale Frage lautet nicht mehr nur, wie stark ein Passwort konstruiert ist. Entscheidend ist vielmehr, ob ein wiederverwendbares Geheimnis überhaupt noch ein tragfähiges Authentifizierungsmodell darstellt.

Warum Komplexitätsrichtlinien nicht ausreichen

Als Reaktion auf zunehmende Angriffe verschärften viele Organisationen im Laufe der Zeit ihre Kennwortrichtlinien. Längere Passwörter, verpflichtende Sonderzeichen, regelmäßige Passwortwechsel und komplexe Richtlinien sollten die Entropie erhöhen und Brute-Force-Angriffe erschweren.

Diese Maßnahmen können tatsächlich die technische Widerstandsfähigkeit einzelner Kennwörter erhöhen. Sie verändern jedoch nicht das grundlegende Authentifizierungsmodell. Das Passwort bleibt ein statisches Wissensmerkmal, das wiederholt zur Authentifizierung eingesetzt wird.

In der Praxis entstehen dadurch häufig neue Risiken. Typische Nebenwirkungen verschärfter Passwortregeln sind:

• Passwort-Wiederverwendung: Benutzer greifen auf ähnliche Kennwörter über mehrere Dienste hinweg zurück
• Steigender Helpdesk-Aufwand: Vergessene Kennwörter führen zu häufigen Zurücksetzungen und erhöhtem administrativem Aufwand
• Umgehungsstrategien: Benutzer entwickeln pragmatische Muster, um die Komplexitätsanforderungen überhaupt erfüllen zu können.
• Unsichere Speicherung: Komplexe Passwörter werden notiert oder in ungeschützten Dateien abgelegt

Diese Effekte zeigen ein grundlegendes Problem: Komplexitätsrichtlinien verbessern einzelne Passwörter, lösen jedoch nicht die strukturelle Schwäche des zugrunde liegenden Modells. Das Passwort bleibt ein wiederverwendbares Geheimnis ohne Bindung an Gerät, Kontext oder Systemintegrität.

Gerade deshalb gerät das Passwort zunehmend in Konflikt mit modernen Sicherheitsarchitekturen wie Zero Trust.

Die entscheidende Konsequenz lautet daher nicht: stärkere Passwörter. Die entscheidende Konsequenz lautet: ein anderes Authentifizierungsmodell.

Multi-Faktor-Authentifizierung: Sicherheitsgewinn oder Übergangslösung?

Multi-Faktor-Authentifizierung (MFA) verfolgt einen evolutionären Ansatz: Anstatt das bestehende Passwortmodell vollständig zu ersetzen, wird es um mindestens einen zusätzlichen Authentifizierungsfaktor erweitert. Ziel ist es, die Wahrscheinlichkeit erfolgreicher Kontoübernahmen deutlich zu reduzieren, indem mehrere unabhängige Merkmale kombiniert werden.

Klassisch unterscheidet man drei grundlegende Faktorarten:

• Wissen: etwas, das nur individuell bekannt ist
• Besitz: etwas, das sich physisch im Besitz befindet
• Inhärenz: etwas, das biometrisch eindeutig ist

Technisch bedeutet dies, dass neben dem Passwort ein weiterer Validierungsmechanismus geprüft wird. In typischen Implementierungen geschieht dies beispielsweise durch:

• Einmalcodes per SMS
• kryptografische Hardware-Token oder Sicherheitsschlüssel
• zeitbasierte OTP-Generatoren in Authenticator-Apps

Die zugrunde liegende Sicherheitsannahme ist klar: Selbst wenn ein Passwort kompromittiert wird, fehlt Angreifer:innen der zweite Faktor. Dadurch steigt der Aufwand für eine erfolgreiche Kontoübernahme erheblich.

Gleichzeitig bleibt die Authentifizierungsarchitektur in vielen Szenarien weiterhin passwortzentriert. Das Passwort fungiert als primärer Identitätsanker, während der zusätzliche Faktor als ergänzende Sicherheitsbarriere dient. Die Identitätsprüfung wird also verstärkt, jedoch nicht grundlegend neu gestaltet.

Genau hier liegt der architektonische Unterschied zwischen „Passwort plus zusätzlicher Faktor“ und einem tatsächlich passwortlosen Authentifizierungsmodell.

Klassische MFA-Varianten und ihre Grenzen

Multi-Faktor-Authentifizierung ist nicht gleich Multi-Faktor-Authentifizierung. In der Praxis existieren unterschiedliche Implementierungsformen, die sich sowohl in ihrer technischen Robustheit als auch in ihrer Widerstandsfähigkeit gegenüber modernen Angriffsmustern deutlich unterscheiden. Zwar erhöhen alle Varianten das Sicherheitsniveau gegenüber einer reinen Passwortauthentifizierung – sie sind jedoch keineswegs gleichwertig.

Entscheidend ist dabei eine zentrale Frage: Wie stark ist die Bindung zwischen Identität, Gerät und Authentifizierungsprozess?

SMS-basierte Verfahren

Einmalcodes per SMS galten lange als pragmatische Einstiegslösung. Die technische Implementierung ist vergleichsweise einfach, da weder zusätzliche Anwendungen noch spezielle Hardware erforderlich sind. Genau deshalb wurde SMS-OTP über viele Jahre hinweg als Standardverfahren für Multi-Faktor-Authentifizierung eingesetzt.

Allerdings bestehen mehrere strukturelle Schwächen:

• abfangbare oder weiterleitbare SMS-Codes
• Schwachstellen im SS7-Signalisierungsprotokoll der Telekommunikationsnetze
• SIM-Swapping durch Social Engineering bei Mobilfunkanbietern

Hinzu kommt ein grundlegendes Problem des Modells: Der Einmalcode bleibt ein übertragbares Geheimnis. Wird er in einem Echtzeit-Phishing-Szenario abgefragt, kann er unmittelbar weitergeleitet und missbraucht werden.

Aus sicherheitstechnischer Sicht gilt SMS-basierte Authentifizierung daher heute eher als Minimalstandard – nicht als robuste Lösung für besonders schützenswerte Identitäten.

Push-basierte Authenticator-Apps

App-basierte Freigaben, beispielsweise über den Microsoft Authenticator, stellen eine Weiterentwicklung dar. Die Bestätigung erfolgt auf einem registrierten Gerät, und der Authentifizierungsprozess kann in Richtlinien wie Conditional Access integriert werden.

Typische Eigenschaften sind:

• Anzeige zusätzlicher Kontextinformationen zur Anmeldung
• Bestätigung direkt auf einem registrierten Gerät
• Integration von Risiko- und Gerätesignalen

Trotz dieser Verbesserungen haben sich neue Angriffsmuster etabliert. Bei sogenannten MFA-Fatigue-Angriffen oder Push Bombing senden Angreifer:innen wiederholt Freigabeanfragen, bis Benutzer:innen aus Unsicherheit, Gewohnheit oder Versehen zustimmen.

Hier zeigt sich erneut die strukturelle Schwäche des Modells: Das Passwort bleibt weiterhin der primäre Angriffsvektor. Der zweite Faktor ist zwar gerätegebunden, jedoch nicht zwingend kryptografisch an die konkrete Anmeldung gekoppelt und kann unter Umständen durch Social Engineering erzwungen werden.

Die Sicherheitsarchitektur verbessert sich damit zwar deutlich – sie wird jedoch nicht grundlegend transformiert.

Echtzeit-Phishing und Token-Weiterleitung

Eine besonders relevante Angriffskategorie moderner Identitätsinfrastrukturen sind sogenannte Adversary-in-the-Middle-Angriffe (AiTM). Dabei versuchen Angreifer:innen nicht nur, Anmeldeinformationen zu stehlen. Stattdessen fungiert die Phishing-Infrastruktur selbst als aktiver Proxy zwischen Benutzer:in und legitimem Dienst.

Die Phishing-Seite ist in diesem Szenario keine statische Kopie der Anmeldeseite. Sie arbeitet vielmehr als Weiterleitungsmechanismus: Jede Eingabe wird in Echtzeit an den tatsächlichen Dienst übertragen.

Ein typischer Ablauf sieht folgendermaßen aus:

• Benutzer:innen geben das Passwort in die Phishing-Seite ein
• Die Eingabe wird unmittelbar an den echten Dienst weitergeleitet
• Das Zielsystem fordert den zweiten Faktor an
• Auch dieser wird über den Proxy abgefragt und weitergereicht
• Der Dienst stellt nach erfolgreicher Prüfung ein gültiges Sitzungstoken aus
• Dieses Token wird durch Angreifer:innen abgegriffen und für eigene Zugriffe verwendet

Der entscheidende Punkt dabei: Das Passwort selbst muss nicht dauerhaft gespeichert werden. Es wird lediglich benötigt, um die Authentifizierung erfolgreich abzuschließen. Der eigentliche Wert liegt im ausgestellten Sitzungstoken. Dieses Token legitimiert weitere API-Aufrufe oder Web-Sitzungen, ohne dass das Passwort erneut abgefragt wird.

In diesem Szenario erfüllt Multi-Faktor-Authentifizierung formal ihre Funktion. Das Passwort allein reicht nicht aus, um den Zugriff zu erhalten. Dennoch bleibt der Anmeldevorgang angreifbar, weil der zweite Faktor nicht kryptografisch an den legitimen Dienst gebunden ist.

Das Sicherheitsproblem verschiebt sich damit vom Schutz des Passworts hin zur Integrität der Authentifizierungssitzung. Genau an diesem Punkt setzen moderne, phishing-resistente Verfahren an: Sie stellen sicher, dass kryptografische Anmeldeantworten ausschließlich für den legitimen Dienst erzeugt werden können und nicht über einen Proxy weiterleitbar sind.

Phishing-resistente Authentifizierung als neue Kategorie

Die Analyse moderner Angriffsmuster führt zu einer zentralen Erkenntnis: Solange Anmeldeinformationen weiterleitbar sind, bleibt Authentifizierung grundsätzlich angreifbar. Genau an dieser Stelle etabliert sich eine neue Kategorie von Verfahren – phishing-resistente Authentifizierung.

Solche Verfahren schützen nicht nur ein Geheimnis vor Wiederverwendung. Sie stellen sicher, dass der gesamte Authentifizierungsvorgang kryptografisch an den legitimen Dienst gebunden ist. Eine Weiterleitung über Phishing-Proxies oder Adversary-in-the-Middle-Infrastrukturen verliert dadurch ihre Wirksamkeit.

Zu dieser Kategorie zählen insbesondere:

• FIDO2-Security-Keys
• Passkeys
• Windows Hello for Business

Der fundamentale Unterschied liegt im zugrunde liegenden kryptografischen Modell. Anstelle eines geteilten Geheimnisses verwenden diese Verfahren ein asymmetrisches Schlüsselpaar. Der private Schlüssel verbleibt auf dem Endgerät – idealerweise geschützt durch eine Hardware-Root-of-Trust wie ein Trusted Platform Module (TPM) oder eine vergleichbare Sicherheitskomponente. Der öffentliche Schlüssel wird beim Identitätsanbieter registriert.

Die eigentliche Anmeldung basiert anschließend auf einem Challenge-Response-Verfahren. Der Dienst stellt eine kryptografische Herausforderung, die ausschließlich mit dem privaten Schlüssel beantwortet werden kann. Da diese Signatur an den konkreten Dienst gebunden ist, lässt sie sich weder sinnvoll weiterleiten noch wiederverwenden.

Damit verschiebt sich die Architektur der Authentifizierung grundlegend: von einem wissensbasierten Modell hin zu einer schlüsselbasierten Identitätsprüfung. Nicht mehr das Wissen um ein Passwort legitimiert den Zugriff, sondern der Besitz eines geschützten privaten Schlüssels in Kombination mit einer lokalen Benutzerverifikation – etwa durch PIN oder Biometrie.

Genau dieser Architekturwechsel markiert den Übergang von stärkeren Passwörtern zu einer tatsächlich passwortlosen Authentifizierungsstrategie.

Einordnung im Zero-Trust-Kontext

Multi-Faktor-Authentifizierung stellt zweifellos einen erheblichen Sicherheitsgewinn dar. Durch die Kombination mehrerer unabhängiger Faktoren steigt die Hürde für Kontoübernahmen deutlich. Insbesondere gegen automatisierte Angriffe wie Credential Stuffing, einfache Phishing-Versuche oder massenhafte Passworttests wirkt MFA sehr effektiv.

Dennoch bleibt in vielen Implementierungen das Passwort weiterhin der primäre Identitätsanker. Der zusätzliche Faktor ergänzt das bestehende Modell, verändert jedoch nicht dessen grundlegende Struktur. Die Authentifizierung basiert weiterhin auf einem wiederverwendbaren Wissensmerkmal, das nach erfolgreicher Validierung zur Ausstellung eines Zugriffstokens führt.

Moderne Zero-Trust-Architekturen verfolgen jedoch einen weitergehenden Ansatz. Sie gehen davon aus, dass jedes Element einer Zugriffskette potenziell kompromittierbar ist – einschließlich Benutzerkonten, Geräte und Anmeldeinformationen. Ziel ist daher nicht nur die Reduktion einzelner Risiken, sondern die systematische Minimierung struktureller Angriffsflächen.

Ein wiederverwendbares Geheimnis steht diesem Ansatz grundsätzlich entgegen. Solange ein Passwort existiert, existiert auch ein übertragbares Authentifizierungsmerkmal, das abgefangen, weitergeleitet oder wiederverwendet werden kann.

Vor diesem Hintergrund verschiebt sich der strategische Fokus zunehmend: weg von Passwort plus zusätzlicher Schutzschicht hin zur Eliminierung des wiederholbaren Geheimnisses selbst. Genau an dieser Stelle beginnt die konsequente Weiterentwicklung moderner Identitätsarchitekturen – hin zu phishing-resistenter, passwortloser Authentifizierung.

Windows Hello for Business: Architektur einer passwortlosen Anmeldung

Nach der Analyse klassischer Passwörter und Multi-Faktor-Authentifizierung stellt sich eine zentrale Frage: Wie lässt sich eine Authentifizierungsarchitektur gestalten, die das wiederholbare Geheimnis konsequent eliminiert?

Genau an dieser Stelle setzt Windows Hello for Business an. Im Alltag wird der Begriff jedoch häufig verkürzt interpretiert. Manche verbinden damit lediglich die Anmeldung per PIN, andere denken vor allem an Gesichtserkennung oder Fingerabdrucksensoren. Tatsächlich verbirgt sich hinter Windows Hello for Business jedoch eine deutlich umfassendere Architektur: eine schlüsselbasierte Authentifizierung, die tief in die Identitätsplattform von Windows, Active Directory und Microsoft Entra ID integriert ist.

Im Kern ersetzt Windows Hello for Business das klassische Passwortmodell durch ein asymmetrisches Schlüsselpaar, das an ein konkretes Gerät gebunden ist und durch eine lokale Benutzerverifikation geschützt wird. Die Anmeldung erfolgt damit nicht mehr über ein übertragbares Geheimnis, sondern über eine kryptografische Identitätsbestätigung.

Dieses Kapitel verfolgt drei zentrale Ziele:

• Klare Abgrenzung zwischen Windows Hello, Komfort-PIN und Windows Hello for Business
• Technische Analyse des zugrunde liegenden kryptografischen Modells
• Einordnung in moderne Cloud-, Hybrid- und Zero-Trust-Architekturen

Neben der technischen Funktionsweise wird auch der praktische Ablauf einer Anmeldung betrachtet. Darüber hinaus werden typische Missverständnisse adressiert – insbesondere im Zusammenhang mit der Speicherung biometrischer Daten und der Rolle der lokalen PIN.

Ziel ist es, Windows Hello for Business nicht als Komfortfunktion für Benutzer:innen zu betrachten, sondern als strategische Sicherheitsarchitektur für passwortlose Identitäten.

Windows Hello, Komfort-PIN und Windows Hello for Business – eine saubere Abgrenzung

Bevor Windows Hello for Business architektonisch analysiert wird, ist eine klare begriffliche Abgrenzung notwendig. Im Windows-Umfeld existieren mehrere Konzepte, die im Alltag häufig miteinander verwechselt werden, obwohl sie unterschiedlichen Sicherheitsmodellen folgen.

Im Wesentlichen lassen sich drei Varianten unterscheiden:

• Windows Hello – biometrische oder PIN-basierte Anmeldung im Microsoft- oder Entra-Kontext
• Komfort-PIN – lokale PIN zur vereinfachten Eingabe eines Kennworts
• Windows Hello for Business – schlüsselbasierte Enterprise-Authentifizierung

Die Unterscheidung ist entscheidend, weil sich insbesondere das zugrunde liegende Vertrauensmodell deutlich unterscheidet.

Windows Hello – lokale Benutzerverifikation mit Cloud-Bindung

Der Begriff Windows Hello bezeichnet zunächst die lokale Benutzerverifikation in Windows 10 und Windows 11. Sie kann sowohl mit Microsoft-Konten als auch mit Microsoft Entra-gebundenen Konten eingesetzt werden.

Typische Verifikationsmethoden sind:

• PIN
• Fingerabdruck
• Gesichtserkennung über eine Infrarotkamera

Für einen sicheren Einsatz sind bestimmte Hardware- und Systemvoraussetzungen erforderlich. Dazu zählen insbesondere:

• ein Trusted Platform Module (TPM) 2.0 als hardwarebasierter Sicherheitsanker
• eine kompatible Windows-Hello-Infrarotkamera oder ein geeigneter Fingerabdrucksensor
• aktivierte Sicherheitsmechanismen wie Secure Boot und entsprechende Geräteschutzrichtlinien

Diese Komponenten stellen sicher, dass die lokale Benutzerverifikation nicht nur komfortabel, sondern auch kryptografisch abgesichert erfolgt.

Bei Verwendung eines Microsoft-Kontos läuft die Anmeldung vereinfacht wie folgt ab:

1. Während der Einrichtung erzeugt das Gerät ein kryptografisches Schlüsselpaar
2. Der private Schlüssel verbleibt lokal auf dem Gerät
3. Der öffentliche Schlüssel wird dem Microsoft-Konto zugeordnet
4. Bei der Anmeldung wird der Zugriff auf den privaten Schlüssel durch PIN oder Biometrie freigegeben
5. Das Gerät signiert eine Challenge des Microsoft-Dienstes
6. Die Cloud validiert die Signatur anhand des hinterlegten öffentlichen Schlüssels

Wichtig ist dabei: Die PIN wird niemals an Microsoft übertragen. Ebenso werden biometrische Daten ausschließlich lokal gespeichert. Windows speichert keine Gesichts- oder Fingerabdruckbilder in der Cloud. Stattdessen werden lediglich lokale mathematische Templates abgelegt, aus denen sich keine biometrischen Rohdaten rekonstruieren lassen.

Typische Befürchtungen wie „Mein Gesicht wird in der Cloud gespeichert“ oder „Mein Fingerabdruck liegt im Firmennetzwerk“ treffen daher nicht zu. Die biometrischen Informationen verlassen das Gerät nicht.

Komfort-PIN – vereinfachte Kennwortverwendung

Die sogenannte Komfort-PIN folgt einem grundlegend anderen Sicherheitsmodell. In diesem Szenario dient die PIN lediglich dazu, das lokal gespeicherte Kennwort freizugeben.

Der Ablauf entspricht weiterhin einer klassischen Passwortauthentifizierung:

1. Benutzer:innen geben eine lokale PIN ein
2. Windows entschlüsselt damit das gespeicherte Kennwort
3. Das Kennwort wird anschließend regulär an den Authentifizierungsdienst übertragen

Die PIN ersetzt hier lediglich die manuelle Eingabe des Passworts. Aus Sicht der Infrastruktur bleibt es ein kennwortbasierter Logon.

Die Komfort-PIN verbessert somit den Bedienkomfort, verändert jedoch nicht das Authentifizierungsmodell.

Warum diese Unterscheidung entscheidend ist

Die häufige Gleichsetzung von PIN-Anmeldung mit passwortloser Authentifizierung führt zu falschen Annahmen. Erst wenn ein asymmetrisches Schlüsselpaar erzeugt und serverseitig registriert wird, liegt ein tatsächlicher Architekturwechsel vor.

Genau diesen Schritt vollzieht Windows Hello for Business.

Windows Hello for Business – schlüsselbasierte Enterprise-Authentifizierung

Windows Hello for Business ersetzt das Passwort nicht durch eine PIN. Stattdessen wird ein kryptografisches Schlüsselpaar erzeugt, das an ein konkretes Gerät gebunden ist.

Die PIN oder biometrische Verifikation dient lediglich dazu, den Zugriff auf den privaten Schlüssel lokal freizugeben.

Die Initialisierung erfolgt typischerweise während der Gerätebereitstellung oder beim ersten Anmeldevorgang nach Richtlinienzuweisung – beispielsweise über Microsoft Intune oder Gruppenrichtlinien.

Der Ablauf lässt sich vereinfacht wie folgt beschreiben:

1. Nach einer initialen Anmeldung (z.B. mit Passwort oder temporären Anmeldeinformationen) wird Windows Hello for Business aktiviert
2. Das Gerät erzeugt ein eindeutiges asymmetrisches Schlüsselpaar
3. Der private Schlüssel verbleibt lokal und wird gegen Extraktion geschützt
4. Der öffentliche Schlüssel wird beim Identitätsanbieter registriert, etwa in Microsoft Entra ID oder im Active Directory

Ab diesem Zeitpunkt erfolgt die Authentifizierung nicht mehr über ein Passwort, sondern über ein gerätegebundenes kryptografisches Anmeldeverfahren.

Wichtig ist auch hier: Die PIN wird nicht beim Identitätsanbieter gespeichert. Sie fungiert ausschließlich als lokaler Entsperrmechanismus für den privaten Schlüssel.

Der Authentifizierungsvorgang im praktischen Betrieb

Bei einer späteren Anmeldung – sei es lokal am Gerät oder gegenüber einem Cloud-Dienst – unterscheidet sich der Ablauf grundlegend von einer klassischen Passwortauthentifizierung. Statt eines übertragbaren Geheimnisses kommt ein kryptografisches Challenge-Response-Verfahren zum Einsatz.

Der Anmeldeprozess lässt sich vereinfacht wie folgt darstellen:

1. Benutzer:innen verifizieren sich lokal per PIN, Fingerabdruck oder Gesichtserkennung
2. Dadurch wird der Zugriff auf den gerätegebundenen privaten Schlüssel freigegeben
3. Der Identitätsdienst sendet eine kryptografische Challenge an das Gerät
4. Das Gerät signiert diese Challenge mit dem privaten Schlüssel
5. Der Dienst überprüft die Signatur anhand des hinterlegten öffentlichen Schlüssels

Der entscheidende Unterschied zum Passwortmodell liegt in der kryptografischen Bindung des Vorgangs. Die erzeugte Signatur ist mathematisch an die konkrete Challenge und den Ziel-Dienst gebunden. Sie kann daher weder wiederverwendet noch über einen Proxy weitergeleitet werden.

Ein typischer Adversary-in-the-Middle-Angriff verliert damit seine Wirkung, da kein übertragbares Geheimnis existiert, das abgefangen werden könnte.

Windows Hello und insbesondere Windows Hello for Business unterscheiden sich damit fundamental von Passwort- oder Komfort-PIN-Modellen. Die Authentifizierung basiert nicht mehr auf dem Wissen um ein Geheimnis, sondern auf dem Besitz eines geschützten privaten Schlüssels, der zusätzlich durch eine lokale Benutzerverifikation freigegeben wird.

Im folgenden Abschnitt wird detailliert betrachtet, welche Rolle das Trusted Platform Module (TPM) als hardwarebasierter Sicherheitsanker in diesem Prozess spielt.

Die Rolle des Trusted Platform Module – Hardware als Vertrauensanker

Ein zentrales Element der Sicherheitsarchitektur von Windows Hello for Business ist das Trusted Platform Module (TPM). Es fungiert als hardwarebasierter Vertrauensanker und stellt sicher, dass kryptografisches Schlüsselmaterial nicht extrahiert oder manipuliert werden kann.

Didaktisch lässt sich die Funktionsweise gut mit einer Bankkarte vergleichen. Die Karte enthält die sicherheitsrelevanten Informationen zur Legitimation gegenüber der Bank. Die PIN selbst ist jedoch nicht die Legitimation – sie dient lediglich dazu, die Karte lokal freizuschalten. Erst anschließend führt die Karte eine kryptografische Operation aus, mit der die Bank die Identität prüft.

Übertragen auf Windows Hello for Business bedeutet das:

• Der private Schlüssel entspricht der Bankkarte
• Die PIN oder Biometrie entspricht der PIN am Geldautomaten
• Die eigentliche Legitimation erfolgt über eine kryptografische Signatur gegenüber dem Identitätsdienst

Die PIN wird dabei niemals übertragen und ist kein Netzwerk-Authentifizierungsmerkmal. Sie dient ausschließlich dazu, den Zugriff auf den im TPM geschützten privaten Schlüssel freizugeben.

Technische Sicherheitsmerkmale des TPM

Das TPM speichert den privaten Schlüssel hardwareisoliert innerhalb eines geschützten Sicherheitsmoduls. Der Schlüssel ist keine exportierbare Datei und nicht Bestandteil eines kopierbaren Containers.

Kryptografische Operationen – insbesondere Signaturen – werden direkt im TPM ausgeführt. Das Schlüsselmaterial verlässt das Modul zu keinem Zeitpunkt.

Diese Architektur schützt unter anderem vor:

• Credential-Theft-Tools
• Extraktion durch administrative Betriebssystemrechte
• Malware-Zugriff auf Prozessspeicher
• Speicher-Dumps

Selbst bei einer vollständigen Kompromittierung des Betriebssystems kann der private Schlüssel nicht ausgelesen oder auf ein anderes Gerät übertragen werden.

Zusätzlich unterstützt das TPM Integritätsmechanismen. In Kombination mit Secure Boot und weiteren Plattformschutzfunktionen kann überprüft werden, ob sich das System in einem vertrauenswürdigen Zustand befindet. Dadurch entsteht eine mehrschichtige Sicherheitsarchitektur aus Schlüsselisolierung und Geräteintegrität.

Der entscheidende Unterschied zum Passwortmodell liegt in der Nicht-Übertragbarkeit. Ein Passwort kann kopiert und beliebig wiederverwendet werden. Ein TPM-geschützter Schlüssel ist hingegen fest an das jeweilige Gerät gebunden.

TPM, fTPM, Intel PTT und vTPM – Varianten im Überblick

Nicht jedes Trusted Platform Module ist ein eigenständiger Sicherheitschip. In modernen Systemen existieren mehrere Implementierungsformen, die jedoch alle dasselbe Sicherheitsprinzip verfolgen: Die sichere, hardwaregebundene Speicherung kryptografischer Schlüssel.

Die wichtigsten Varianten lassen sich im Detail wie folgt unterscheiden.

Sicherheitsrelevanter Hinweis: Während diskrete TPMs eine physische Hardwaretrennung bieten, gelten moderne fTPM- und PTT-Implementierungen ebenfalls als sicherheitskonform für Windows 11 und Windows Hello for Business. In Virtualisierungsumgebungen hängt das tatsächliche Sicherheitsniveau zusätzlich vom Schutz des Hypervisors ab.

Sicherheitliche Konsequenz

Unabhängig von der konkreten Implementierungsform bleibt das zentrale Prinzip identisch: Der private Schlüssel ist hardwaregebunden und nicht exportierbar. Die PIN oder biometrische Verifikation dient ausschließlich als lokaler Entsperrmechanismus.

Selbst bei Kenntnis der PIN kann das Schlüsselmaterial nicht kopiert und auf einem anderen Gerät verwendet werden. Genau diese Eigenschaft macht Windows Hello for Business zu einer phishing-resistenten Authentifizierungsarchitektur.

Registrierung und Vertrauensmodell – wie Vertrauen technisch entsteht

Die eigentliche Sicherheitswirkung von Windows Hello for Business entsteht nicht allein durch die lokale Generierung eines Schlüsselpaares. Entscheidend ist vielmehr, wie dieser Schlüssel in die bestehende Identitätsinfrastruktur eingebunden wird.

Während der Ersteinrichtung wird der öffentliche Schlüssel des Geräts im Identitätsverzeichnis registriert. Je nach Architektur erfolgt diese Registrierung in unterschiedlichen Verzeichnisdiensten:

• Microsoft Entra ID (Cloud Trust)
• Active Directory im lokalen Netzwerk (Key Trust oder Certificate Trust)

Auf diese Weise entsteht eine eindeutige Zuordnung zwischen Benutzerkonto, Gerät und öffentlichem Schlüssel. Der Identitätsanbieter speichert dabei keinen Passwort-Hash mehr, sondern einen kryptografischen Verifikationsschlüssel.

Damit verändert sich das zugrunde liegende Vertrauensmodell grundlegend. Während beim klassischen Passwort die Kenntnis eines Geheimnisses überprüft wird, basiert die Authentifizierung hier auf einem kryptografischen Nachweis. Der Dienst prüft nicht mehr, ob ein Geheimnis korrekt übermittelt wurde, sondern ob das Gerät eine gültige Signatur mit dem registrierten privaten Schlüssel erzeugen kann.

Eine zusätzliche Sicherheitsdimension entsteht durch die Bindung des Schlüssels an ein konkretes Gerät. Selbst wenn ein Benutzerkonto kompromittiert wird, kann ein Angreifer dieses nicht ohne Weiteres auf einem anderen System verwenden. Dort existiert kein passendes Schlüsselpaar, und der private Schlüssel des ursprünglichen Geräts bleibt geschützt.

In der Praxis entsteht dadurch eine mehrschichtige Vertrauensstruktur:

• Identität ↔ öffentlicher Schlüssel
• Schlüssel ↔ konkretes Gerät
• Gerät ↔ definierter Vertrauenskontext

Diese Verknüpfung aus Identität, Gerät und kryptografischem Schlüssel bildet die Grundlage für die Integration von Windows Hello for Business in moderne Zero-Trust-Architekturen.

Cloud Trust, Key Trust, Kerberos Trust und Certificate Trust – Vertrauensmodelle im Vergleich

Windows Hello for Business unterstützt mehrere Vertrauensmodelle. Diese unterscheiden sich nicht im kryptografischen Grundprinzip der Authentifizierung, sondern in der Art, wie der öffentliche Schlüssel in die Identitätsinfrastruktur eingebunden wird und wie Zugriffstoken oder Kerberos-Tickets ausgestellt werden.

Die Wahl des geeigneten Modells hängt maßgeblich von der vorhandenen Architektur ab – etwa davon, ob eine Umgebung Cloud-only, hybrid oder rein On-Premises betrieben wird.

Cloud Trust

Beim Cloud-Trust-Modell wird der öffentliche Schlüssel direkt in Microsoft Entra ID registriert. Die Authentifizierung erfolgt primär cloudbasiert. In hybriden Szenarien kann Entra ID zusätzlich Kerberos-Tickets für lokale Ressourcen bereitstellen, ohne dass eine klassische Zertifikatsinfrastruktur erforderlich ist.

Cloud Trust zeichnet sich durch folgende Eigenschaften aus:

• keine eigene PKI erforderlich
• geringe Implementierungskomplexität
• enge Integration mit Microsoft Intune und Entra ID
• geeignet für Entra-joined und hybrid-joined Geräte

In modernen Microsoft-365-Architekturen gilt Cloud Trust heute häufig als das empfohlene Standardmodell, da es eine relativ einfache Implementierung mit hoher Sicherheit kombiniert.

Kerberos Trust (Hybrid Cloud Kerberos Trust)

Der sogenannte Kerberos Trust, genauer Hybrid Cloud Kerberos Trust, adressiert hybride Umgebungen, in denen weiterhin klassische Active-Directory-Ressourcen genutzt werden.

Technisch erfolgt die Schlüsselregistrierung in Microsoft Entra ID. Zusätzlich wird ein Azure AD Kerberos Server eingerichtet, der Kerberos-Tickets für On-Premises-Domänenressourcen ausstellen kann. Dadurch können sich Benutzer:innen mittels Windows Hello for Business sowohl gegenüber Cloud-Diensten als auch gegenüber klassischen Domänenressourcen authentifizieren – ohne dass Benutzerzertifikate ausgerollt werden müssen.

Der wesentliche Vorteil liegt in der reduzierten Infrastrukturkomplexität gegenüber dem Certificate-Trust-Modell. Da keine vollständige Zertifikatsinfrastruktur erforderlich ist, lässt sich das Verfahren deutlich einfacher implementieren und betreiben. Gleichzeitig bleibt die bestehende Kerberos-basierte Zugriffskontrolle für Active-Directory-Ressourcen vollständig erhalten.

Für Administrator:innen, die dieses Modell praktisch implementieren möchten, bietet Julian Stabentheiner eine sehr strukturierte mehrteilige Anleitung zur Umsetzung von Hybrid Cloud Kerberos Trust. In seinem Blogbeitrag werden sowohl die zugrunde liegende Architektur als auch die einzelnen Implementierungsschritte detailliert erläutert. Besonders für hybride Microsoft-365-Umgebungen stellt diese Anleitung eine hilfreiche praktische Ergänzung zur konzeptionellen Betrachtung dar.

Key Trust

Beim Key-Trust-Modell wird der öffentliche Schlüssel des Benutzerkontos direkt im Active Directory gespeichert. Die Authentifizierung erfolgt anschließend gegenüber Domänencontrollern auf Basis dieses hinterlegten Schlüssels.

Typische Einsatzszenarien sind:

• klassische Active-Directory-Domänenumgebungen
• hybride Infrastrukturen mit starkem On-Premises-Fokus
• Organisationen mit bestehender Zertifikatsinfrastruktur

Im Hybridbetrieb wird der Schlüssel sowohl in Entra ID als auch im Active Directory berücksichtigt. Der Zugriff auf Domänenressourcen erfolgt weiterhin primär über lokale Domänencontroller.

Auch wenn kein klassisches Smartcard-Zertifikat ausgerollt wird, basiert dieses Modell intern auf PKI-Mechanismen innerhalb der Active-Directory-Umgebung. Eine funktionierende Zertifikatsinfrastruktur ist daher in der Praxis meist Voraussetzung.

Im Vergleich zu Cloud Trust oder Kerberos Trust ist Key Trust stärker an die traditionelle AD-Architektur gebunden und mit höherem Infrastrukturaufwand verbunden. Strategisch wird es heute häufig als Übergangsmodell für bestehende Umgebungen betrachtet.

Certificate Trust

Das Certificate-Trust-Modell ist die klassische und zugleich infrastrukturell anspruchsvollste Variante von Windows Hello for Business.

Hier wird das erzeugte Schlüsselpaar in eine vollständige Public Key Infrastructure (PKI) eingebunden. Für das Benutzerkonto wird ein Zertifikat ausgestellt, dessen öffentlicher Schlüssel zur Authentifizierung verwendet wird.

Die Anmeldung funktioniert damit ähnlich wie bei einer Smartcard-basierten Authentifizierung:

• das Zertifikat dient als Authentifizierungsnachweis
• die PIN oder Biometrie ersetzt die klassische Smartcard-PIN
• der Domänencontroller validiert das Zertifikat und stellt ein Kerberos-Ticket aus

Certificate Trust ist insbesondere relevant in Umgebungen mit:

• bestehender Smartcard-Infrastruktur
• regulatorischen Anforderungen an zertifikatsbasierte Authentifizierung
• komplexen PKI-Landschaften
• hohen Compliance- oder Audit-Anforderungen

Der infrastrukturelle Aufwand ist jedoch deutlich höher als bei anderen Modellen. Zu berücksichtigen sind unter anderem:

• Betrieb und Absicherung einer internen Zertifizierungsstelle
• Zertifikatsausstellung und -erneuerung
• Verwaltung von Sperrlisten (CRL) oder OCSP
• vollständiges Zertifikats-Lifecycle-Management

Aus diesem Grund gilt Certificate Trust zwar als technisch sehr robust, wird in modernen Hybridarchitekturen jedoch häufig durch Cloud Trust oder Hybrid Cloud Kerberos Trust ersetzt, sofern keine regulatorischen Anforderungen eine zertifikatsbasierte Lösung zwingend erfordern.

Strategische Einordnung – Architekturentscheidung statt Komfortfunktion

In der Praxis lässt sich eine klare Entwicklung beobachten: Viele Organisationen orientieren sich zunehmend an den Modellen Cloud Trust und Hybrid Cloud Kerberos Trust. Beide Varianten integrieren sich nahtlos in moderne Microsoft-365-Architekturen und reduzieren die betriebliche Komplexität gegenüber klassischen PKI- und Zertifikatsszenarien erheblich.

Der strategische Vorteil liegt jedoch nicht allein in der Vereinfachung der Infrastruktur. Entscheidender ist der zugrunde liegende Architekturwechsel. Während Certificate Trust und Key Trust historisch aus Smartcard- und PKI-basierten Sicherheitsmodellen entstanden sind, ermöglichen Cloud-basierte Trust-Modelle eine konsistente Identitätsstrategie über Cloud- und Hybridumgebungen hinweg.

Unabhängig vom gewählten Vertrauensmodell bleibt dabei das sicherheitstechnische Fundament identisch: Die Authentifizierung basiert auf einem asymmetrischen, gerätegebundenen Schlüsselpaar. Es existiert kein übertragbares Passwort, kein synchronisierter Hash und kein wiederverwendbares Geheimnis.

Damit adressiert Windows Hello for Business zentrale Anforderungen moderner Zero-Trust-Architekturen:

• Minimierung wiederverwendbarer Anmeldeinformationen
• Gerätebindung der Identität
• Schutz vor Phishing- und Replay-Angriffen
• Reduktion passwortbasierter Angriffsflächen

Windows Hello for Business ist damit nicht lediglich eine komfortablere Anmeldung per PIN oder Biometrie. Vielmehr handelt es sich um eine strukturelle Weiterentwicklung des Authentifizierungsmodells, die sowohl in Cloud-only- als auch in hybriden Infrastrukturen eine passwortlose Identitätsstrategie ermöglicht.

Passkeys – Standardisierte, plattformübergreifende schlüsselbasierte Authentifizierung

Während Windows Hello for Business eine tief in die Microsoft-Identitätsplattform integrierte Enterprise-Architektur darstellt, verfolgen Passkeys einen deutlich breiteren Ansatz. Sie basieren auf offenen Standards wie FIDO2 und WebAuthn und sind nicht an ein einzelnes Betriebssystem oder eine spezifische Identitätsplattform gebunden.

Passkeys sind damit keine völlig neue Authentifizierungsidee. Vielmehr handelt es sich um eine Standardisierung phishing-resistenter, asymmetrischer Authentifizierung für Web- und Cloud-Dienste.

Das grundlegende Sicherheitsprinzip entspricht dem bereits beschriebenen Modell:

• Ein asymmetrisches Schlüsselpaar wird erzeugt
• Der private Schlüssel verbleibt auf dem Gerät
• Der öffentliche Schlüssel wird beim Dienst registriert
• Die Anmeldung erfolgt über ein Challenge-Response-Verfahren

Der entscheidende Unterschied liegt jedoch in der Interoperabilität. Passkeys sind nicht an ein einzelnes Betriebssystem oder einen bestimmten Anbieter gebunden, sondern funktionieren plattformübergreifend. Moderne Betriebssysteme wie Windows, macOS, iOS und Android unterstützen Passkeys ebenso wie aktuelle Browserumgebungen.

Dadurch können sich Benutzer:innen mit demselben kryptografischen Prinzip bei unterschiedlichsten Webdiensten und Cloudplattformen authentifizieren – unabhängig davon, welches Gerät oder Betriebssystem sie verwenden.

Diese Plattformunabhängigkeit markiert einen wichtigen Entwicklungsschritt. Während Smartcards oder proprietäre Enterprise-Lösungen häufig an spezifische Infrastrukturen gebunden waren, etabliert sich mit Passkeys ein offener, internetweiter Authentifizierungsstandard.

Im Kern wird damit ein bewährtes Sicherheitsprinzip aus Hochsicherheitsumgebungen – ein hardwaregeschützter privater Schlüssel in Kombination mit einem serverseitig hinterlegten öffentlichen Schlüssel – für den breiten Web- und Cloud-Kontext verfügbar gemacht.

Passkeys übertragen somit das Konzept asymmetrischer Authentifizierung aus spezialisierten Enterprise-Szenarien in eine globale, plattformübergreifende Identitätsarchitektur.

Technische Grundlage: FIDO2 und WebAuthn

Passkeys basieren auf offenen, standardisierten Protokollen, die unter dem Begriff FIDO2 zusammengefasst werden. Diese Standards werden von der FIDO Alliance (Fast IDentity Online) in Zusammenarbeit mit dem World Wide Web Consortium (W3C) entwickelt und ermöglichen eine sichere, passwortlose Authentifizierung im Web.

FIDO2 ist dabei kein einzelnes Protokoll, sondern ein Zusammenspiel mehrerer Spezifikationen, die unterschiedliche Ebenen der Authentifizierung abdecken.

Eine zentrale Rolle spielt WebAuthn (Web Authentication API). Dieser Standard definiert die Schnittstelle zwischen einer Webanwendung – der sogenannten Relying Party – und dem Authentifikator auf dem Endgerät. Über WebAuthn wird gesteuert, wie kryptografische Schlüssel registriert, Herausforderungen übermittelt und Signaturen überprüft werden.

Ergänzend dazu kommt das Client to Authenticator Protocol (CTAP) zum Einsatz. CTAP regelt die Kommunikation zwischen dem Client-System – etwa einem Browser oder Betriebssystem – und dem eigentlichen Authentifikator, der die kryptografischen Operationen ausführt.

Der Authentifikator kann unterschiedlich implementiert sein. Möglich sind beispielsweise:

• plattformgebundene Authentifikatoren, etwa ein Trusted Platform Module (TPM), eine Secure Enclave oder Android StrongBox
• externe Hardware-Security-Keys, die über USB, NFC oder Bluetooth angebunden werden

Architektonisch entscheidend ist dabei die Bindung jedes Schlüssels an eine konkrete Relying Party. Der erzeugte Schlüssel ist domain-spezifisch und kann nicht für andere Dienste verwendet werden.

Selbst wenn eine Phishing-Seite als Proxy zwischengeschaltet wird, kann eine erzeugte Signatur nicht sinnvoll weitergeleitet oder wiederverwendet werden. Die kryptografische Antwort ist an die ursprüngliche Domain gebunden.

Damit erfüllen Passkeys die Anforderungen phishing-resistenter Authentifizierung nicht durch zusätzliche Schutzmechanismen, sondern bereits auf Protokollebene. Das Sicherheitsmodell verhindert strukturell klassische Angriffsszenarien wie Weiterleitung, Replay oder Credential Theft.

Plattformintegration und Synchronisierung

Ein zentraler Unterschied zwischen Windows Hello for Business und Passkeys liegt im jeweiligen Synchronisierungsmodell und damit in der zugrunde liegenden Vertrauensarchitektur.

Windows Hello for Business verfolgt einen konsequent gerätegebundenen Ansatz. Das asymmetrische Schlüsselpaar wird auf dem jeweiligen Gerät erzeugt, und der private Schlüssel verbleibt dauerhaft im Trusted Platform Module. Eine automatische Synchronisierung auf andere Geräte findet nicht statt.

Dieses Modell ist klar auf Enterprise-Umgebungen ausgerichtet und ermöglicht eine enge Kopplung zwischen Identität, Gerät und geprüftem Gerätezustand.

Passkeys verfolgen dagegen – abhängig von Plattform und Implementierung – einen synchronisierten Ansatz. Viele Plattformen ermöglichen eine verschlüsselte Replikation von Passkeys innerhalb eines Benutzerökosystems. Beispiele sind:

• Google Password Manager im Android- und Chrome-Kontext
• iCloud Keychain im Apple-Ökosystem
• Microsoft Authenticator Microsoft-Konto-basierte Passkey-Synchronisierung

Der private Schlüssel bleibt dabei weiterhin hardwaregeschützt, wird jedoch zusätzlich verschlüsselt innerhalb des Plattformkontos synchronisiert, sodass derselbe Passkey auf mehreren Geräten verwendet werden kann.

Damit erweitert sich das Vertrauensmodell. Neben der Sicherheit des einzelnen Geräts spielt nun auch die Sicherheit des Synchronisierungsdienstes eine zentrale Rolle. Mechanismen wie Ende-zu-Ende-Verschlüsselung, gerätegebundene Freigaben und eine starke Absicherung des Plattformkontos sind deshalb entscheidend.

Dieses Modell erhöht den Benutzerkomfort erheblich und erleichtert die Nutzung über mehrere Geräte hinweg – insbesondere im Consumer- und BYOD-Kontext. Gleichzeitig entstehen neue strategische Fragestellungen, etwa in Bezug auf:

• Abhängigkeiten von Plattformanbietern
• Kontrolle über Synchronisierungsdienste
• Schlüsselverwaltung über mehrere Geräte
• Wiederherstellungsmechanismen bei Geräteverlust

Organisationen müssen daher bewusst entscheiden, in welchen Szenarien ein gerätegebundenes Enterprise-Modell wie Windows Hello for Business sinnvoll ist und wo plattformübergreifend synchronisierte Passkeys einen praktischen Vorteil bieten.

Passkeys im Enterprise-Umfeld

Passkeys sind längst nicht mehr ausschließlich ein Consumer-Thema. In modernen Identitätsarchitekturen lassen sie sich zunehmend auch im Unternehmenskontext einsetzen. In Microsoft Entra ID können beispielsweise sowohl externe FIDO2-Sicherheitsschlüssel als auch plattformgebundene Passkeys als Authentifizierungsmethode registriert werden. Die Anmeldung erfolgt anschließend über das standardisierte FIDO2- und WebAuthn-Verfahren, ohne dass ein Passwort erforderlich ist.

Im praktischen Enterprise-Kontext eignen sich Passkeys insbesondere für webbasierte Anwendungen und Cloud-Dienste. SaaS-Plattformen, moderne Webportale oder Partnerzugänge profitieren von der standardisierten Unterstützung in aktuellen Browsern und Betriebssystemen. Auch für externe Benutzerkonten, Gastzugriffe oder Business-to-Business-Szenarien bieten Passkeys eine robuste und phishing-resistente Alternative zum klassischen Kennwortmodell.

Darüber hinaus spielen Passkeys eine wichtige Rolle in BYOD-Umgebungen. Wenn Endgeräte nicht vollständig durch die Organisation kontrolliert werden, können plattformintegrierte Sicherheitsmodule wie Secure Enclave, Android StrongBox oder ein Trusted Platform Module (TPM) dennoch ein hohes Sicherheitsniveau gewährleisten. Die Authentifizierung bleibt hardwaregebunden und kryptografisch abgesichert, selbst wenn das Gerät nicht in eine Unternehmensdomäne eingebunden ist.

Im Vergleich zu Windows Hello for Business sind Passkeys stärker standardisiert und plattformübergreifend ausgerichtet. Sie integrieren sich nahtlos in moderne Web- und Cloud-Architekturen, sind jedoch weniger tief in klassische Kerberos- oder Active-Directory-Strukturen eingebunden.

Während Windows Hello for Business insbesondere domänenbasierte und hybride Enterprise-Szenarien adressiert, fokussieren Passkeys primär internetbasierte Authentifizierungsmodelle.

Beide Ansätze verfolgen jedoch dasselbe sicherheitstechnische Ziel: die Eliminierung wiederverwendbarer Geheimnisse. Der wesentliche Unterschied liegt weniger im kryptografischen Fundament als im jeweiligen Integrationskontext und Vertrauensmodell.

Vergleich: Windows Hello for Business und Passkeys

Nach der technischen Analyse beider Verfahren stellt sich eine zentrale Frage: Wo liegen die praktischen Unterschiede im Architektur- und Einsatzkontext?

Sowohl Windows Hello for Business als auch Passkeys basieren auf asymmetrischer Kryptografie, eliminieren das wiederverwendbare Passwort und gelten als phishing-resistente Authentifizierungsverfahren. Beide ersetzen das klassische Wissensgeheimnis durch ein gerätegebundenes Schlüsselpaar, dessen private Komponente das Endgerät nicht verlässt.

Trotz dieser gemeinsamen Grundlage verfolgen beide Ansätze unterschiedliche Integrationsstrategien und adressieren unterschiedliche Zielumgebungen.

Windows Hello for Business ist primär auf Enterprise-Identitätsarchitekturen ausgerichtet. Es integriert sich tief in Active Directory, hybride Infrastrukturen und Microsoft Entra ID und unterstützt domänenbasierte sowie gerätegebundene Authentifizierungsszenarien.

Passkeys hingegen sind plattformübergreifend standardisiert und orientieren sich stärker an Web- und Cloud-Authentifizierungsmodellen. Sie basieren auf offenen Standards wie FIDO2 und WebAuthn und lassen sich unabhängig vom Betriebssystem oder Anbieter einsetzen.

Der folgende Vergleich stellt beide Ansätze systematisch gegenüber:

Beide Verfahren verfolgen dasselbe sicherheitstechnische Ziel: Sie ersetzen das wiederverwendbare, übertragbare Passwort durch ein gerätegebundenes asymmetrisches Schlüsselpaar. Die Authentifizierung erfolgt nicht mehr über ein geteiltes Geheimnis, sondern über kryptografische Signaturen, die an den jeweiligen Dienst gebunden sind. Dadurch sind sowohl Windows Hello for Business als auch Passkeys strukturell phishing-resistent.

Die Unterschiede liegen daher weniger im kryptografischen Fundament als im architektonischen Integrationskontext. Windows Hello for Business ist tief in Enterprise-Identitätsinfrastrukturen eingebettet und adressiert insbesondere domänenbasierte und hybride Szenarien. Passkeys hingegen sind stärker standardisiert, plattformübergreifend ausgerichtet und besonders für internetbasierte Authentifizierungsmodelle optimiert.

Die Wahl zwischen beiden Ansätzen ist somit keine Frage der grundsätzlichen Sicherheit, sondern der strategischen Passung zur jeweiligen Identitäts- und Infrastrukturarchitektur.

Strategische Perspektive

Passkeys markieren einen entscheidenden Entwicklungsschritt in der Standardisierung passwortloser Authentifizierung. Während Windows Hello for Business primär im Enterprise-Umfeld verankert ist und hybride Identitätsarchitekturen adressiert, übertragen Passkeys dasselbe sicherheitstechnische Prinzip in den globalen Web- und Cloud-Kontext.

Damit entsteht erstmals ein plattformübergreifend akzeptierter Standard für asymmetrische, phishing-resistente Authentifizierung im Internetmaßstab.

Beide Ansätze stehen dabei nicht in Konkurrenz, sondern ergänzen sich strategisch. Windows Hello for Business stärkt die Identität innerhalb kontrollierter Unternehmensumgebungen mit klar definierten Vertrauensmodellen. Passkeys ermöglichen eine konsistente, standardisierte Umsetzung desselben kryptografischen Prinzips über Betriebssystem-, Geräte- und Anbietergrenzen hinweg.

Gemeinsam zeigen beide Technologien eine klare technologische Entwicklung: Das wiederholbare, übertragbare Passwort ist ein Relikt historischer Systemarchitekturen. Es lässt sich durch Komplexitätsregeln, Passwortrotation oder Multifaktor-Verfahren zwar absichern – strukturell lösen lassen sich die zugrunde liegenden Probleme damit jedoch nicht.

Die Zukunft der Authentifizierung liegt in schlüsselbasierter, hardwaregestützter Identität. Sie basiert auf kryptografisch gebundenen Geräten, überprüfbarer Geräteintegrität und Protokollen, die Phishing, Credential-Theft und Weiterleitungsangriffe bereits auf architektonischer Ebene verhindern.

Die zentrale Frage lautet daher nicht mehr, ob passwortlose Authentifizierung zum Standard wird – sondern wie schnell Organisationen ihre Identitätsarchitektur auf diese Realität ausrichten.

Vergleich der Authentifizierungsmodelle – Von Passwort bis Passkey

Nach der technischen Analyse der einzelnen Verfahren stellt sich eine übergeordnete Frage: Wie lassen sich die verschiedenen Authentifizierungsmodelle strategisch einordnen – nicht isoliert betrachtet, sondern im Kontext moderner Cloud- und Zero-Trust-Architekturen?

Die Diskussion um Anmeldesicherheit darf sich dabei nicht auf technische Detailaspekte beschränken. Entscheidend ist vielmehr, welches Sicherheitsprinzip einem Verfahren zugrunde liegt, welche strukturellen Schwächen bestehen und wie gut sich ein Modell in bestehende Identitäts- und Infrastrukturarchitekturen integrieren lässt.

Dabei geht es nicht um ein einfaches besser oder schlechter. Jedes Authentifizierungsmodell entstand in einem bestimmten historischen und technologischen Kontext. Das Passwort adressierte ursprünglich geschlossene, kontrollierte Systeme. Multi-Faktor-Authentifizierung reagierte auf zunehmende Vernetzung und wachsende Bedrohungsszenarien. Hardwaregestützte Schlüsselverfahren wiederum sind eine Antwort auf global skalierbare Phishing-, Proxy- und Token-Angriffe.

Für eine fundierte Bewertung müssen daher mehrere Kriterien berücksichtigt werden:

• Existiert ein wiederverwendbares Geheimnis?
• Besteht eine Bindung an ein konkretes Gerät?
• Ist das Verfahren phishing-resistent?
• Welche infrastrukturellen Abhängigkeiten entstehen?
• Wie hoch sind Integrations- und Betriebsaufwand?

Erst auf dieser Grundlage lässt sich beurteilen, welches Authentifizierungsmodell in welcher Architektur sinnvoll eingesetzt werden kann – und an welchen Stellen das klassische Passwortmodell an seine strukturellen Grenzen stößt.

Im folgenden Abschnitt werden die wichtigsten Authentifizierungsverfahren systematisch eingeordnet und miteinander verglichen.

Passwort

Das klassische Passwortmodell ist einfach implementierbar, weit verbreitet und nahezu universell kompatibel. Es benötigt weder spezielle Hardware noch zusätzliche Infrastruktur. Genau diese Eigenschaften haben dazu geführt, dass Passwörter bis heute in nahezu jedem IT-System eingesetzt werden.

Sicherheitstechnisch basiert das Modell jedoch auf einem grundlegenden Prinzip: einem wiederverwendbaren, übertragbaren Geheimnis, das sowohl gespeichert als auch über Netzwerke übertragen werden kann. Dieses Design war für frühe, abgeschlossene Systemumgebungen ausreichend, stößt jedoch in heutigen, global vernetzten Identitätsarchitekturen zunehmend an seine Grenzen.

Passwörter besitzen keine Gerätebindung und bieten keine Möglichkeit zur kryptografischen Integritätsprüfung des anfragenden Systems. Selbst bei modernen Sicherheitsrichtlinien – etwa komplexen Passwortregeln oder regelmäßiger Rotation – bleibt das zugrunde liegende Authentifizierungsmodell anfällig für typische Angriffsmethoden wie Phishing, Credential Stuffing oder Token-Diebstahl nach erfolgreicher Anmeldung.

Die strukturellen Schwächen liegen daher weniger in der Implementierung als im grundlegenden Sicherheitsprinzip selbst.

⚠ Nachteil

Strukturell angreifbares Authentifizierungsmodell auf Basis eines wiederverwendbaren Geheimnisses

Passwort plus Multi-Faktor-Authentifizierung

Die Kombination aus Passwort und Multi-Faktor-Authentifizierung (MFA) reduziert das Risiko erfolgreicher Kontoübernahmen erheblich. Insbesondere gegen automatisierte Angriffe wie Credential Stuffing oder einfache Passwortkompromittierungen stellt ein zusätzlicher Faktor eine wirksame Sicherheitsbarriere dar. Die Eintrittswahrscheinlichkeit erfolgreicher Angriffe sinkt deutlich, während der notwendige Angriffsaufwand steigt.

Gleichzeitig bleibt jedoch in vielen Implementierungen das Passwort der primäre Identitätsanker. Der zweite Faktor ergänzt das bestehende Modell, ersetzt es jedoch nicht. Die Authentifizierung basiert weiterhin auf einem wiederverwendbaren Geheimnis, das übertragen und abgefangen werden kann.

In modernen Adversary-in-the-Middle-Phishing-Szenarien können selbst MFA-Mechanismen umgangen werden, wenn der zweite Faktor nicht kryptografisch an den legitimen Dienst gebunden ist. Angreifer leiten den gesamten Anmeldeprozess über einen Proxy weiter und erhalten nach erfolgreicher Anmeldung ein gültiges Sitzungstoken.

⚠ Nachteil

Das wiederverwendbare Geheimnis bleibt bestehen und kann in Proxy-Phishing-Szenarien weiterhin ausgenutzt werden

FIDO2-Sicherheitsschlüssel

Hardwarebasierte FIDO2-Sicherheitsschlüssel ermöglichen eine phishing-resistente Authentifizierung auf Basis asymmetrischer Kryptografie. Der private Schlüssel wird innerhalb des Sicherheitsmoduls des Tokens erzeugt und verlässt dieses niemals. Die Authentifizierung erfolgt über ein Challenge-Response-Verfahren, bei dem jede kryptografische Antwort an die konkrete Relying Party (Domain) gebunden ist.

Damit sind klassische Phishing-Angriffe, Proxy-Weiterleitungen oder Credential-Theft-Szenarien strukturell deutlich erschwert. Hardware-Security-Keys gelten daher als besonders robuste Authentifizierungsform und werden häufig für hochprivilegierte Konten, Administratorzugänge oder besonders schützenswerte Systeme eingesetzt.

Der praktische Einsatz bringt jedoch organisatorische Anforderungen mit sich. Organisationen müssen Prozesse für Beschaffung, Ausgabe, Ersatzgeräte, Verlustmanagement und Wiederherstellung definieren. Gerade in großen Umgebungen kann der physische Umgang mit Hardware-Token zusätzlichen Verwaltungsaufwand verursachen.

⚠ Nachteil

Zusätzlicher organisatorischer Aufwand für Beschaffung, Verwaltung und Verlustmanagement der Hardware-Tokens

Windows Hello for Business

Windows Hello for Business integriert asymmetrische Authentifizierung tief in moderne Enterprise-Identitätsarchitekturen. Bei der Registrierung wird ein gerätegebundenes Schlüsselpaar erzeugt, dessen privater Schlüssel durch ein Trusted Platform Module (TPM) geschützt ist. Die Authentifizierung erfolgt anschließend über kryptografische Signaturen, die gegenüber dem Identitätsdienst – etwa Active Directory oder Microsoft Entra ID – validiert werden.

Durch die Kombination aus gerätegebundenem Schlüssel, hardwarebasierter Schlüsselisolierung und Verzeichnisintegration entsteht eine robuste Sicherheitsarchitektur. Das Verfahren ist phishing-resistent und ermöglicht eine konsequente Abkehr vom klassischen Passwortmodell innerhalb kontrollierter Unternehmensumgebungen.

Windows Hello for Business eignet sich besonders für hybride Microsoft-Infrastrukturen, in denen sowohl Cloud- als auch Domänenressourcen genutzt werden. Die Integration in bestehende Identitätsdienste sowie die Unterstützung verschiedener Trust-Modelle ermöglichen eine schrittweise Migration von passwortbasierter zu schlüsselbasierter Authentifizierung.

⚠ Nachteil

Stärker an Microsoft-Plattformen und Enterprise-Infrastrukturen gebunden

Passkeys

Passkeys übertragen das FIDO2-Prinzip in einen plattformübergreifend standardisierten Authentifizierungsmechanismus. Sie basieren auf offenen Standards wie FIDO2 und WebAuthn und funktionieren direkt in modernen Browsern, mobilen Betriebssystemen und Cloud-Diensten – ohne proprietäre Abhängigkeit von einer einzelnen Plattform oder Infrastruktur.

Der private Schlüssel verbleibt dabei im Sicherheitsmodul des jeweiligen Geräts, während der öffentliche Schlüssel beim Dienst registriert wird. Die Authentifizierung erfolgt über ein Challenge-Response-Verfahren, das kryptografisch an die jeweilige Domain gebunden ist und damit strukturell phishing-resistent ist.

Die besondere Stärke von Passkeys liegt in ihrer Standardisierung und Interoperabilität. Sie ermöglichen passwortlose Authentifizierung über Betriebssystem- und Anbietergrenzen hinweg und lassen sich sowohl in Consumer- als auch in Cloud-basierten Unternehmensumgebungen einsetzen.

Bei plattformübergreifenden Synchronisationsmodellen entsteht jedoch eine zusätzliche Vertrauensebene: das jeweilige Plattform-Ökosystem, über das Passkeys zwischen Geräten repliziert werden können.

⚠ Nachteil

Geringere Integrationstiefe in klassischen Active-Directory- und Kerberos-basierten Infrastrukturen

Zusammenführung der Bewertung und Übergang zur Architekturtransformation

Die Betrachtung der unterschiedlichen Authentifizierungsmodelle zeigt deutlich, dass sich die Diskussion nicht auf Komfort oder Implementierungsaufwand reduzieren lässt. Im Kern geht es um das zugrunde liegende Sicherheitsprinzip.

Das klassische Passwort basiert auf einem wiederverwendbaren Geheimnis. Multi-Faktor-Authentifizierung reduziert zwar das Risiko erfolgreicher Angriffe, verändert jedoch häufig nicht die strukturelle Grundlage des Modells. Das Passwort bleibt weiterhin zentraler Bestandteil der Authentifizierung.

Phishing-resistente Verfahren wie FIDO2-Sicherheitsschlüssel, Windows Hello for Business oder Passkeys verfolgen einen anderen Ansatz. Sie eliminieren das geteilte Geheimnis vollständig und ersetzen es durch gerätegebundene, asymmetrische Kryptografie.

Damit verschiebt sich die Sicherheitsarchitektur grundlegend: von wissensbasierter Legitimation hin zu schlüsselbasierter Identität mit hardwaregestützter Vertrauenskette. Der entscheidende Unterschied liegt nicht in der Anzahl der Faktoren, sondern in der Natur des Authentifizierungsmerkmals.

Strategisch ergibt sich daraus eine klare Konsequenz. Die Frage ist nicht mehr, ob Multi-Faktor-Authentifizierung eingesetzt werden sollte – sie ist inzwischen Mindeststandard moderner Identitätsarchitekturen. Die eigentliche Herausforderung besteht darin, den Übergang von einem passwortzentrierten Modell hin zu einer strukturell passwortlosen Architektur zu gestalten.

Genau an diesem Punkt setzt das folgende Kapitel an. Es betrachtet nicht mehr das Ob, sondern das Wie – und skizziert einen realistischen Weg zur Transformation moderner Identitätsarchitekturen.

Migrationsstrategie – Der Weg zur passwortlosen Architektur

Die Ablösung des Passworts erfolgt in der Praxis nicht abrupt, sondern schrittweise. In gewachsenen IT-Landschaften existieren zahlreiche Abhängigkeiten, Legacy-Anwendungen und organisatorische Rahmenbedingungen, die eine sofortige Eliminierung klassischer Anmeldeverfahren unrealistisch machen. Identitätsarchitekturen sind historisch gewachsen und eng mit Geschäftsprozessen, Compliance-Vorgaben und Benutzergewohnheiten verknüpft.

Eine passwortlose Strategie ist daher kein einzelnes Projekt, sondern eine kontrollierte Architekturtransformation. Sie erfordert technische Vorbereitung, Anpassungen von Richtlinien, organisatorische Begleitmaßnahmen und eine klare Priorisierung der relevanten Risiken. Gleichzeitig darf die Sicherheit während der Übergangsphase nicht geschwächt werden. Ziel ist es nicht, Passwörter möglichst schnell zu entfernen, sondern ihre Bedeutung im Authentifizierungsprozess systematisch zu reduzieren.

In der Praxis folgt eine erfolgreiche Migration meist einem mehrstufigen Vorgehensmodell. Zunächst wird das bestehende Risiko durch eine konsequente Einführung von Multi-Faktor-Authentifizierung reduziert. Anschließend werden phishing-resistente Verfahren schrittweise eingeführt und priorisiert. In einem weiteren Schritt verlieren Passwörter zunehmend ihre operative Bedeutung, bis sie – soweit technisch möglich – vollständig deaktiviert werden können. Parallel dazu wird das Gerätevertrauen stärker in die Zugriffskontrolle integriert.

Diese vier Schritte bilden einen realistischen und strategisch tragfähigen Rahmen für den Übergang zu einer passwortlosen Identitätsarchitektur.

Schritt 1: Multi-Faktor-Authentifizierung flächendeckend durchsetzen

Bevor Passwörter strukturell ersetzt werden können, muss zunächst das unmittelbare Risiko identitätsbasierter Angriffe reduziert werden. Multi-Faktor-Authentifizierung (MFA) bildet daher die Mindestanforderung moderner Identitätsarchitekturen und stellt den ersten zwingenden Transformationsschritt dar.

Ohne MFA genügt die Kompromittierung eines einzelnen Geheimnisses für eine vollständige Kontoübernahme. Angesichts der hohen Skalierbarkeit von Password-Spray- und Credential-Stuffing-Angriffen ist ein ausschließlich passwortbasierter Zugriff in Cloud- und Hybridumgebungen nicht mehr vertretbar. Die Einführung von MFA erhöht die Eintrittshürde signifikant und reduziert insbesondere automatisierte Angriffe deutlich.

Strategisch stehen in diesem Schritt zwei Aspekte im Mittelpunkt: Breite und Qualität.

Zunächst muss MFA flächendeckend erzwungen werden – nicht optional und nicht nur für privilegierte Konten, sondern für sämtliche Identitäten mit Zugriff auf produktive Systeme. Ausnahmen sollten ausschließlich für klar definierte Notfall- oder Break-Glass-Konten bestehen, die technisch abgesichert und organisatorisch streng kontrolliert sind.

Darüber hinaus ist die Qualität der eingesetzten MFA-Verfahren entscheidend. SMS-basierte Verfahren gelten heute lediglich als Basisschutz. Push-basierte Authenticator-Apps stellen eine Verbesserung dar, bleiben jedoch anfällig für Social-Engineering-Angriffe wie MFA-Fatigue. Bereits in diesem frühen Transformationsschritt sollte daher geprüft werden, inwieweit phishing-resistente Verfahren priorisiert werden können.

In Microsoft-zentrierten Umgebungen lässt sich dieser Schritt beispielsweise über Conditional Access Policies umsetzen. Dabei werden Mindestanforderungen an Authentifizierungsstärken definiert und risikobasierte Bewertungen in die Zugriffskontrolle integriert. Ziel ist es, sicherzustellen, dass kein produktiver Zugriff mehr ausschließlich auf einem Passwort basiert.

Wichtig ist jedoch: MFA ist kein Endzustand, sondern eine Risikoreduktion im bestehenden Modell. Das Passwort bleibt weiterhin Bestandteil der Authentifizierungskette. Schritt 1 schafft somit die notwendige Sicherheitsbasis für die eigentliche Transformation – die schrittweise Ablösung des wiederverwendbaren Geheimnisses in den folgenden Phasen.

Schritt 2: Phishing-resistente Methoden priorisieren

Nach der flächendeckenden Einführung von Multi-Faktor-Authentifizierung muss der Fokus von bloßer Risikoreduktion hin zur strukturellen Härtung der Authentifizierungsarchitektur verschoben werden. Ziel dieses zweiten Schrittes ist es nicht mehr, zusätzliche Faktoren zu prüfen, sondern weiterleitbare Anmeldeinformationen systematisch zu eliminieren.

Hier kommen phishing-resistente Verfahren ins Spiel. Im Gegensatz zu klassischen MFA-Mechanismen basieren FIDO2-Authentifikatoren, Windows Hello for Business oder Passkeys auf asymmetrischer Kryptografie. Es existiert kein geteiltes Geheimnis, das abgefangen oder weitergeleitet werden könnte. Jede Authentifizierungsantwort ist kryptografisch an den legitimen Dienst gebunden und damit nicht übertragbar.

In Microsoft-zentrierten Identitätsarchitekturen lässt sich dieser Schritt beispielsweise über Authentication Strength Policies umsetzen. In Kombination mit Conditional Access können Richtlinien definiert werden, die für bestimmte Szenarien ausschließlich phishing-resistente Authentifizierungsmethoden zulassen – etwa für privilegierte Konten oder besonders schützenswerte Anwendungen.

Strategisch empfiehlt sich dabei ein gestaffeltes Vorgehen. Zunächst sollten administrative Konten und hochprivilegierte Rollen auf hardware- oder schlüsselbasierte Verfahren umgestellt werden. Anschließend kann der Schutz schrittweise auf weitere Benutzergruppen ausgeweitet werden. Gerade in Cloud- und SaaS-Umgebungen lassen sich Passkeys oder FIDO2-Sicherheitsschlüssel effizient einsetzen.

Entscheidend ist in dieser Phase eine klare Zielsetzung: Das Passwort darf nicht länger als primärer Identitätsanker fungieren. Selbst wenn es technisch weiterhin existiert, verliert es durch Richtliniensteuerung und Priorisierung phishing-resistenter Verfahren seine operative Bedeutung.

Schritt 2 markiert damit den Übergang von einer verstärkten Passwortarchitektur hin zu einer tatsächlich passwortlosen Identität. Während MFA in Schritt 1 das Risiko reduziert, beginnt hier die strukturelle Transformation der Authentifizierungsgrundlage.

Schritt 3: Passwörter technisch entwerten

Nachdem phishing-resistente Verfahren priorisiert und technisch durchgesetzt wurden, folgt der entscheidende Transformationsschritt: Das Passwort verliert seine operative Bedeutung. Ziel ist nicht mehr nur die Ergänzung durch zusätzliche Faktoren, sondern die systematische Entwertung des wiederverwendbaren Geheimnisses als reguläres Authentifizierungsmerkmal.

Technisch bedeutet dies, dass passwortbasierte Logins – soweit möglich – deaktiviert oder stark eingeschränkt werden. In Cloud-Umgebungen können entsprechende Richtlinien verhindern, dass ein Zugriff ausschließlich mit Benutzername und Kennwort erfolgt. Conditional-Access-Policies und Authentication-Strength-Vorgaben stellen sicher, dass nur noch schlüsselbasierte oder hardwaregestützte Verfahren akzeptiert werden.

In hybriden oder Legacy-Umgebungen ist dieser Schritt häufig komplexer. Bestimmte Anwendungen oder Protokolle sind weiterhin passwortabhängig. In solchen Fällen müssen Übergangslösungen geschaffen werden, etwa durch Protokollmodernisierung, Identitätsproxies oder die schrittweise Ablösung veralteter Systeme. Die Entwertung des Passworts ist daher nicht nur eine Konfigurationsfrage, sondern häufig auch Teil einer umfassenderen Modernisierung der Anwendungslandschaft.

Ein zentrales Element bleibt das sogenannte Break-Glass-Prinzip. Für Notfallszenarien müssen klar definierte, hoch abgesicherte Konten existieren, die im Ausnahmefall auch mit Passwortzugriff arbeiten können. Diese Konten dürfen jedoch nicht im regulären Betrieb verwendet werden. Sie müssen technisch isoliert, besonders überwacht und organisatorisch streng kontrolliert sein.

Strategisch markiert Schritt 3 den Übergang von einer Architektur Passwort plus zusätzlicher Absicherung hin zu einem Modell, in dem das Passwort nicht mehr Teil des regulären Anmeldeprozesses ist. Es existiert lediglich noch als Fallback für klar definierte Ausnahmesituationen.

Damit wird das wiederverwendbare Geheimnis nicht nur ergänzt, sondern systematisch aus der täglichen Authentifizierung entfernt.

Schritt 4: Gerätevertrauen konsequent integrieren

Die Eliminierung des Passworts allein genügt nicht, wenn das zugrunde liegende Endgerät kompromittiert oder manipuliert ist. Moderne Identitätsarchitekturen müssen daher nicht nur die Benutzeridentität verifizieren, sondern auch die Vertrauenswürdigkeit des verwendeten Geräts bewerten. Genau hier setzt der vierte Transformationsschritt an.

Hardwarebasierte Root-of-Trust-Mechanismen wie Trusted Platform Module (TPM), Secure Enclave oder StrongBox bilden die technische Grundlage. Sie stellen sicher, dass kryptografische Schlüssel isoliert erzeugt und geschützt werden. Ergänzend ermöglichen Verfahren wie Secure Boot, Measured Boot und Remote Attestation eine Überprüfung des Systemzustands bereits während des Startprozesses.

Diese Integritätsinformationen dürfen jedoch nicht isoliert betrachtet werden. Sie müssen Bestandteil der gesamten Zugriffskette sein. In Enterprise-Umgebungen geschieht dies durch Gerätecompliance-Prüfungen, Zustandsbewertungen und risikobasierte Zugriffskontrollen. Nur wenn sowohl Identität als auch Gerätezustand als vertrauenswürdig eingestuft werden, wird Zugriff auf sensible Ressourcen gewährt.

Damit entsteht ein mehrschichtiges Sicherheitsmodell. Die zentrale Frage lautet nicht mehr nur Wer greift zu?, sondern ebenso Von welchem Gerät und unter welchen Bedingungen?.

Dieser Schritt hebt die Migration auf eine strategische Ebene. Identität, Gerät und Sicherheitskontext werden zu einer zusammenhängenden Vertrauenskette verknüpft. Die Authentifizierung endet nicht mehr bei der kryptografischen Signatur, sondern wird durch kontinuierliche Zustandsbewertung und kontextbasierte Richtlinien ergänzt.

Die Transformation zur passwortlosen Architektur ist daher weniger ein einzelnes IT-Projekt als vielmehr eine strukturelle Neuausrichtung der Sicherheitsarchitektur. Sie betrifft Richtlinien, Infrastruktur, Schulung, Betriebsprozesse und Governance gleichermaßen.

Erst wenn Identität, Schlüssel und Geräteintegrität als zusammenhängendes Vertrauensmodell verstanden werden, ist der Übergang zu einer modernen, phishing-resistenten Anmeldesicherheit vollständig vollzogen.

Das Passwort als historisches Artefakt – Eine sicherheitstechnische Einordnung

Die Entwicklung von Authentifizierungsverfahren folgt einem klar erkennbaren Muster. Jede Phase der IT-Geschichte brachte ein Verfahren hervor, das zur jeweiligen Systemarchitektur und zum damaligen Bedrohungsmodell passte.

Das Passwort entstand in einer Zeit zentraler Großrechner, physischer Zugangskontrollen und begrenzter Vernetzung. Es erfüllte seinen Zweck: die Trennung von Benutzerkonten in überschaubaren Systemen. Es war pragmatisch, einfach implementierbar und für das damalige Umfeld ausreichend.

Mit der globalen Vernetzung digitaler Dienste veränderte sich dieses Umfeld jedoch grundlegend. Cloud-Architekturen, mobile Endgeräte und weltweit erreichbare Identitätsdienste führten zu einer massiven Vergrößerung der Angriffsfläche. In dieser Architektur wurde das wiederholbare Geheimnis selbst zum primären Angriffsziel.

Multi-Faktor-Authentifizierung stellte eine notwendige Weiterentwicklung dar. Sie erhöhte die Sicherheit erheblich und reduzierte viele automatisierte Angriffe. Dennoch blieb das strukturelle Grundproblem bestehen: Ein übertragbares Geheimnis blieb weiterhin Bestandteil des Authentifizierungsmodells.

Erst mit asymmetrischer, gerätegebundener Authentifizierung vollzieht sich ein tatsächlicher Architekturwechsel. Verfahren wie Windows Hello for Business, FIDO2-Sicherheitsschlüssel oder Passkeys eliminieren das geteilte Geheimnis vollständig. Die Legitimation basiert nicht mehr auf Wissen, sondern auf kryptografischem Besitz in Kombination mit überprüfbarer Geräteintegrität.

Damit verändert sich die Vertrauenslogik grundlegend:

• Vom Wissen zum Schlüssel
• Vom Passwort zum Sicherheitsmodul
• Vom Netzwerkperimeter zur Identitäts- und Gerätebindung

In modernen Identitätsarchitekturen ist das Passwort daher kein Sicherheitsfundament mehr, sondern ein Kompatibilitätsartefakt. Es existiert häufig aus historischen Gründen – nicht aus sicherheitstechnischer Überzeugung.

Gleichzeitig bedeutet diese Einordnung nicht, dass Passwörter kurzfristig verschwinden werden. Legacy-Systeme, Interoperabilitätsanforderungen und organisatorische Realitäten sorgen dafür, dass sie weiterhin Bestandteil vieler Umgebungen bleiben. Die strategische Frage lautet jedoch längst nicht mehr, ob das Passwort langfristig ersetzt wird, sondern wie konsequent Organisationen den Übergang gestalten.

Die Zukunft der Authentifizierung ist schlüsselbasiert, hardwaregestützt und phishing-resistent. Identität wird nicht mehr durch wiederholbares Wissen bewiesen, sondern durch kryptografisch gesicherte Besitznachweise in einem überprüfbaren Vertrauenskontext.

Damit schließt sich der Kreis: Moderne Anmeldesicherheit ist keine Frage stärkerer Passwörter – sondern eine Frage grundlegender Architekturentscheidungen.

Quellenangaben

(Abgerufen am 06.03.2026)

Primärquellen und Standards

• David Temoshok et al. (NIST): Digital Identity Guidelines (NIST SP 800-63-4) (PDF-Datei)
• FIDO Alliance: FIDO Passkeys: Passwordless Authentication
• Jeff Hodges et al. (W3C): Web Authentication: An API for accessing Public Key Credentials Level 2
• Microsoft Learn: Authentication methods in Microsoft Entra ID – passkeys (FIDO2)
• Microsoft Learn: Plan a Windows Hello for Business deployment
• Microsoft Learn: Support for passkeys in Windows
• Microsoft Learn: Windows Hello for Business authentication

Fachartikel und technische Analysen

• Joeri Juramento (Medium): Passwordless Passkeys — Deep-Dive Microsoft 365 Admin [8]
• Julian Stabentheiner: Windows Hello for Business SSO – Cloud Kerberos Trust
• Mobile Jon: Demystifying Passkeys and Extending Microsoft Entra with Passwordless Authentication
• NetXConsult: Passkeys in Microsoft – What IT admins and companies need to know!
• Thomas Joos (Security Insider): Mit Passkeys an Microsoft 365 und Azure anmelden

Historische Einordnung und Passwortentwicklung

• Cisco: Passwords have a long history – how much do you know…?
• Dashlane: A Brief History of Passwords
• Exploring Information Security: The History of Passwords
• FusionAuth: Passwords Are History

Smartcard-Technologie

• Giesecke+Devrient: Smart card technology: How a german invention shaped our digital lives
• Katherine M. Shelfer, J. Drew Procaccino (ACM): Smart Card Evolution
• Tensor plc: A Brief History of Smart Cards

Angriffsdynamik und Bedrohungslage

• Enzoic: 8 Scary Statistics about the Password Reuse Problem
• Microsoft: Microsoft Digital Defense Report

Weiterlesen hier im Blog

• Azure Grundlagen: Architekturprinzipien, Identität, Governance und Best Practices für moderne Cloud-Umgebungen
• KI frisst Hardware – Warum der Infrastrukturhunger den IT-Markt neu definiert
• SC-300 in der Praxis – Identität sichern, Zugriff steuern, Vertrauen gestalten
• Toolmaking-Grundlagen in PowerShell – Warum nachhaltige Automatisierung mit Architektur beginnt
• Wie KI lernt – vom Datenpunkt zur Entscheidung
• Windows 11 im Modern Workplace: Identität, Geräteverwaltung und Sicherheit mit Entra ID und Intune