Die Multi-Faktor-Authentifizierung (MFA) ist ein Verfahren, bei dem Benutzer ihre Identität mit mindestens zwei verschiedenen Authentifizierungsmethoden bestätigen müssen, bevor ihnen Zugriff auf angeforderte Ressourcen gewährt wird. Dieser mehrstufige Prozess verhindert die Abhängigkeit von einem einzelnen Faktor wie einem Passwort, das leicht gestohlen, erraten oder weitergegeben werden kann.

Die ständige Gefahr des Diebstahls von Anmeldedaten macht MFA unerlässlich. Der Verizon Data Breach Investigations Report (DBIR) 2025 stellt fest, dass der Missbrauch von Zugangsdaten nach wie vor der wichtigste Erstzugriffsvektor bei Sicherheitsverletzungen und für 22 % aller Zwischenfälle verantwortlich ist. Eine starke MFA trägt dazu bei, das Risiko des unbefugten Zugriffs mit kompromittierten Anmeldedaten zu verringern.

MFA verifiziert die Identität anhand von drei Kategorien, die die Identität jeweils über einen anderen Mechanismus validieren.

Wenn Faktoren mehrerer Kategorien kombiniert werden, steigt die Sicherheit:

Etwas, das man weiß (Wissen)

• Passwörter
• PINs
• Auswendig gelernte Muster

Etwas, das man hat (Besitz)

• TOTP-Authentifikator-Apps
• Push-Benachrichtigungen
• FIDO2/WebAuthn-Schlüssel
• Smartcards

Etwas, das man ist (Inhärenz)

• Fingerabdruck
• Face ID
• Iris-Scan

Je mehr Faktoren Sie aus unterschiedlichen Kategorien kombinieren, desto stärker wird die MFA (d. h. zwei Passwörter ergeben keine Multi-Faktor-Authentifizierung).

Jeder Faktortyp stützt sich auf unterschiedliche Mechanismen und Schutzmaßnahmen, um die Identität sicher zu verifizieren. Wenn Sie MFA richtig implementieren wollen, müssen Sie die technischen Details und Sicherheitsaspekte der Wissens-, Besitz- und Inhärenzfaktoren verstehen.

Wissensfaktoren

• Die Passwort- und PIN-Validierung erfolgt über den Abgleich einer Benutzereingabe mit einem gespeicherten Hash-Wert anstelle von Klartext. Das System generiert den Hash-Wert mithilfe adaptiver, speicher- oder CPU-intensiver Algorithmen (Argon2, bcrypt oder PBKDF2) mit individuellen Salts und optimierten Arbeitsfaktoren gemäß OWASP und NIST SP 800-63B §5.1.1.2.
• Sicherheitsfragen basieren auf privaten Informationen, die nur dem Benutzer bekannt sind. Dieser Mechanismus ist von Natur aus schwach, da Angreifer durch Social Engineering oder Datenlecks in öffentlichen Datenquellen oft an die erforderlichen Antworten gelangen können.

Besitzfaktoren

• Time-Based One-Time-Passwords (TOTPs) generieren Codes aus einem Shared Secret und der aktuellen Uhrzeit. Server validieren die Codes innerhalb eines kurzen Zeitfensters (typischerweise 30 Sekunden, mit einer Toleranz von ± 1). So wird sichergestellt, dass jeder Code schnell abläuft und nur einmal verwendet werden kann.
• Push-Benachrichtigungen senden eine Authentifizierungsanfrage an ein registriertes Gerät. Die Bestätigungsaktion des Benutzers auf seinem Gerät dient als kryptografischer Besitznachweis. Dieser wird oft um kontextabhängige Informationen (z. B. Standort, Gerätetyp, Zeitstempel) ergänzt, damit der Benutzer legitime Anfragen von betrügerischen unterscheiden kann.
• FIDO2/WebAuthn-Schlüssel verwenden eine asymmetrische Verschlüsselung, bei der ein privater Schlüssel auf einem physischen Gerät gespeichert wird. Während der Authentifizierung signiert das Gerät eine Sicherheitsabfrage mit dem privaten Schlüssel und die Signatur wird kryptografisch an die Ursprungsdomain gebunden. Dadurch werden die Anmeldedaten auf jeder anderen Website ungültig.
• Smartcards speichern kryptografische Anmeldedaten auf manipulationssicherer Hardware. Die Smartcard führt intern kryptografische Operationen durch, wenn ein Benutzer eine PIN eingibt. So wird sichergestellt, dass das private Schlüsselmaterial den Sicherheitschip niemals verlässt.
• Backup-Codes sind vorab generierte, einmalig verwendbare Passwörter, die während der MFA-Registrierung erstellt werden. Jeder Code kann nur einmal validiert werden, sodass eine Account-Wiederherstellung ohne einen primären zweiten Faktor möglich wird.

