Phishing-resistant MFA with open source: FIDO2 and passkeys

Phishing-resistant MFA with open source: why OTP and push fall short for federal and regulated logins

If your organization runs OTP or push MFA today and a federal contract or examiner now expects phishing resistance, the platform path is FIDO2 security keys and passkeys, verified by a self-hosted identity provider. Keycloak, privacyIDEA and ZITADEL all support WebAuthn-based authenticators, so the decision is less about whether open source can do this and more about which logins move first and what your users will carry. The starting point is understanding why the current methods fall short.

OTP codes and push approvals can be phished because the user is the one who releases the secret or approves the request. A convincing lookalike login page can capture a six-digit code and replay it within its validity window, and push fatigue attacks rely on users approving prompts they did not start. OMB M-22-09 addresses this directly: for routine self-service access by staff, contractors and partners, it tells agencies to discontinue authentication methods that fail to resist phishing, including SMS or voice codes, one-time codes and push notifications. It defines phishing-resistant authentication as processes designed to detect and prevent disclosure of authentication secrets and outputs to a masquerading site, and it permits FIDO2 and Web Authentication authenticators.

Before changing anything, inventory every login path that still uses OTP or push, including VPN, email, admin consoles and vendor access, and mark which ones are routine self-service versus exceptions. Then confirm with your auditor or contracting officer which requirement applies to your scope, since M-22-09 binds federal agencies and regulated examiners may ask for something different. Keycloak's WebAuthn support, privacyIDEA's FIDO2 and hardware key support and ZITADEL's passkeys each need to be tested against your user stores and applications before you commit to a sequence.

Which requirements shape a FIDO2 and passkey design

This table maps four federal and sector requirements to the design decisions they force on a self-hosted FIDO2 or passkey deployment. Read each row as a question to answer for your own environment: which logins are in scope, which authenticators are allowed, and what the audit trail must show. The main takeaway is that only the OMB memorandum sets a phishing-resistance bar, so the HIPAA and FTC rows are met by any MFA that meets their wording, while FIDO2 is the stronger choice wherever the scope applies.

Requirement	What it asks for	What it means for the build
OMB M-22-09: discontinue weak methods for routine self-service	Stop routine self-service access by staff, contractors and partners using SMS or voice codes, one-time codes and push notifications	Set token policy so these methods are not offered for in-scope logins. Confirm with your agency or contract office which M-22-09 scope applies to your relationship before you retire any method.
OMB M-22-09: definition of phishing-resistant authentication	Processes designed to detect and prevent disclosure of authentication secrets to a masquerading site, with FIDO2 and Web Authentication authenticators permitted	Use FIDO2 security keys or passkeys as the primary factor for in-scope logins in Keycloak WebAuthn, privacyIDEA or ZITADEL. Test that the relying party ID and origin checks are enforced for each application.
HIPAA 45 CFR 164.312: person or entity authentication and unique user identification	Verify that a person or entity seeking access is who they claim, and assign unique user identifiers to access ePHI systems where applicable	Disable shared logins and generic accounts on in-scope systems. Enroll each clinician or vendor user to a single identity in the directory so FIDO2 credentials bind to one account.
FTC Safeguards 16 CFR 314.4(c): MFA for any individual accessing information systems	Require multi-factor authentication for any individual accessing any information system at a covered financial institution, plus logging of authorized user activity	The rule does not specify phishing-resistant methods, so a FIDO2 design meets the MFA requirement but the choice is yours. Log every authentication event, enrollment, recovery and token change, and keep those logs with the access records.

Which logins can move to phishing-resistant MFA first

Start with the logins that give the most control for the least integration work: administrator accounts, remote access to internal web applications, and the federated single sign-on hub. In a Keycloak realm or a ZITADEL instance, a WebAuthn or passkey policy set once at the identity provider covers every application that signs in through it. Moving those accounts first gives the largest reduction in phishable exposure per change. Before enabling anything, confirm which applications are federated to the hub and which still hold local passwords, because those local logins sit outside the policy and need their own plan.

VPN and Windows or Linux logons usually need a separate path. A VPN typically authenticates over RADIUS, so the second factor is handled by the RADIUS server, and the key question is whether the VPN client and RADIUS flow can carry a FIDO2 challenge at all. Desktop logon depends on a credential provider on Windows and a PAM module on Linux, both of which are configured per host and tested separately. Plan a fallback for these systems during transition, such as a time-limited second factor that a help desk can reset, so that a failed key or a broken integration does not lock out remote staff or administrators.

