MFA-Methoden: TOTP vs. FIDO2 vs. Push — was für KMU?

Zwei-Faktor-Authentifizierung ist im Jahr 2026 keine Kür mehr, sondern Pflicht — Cyberversicherer verweigern ohne belegbares MFA-Konzept regelmäßig die Deckung, und die DSGVO-Aufsicht wertet fehlende MFA bei Admin-Konten als “Stand der Technik”-Verstoß. Die eigentliche Frage in mittelständischen IT-Umgebungen ist daher nicht mehr ob, sondern welches Verfahren: TOTP-Codes aus einer Authenticator-App, hardwaregebundene FIDO2-Keys oder Push-Benachrichtigungen auf das Smartphone.

Alle drei Verfahren lösen dasselbe Grundproblem — sie verhindern, dass ein geleaktes Passwort allein zum Kontrollverlust führt. In der Praxis unterscheiden sie sich aber massiv in Phishing-Resistenz, Anschaffungskosten und Nutzerakzeptanz. Dieser Artikel ordnet die drei Verfahren technisch ein und gibt eine differenzierte Empfehlung für Admin-Konten und normale Anwender.

TOTP: der pragmatische Klassiker

Time-based One-Time Passwords nach RFC 6238 sind seit über einem Jahrzehnt der De-facto-Standard für “zweiter Faktor light”. Server und Client teilen sich ein 160-Bit-Secret, aus dem alle 30 Sekunden ein sechsstelliger Code abgeleitet wird. Enrollment erfolgt per QR-Code, die App — Aegis, Ente Auth, 2FAS oder der Bitwarden-Authenticator — läuft offline auf jedem Smartphone.

Die Stärken sind klar: null Hardware-Kosten, universelle Unterstützung von GitHub bis zur Fritzbox, funktioniert auch offline und ohne Cloud-Konto. Für KMU mit begrenztem Budget ist TOTP der niedrigschwellige Einstieg.

Die Schwäche ist ebenso klar: TOTP-Codes sind phishbar. Eine Adversary-in-the-Middle-Kampagne — Modlishka, Evilginx oder mittlerweile fertige “Phishing-as-a-Service”-Kits wie Tycoon 2FA — proxied die Login-Seite in Echtzeit. Der Nutzer tippt Passwort und Code auf einer gefälschten Domain, der Angreifer reicht beides in unter zwei Sekunden an den echten Server durch und übernimmt die Session. Der zweite Faktor wird zum Feigenblatt.

Zusätzlich problematisch: Enrollment-Secrets sind in vielen Umgebungen nie rotiert, liegen als QR-Code-Screenshot in irgendeinem Ticketsystem und wandern bei Handywechsel per E-Mail zurück an den Nutzer. Wer TOTP ernst nimmt, braucht ein sauberes Enrollment- und Recovery-Konzept.

FIDO2/WebAuthn: phishing-resistent per Design

FIDO2 löst das Phishing-Problem strukturell. Statt eines symmetrischen Secrets nutzt der Standard asymmetrische Kryptografie pro Relying Party (Domain). Der Private Key verlässt niemals den Authenticator — YubiKey 5, Token2 PIN+, Feitian ePass oder auch die Platform-Authenticators in Windows Hello, Touch ID und Android Passkey.

Der entscheidende Punkt: Der Browser signiert die Challenge zusammen mit der aufrufenden Origin. Steht der Nutzer auf login-datazone.evil.tld statt login.datazone.de, weigert sich der Authenticator schlicht zu signieren. Adversary-in-the-Middle scheitert — nicht weil der Nutzer klug ist, sondern weil das Protokoll es verhindert. Das ist der Grund, warum Google seit dem verpflichtenden FIDO2-Rollout für alle Mitarbeiter keinen einzigen erfolgreichen Phishing-Angriff mehr auf Konten meldet, die konsequent auf Security Keys umgestellt wurden (Quelle: Google Security Blog).

Der Preis: Hardware. Zwei Keys pro Nutzer sind Pflicht (einer im Einsatz, einer im Safe für den Verlustfall), das sind je nach Modell 50–120 Euro pro Kopf. Dazu die operative Frage: Was passiert bei verlorenem Key? Wie sieht das Enrollment für Remote-Mitarbeiter aus, die den Key nicht persönlich abholen können?

Passkeys — genauer: Discoverable Credentials nach FIDO2 Level 2 — glätten diesen Prozess. Der Authenticator im Smartphone oder Notebook agiert selbst als FIDO2-Device, syncen kann man optional über iCloud Keychain oder Google Password Manager. Für den KMU-Alltag heißt das: FIDO2-Sicherheit ohne separate Hardware, dafür mit Vertrauen auf den jeweiligen Plattform-Anbieter.

Push-Benachrichtigungen: bequem, aber fragil

Push-basiertes MFA — bekannt aus Microsoft Authenticator, Duo oder Okta Verify — funktioniert asymmetrisch (der Push enthält keinen wiederverwendbaren Code) und ist damit theoretisch phishing-resistenter als TOTP. In der Realität scheitert das Konzept an der menschlichen Komponente: MFA-Fatigue.

Der Angriff auf Uber im September 2022 lief exakt so ab: Kompromittiertes Passwort, dann eine Stunde lang minütliche Push-Requests an den Nutzer, parallel eine WhatsApp-Nachricht “vom IT-Support” mit der Bitte, die Anfrage endlich zu bestätigen. Der Mitarbeiter klickt genervt “Accept” — Session übernommen, Angreifer im internen Netz.