Inhärenzfaktor

• Die biometrische Authentifizierung vergleicht eine Live-Aufnahme mit einer gespeicherten Vorlage, die kryptografisch aus den ursprünglichen biometrischen Daten transformiert wurde. Das System speichert niemals Rohabbilder oder Scans. Es speichert lediglich die mathematischen Darstellungen, die eine Übereinstimmung ohne Rekonstruktion der ursprünglichen biometrischen Daten verifizieren können.
• Die Liveness Detection unterscheidet echte menschliche Biometrie von Spoofing-Versuchen (z. B. Fotos, Masken, Aufzeichnungen) mithilfe von Techniken wie Tiefensensorik, Erkennung von Mikrobewegungen oder Reaktion auf Sicherheitsabfragen (z. B. „Zweimal blinzeln“). Die Wirksamkeit dieser Gegenmaßnahmen variiert zwischen Verbrauchergeräten und Hochsicherheitssystemen.
• Die Template-Sicherheit bestimmt, ob der biometrische Faktor auch bei einer Kompromittierung des Geräts geschützt bleibt. Sichere Enklaven-Prozessoren und Hardware-basierte Schlüsselspeicher isolieren die biometrische Verarbeitung vom zentralen Betriebssystem und verhindern so die Extraktion der Vorlage (Template) selbst bei einem Zugriff auf Geräteebene.

Zentrale Kategorien und Mechanismen der MFA

Die Zwei-Faktor-Authentifizierung (2FA) erfordert genau zwei Faktoren – typischerweise ein Passwort plus eine zusätzliche Verifizierungsmethode. 2FA ist das gängigste Implementierungsmuster und wird von den meisten Menschen mit „MFA“ gleichgesetzt.

Die Multi-Faktor-Authentifizierung (MFA) ist eine breiter gefasste Kategorie. Sie schließt alle Authentifizierungsmethoden ein, die zwei oder mehr Authentifizierungsfaktoren erfordern. Auch wenn die Unterscheidung rein semantischer Natur sein mag, ist sie für die Sicherheitsrichtlinie relevant. Beispielsweise weisen Systeme, die für risikoreiche Aktionen drei Faktoren (Passwort, TOTP und Biometrie) erfordern, andere Bedrohungsmodelle auf als die Standard-2FA.

In der Praxis ist die Zwei-Faktor-Authentifizierung (2FA) eine spezifische Implementierung der Multi-Faktor-Authentifizierung (MFA).

Die Abfrage derselben Authentifizierungsfaktoren für jede Anmeldung erzeugt Reibung ohne einen entsprechenden Zuwachs an Sicherheit.

Bei der Step-up-Authentifizierung werden Benutzer nur zur Angabe zusätzlicher Faktoren aufgefordert, wenn sie versuchen, auf sensiblere Ressourcen zuzugreifen. Ein Benutzer meldet sich beispielsweise normal an, navigiert durch eine Anwendung und trifft dann auf eine MFA-Sicherheitsabfrage, wenn er auf geschützte Ressourcen zugreifen oder risikoreiche Aktionen ausführen will.

Anwendung in der Praxis: Für den Lesezugriff auf Dokumente kann ein Mitarbeiterportal beispielsweise eine rein passwortbasierte Authentifizierung verwenden. Die Änderung von Gehaltsabrechnungsdaten, das Herunterladen personenbezogener Mitarbeiterdaten oder die Anpassung von Systemkonfigurationen erfordert jedoch einen zweiten Authentifizierungsfaktor, z. B. einen TOTP-Code oder eine biometrische Verifizierung.

Dieser Ablauf bietet eine reibungslosere User Experience für Routineaufgaben und im Bedarfsfall mehr Sicherheit. Bei der Implementierung müssen die Ressourcen und Aktionen identifiziert werden, die eine zusätzliche Überprüfung erfordern – eine sicherheitsarchitektonische Entscheidung, bei der zwischen Risiko und Benutzerfreundlichkeit abgewogen werden muss.

Adaptive MFA (auch bekannt als Risk-Based Authentication) passt die Authentifizierungsanforderungen dynamisch auf Basis kontextabhängiger Signale an. Anstatt bei jedem Anmeldeversuch identische Regeln anzuwenden, berechnet das System einen Risiko-Score aus den folgenden Faktoren:

