Passkeys im Mittelstand: passwortlos in 2026

Passwörter sind 2026 das schwächste Glied in jeder Mittelstands-IT. Phishing-Kits mit Echtzeit-Proxy umgehen TOTP-Codes, MFA-Push-Fatigue führt zu kompromittierten Microsoft-365-Tenants, und der Helpdesk verbringt einen erheblichen Teil seiner Zeit mit Passwort-Resets. Passkeys — also FIDO2/WebAuthn-Credentials — sind die erste Authentifizierungsmethode, die diese Probleme strukturell löst: Sie sind Phishing-resistent durch Origin-Bindung, benötigen keinen geteilten Geheimnis-Speicher und lassen sich für Endanwender so einfach gestalten wie ein Fingerabdruck.

In diesem Artikel zeigen wir Ihnen, wie ein realistischer Passkey-Rollout im Mittelstand 2026 aussieht: vom Self-hosted Identity Provider über die Hardware-Wahl bis zur Migration weg von Passwort plus TOTP — inklusive Fallback-Strategie für verlorene Schlüssel und gestohlene Laptops.

Warum Passkeys, warum jetzt

Ein Passkey ist ein asymmetrisches Schlüsselpaar nach dem WebAuthn-Standard. Der private Schlüssel verlässt niemals das Gerät (oder bei synchronisierten Passkeys: niemals das Vendor-Ökosystem), der öffentliche Schlüssel wird beim Identity Provider hinterlegt. Beim Login signiert das Gerät eine Challenge, die an die exakte Origin (also Domain) gebunden ist. Ein gefälschtes Login-Portal auf authentik-login.com kann diese Signatur schlicht nicht erzeugen, selbst wenn der Nutzer sie freigibt.

Drei Entwicklungen machen 2026 zum richtigen Zeitpunkt für den Rollout:

1. Breite Plattform-Unterstützung: Windows 11 24H2, macOS 15, iOS 18 und Android 15 unterstützen Passkeys nativ über die jeweiligen Credential Manager.
2. Reife Self-hosted IdPs: Authentik 2026.4 und Keycloak 26 bieten produktionsreife WebAuthn-Flows inklusive Conditional UI und Discoverable Credentials.
3. Compliance-Druck: NIS2 und die novellierte BSI-Grundschutz-Kompendium-Bausteine empfehlen explizit Phishing-resistente MFA — TOTP gilt nicht mehr als ausreichend für privilegierte Zugriffe.

Self-hosted IdP: Authentik vs. Keycloak

Für den Mittelstand kommen praktisch zwei Open-Source-Optionen in Frage. Beide laufen problemlos auf einem Proxmox-Cluster als LXC oder VM mit moderater Last:

Kriterium	Authentik 2026.4	Keycloak 26
Passkey-Support	Nativ, Discoverable Credentials, Conditional UI	Nativ, Resident Keys ab v25
Admin-UX	Modern, Flow-basiert, klares Policy-Modell	Mächtig, aber steile Lernkurve
Ressourcen-Bedarf	2 vCPU, 4 GB RAM, Postgres	4 vCPU, 8 GB RAM, Postgres
Protokolle	OIDC, SAML, LDAP, RADIUS, SCIM	OIDC, SAML, LDAP, SCIM
Outpost-Konzept	Ja — Proxy fuer Legacy-Apps	Nein, externe Lösung nötig
Lizenz	MIT, Enterprise-Tier optional	Apache 2.0

Für die meisten SMBs mit 30 bis 300 Mitarbeitern empfehlen wir Authentik. Das Flow-Modell macht komplexe Szenarien — etwa Passkey-Pflicht für Admins, Passkey-optional für Standard-User — ohne Code abbildbar. Der Outpost-Proxy ermöglicht es zudem, Legacy-Webanwendungen ohne SSO-Support hinter eine Passkey-Authentifizierung zu setzen.

Hardware-Wahl: YubiKey vs. Platform Passkey

Die wichtigste strategische Entscheidung im Rollout: Setzen Sie auf Hardware-Token (YubiKey 5 Series, Token2 PIN+), Platform Passkeys (Windows Hello, Touch ID, iCloud Keychain) oder eine Mischform? Wir empfehlen ein abgestuftes Modell:

Privilegierte Accounts (Admins, Geschäftsführung, Finanzbuchhaltung): Zwei YubiKey 5C NFC pro Person — einer am Schlüsselbund, einer im Tresor. Kosten: ca. 110 Euro pro Hardware-Token. Kein Sync, kein Cloud-Backup, klare Custody. Diese Schlüssel werden ausschliesslich für hochprivilegierte Logins genutzt.

Standard-Anwender: Platform Passkeys über Windows Hello (für Domain-Joined Devices mit TPM 2.0) oder bei BYOD über die plattform-eigenen Credential Manager. Vorteil: Onboarding in unter 60 Sekunden, kein Hardware-Beschaffungsprozess, automatischer Sync auf das Zweitgerät über iCloud Keychain oder Google Password Manager.

