In 2026, passwords remain the weakest link in any SMB IT stack. Real-time proxy phishing kits bypass TOTP codes, MFA push fatigue leads to compromised Microsoft 365 tenants, and the helpdesk spends a significant share of its time on password resets. Passkeys — FIDO2/WebAuthn credentials — are the first authentication method that solves these problems structurally: they are phishing-resistant through origin binding, require no shared secret store, and can be made as simple for end users as a fingerprint.
In this article we show what a realistic SMB passkey rollout looks like in 2026: from a self-hosted identity provider through hardware selection to the migration away from password plus TOTP — including a fallback strategy for lost keys and stolen laptops.
Why passkeys, why now
A passkey is an asymmetric key pair following the WebAuthn standard. The private key never leaves the device (or for synced passkeys: never leaves the vendor ecosystem), while the public key is stored at the identity provider. On login, the device signs a challenge bound to the exact origin (the domain). A spoofed login portal on authentik-login.com simply cannot produce that signature, even if the user approves it.
Three developments make 2026 the right time for the rollout:
- Broad platform support: Windows 11 24H2, macOS 15, iOS 18 and Android 15 support passkeys natively through their respective credential managers.
- Mature self-hosted IdPs: Authentik 2026.4 and Keycloak 26 offer production-ready WebAuthn flows including conditional UI and discoverable credentials.
- Compliance pressure: NIS2 and the updated BSI baseline protection modules explicitly recommend phishing-resistant MFA — TOTP is no longer considered sufficient for privileged access.
Self-hosted IdP: Authentik vs. Keycloak
For SMBs there are practically two open-source options. Both run comfortably on a Proxmox cluster as an LXC or VM with moderate load:
| Criterion | Authentik 2026.4 | Keycloak 26 |
|---|---|---|
| Passkey support | Native, discoverable credentials, conditional UI | Native, resident keys since v25 |
| Admin UX | Modern, flow-based, clear policy model | Powerful, but steep learning curve |
| Resource footprint | 2 vCPU, 4 GB RAM, Postgres | 4 vCPU, 8 GB RAM, Postgres |
| Protocols | OIDC, SAML, LDAP, RADIUS, SCIM | OIDC, SAML, LDAP, SCIM |
| Outpost concept | Yes — proxy for legacy apps | No, external solution needed |
| License | MIT, optional Enterprise tier | Apache 2.0 |
For most SMBs with 30 to 300 employees we recommend Authentik. The flow model makes complex scenarios — passkey-required for admins, passkey-optional for standard users — expressible without code. The outpost proxy also makes it possible to put legacy web apps without SSO support behind passkey authentication.
Hardware choice: YubiKey vs. platform passkey
The most important strategic decision in the rollout: do you bet on hardware tokens (YubiKey 5 Series, Token2 PIN+), platform passkeys (Windows Hello, Touch ID, iCloud Keychain) or a hybrid? We recommend a tiered model:
Privileged accounts (admins, executives, finance): Two YubiKey 5C NFC per person — one on the keyring, one in the safe. Cost: roughly 110 EUR per hardware token. No sync, no cloud backup, clear custody. These keys are used exclusively for high-privilege logins.
Standard users: Platform passkeys via Windows Hello (for domain-joined devices with TPM 2.0) or, for BYOD, the platform-native credential managers. Advantage: onboarding under 60 seconds, no hardware procurement process, automatic sync to a second device via iCloud Keychain or Google Password Manager.
Mixed field-work setup: A YubiKey 5C NFC as a roaming authenticator plus a platform passkey on the primary device. If the device is lost, the hardware token is the recovery path.
Migration: from password plus TOTP to passkey-only
The typical starting state: Microsoft 365 with Authenticator app, a few internal apps via VPN with local AD login, perhaps an Atlassian tenant with its own credentials. A realistic 12-week migration path looks like this:
Week 1 to 2 — IdP setup: Deploy Authentik on the existing Proxmox environment, set up Postgres backups, federate against the existing AD via LDAP. First test integration of Microsoft 365 as a SAML service provider.
Week 3 to 4 — pilot with IT team: Configure a WebAuthn stage in the Authentik flow, the pilot group registers passkeys in parallel with the existing login. Example configuration for the 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
Week 5 to 8 — staged rollout: Department-by-department 30-minute onboarding sessions. Each employee registers at least two authenticators — typically a platform passkey plus a backup token or a second device. Password plus TOTP remains active in parallel.
Week 9 to 10 — passkey-first: In the login flow, passkey becomes the default method, password is only reachable via “choose another method”. Helpdesk tickets are closely monitored.
Week 11 to 12 — password deprecation: For all accounts with a registered passkey, password login is disabled. The recovery flow remains as an exception. Passwords in the IdP are reset to random 64-character values and no longer communicated.
Fallback strategy: what if the key is gone
The most common SMB concern: “What if an employee loses their phone and cannot get into the system in the morning?” A resilient recovery strategy has three layers:
- Multiple authenticators per account: minimum two is mandatory. Loss of one device is then a routine helpdesk case, not an incident.
- Recovery codes: Authentik generates eight single-use codes at setup. These are printed and stored in the personal safe or with the manager — never digitally.
- Helpdesk reset with out-of-band verification: the admin can temporarily unlock an account for a new passkey registration. Mandatory: video verification plus callback to a number on file in the HR system.
You should document the third path as a runbook and test it at least once per quarter. A dedicated Linux-based recovery workstation used solely for this purpose reduces the risk that the reset process itself is compromised.
What you must not forget
Three points are regularly underestimated in rollout projects: first, every service account and CI/CD system still needs its own authentication strategy — typically OIDC client credentials or mTLS, not passkeys. Second, legacy applications without SAML or OIDC support are integrated via the Authentik outpost proxy, which means DNS adjustments on the OPNsense. Third, the IdP backup — including Postgres and encryption keys — must be wired into the existing backup concept, otherwise the IdP becomes a single point of failure.
DATAZONE supports your passwordless rollout
We accompany mid-sized companies in Bavaria and across Germany from the first architecture sketch to passkey-only day X: Authentik deployment on your Proxmox environment, federation against your existing Active Directory, hardware procurement, and onboarding sessions for your staff. Talk to us — in a no-obligation initial conversation we will outline what a realistic migration plan looks like for your environment. More at Contact.
More articles
OPNsense VLAN Routing: 6 Best Practices for SMB Networks
Plan OPNsense VLAN routing right: management isolation, per-VLAN DHCP, default-deny, MAC tracking, Unbound views and IoT segmentation explained.
GDPR Logging Requirements 2026: What to Log and What Not To
GDPR-compliant logging in 2026: mandatory security and PII access logs, forbidden fields, retention periods, and pseudonymization in ELK and Loki.
fail2ban Jail Templates for Typical SMB Servers
Production-ready fail2ban jails for SSH, Postfix, Dovecot, Nextcloud, Vaultwarden and Authentik. Includes recidive configuration and Cloudflare integration.