• Standortsignale: Reputation der IP-Adresse, geografischer Standort und Erkennung nicht plausibler Standortänderungen.
• Gerätekontext: Bekannte vs. unbekannte Geräte, Geräte-Fingerabdruck, Sicherheitslage
• Verhaltensmuster: Tageszeit, typische Zugriffsmuster, Geschwindigkeitsprüfungen
• Threat-Informationen: Bekanntermaßen kompromittierte Anmeldedaten, aktive Angriffskampagnen

In Szenarien mit geringem Risiko (z. B. bekanntes Gerät, vertrauter Standort oder normales Verhalten) reicht manchmal auch die Ein-Faktor-Authentifizierung. Hochrisikoszenarien (z. B. neues Gerät, ungewöhnliche Standorte oder Zugriff außerhalb der Geschäftszeiten) erfordern automatisch einen zusätzlichen Verifizierungsfaktor oder blockieren den Zugriff komplett.

Eine effektive adaptive MFA erfordert eine Risiko-Engine, die Sicherheitssignale und historische Daten in Echtzeit verarbeitet. Diese Fähigkeit besitzen typischerweise Identity-Plattformen im Gegensatz zu kundenspezifischen Lösungen, da die Falsch-Positiv-Rate darüber entscheidet, ob die adaptive MFA die User Experience verbessert oder verschlechtert.

TOTP-Codes und SMS-Verifizierung sind sicherer als die reine Passwortauthentifizierung, doch raffinierte Angreifer haben sich auch an diese Methoden bereits angepasst. Echtzeit-Phishing-Proxys können sowohl Passwörter als auch Einmalcodes während der Eingabe durch den Benutzer erfassen und diese Anmeldedaten schnell an den legitimen Dienst weiterleiten, bevor sie ablaufen.

Der Angriff führt zum Erfolg, weil TOTP und SMS auf Shared Secrets beruhen, die sowohl auf dem Client als auch auf dem Server vorhanden sind. Wenn sich ein Angreifer dazwischenschaltet, kann er diese Secrets abfangen und die Authentifizierung damit umgehen.

Bei MFA Fatigue-Angriffen versenden Angreifer massenhaft Push-Benachrichtigungsanfragen in der Hoffnung, dass der Benutzer schließlich eine davon genehmigt, nur um die Benachrichtigungen zu stoppen.

FIDO2 implementiert Public-Key-Verschlüsselung, um Schwachstellen durch Shared Secrets zu eliminieren.

FIDO2 besteht aus:

• WebAuthn: W3C-Standard-API, die Browser und Betriebssysteme zur Interaktion mit Authentifizierungsfaktoren verwenden.
• Client-to-Authenticator Protocoll (CTAP): Protokoll, das externe Geräte (Sicherheitsschlüssel, NFC/Bluetooth/USB-Authentifizierungsfaktoren) für die Kommunikation mit dem Client verwenden.

Funktionsweise der FIDO2-Authentifizierung:

Registrierung

• Der Authentifizierungsfaktor generiert ein öffentliches/privates Schlüsselpaar.
• Der private Schlüssel verlässt niemals das Gerät und der öffentliche Schlüssel wird beim Dienst registriert.

Authentifizierung (Anmeldung)

• Der Dienst sendet eine kryptografische Abfrage.
• Der Authentifizierungsfaktor signiert die Abfrage mit dem privaten Schlüssel.
• Die Signatur ist an den Ursprung (Domain) der Website gebunden. Dadurch wird ihre Verwendung auf Phishing-Websites verhindert.

Selbst wenn ein Benutzer versucht, sich auf einer schädlichen Website zu authentifizieren, ist die signierte Antwort nur für die legitime Domain gültig. Es gibt kein Secret, das Angreifer stehlen könnten. Damit sind FIDO2-Schlüssel Phishing-resistent.

Passkeys sind FIDO2-Anmeldedaten, die in der sicheren Umgebung des Geräts (z. B. in der Keychain des Betriebssystems) gespeichert sind und über mehrere vertrauenswürdige Geräte hinweg synchronisiert werden können. Der Benutzer löst die Authentifizierung mit einer einzigen Geste aus, z. B. durch das Entsperren des Geräts mittels biometrischer Verifizierung oder PIN.

Für Passkeys gilt:

• Es gibt es keine Passwörter, die gestohlen werden können.
• Es gibt es keine Einmalcodes, die durch Phishing abhandenkommen können.
• Bei Sicherheitsverletzungen werden keine Shared Secrets offengelegt.