Mischeinsatz im Aussendienst: Ein YubiKey 5C NFC als Roaming Authenticator, zusätzlich Platform Passkey auf dem Hauptgerät. Bei Geräteverlust ist der Hardware-Token der Recovery-Pfad.

Migration: Vom Passwort plus TOTP zum Passkey-only

Der typische Ausgangszustand: Microsoft 365 mit Authenticator-App, ein paar interne Apps via VPN mit lokalem AD-Login, vielleicht ein Atlassian-Tenant mit eigenen Credentials. Ein realistischer Migrationspfad über 12 Wochen sieht so aus:

Woche 1 bis 2 — IdP-Setup: Authentik auf der bestehenden Proxmox-Umgebung deployen, Postgres-Backup einrichten, gegen den bestehenden AD per LDAP federieren. Erste Test-Anbindung von Microsoft 365 als SAML-Service-Provider.

Woche 3 bis 4 — Pilot mit IT-Team: WebAuthn-Stage im Authentik-Flow konfigurieren, Pilot-Gruppe registriert Passkeys parallel zum bestehenden Login. Beispiel-Konfiguration für die Authentik Flow Stage:

name: passkey-required
authenticator_validate_stage:
  device_classes:
    - webauthn
  webauthn_user_verification: required
  not_configured_action: configure
  configuration_stages:
    - webauthn-setup-stage
last_auth_threshold: hours=8

Woche 5 bis 8 — Gestaffelter Rollout: Abteilungsweise Onboarding-Sessions à 30 Minuten. Jeder Mitarbeiter registriert mindestens zwei Authentifikatoren — in der Regel ein Platform Passkey plus ein Backup-Token oder ein zweites Gerät. Parallel bleibt Passwort plus TOTP aktiv.

Woche 9 bis 10 — Passkey-First: Im Login-Flow wird Passkey zur Default-Methode, Passwort nur noch über “Andere Methode wählen” erreichbar. Helpdesk-Tickets werden eng beobachtet.

Woche 11 bis 12 — Passwort-Deprecation: Für alle Accounts mit registriertem Passkey wird der Passwort-Login deaktiviert. Ausnahme bleibt der Recovery-Flow. Passwörter werden im IdP auf zufällige 64-Zeichen-Werte gesetzt und nicht mehr kommuniziert.

Fallback-Strategie: Was, wenn der Schlüssel weg ist

Die häufigste Sorge im Mittelstand: “Was, wenn ein Mitarbeiter sein Handy verliert und morgens nicht ins System kommt?” Eine belastbare Recovery-Strategie hat drei Ebenen:

1. Mehrere Authentifikatoren pro Account: Pflicht ist mindestens zwei. Verlust eines Geräts ist dann ein normaler Helpdesk-Vorgang, kein Notfall.
2. Recovery-Codes: Authentik generiert beim Setup acht einmalig verwendbare Codes. Diese werden ausgedruckt und im persönlichen Tresor oder beim Vorgesetzten hinterlegt — nie digital gespeichert.
3. Helpdesk-Reset mit Out-of-Band-Verifikation: Der Admin kann einen Account temporär für eine erneute Passkey-Registrierung freischalten. Pflicht ist eine Video-Verifikation plus Rückruf auf eine im HR-System hinterlegte Nummer.

Den dritten Pfad sollten Sie als Runbook dokumentieren und mindestens einmal pro Quartal testen. Eine Linux-basierte Recovery-Workstation mit ausschliesslich diesem Zweck reduziert das Risiko, dass der Reset-Prozess selbst kompromittiert wird.

Was Sie nicht vergessen dürfen

Drei Punkte werden in Rollout-Projekten regelmässig unterschätzt: Erstens braucht jeder Service-Account und jedes CI/CD-System weiterhin eine eigene Authentifizierungsstrategie — typischerweise OIDC Client Credentials oder mTLS, nicht Passkeys. Zweitens sind Legacy-Anwendungen ohne SAML- oder OIDC-Support per Authentik-Outpost-Proxy einzubinden, was DNS-Anpassungen auf der OPNsense bedeutet. Drittens muss das Backup des IdP — inklusive Postgres und Encryption Keys — in das bestehende Backup-Konzept eingebunden werden, sonst wird der IdP zur Single Point of Failure.

DATAZONE unterstützt Sie beim passwortlosen Rollout

Wir begleiten mittelständische Unternehmen aus Bayern und ganz Deutschland von der ersten Architektur-Skizze bis zum Passkey-only-Tag X: Authentik-Deployment auf Ihrer Proxmox-Umgebung, Federation gegen Ihr bestehendes Active Directory, Hardware-Beschaffung und Onboarding-Sessions für Ihre Mitarbeiter. Sprechen Sie uns an — wir zeigen Ihnen in einem unverbindlichen Erstgespräch, wie ein realistischer Migrationsplan für Ihre Umgebung aussieht. Mehr unter Kontakt.