Every exception must be written down. Service accounts, automation, and legacy clients that cannot perform a browser-based WebAuthn ceremony should appear on a register with an owner, the reason for the exception, the compensating control, and an expiry date. Review that register on a fixed schedule and close entries as clients are upgraded. Confirm with each vendor which of your clients support passkeys and which do not, since that answer determines how long the exception list will last.

Which open source platform fits FIDO2 and passkey MFA

Three open source platforms cover most FIDO2 and passkey requirements, but each fits a different starting point: an existing Keycloak estate, a second-factor layer in front of VPNs and operating system logins, or a multi-tenant identity platform. Confirm the passkey features you need against each product's current documentation before you commit to one.

Keycloak for web app passkeys

Keycloak is the most common choice when the target is web single sign-on, and it documents W3C WebAuthn, passkeys with conditional and modal UI, and recovery codes. It is Apache-2.0 licensed and a CNCF incubating project, which matters if your procurement rules favor permissive licenses. For high availability, plan for a synchronously replicated database, because both supported multi-cluster designs depend on it. Deploy the Operator with manual approval mode for updates so upgrades are scheduled, not automatic. Test the recovery code flow with help desk staff before rollout.

privacyIDEA for network and OS logins

privacyIDEA fits when FIDO2 keys must protect more than web apps, since it adds a PAM module for Linux, a credential provider for Windows logon and RADIUS for VPNs such as OpenVPN, Fortinet and Palo Alto. It also supports PIV and x509 smartcards, which helps where agencies already issue cards. It is AGPLv3 licensed, so confirm how that license applies to your deployment and any modifications. Check the passkey enrollment path and the offline behavior of each client before assuming coverage of your Windows fleet.

ZITADEL for multi-tenant passkeys

ZITADEL suits organizations that run one identity platform for several business units, customers or subsidiaries, because it separates tenants as instances and organizations with their own identity providers. It supports passkeys based on FIDO2 and WebAuthn with fallback to password login, which you should disable for privileged roles if policy requires phishing resistance. Its core moved to AGPL-3.0 with v3.0, while APIs and Helm charts stay Apache 2.0. Self-hosting requires PostgreSQL 14 through 18.

Confirm passkey support in authentik and Ory

authentik and the Ory stack (Kratos and Hydra) are also open source identity options, but this page does not supply verified detail on their passkey and FIDO2 features. Before shortlisting either, confirm the authenticator types, attestation handling, recovery flows and admin controls against your written requirements. Ask a partner to demonstrate each requirement in a test realm rather than relying on feature lists. authentik's enterprise directory carries a separate license, so confirm which features you need fall under it.

How to roll out passkeys in phases without locking people out

This sequence moves phishing-resistant logins into production one population and one system group at a time, so every phase has a tested recovery path before the next one starts. Each phase closes with a written output that the next phase depends on.

Inventory every login path and token type
Map each system that authenticates people, including web apps, VPN, Windows and Linux logons, SSH, admin consoles and vendor access, and record the factor each one accepts today, such as SMS, one-time codes, push or passwords only. Note which accounts are privileged, which are shared, and which service accounts cannot use interactive MFA at all. The output is a register with one row per login path, its current factor, its owner and its target phase. The step is done when the security team and system owners have signed off on the register.
Pilot with a small administrator group
Stand up a non-production Keycloak or ZITADEL realm, enable WebAuthn and passkeys with the policy you intend to use, and enroll a small group of administrators who already hold privileged access. Test each supported path in the pilot, including login on managed and unmanaged devices, sign-in through the admin console and the fallback to password login where it applies. The output is a pilot report listing the flows that worked, the ones that failed and the fixes applied. The step is done when the pilot group has used the keys through several normal working days.
Enroll hardware keys and passkeys with recovery
Issue hardware keys and register passkeys for the pilot group, and require at least two authenticators per account so that one lost key does not block access. Generate recovery codes, store them under a documented process, and write a help desk procedure that covers identity verification, temporary access, key revocation and re-enrollment. The output is an enrollment record for each account, a tested help desk runbook and a recovery drill that the help desk completes without engineering help. The step is done when a lost-key scenario has been walked through end to end.
Cut over routine self-service access
Move in-scope staff, contractors and partners from one-time codes and push to FIDO2 or passkeys for routine self-service access to the systems in the first production wave. Communicate the change, keep the old factor available only as a time-limited exception with a named owner, and monitor sign-in failures and help desk tickets during the cutover. The output is a cutover log, a list of accounts still on the old factor with reasons, and a decision record for retiring OTP and push for the wave. The step is done when the old factor is disabled for every in-scope population that is not on an approved exception.
Extend to VPN, Windows and Linux access
Bring the remaining login paths into scope using the integration designs covered in the sibling MFA pages for VPN and RADIUS, Windows logon and Linux or SSH. Confirm with the platform vendor or partner which of these paths accept FIDO2 directly and which need a stronger token or a different design, because a RADIUS or PAM path may not behave like a browser flow. The output is a per-system table showing the factor, the fallback, the offline behavior and the owner. The step is done when each path has a tested sign-in and a tested recovery route.
Review exceptions on a fixed cycle
Keep a single exception register for every account or system still using a weaker factor, service accounts that cannot use interactive MFA, and legacy applications. Review each entry on a schedule the security owner sets, confirm whether the business reason still holds, and close entries when the system moves. The output is a dated exception review record that shows what was approved, what was closed and what is still open. The step is complete as a recurring control once the first review has been recorded and the register is part of the identity governance evidence.