Passkeys bieten Sicherheit auf MFA-Niveau mit nur einer einzigen, benutzerfreundlichen Aktion.

APIs, Service-Accounts und Machine-to-Machine-Kommunikation können keine interaktiven MFA-Sicherheitsabfragen wie TOTP-Codes oder Push-Benachrichtigungen durchführen. Stattdessen werden MFA-Prinzipien durch kryptografische Attestierung angewendet, um einen Identitäts- und Besitznachweis zu erbringen.

• Asymmetrische Schlüsselpaare: Dienste verwenden private Schlüssel, um Anfragen oder OAuth 2.0 JWT-Bearer-Client-Assertions zu signieren (gemäß RFC 7523). Der Autorisierungsserver registriert öffentliche Schlüssel. Der private Schlüssel verlässt niemals den Dienst oder das HSM und dient als Besitzfaktor-Äquivalent.
• Mutual TLS (mTLS): Sowohl der Client als auch der Server präsentieren ein Zertifikat, um Vertrauen in beide Richtungen herzustellen. Das Client-Zertifikat dient als Identitäts- und Besitznachweis des Dienstes, während das Server-Zertifikat die Authentizität bestätigt.
• Plattformgestützte Identitäts-Attestierung für Workloads: Die Cloud-Plattform bestätigt kryptografisch die Identität und Integrität laufender Workloads und die Plattform generiert dynamisch kurzlebige Anmeldedaten, sodass keine langlebigen Secrets mehr benötigt werden. Dieser Ansatz ermöglicht die Dienstauthentifizierung nach dem Zero-Trust-Prinzip ohne manuelle Schlüsselverwaltung.

Diese Muster erweitern das mehrschichtige Verifizierungsmodell der Multi-Faktor-Authentifizierung auf automatisierte Systeme und verwenden dabei Verschlüsselung anstelle interaktiver Benutzereingaben. Besitzfaktoren für nicht-menschliche Identitäten können asymmetrische Schlüsselpaare, signierte JWT-Assertions oder HSM-gestützte Signaturschlüssel umfassen und bieten eine starke, Phishing-resistente Verifizierung für Maschinen und Dienste.

Für viele Unternehmen ist die Multi-Faktor-Authentifizierung nicht mehr optional, da sie inzwischen von immer mehr gesetzlichen Vorschriften für den Zugriff auf sensible Daten vorgeschrieben wird:

• PCI DSS v4.x schreibt MFA für die meisten Zugriffe auf die Karteninhaberdatenumgebung (CDE) vor, einschließlich Fernzugriff und privilegierter Benutzer. Es gelten jedoch spezifische Klauseln und Ausnahmen. IT- und Security-Teams sollten die PCI SSC-Richtlinien hinsichtlich des genauen Umfangs der Anforderungen prüfen.
• Die DSGVO verlangt „geeignete technische und organisatorische Maßnahmen“, die von den Aufsichtsbehörden zunehmend so interpretiert werden, dass sie auch die Multi-Faktor-Authentifizierung (MFA) für den Zugriff auf personenbezogene Daten umfassen.
• Die Authentifizierungskontrollen werden im Rahmen von SOC2-Audits bewertet und die Zertifizierung setzt in der Regel die MFA für den administrativen Zugriff und privilegierte Operationen voraus.
• NIST SP 800-63B formuliert technische Leitlinien für die Authentifizierung digitaler Identitäten. Sie müssen von Bundesbehörden befolgt werden und werden auch von privaten Unternehmen zunehmend als Best Practice übernommen.

1. Unsichere Wiederherstellungsabläufe: Account-Wiederherstellungsabläufe, die die MFA-Authentifizierung umgehen (z. B. Links zum Zurücksetzen der E-Mail-Adresse mit nur einem Faktor), schaffen Hintertüren. Teams müssen die Wiederherstellung mit dem gleichen oder einem höheren Sicherheitsstandard als die ursprüngliche Anmeldung konzipieren.
2. SMS als einziger zusätzlicher Faktor: Die ausschließliche Nutzung von SMS macht Unternehmen anfällig für SIM-Swapping-Angriffe. TOTP-Authentifizierungsfaktoren (Anwendungen oder Hardwareschlüssel) bieten besseren Schutz.
3. Fehlender Schutz für Session Token: Die MFA ist bei der Anmeldung wirkungslos, wenn Angreifer das Session Token stehlen und verwenden. Token müssen ein geeignetes Ablaufdatum erhalten sowie sicher gespeichert und überwacht werden.
4. Universelle MFA-Durchsetzung ohne Risikokontext: Wenn immer dieselben Authentifizierungsfaktoren für jede Aktion abgefragt werden, entstehen Reibungspunkte und Benutzer werden gezwungen, Umgehungsmöglichkeiten zu finden. Die Step-up-Authentifizierung konzentriert den Schutz auf die relevanten Bereiche und wahrt gleichzeitig die Benutzerfreundlichkeit.
5. Ignorieren von Phishing-resistenten Methoden: TOTP-Codes und SMS sind zwar Verbesserungen gegenüber reinen Passwortlösungen, bleiben aber anfällig für Echtzeit-Phishing. Unternehmen, die sensible Daten verarbeiten, sollten WebAuthn/FIDO2-Sicherheitsschlüssel und Passkeys priorisieren.

