How authentik passkeys and WebAuthn fit a passwordless rollout
authentik's WebAuthn support is the mechanism behind both passkeys and hardware security keys, so the answer to your question is that it can cover both, but the two use cases are configured differently. WebAuthn is the browser standard that lets a user register a FIDO2 credential and prove possession of it at sign-in. A platform passkey stored on a laptop or phone and a roaming security key plugged into a USB port both use this standard, so the decision you face is which credential types to allow for which users, not whether authentik can handle either one. Teams usually need this for phishing-resistant multi-factor authentication for administrators and finance staff, for passwordless sign-in for the wider workforce, or for replacing SMS and email codes that attackers can intercept or redirect.
Enrollment in authentik is handled by flow stages and policies inside your own deployment, so the rollout is a configuration and policy project that your team, or a partner working in your infrastructure, carries out on the instance you already run. The work involves deciding which stage prompts users to register a credential, which groups see it, whether the flow runs during first login or from a user's self-service settings, and how a user who loses every registered device recovers access. Each of these choices affects helpdesk load and lockout risk, so they should be written down before the first pilot group is enrolled. Confirm the exact stage and setting names, and how each behaves, in the authentik documentation for the version you run. The supported release lines are 2026.5.x and 2026.8.x, and the release notes for your version are the reference for any behavior change.
Enrollment settings and authenticator restrictions to decide before rollout
This table compares the configuration decisions teams make before enabling passkeys in authentik, including first or second factor use, user verification, resident keys, authenticator types and model restrictions. Read each row as a choice with a usability cost on one side and an assurance or recovery cost on the other, then confirm the setting names and defaults in the current authentik documentation for your release.
| Decision | Option and when it fits | Trade-off | What to confirm in authentik |
|---|---|---|---|
| Passkey role in sign-in | First factor (passwordless) for users who can sign in with a device and no password, or second factor where passwords stay in place during rollout | Passwordless removes password theft risk for enrolled users but makes device loss and recovery the main risk; second factor is simpler to introduce but keeps password exposure | Which stages accept WebAuthn as a first or second factor, and how the identification and authentication flows order them |
| User verification: required | Use when the account or application needs proof of the person at the authenticator, such as a PIN or biometric prompt on every use | Strongest local check, but some older keys or browsers may lack support, which adds help-desk tickets | The user verification field on the WebAuthn stages, and which authenticator types honor it |
| User verification: preferred | Use when you want verification where the authenticator supports it without blocking enrollment of simpler keys | Mixed assurance: some sign-ins verify the user and others do not, which auditors may question | Whether the setting is passed to the browser as a preference and how it is recorded in the event log |
| User verification: discouraged | Use only for narrow cases such as a tap-only key in a low-risk second factor step | Lowest friction, but weakens the claim that the passkey proves the person, so it rarely suits passwordless sign-in | Whether discouraged is offered at all for your flow, and the default value on new stages |
| Resident key (discoverable credentials) | Required or preferred when users should pick an account from the login page without typing a username, typical for passwordless sign-in | Credentials are stored on the authenticator, which helps usability but makes an authenticator with a stored account more sensitive to loss | The resident key setting on the enrollment stage and whether your target authenticators store discoverable credentials |
| Platform authenticators | Allow when users sign in with built-in laptop or phone passkeys, which is common for staff on managed devices | Easy to use and synced by some platforms, but sync scope depends on the vendor's cloud account, which you may not control | Whether platform authenticators are selectable on your enrollment stage and how sync impacts your recovery plan |
| Roaming security keys | Allow when privileged or high-risk users should carry a dedicated hardware key that is not tied to a personal device | Stronger separation and easier revocation, but needs a procurement, distribution and lost-key process | Whether roaming keys can be the only enrolled method and how to require at least one backup authenticator |
| Restrict by authenticator model (vendor or attestation) | Use when policy requires only approved hardware models, identified by vendor or attestation data | Tighter control, but attestation data depends on the authenticator and browser, and an approved model list needs upkeep as hardware changes | Whether attestation is requested at enrollment, which attestation fields authentik can match, and where allowed models are configured |
Choosing passkey settings by user group and environment
Office staff on managed laptops and phones are usually the group where passkeys deliver the most day-to-day value, because they sign in often and use a small set of devices. Passkey settings for this group typically favor a flow that lets users enroll a passkey alongside an existing second factor, so a lost or replaced device does not block sign-in. Verification settings should be set with your identity policy in mind, since requiring user verification changes what the authenticator asks for at sign-in.
- Enrollment path: Offer passkey enrollment in the same stage that handles other factors, and confirm the fallback path still works when a user changes phones.
- Verification level: Decide whether user verification is required or preferred, and test the prompt on each managed laptop model and OS build you support.
- Device and browser checks: Confirm the browsers in your standard image handle passkeys and that your mobile device management policy does not block the platform authenticator.
- Support load: Expect most tickets around first enrollment and device replacement, so write a short self-service guide and a recovery route before launch.
- Pilot group: Start with a small department and track enrollment completion before expanding.
Before rollout, test with your own device inventory rather than assuming support across models and browsers.
Privileged administrators are the group where hardware security keys are the usual choice, because a key bound to a physical device and protected by user verification gives a stronger position than a synced credential on a general-purpose phone. Settings for this group should restrict which authenticator models are allowed, so that only keys your security team has approved can be enrolled. Keep at least one recovery method that does not depend on the same key, and plan for admins who lose or break a key.
- Authenticator restriction: Limit enrollment to approved key models and check the allowed-authenticator settings against the models you have purchased.
- User verification: Require verification for admin sign-in so that possession of a key alone is not enough.
- Backup keys: Require two registered keys per administrator and store the second key in a separate location.
- Recovery process: Define who can reset an admin factor, how identity is confirmed and how the event is logged.
- Support load: Expect fewer tickets but higher urgency, so agree on an out-of-hours path for lockouts.
Confirm with your key vendor that the models you select work with the browsers your administrators use, and test a full recovery drill.
Shared or kiosk workstations, such as clinical terminals, plant floor computers and reception desks, are where passkeys may be unsuitable. A passkey is tied to a person and a device, while shared machines often have several users, automatic logouts and sessions that persist after a shift change. Before enabling passkeys for these users, decide whether they should sign in with a passkey at all, or whether a different flow, such as a badge or a short-lived code, fits the workflow better.
- Suitability check: Confirm whether each shared device can hold a user credential safely and whether a platform authenticator can be used at all.
- Scope limits: Restrict passkey enrollment on kiosk-profile accounts and keep these users on flows you have already reviewed.
- Session handling: Set session lifetimes and confirm that a passkey sign-in does not leave the previous user signed in.
- Device inventory: List which terminals, browsers and peripherals are in use, since many shared endpoints are locked down in ways that block passkey prompts.
- Support load: Expect troubleshooting on locked-down images and prompts that appear at unexpected times, so involve the site support team early.
Run the sign-in and sign-out sequence on each terminal model before deciding.
External users and contractors often sign in from devices your organization does not manage, and their enrollment may be handled by a sponsor rather than by your help desk. Passkey settings here should reflect how long the account exists, which devices they use and what they can reach. Short-lived accounts may not justify a full passkey enrollment, while longer engagements benefit from a stronger factor with a clear offboarding path.
- Device trust: Assume unmanaged devices and browsers, and set verification and session rules that reflect that risk.
- Enrollment ownership: Decide whether contractors enroll themselves, whether sponsors approve enrollment, and who removes credentials at contract end.
- Recovery: Use a recovery route that does not require your internal help desk to verify identity from memory alone.
- Support load: Expect more self-service questions and cross-time-zone support, so publish plain instructions and a contact path for the sponsoring team.
- Offboarding link: Tie credential removal to the account end date so that registered passkeys do not outlive the engagement.
Confirm each contractor's device and browser situation during onboarding rather than assuming it.
Rolling out authentik passkeys and security keys in phases
This sequence moves authentik from a single enrollment setting to passkey and security key use across the organization, with a checkpoint at each stage so problems surface in a pilot rather than during a company-wide change. Each step ends with a result you can verify before moving on.
Confirm version, domain and HTTPS
The platform team confirms which authentik version the instance runs and checks that it is on a version that still receives security fixes, using the project's security policy. They confirm the public domain users sign in through, that it resolves correctly and that it is served over HTTPS with a valid certificate. WebAuthn credentials are bound to this domain, so the domain must be settled before any enrollment. Done when the login page loads over HTTPS on the intended domain and the version is recorded in the change ticket.
Define authenticator policy and user groups
The security lead and the IAM owner decide which authenticator types are allowed, whether user verification is required, and which groups get passkeys first. Write these decisions down, including how a user without a compatible device will still sign in. Confirm with your own environment and the authentik documentation which authenticator model restrictions the installed version supports. Done when the policy is approved and the pilot group is populated in authentik.
Configure the WebAuthn enrollment stage
An administrator creates the WebAuthn enrollment stage in authentik, sets user verification and the allowed authenticator options according to the approved policy, and binds it to the relevant flows: enrollment, authentication and recovery. Binding the stage to all three ensures users can register a key, sign in with it, and re-enroll after losing a device. Done when each flow lists the stage in the expected order and a test user can start enrollment from the flow.
Pilot on a non-production instance
Run the same configuration on a non-production authentik instance with the same public domain pattern and a small group of volunteers. The pilot tests the configuration before production users depend on it and gives the help desk real tickets to practice with. Keep a rollback path such as reverting the flow binding. Done when pilot users have enrolled at least one passkey and one hardware security key without administrator intervention.
Test passwordless login across browsers and devices
Testers sign in from several browsers and operating systems, using a platform passkey and a physical security key. They test discoverable credential login with no username entered, passkey autofill on the sign-in page, and a sign-in with a password where the flow still allows it. Confirm that the relying party matches the domain, and that a passwordless test login succeeds without a password. Done when every browser and device combination on the test matrix has a documented pass or a logged defect.
Verify enrollment and sign-in events in logs
Before expanding, the operations team checks that enrollment, failed attempts and successful passwordless sign-ins appear in the authentik event log and reach the log destination your monitoring uses. This evidence supports both troubleshooting and later audit questions about how a user authenticated. Done when a test enrollment and a test sign-in each produce a matching event that the team can find and query.
Expand in waves with help desk guidance
Roll out to additional groups in waves rather than all at once. Before each wave, the help desk receives short guidance on enrollment steps, lost-key recovery through the recovery flow, and the sign-in errors pilot users reported. Review enrollment and failure events after each wave before starting the next. Done when each wave's enrollment rate and open tickets have been reviewed and the next group is approved.
Security risks in passkey enrollment and sign-in
Passkeys remove the password, but they move the trust decision to enrollment, origin checks and the audit trail behind them. The cards below pair each risk with the control to apply in authentik and the evidence to confirm before rollout.
Enrollment by a stolen session
A user with a hijacked session can register a new passkey and then sign in without ever knowing the password. Restrict the enrollment flow to users who have already completed a strong factor, and require re-authentication before a new credential is added. Check which stages and policies gate the enrollment flow in your tenant and whether a recent-login condition can be applied to it.
Weak enrollment policy
If the enrollment stage accepts any authenticator without a verification requirement, a passkey can be registered on a device the account owner never controlled. Set user verification to required on the enrollment stage so that enrollment checks the user's biometric or PIN, not only the presence of a key. Test enrollment with a plain security key and with a platform passkey to confirm the behavior you want for each.
Origin misconfiguration behind a proxy
WebAuthn credentials are bound to the domain where they were created, so a wrong public URL or forwarded host header can make passkeys fail or, in a poor setup, accept sign-ins on an unexpected origin. Confirm that the reverse proxy forwards the correct host and protocol headers, and that authentik's configured domain matches the address users type. Verify sign-in from each hostname you serve.
Overly permissive authenticator models
Allowing every authenticator model lets users enroll low-assurance or unapproved hardware. Restrict allowed authenticator models to the vendors and device types your policy approves, and review the list when you add a new hardware line. Ask your vendor and your testers how the current release identifies authenticator models, because the matching method determines how strict the restriction really is.
Shared credentials on unmanaged devices
Platform passkeys can sync through a personal account, so a credential created on an unmanaged laptop or phone may be available on devices your organization does not control. Decide which passkey types are acceptable for each user group, and document where synced credentials are allowed. Confirm with your security team how discoverable credentials are handled on shared or unmanaged endpoints before you enable passwordless login broadly.
Missing audit trail for enrollment changes
Passkey registration and removal events are the evidence an assessor or incident responder will ask for. Make sure enrollment, deletion and failed verification attempts reach your central log store, and that someone can tie each event to a user and a device. Confirm how the current authentik release records these events and how long they are retained before you rely on them.
How account recovery works when a passkey is lost
Recovery decides whether a passwordless rollout holds up in production. A lost phone, a wiped security key or a departed employee can lock someone out of every application behind authentik, and the help desk will receive those requests on day one. Design recovery before you enable passkeys for anyone, because a rollout without a tested recovery path tends to fall back to weaker methods under pressure.
Several design choices reduce the impact. Require each user to keep a second enrolled credential, such as a second security key or a platform passkey on another device, so that losing one device does not end access. Where a second credential is not practical, define a supervised re-enrollment path in which the help desk verifies the user's identity through an agreed out-of-band process before an administrator allows a new passkey to be enrolled. Recovery links sent to users should be time-limited and single-use, and their lifetime should be set by policy rather than left at defaults. After offboarding, remove the user's passkeys and other authenticators as part of the same leaver process, so that a retired credential cannot be used to sign in.
Confirm which recovery stages and flows your authentik release provides, how they are bound to identity verification, and which events they write to the audit log. Test each path with a lost-device scenario, an expired link and a leaver account before rollout, and review recovery flows as a security boundary alongside the authentication flow, since an attacker who can trigger recovery may bypass the passkey entirely. Ask your implementation partner to document each recovery path in the runbook, with its owner and its verification step.
Limits to confirm in your environment before you commit
Passkey and security key rollouts depend on details that vary by edition, browser, device and authentik version. The cards below list the points to confirm, where to confirm each one, and what to test on your own fleet before you set enrollment and login policy.
Edition coverage for WebAuthn
The authentik pricing page lists Enterprise-only features such as Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication and enhanced audit logging. It does not state where WebAuthn and passkey stages sit between the Open Source and Enterprise editions. Confirm the edition for each passkey capability with authentik before you plan the build, since a licensing gap changes the design and the budget.
Discoverable credential support on the fleet
Passwordless login depends on discoverable credentials, and support varies across operating systems, browsers, password managers and hardware keys. Test on each device family you support, including managed and unmanaged machines, and record whether the credential appears in the account chooser without a username. Results from one browser do not carry over to another.
Passkey autofill behavior by browser
Autofill prompts for passkeys depend on the browser, the password manager and the login page markup used by your flows. Test sign-in on the sites and browsers your users actually open, and check whether the prompt appears on the first screen or only after a username is entered. Note any change in behavior after a browser update, because these prompts are controlled outside authentik.
User verification across platforms
Whether a user is asked for a PIN, biometric or touch depends on the authenticator, the platform and the verification setting in your stage. A security key may behave differently from a platform passkey on the same laptop. Test each authenticator type against your required verification level and confirm what the audit log records for each sign-in.
Reuse across forward auth and LDAP or RADIUS
A passkey signs users into OIDC and SAML applications through the browser, but applications behind the proxy provider, LDAP binds and RADIUS clients use different login paths. Confirm with a test which applications accept a passkey session, and which need a separate second factor or application password. Document these gaps so help desk staff do not promise access the protocol cannot provide.
Flow changes between authentik versions
Passkey enrollment and login are built from flow stages, so a version upgrade can change stage behavior, default bindings or prompts. Read the release notes for the version you plan to run and for every version between your current and target release. Then repeat your enrollment and login tests in a staging environment before any production upgrade.
Questions teams ask before rolling out passkeys in authentik
What drives the cost and effort of a passkey rollout in authentik?
The main drivers are scope, not a single product line item: how many user groups will enroll, how varied their devices and browsers are, how recovery is designed, and which applications and clients must accept the new sign-in path. Each additional user group adds enrollment flows, policy bindings and test cases. Device diversity multiplies testing, because passkey behavior differs across platform authenticators, roaming hardware keys and browsers. Recovery design and help desk procedures add work that recurs after launch. Applications and clients that still expect a password or a different second factor add integration effort. Testing with a non-production instance is usually the largest variable. Ask any partner for a quote built from these items, with each one listed as one-time or recurring.
Can our team roll out passkeys in authentik without outside help?
Yes, if your team already has authentik experience, is comfortable building and testing flows and stages, and has a test environment that mirrors production closely enough to trust the results. The configuration itself is not the hard part. The difficult work is deciding which users enroll first, how lost-device recovery works, which applications are affected, and how the help desk responds to failed sign-ins. Teams without recent flow work often benefit from a short planning review or a fixed-scope engagement that covers design, build and testing. Check your internal skills against the enrollment stage, user verification and recovery steps before deciding.
How long does a passkey rollout take?
Duration depends on the scope drivers above, so no fixed timeline applies to every organization. A small pilot with one user group and a few well-understood applications is much shorter than a phased rollout across several business units with mixed devices and legacy clients. Ask for a written plan that lists phases, entry and exit criteria for each phase, the testing window, and the sign-off points. Treat any duration in a proposal as conditional on the inputs in that plan, such as device inventory completeness and the availability of identity owners for review.
What does our organization need to provide for a passkey project?
Most of the input has to come from your side. Expect to provide:
- A device and browser inventory for each user group, including managed and unmanaged devices and any existing hardware security keys
- Named identity owners for each group and application who can approve policy and recovery decisions
- Help desk runbooks for enrollment, lockout and device replacement, reviewed by the team that will use them
- A test instance with representative users, applications and clients
- Written sign-off from security, identity and application owners before each rollout phase
Missing any of these typically slows the project more than the configuration work does.
Do passkeys replace MFA or add to it in authentik?
It depends on how you configure the flows and on your risk model. A passkey can work as a single factor that is both possession-bound and user-verified, which is why some organizations use it for passwordless sign-in. Other organizations keep a second factor for sensitive applications or for sign-ins from unrecognized devices. The decision should be written into your authentication policy per application and user group, rather than assumed from the product. Confirm with your security team how user verification is required in each flow, and test how fallback factors behave when a passkey is unavailable. Verify current protocol and platform behavior against the authentik documentation for your release.
Must lost-device recovery be designed before passkeys launch?
Yes. Recovery must be designed before the first user enrolls, because a passkey bound to a lost or wiped device can lock a user out of every application that depends on it. Decide which recovery paths are acceptable, such as a second enrolled passkey, a hardware key kept in a secure location, or a verified help desk process. Define how identity is proven before an administrator removes or resets a credential, and how those actions are logged. Write the runbook, rehearse it in the test instance, and confirm that the help desk can execute it without elevated access it does not hold. Skipping this step is one of the most common causes of post-launch incidents.
Which authenticator models should we allow for passkeys?
Start from your device inventory and your risk requirements, then decide which authenticator types and models your policies accept. Some organizations allow only specific hardware security keys for administrators and permit platform authenticators for general staff. Restricting models requires knowing the make and model data your authenticators report, so verify in a test instance that the restriction behaves as intended before you enforce it. Document the allowed list, its owner and the review cadence, and plan how users with unlisted devices will re-enroll without weakening the control.
How DeployOpen scopes and delivers authentik passkey work
DeployOpen plans, implements, tests, documents and supports self-hosted authentik inside your own infrastructure, including passkey and WebAuthn rollouts. Each engagement starts from a written scope that sets which user groups, applications and authenticator rules are in play before any configuration changes are made.
How we scope
- Written scope lists which user groups, applications and login flows will accept passkeys and security keys.
- We record the authenticator models to allow or block, and the user verification level each flow requires.
- Scope also names the authentik version, deployment type and the stages that will change during rollout.
How we build
- We configure WebAuthn enrollment stage settings and bind them to the flows your users actually complete.
- Discoverable credential and passkey autofill settings are set and tested against each target browser and platform.
- Each change is applied from configuration kept under version control, so reviewers can trace every setting.
How we hand over
- Delivery includes a test record covering enrollment, sign-in, recovery and fallback for each user group.
- Runbooks explain how to reset a lost security key and how to revoke a compromised authenticator.
- Documentation describes which settings are configured, why they were chosen and what your team must review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
- Retainers can cover authentik upgrades that touch flows, stages or authenticator settings used for passkeys.
- Ask your quote to name who reviews support requests and how security fixes are scheduled against your change windows.