Hardware key logistics, recovery and lost-key handling

Recovery design comes before cutover, because a phishing-resistant factor that locks someone out is a help desk incident on day one. Before any user is moved off OTP or push, decide three things for every population: a second enrolled key or passkey, a recovery path that does not depend on the lost factor, and a help desk identity check that a caller cannot fake with a phone call. Keycloak documents recovery codes in its server administration guide, but the codes are only useful if they are issued at enrollment, stored by the user outside the device they are protecting, and tested in a pilot. Confirm the recovery path for each platform you deploy, whether that is Keycloak, privacyIDEA or ZITADEL, because the enrollment and reset flows differ and an administrator reset may be the only path on some of them.

Hardware key logistics are the part most projects underestimate. Procurement, shipping, inventory and enrollment need an owner who tracks which key is assigned to which identity, whether keys are shipped to a home address or collected on site, and what happens to a key when someone leaves. A roaming key such as a USB or NFC security key travels with the person and works across devices, so it suits shared workstations and contractors without managed laptops. A platform passkey lives in a device's secure hardware or synced credential manager, which is convenient on managed devices but ties the factor to that device or vendor ecosystem. Regional and remote staff need a shipping and replacement process that does not require a visit to headquarters, and contractors without managed devices need a decision on who buys and returns their keys. Ask the implementation partner to write these steps into the runbook before the pilot starts.

How the identity layer is deployed for phishing-resistant logins

This option fits organizations that already run Kubernetes and want the identity layer managed like other platform services. The Keycloak Operator is installed through Operator Lifecycle Manager, which the Keycloak documentation recommends, although kubectl and an experimental Helm chart are also documented. The Operator manages the Keycloak server, realm imports and OIDC and SAML client definitions as custom resources, so realm configuration can live in version control. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates, which keeps upgrades under change control.

Database: Keycloak supports PostgreSQL 14 to 18 among its production databases. Plan a database that the high availability design can replicate synchronously, because both supported multi-site designs require it.
High availability: Keycloak documents a single cluster that can span availability zones and a multi-cluster v2 design without an external Infinispan cluster. The v1 multi-cluster design is deprecated.
Upgrades: Schema migration runs automatically at startup by default. Large deployments can apply the SQL manually, as the upgrading guide suggests.
Passkeys: Enable the WebAuthn and passkey settings in the realm and test the conditional and modal sign-in flows with your browsers.
Operations: Keep metrics and recovery codes in the runbook from the first day.

Confirm with your platform team which Kubernetes distribution, database service and availability zone layout you will use, and whether your change process allows manual operator approval.

Evidence auditors and examiners ask for from passkey MFA

This table maps each piece of evidence an assessor typically asks for to the component that produces it and the owner who keeps it. Read it as a checklist for the evidence pack: DeployOpen prepares and organizes these records, but independent auditors and examiners decide whether they are sufficient. Keep each record tied to a date range so it covers the full review period.