Moderne Push-Implementierungen versuchen gegenzusteuern mit Number Matching (der Nutzer muss eine zweistellige Zahl aus dem Login-Prompt in die App tippen) und Context Display (Standort, App, IP-Adresse werden angezeigt). Das hilft — beseitigt aber nicht das Grundproblem, dass ein müder Nutzer irgendwann falsch entscheidet.

Direktvergleich der drei Verfahren

Die folgende Matrix fasst die wesentlichen Kriterien für die KMU-Entscheidung zusammen:

Kriterium	TOTP	FIDO2 / Passkey	Push
Phishing-resistent	Nein	Ja (per Protokoll)	Teilweise (Fatigue)
Hardware-Kosten pro User	0 EUR	50–120 EUR (2 Keys)	0 EUR (BYOD)
Offline-fähig	Ja	Ja	Nein
Nutzerkomfort	Mittel (Code tippen)	Hoch (Touch)	Hoch (Klick)
Verlust-Recovery	Backup-Codes	Zweit-Key/Passkey-Sync	Neu-Enrollment
Enrollment-Aufwand	Niedrig	Mittel	Niedrig
Cyberversicherer-Anerkennung	Basis	Premium	Basis
Empfohlen für	Alle User	Admins, priv. Accounts	Normale User (mit Number Matching)

Rollout mit Authentik oder Keycloak

In den Linux-Infrastrukturen, die wir betreuen, hat sich ein zentraler Identity-Provider durchgesetzt — meist Authentik 2025.10 oder Keycloak 26. Beide beherrschen alle drei MFA-Verfahren nativ und lassen sich per SAML/OIDC an Nextcloud, GitLab, Grafana, Proxmox VE, TrueNAS SCALE und OPNsense anbinden.

Eine typische Authentik-Policy für gestaffelte MFA-Anforderungen sieht so aus:

# Authentik Expression Policy: FIDO2 Pflicht für Admin-Gruppen
if ak_is_group_member(request.user, name="administrators"):
    # Prüft, ob ein WebAuthn-Device registriert ist
    return any(
        d.__class__.__name__ == "WebAuthnDevice"
        for d in request.user.mfa_devices.all()
    )
# Normale User: TOTP oder Push reicht
return request.user.mfa_devices.exists()

Diese Policy wird an einen Authentication Flow gebunden. Admin-Konten ohne FIDO2 kommen schlicht nicht mehr rein — auch nicht mit korrekt geliefertem Passwort und TOTP. Für normale Nutzer bleibt TOTP als Basis-Faktor, Push kann optional als Komfort-Option angeboten werden.

Praktische Rollout-Reihenfolge, die wir in Kundenprojekten fahren:

1. Woche 1–2: Zentrales IdP-Setup, Anbindung der wichtigsten Applikationen per SSO
2. Woche 3: FIDO2-Pflicht für alle Konten mit administrativen Rechten (Domain-Admins, Proxmox-Root, TrueNAS-Admin, OPNsense-Admin, Backup-Konten)
3. Woche 4–6: TOTP-Enrollment für alle Standard-User mit dokumentiertem Recovery-Prozess
4. Ab Woche 7: Optional Passkey-Migration für Endnutzer, die keinen physischen Key wollen

Sonderfall privilegierte Zugänge

Backup-Konten, Firewall-Admin und Hypervisor-Root sind die Kronjuwelen jeder Infrastruktur. Wer hier auf TOTP oder Push setzt, hat das Bedrohungsmodell nicht ernst genommen. Für die Backup-Infrastruktur und den Proxmox-Root-Zugriff gilt in unseren Projekten kompromisslos: FIDO2 mit zwei separaten Hardware-Keys pro Person, dokumentiert in einem Notfall-Runbook.

Der Grund ist einfach: Wenn Ransomware erst einmal einen Domain-Admin phisht, sind wenige Minuten später auch die Backups im Zugriff. FIDO2 unterbricht diese Kette nicht durch bessere Nutzeraufklärung, sondern durch ein Protokoll, das Origin-Spoofing schlicht ignoriert. Das ist der einzige zuverlässige Schutz vor dem “letzten Mail-Klick” eines gestressten Kollegen.

Fazit

Die pragmatische Antwort für den KMU-Alltag ist ein gestaffeltes Modell: FIDO2 für alle privilegierten Zugänge (nicht verhandelbar), Push mit Number Matching für die tägliche Endnutzer-Anmeldung, TOTP als Fallback für Systeme ohne WebAuthn-Support. Wer noch nirgends MFA hat, startet mit TOTP flächendeckend und upgradet Admin-Konten binnen 30 Tagen auf FIDO2. Reine TOTP-Deployments für Admin-Rollen sind 2026 nicht mehr verteidigbar.

Die Investition in FIDO2-Hardware amortisiert sich beim ersten verhinderten Phishing-Vorfall — Faktor 100 oder mehr, wenn man Downtime, Forensik und mögliche Datenschutzverfahren einrechnet.

DATAZONE unterstützt Sie beim MFA-Rollout von der Bedrohungsanalyse über die Auswahl der passenden Authenticator-Hardware bis zur Integration in Authentik oder Keycloak — inklusive Anbindung Ihrer bestehenden Proxmox-, TrueNAS- und OPNsense-Infrastruktur. Sprechen Sie uns an, wir prüfen Ihre aktuelle MFA-Landschaft und liefern eine belastbare Roadmap.