Was ist der größte Sicherheitsvorteil von Multi-Faktor-Authentifizierung (MFA) gegenüber reiner Passwortauthentifizierung?

MFA schützt vor dem Diebstahl von Anmeldedaten. Selbst wenn Angreifer ein Passwort stehlen, können sie ohne den zweiten Faktor – sei es ein gerätegenerierter Code, eine biometrische Verifizierung oder ein physischer Sicherheitsschlüssel – nicht auf das Konto zugreifen.

Warum raten Sicherheitsexperten von SMS-basierter MFA ab?

Angreifer nutzen SMS-Codes durch SIM-Swapping-Angriffe aus, bei denen sie Mobilfunkanbieter dazu bringen, Telefonnummern auf von ihnen kontrollierte Geräte zu portieren. Während SMS-MFA effektiver ist als die reine Passwortauthentifizierung, bieten TOTP-Authentifizierungsanwendungen und Hardware-Sicherheitsschlüssel einen stärkeren Schutz, der nicht von den Sicherheitspraktiken der Mobilfunkanbieter abhängt.

Können Angreifer MFA umgehen oder knacken?

Raffinierte Phishing-Angriffe mit Echtzeit-Proxys können die traditionelle MFA mit TOTP- oder SMS-Codes knacken. MFA mit FIDO2/WebAuthn-Sicherheitsschlüsseln oder Passkeys basiert auf kryptografischen Besitznachweisen, die an eine bestimmte Domain gebunden sind.

Was passiert, wenn Benutzer den Zugriff auf ihren zweiten Faktor verlieren?

IT-Teams können für die Wiederherstellung des Zugriffs sichere Methoden implementieren, z. B. mit Backup-Codes, die während der ersten oder erneuten Registrierung mit Identitätsprüfung generiert wurden. Security-Teams sollten den Wiederherstellungsprozess mit derselben oder einer höheren Sicherheitsstufe wie den ursprünglichen MFA-Prozess schützen und Ein-Faktor-Prozesse (z. B. Rücksetzungen ausschließlich per E-Mail-Adresse) vermeiden, die die MFA umgehen könnten.

Wird die MFA durch Gesetze oder Verordnungen vorgeschrieben?

Viele gesetzgeberische Rahmenbedingungen fordern oder empfehlen MFA dringend. PCI DSS v4.x verlangt MFA für den Großteil des Zugriffs auf die Karteninhaber-Datenumgebung (CDE), einschließlich Remote- und privilegierter Benutzer. Dabei gelten jedoch spezifische Klauseln und Ausnahmen. Im Gesundheitswesen ist die Multi-Faktor-Authentifizierung (MFA) gemäß HIPAA eine dringend empfohlene Schutzmaßnahme. Unternehmen, die sich gegen die Implementierung entscheiden, müssen ihre Gründe dokumentieren und alternative Kontrollmechanismen durchsetzen, die einen vergleichbaren Schutz für elektronische Gesundheitsdaten gewährleisten.

Sie können MFA-Funktionen zwar selbst entwickeln, moderne Identity-Plattformen bieten jedoch eine produktionsreife Implementierung mit adaptiven Risiko-Engines, Phishing-resistenten Authentifizierungsfaktoren und integrierten Compliance-Kontrollen. In unserer Reihe „Einführung in IAM“ finden Sie weitere Informationen zu Identity and Access Management (IAM).

Mehr erfahren

Diese Materialien dienen nur zur allgemeinen Information. Es liegt in Ihrer Verantwortung, sich mit Blick auf Sicherheit, Datenschutz, Compliance oder geschäftliche Angelegenheiten beraten zu lassen und sich nicht ausschließlich auf die hierin bereitgestellten Informationen zu verlassen.