Evidence	What it shows	Produced by	Where it usually fails
In-scope application inventory	Each application, VPN and admin console with the authentication method it uses (FIDO2, passkey, OTP or exception)	Keycloak clients or ZITADEL projects, plus the CMDB or asset list you maintain	Apps added outside the identity provider, or SaaS logins that still accept SMS or push
FIDO2 enrollment records	Which user registered which authenticator, when, and whether the key is attested or passkey-based	Keycloak WebAuthn registration events or privacyIDEA token records; ZITADEL passkey settings	Shared keys, unlisted enrollments, or keys that were never tied to a named user
Recovery code issuance log	When recovery codes were generated, who received them, and that each was used once	Keycloak recovery codes feature; help desk ticketing for identity verification steps	Recovery paths that fall back to SMS or email codes, which weaken the phishing-resistant claim
WebAuthn and passkey policy export	Required authenticator type, user verification setting, and which flows allow passkeys	Configuration export from the Keycloak realm or ZITADEL instance, stored under change control	Policies changed in the console with no export or version history
OTP and fallback policy export	Which OTP or push methods remain enabled, and where they are limited to exceptions	Keycloak OTP policies and authentication flows; privacyIDEA policies	Legacy OTP left enabled as a fallback for all users by default
Authentication logs by method	Each login with timestamp, user, application and the factor used	Keycloak event logs forwarded to a SIEM such as Wazuh; privacyIDEA audit log	Logs retained for too short a period, or method not recorded for SSO logins
Exception register	Service accounts, legacy clients and approved exceptions, with owner, reason, compensating control and expiry date	Your risk register, reviewed with the identity team; linked to Keycloak client IDs	Exceptions granted verbally and never recorded, or with no review date
Change records for platform upgrades	Versions deployed, test results, approvals and rollback steps for each Keycloak or privacyIDEA release	Change tickets, Keycloak Operator update approval records, and the database migration log	Automatic updates applied without an approval record, or no evidence of testing

Questions buyers ask about FIDO2 and passkey MFA cost, timing and effort

What drives the cost of hardware security keys and enrollment?

Hardware keys are a per-user purchase, and enrollment is labor, so the total depends on headcount, key model count and how many people need a spare. Software costs are usually lower than people expect: privacyIDEA, Keycloak and ZITADEL are open source, so license fees come from support subscriptions or partner services rather than per-user licenses. Enrollment effort grows with the number of identity stores, the number of users who need in-person verification and how many help desk calls each enrollment generates. Ask any quote to split one-time costs (keys, setup, integration, testing) from recurring costs (support, key replacement, help desk time, upgrades) and to state which systems are included.

How long does a phased FIDO2 rollout take?

No duration is meaningful until the scope is fixed, because the schedule depends on how many applications and identity sources must change, how many users enroll and how much change control your organization requires. A rollout usually starts with a small group of administrators and high-risk applications, then expands in phases once recovery and help desk steps are proven. Ask a partner to show the phases, the entry and exit criteria for each, and which items depend on your teams (approvals, access to identity stores, test accounts). Any timeline in a written scope should trace back to those named inputs.

What does our team need to provide before an engagement starts?

Three inputs decide most of the scope and schedule: an application inventory, a map of identity sources and a documented help desk process. The application inventory should list each login path, including VPN, email, admin consoles, SSH and internal web apps, with the protocol each uses (SAML, OIDC, RADIUS, PAM or Windows logon). The identity source map should cover directories such as Active Directory or LDAP, any HR system feeding them and which accounts are service or shared accounts. The help desk process should describe identity verification for resets, lost key handling and escalation. Gaps in any of these usually appear as change requests later, so ask for them to be listed in the written scope.

Can our internal staff run FIDO2 MFA without an outside partner?

Yes, many teams run the platform themselves, but the work needs people who can operate identity infrastructure, not only install software. Internal staff typically need skills in directory integration, the chosen protocol (OIDC, SAML, RADIUS or PAM), database and high availability operations, certificate handling and incident response for locked-out users. Keycloak documents an Operator and multiple high availability designs that require a synchronously replicated database, and privacyIDEA and ZITADEL have their own installation and database requirements. Partners are often used for the initial build, integration testing, hardening and documented runbooks, with internal teams taking over operations. Confirm your capacity against those tasks before choosing a model.

What happens when a user loses a hardware security key?

A lost key should never be replaced by a weaker factor without a verified identity check, so the recovery path must be designed before rollout. Most designs give users a second registered authenticator, such as a spare key stored in a secure location, and a supervised reissue process through the help desk. Keycloak supports recovery codes as a documented option, which can be issued and tracked, while privacyIDEA and ZITADEL offer their own enrollment and recovery workflows that your team should test. Write down who can approve a reissue, how identity is confirmed, how the old key is revoked and how the event is logged for audit.

Do passkeys replace hardware keys, and what changes for shared devices?

Passkeys based on FIDO2 and WebAuthn can replace some hardware key use cases, but not every one, and the answer depends on the device, the platform and the policy you set. Keycloak documents passkeys with conditional and modal user interfaces, and ZITADEL supports passwordless passkey login with password fallback. Shared devices need extra design: a passkey tied to one person's device or account can be a problem on a workstation used by several staff, so teams often keep hardware keys for shared or privileged use. Confirm with each application owner whether passkeys are stored on personal devices, whether roaming keys are required and how fallback is handled when a password remains enabled.

Which platform should we pick: Keycloak, privacyIDEA or ZITADEL?

Choose by the systems you must protect first, not by brand. Keycloak is a strong fit when applications speak SAML or OIDC and you want a single identity server with WebAuthn, passkeys and OTP policies. privacyIDEA fits when VPNs, Windows and Linux logins, RADIUS, PAM and smartcards must be covered, because it integrates through a PAM module, a Windows credential provider and RADIUS. ZITADEL is worth evaluating when multi-tenant customer or partner organizations need separate identity providers and SCIM provisioning, and it uses PostgreSQL with a Helm chart for Kubernetes. Many organizations combine tools, so write the integration list first and test each candidate against it.

How are upgrades handled given Keycloak's release cadence?

Keycloak plans four minor releases a year, and since version 26.0 breaking changes in minor releases are opt-in, according to the project's October 2024 release notes. The current release is 26.8.1, published October 13, 2026, so a team on an older version needs a planned upgrade path rather than occasional patching. The Keycloak Operator documentation strongly recommends manual approval mode to avoid unintended upgrades, and database schema migration runs automatically at startup by default, though manual SQL migration is available for large deployments. Ask for a written upgrade procedure that includes a staging test, a database backup, rollback steps and a review of the upgrading guide for each target version.

What to ask an implementation partner before you commit

Start with the definition. Ask the partner to state, in writing, which authenticators they classify as phishing-resistant and why. OMB M-22-09 describes phishing-resistant authentication in terms of preventing disclosure of secrets and outputs to a masquerading site, and it permits FIDO2 and Web Authentication authenticators. Ask whether a passkey synced through a cloud provider counts, whether a privacyIDEA or Keycloak user can fall back to OTP or push during enrollment, and which fallback paths remain enabled after go-live. A partner who cannot answer these precisely has not designed the control yet.

Next, ask which M-22-09 scope they assume. The memo targets routine self-service access by staff, contractors and partners, so the partner should name the applications in that population, the ones excluded and the reason for each. Ask how they handle exceptions and service accounts, since automation and legacy clients often cannot complete a WebAuthn ceremony. Request the exception register format, the approver role and the expiry rule. Also ask how key procurement and recovery are designed: who issues keys, how lost keys are revoked in Keycloak or privacyIDEA, what recovery codes or a second enrolled key are allowed, and how the help desk verifies identity before re-enrollment.

Then cover availability, data and change control. Ask which database the partner will run, given Keycloak's supported production databases and the requirement for synchronous replication in its high availability designs, and for ZITADEL, its PostgreSQL versions. Ask for the upgrade approval process, including whether the Keycloak Operator runs in manual approval mode and whether database schema migration runs at startup or as reviewed SQL. Finally, require the evidence package in the written scope: enrollment and recovery test results, configuration exports, admin audit logs and a decision record explaining why the chosen platform fits. Ask whether the partner tests the enrollment and recovery paths, not only login. Confirm all deliverables and timelines in writing before any work starts.

How DeployOpen scopes and builds phishing-resistant MFA

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source identity platforms inside the client's own infrastructure. For phishing-resistant MFA, that means agreeing in writing which logins move to FIDO2 or passkeys first, then building and evidencing that change in your environment.

How we scope

Engagements are fixed-scope, with the systems, login paths and deliverables agreed in writing before work starts.
Scope lists which applications, VPNs, admin consoles and operating system logins move to FIDO2 or passkeys, and which keep an interim method.
Scope records the authenticator types in use, such as hardware keys, passkeys or smartcards, and who is enrolling them.
Scope defines the recovery path, including recovery codes, help desk steps and replacement key issuance.

How we build

We deploy the chosen platform, such as Keycloak WebAuthn, privacyIDEA or ZITADEL, inside your cloud accounts, data centers or air-gapped networks.
We configure WebAuthn and passkey policies, OTP fallback rules and relying party settings for each agreed application.
We integrate the MFA platform with the in-scope systems and test each login path against a phishing simulation before cutover.
We run security testing on the authentication flows, including the recovery and enrollment paths that attackers often target.

How we hand over

We document the enrollment procedure, recovery steps, key lifecycle and policy settings so your staff can operate the platform.
We deliver configuration exports and evidence that show which systems require phishing-resistant authentication and when they were set.
We document the upgrade and backup procedures for the platform, including database and high availability design.
We prepare control evidence for your compliance assessor, while the auditor or certification body makes the formal determination.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
A retainer can cover platform upgrades, reviews of new applications added to the phishing-resistant scope, and periodic recovery tests.
Ask any partner to confirm response commitments and service levels in the written agreement before you sign.