Restricting authentik WebAuthn to approved hardware keys: when you need it
If your security team wants staff to sign in only with a company-issued FIDO2 key, not with any passkey or security key a user happens to own, you need WebAuthn device type restrictions. Without them, authentik accepts any WebAuthn authenticator a user enrolls, so the control you intend to enforce is really a policy that depends on user behavior. The restriction is the mechanism that turns a preferred key into the only accepted one. In authentik, the restriction lives in the authenticator validation stage. Its WebAuthn device type restrictions create an allowlist of authenticator types, and a login succeeds with a WebAuthn device only when that device matches an entry on the list. Matching depends on the device type stored at enrollment. According to the authenticator validation stage documentation, only devices enrolled in authentik 2024.4 or later have a stored device type that can match, so any key registered before that version cannot pass the allowlist until a user re-enrolls it. Review the authenticator validation stage documentation before you draft the allowlist, because the device types it matches against determine which keys you can actually approve.
The practical decision is therefore sequencing. Before you enforce the allowlist, inventory which users hold WebAuthn devices enrolled before 2024.4, plan a re-enrollment window for them, and decide whether the stage should reject older devices outright or whether a fallback factor applies during that window. Confirm with your own tests which device types your approved keys report, since a key model you assume is covered may not match the type you configured. Also confirm how your enrollment flow handles a second key, because enrollment controls and login controls are separate settings and both must agree with the policy.
Configuration options and when each fits
This table compares the four settings that shape a company-issued key policy in authentik, with the fit and the gaps for each. Read it as a checklist: most policies need more than one setting, and each row names what the setting cannot enforce on its own.
| Setting | When it fits a company-issued key policy | What it does not cover |
|---|---|---|
| Device type allowlist at the authenticator validation stage | Limits which registered WebAuthn device types can satisfy login, so only approved key models pass at sign-in. | Does not stop a user from enrolling a non-approved key unless the enrollment stage is also restricted. Devices without a stored device type cannot match. |
| Device type restriction at the WebAuthn setup stage | Blocks enrollment of keys outside the approved list, so unapproved models never get stored as factors. | Does not change keys already enrolled before the policy existed. Settings on this stage are separate from the login-time allowlist, so both should be checked. |
| User verification requirement | Requires the key to confirm the user, such as with a PIN or biometric, which fits policies that treat a key plus PIN as the standard. | Depends on what the key and client support. Confirm behavior on each approved model before setting it as mandatory, since some keys may not offer it. |
| Keeping other authenticators as fallback | Lets users with a lost or damaged key sign in through TOTP, recovery codes or another approved method, so a key policy does not cause a lockout. | Each fallback is a second path to sign in. A weak fallback can undermine a key-only standard, so fallbacks should match the risk level of the policy. |
| Re-enrolling older devices | Required for keys enrolled before authentik 2024.4, because only devices with a stored device type can match an allowlist. | Does not identify which users hold older keys. Run a report of enrolled devices and plan re-enrollment before enabling the allowlist for everyone. |
Setting up the allowlist at login and enrollment
This sequence restricts WebAuthn to one approved key model at both enrollment and sign-in, so a user cannot register or use a key outside the list. It also confirms that devices enrolled before the allowlist existed are handled deliberately rather than left to fail silently.
Confirm the authentik version in use
The platform administrator checks the running version in the admin interface before changing anything. Device type restrictions depend on devices carrying a stored device type, which applies to devices enrolled in authentik 2024.4 or later, so the version determines how much re-enrollment the rollout needs. Also confirm that the WebAuthn setup stage in your version no longer offers the Prevent duplicate devices option, which authentik 2026.8 removed. The check is complete when you have written down the exact version and the upgrade you will need, if any, recorded in your change ticket.
Identify the approved key model and device type
The security team gets the exact model, firmware and FIDO2 authenticator type of the company-issued key from the procurement record or the vendor's product documentation. Keys from one model can still differ by firmware, so record both. Test enrollment with one sample key in a lab tenant and read back the device type that authentik stores for it. The output is a short written entry containing the model name, firmware and the stored device type value, which the allowlist will reference. Confirm the vendor's current attestation details with the vendor, since they are not part of this sequence.
Restrict the WebAuthn setup stage to approved keys
An administrator opens the WebAuthn setup stage used by the enrollment flow and adds the approved device type to its device type restrictions, so the stage accepts only that type. Leave any other enrollment options as your current design requires. Save the stage and then enroll the sample approved key through a test user account. The check is complete when the approved key registers and the event log shows a successful enrollment for that device type.
Apply the same restriction to the validation stage
In the authenticator validation stage used at sign-in, the administrator adds the same device type to the WebAuthn device type restrictions. Using identical values in enrollment and validation prevents a user from enrolling a key that the login step later refuses. Confirm that the stage's device classes still include the other factors you intend to allow, such as TOTP or a recovery method, so that users are not locked out of a non-WebAuthn option. The check is complete when the stage saves with both settings matching the enrollment stage.
Bind both stages to the relevant flows
Confirm that the enrollment flow contains the WebAuthn setup stage and that the authentication flow contains the validation stage, each bound to the correct flow and the correct policy bindings. Check the stage order so that the validation stage runs after the password step. Review which user groups each flow applies to, because a flow bound to the wrong group will bypass the allowlist. The check is complete when a flow inspection in the admin interface shows both stages in the intended positions and no other flow offers WebAuthn enrollment to these users.
Test with an approved key
A test user signs in with the approved key through the bound flow. The sign-in should succeed without an error about the device. Also confirm that user verification behaves as your policy requires, since the device must complete the verification step your configuration asks for. The check is complete when the sign-in succeeds and the event log records the authenticator type used for the attempt.
Test with an unapproved key and an older device
Repeat enrollment with a different key model that is not on the allowlist, and confirm that the setup stage refuses it with a clear error. Then try signing in with an older WebAuthn device enrolled before the restriction. Because devices without a stored device type cannot match the allowlist, that older device should not satisfy the validation stage. Record the outcome for each device, and confirm that the affected user has a remaining approved method or a re-enrollment path before rollout. The check is complete when both refusals appear in the logs and the re-enrollment path has been tested with a test user.
Re-enrolling older devices without locking users out
Keys enrolled before authentik 2024.4 have no stored device type, so they cannot match a WebAuthn device type allowlist. The cards below cover the sequence that moves those users onto approved keys without stranding anyone who is mid-transition.
Inventory affected users first
Before changing any stage, list every user with a WebAuthn device enrolled before authentik 2024.4. Each of those devices lacks a stored device type, so an allowlist will reject it even if the key model is approved. Pull the enrollment dates from the authenticator records and group users by department, role and privilege level. Check service accounts and break-glass identities too, since they often hold older keys that nobody remembers registering. Confirm the count with your identity team before the rollout is scheduled.
Sequence rollout in waves
Move users onto approved keys in groups, starting with administrators and staff who already carry company-issued keys. Each wave should enroll a replacement key, confirm it logs in through the allowlisted stage, and only then retire the old credential. Keep waves small enough that help desk capacity can absorb re-enrollment questions. Hold a final wave for users who are hard to reach, such as long-leave or shift staff, and set a clear cut-off date that you announce in advance.
Keep a fallback during transition
Do not enforce the allowlist for a user until that user has a working approved key. During the overlap, the authenticator validation stage can still accept the older device or a secondary factor, so people are not blocked mid-migration. Document which stage each group sees at each wave, and remove the fallback only when the inventory shows no remaining older devices in that group. Test the fallback path with a pilot account before each wave.
Handle a lost approved key
When a user loses their company-issued key, the recovery path must not be a weaker login. Decide in advance who verifies identity, which second factor covers the gap until a replacement is issued, and how the lost key is removed from the account. Remove the lost credential promptly so it cannot be used if found. Avoid letting users self-enroll an unapproved key as a shortcut, because that defeats the allowlist the rollout was built to create.
Communicate expectations to users
Tell affected users what changes, which key models are approved, where to obtain one, and the date the old key stops working. Explain that enrollment takes place in the authentik user settings or the enrollment flow, and that a replacement key does not require a new password. Give users one support contact and a short script for help desk staff. Send a reminder before each wave closes so that people who postponed do not discover the change at login.
User verification and why attestation changed in 2026.8
User verification is a setting your team has to decide on purpose, because it changes what a successful WebAuthn login proves. With user verification set to required, the authenticator must confirm the person holding the key, typically with a PIN or a fingerprint on the key or device. With it set to discouraged, a touch alone can satisfy the step. A physical key that only requires a touch proves possession of the key, not that the right person used it. If a lost or borrowed company key is a realistic concern for your program, decide whether the PIN or biometric prompt is required for the device types you allow, and confirm in your own pilot that the key model you have approved actually supports that prompt and that users know how to set it up. Do not assume the default covers your policy.
Attestation is the part of enrollment that proves what kind of authenticator is being registered. authentik 2026.8 removed the Prevent duplicate devices option from the WebAuthn setup stage. The reason given in the release notes is that attestation certificates are shared across production batches of a model, so the check blocked legitimate second keys from the same batch. If your team relied on that option to stop one person enrolling two keys, do not rebuild it by matching attestation certificates. Instead, enforce the rule with controls you can explain: restrict enrollment to the approved device types with a device type allowlist, limit who can start enrollment through flow and group design, and review the device list for each user during onboarding and periodic access reviews. Read the authentik 2026.8 release notes before upgrading, and confirm the current behavior in your test instance.
Security and operational considerations
An allowlist is only as strong as the device data behind it, and it changes how lockouts, replacements and reviews play out. The cards below cover the decisions that connect policy, recovery and ongoing maintenance.
Device type is not identity
A device type match tells authentik which authenticator model or attestation profile a credential reports, not who is holding the key. A stolen or cloned key that reports an approved type still needs the user's PIN or biometric if user verification is required, and the password step still applies. Confirm with your team that user verification is enforced on the stage so the allowlist is never the only check on possession.
Recovery and lockout paths
When the allowlist rejects a user's only key, that user cannot sign in with it and may be locked out of the account entirely unless another enrolled factor is accepted. Decide before rollout which fallback applies, such as a second approved key, a TOTP factor or a supervised recovery flow, and document who may approve it. Test the path with a user whose key is not on the list.
Help desk load at cutover
Restricting models at login usually creates a spike of support tickets from users with personal keys or older hardware. Estimate the number of affected users from your inventory of current WebAuthn devices before you enable enforcement, and plan who will re-enroll them and how identity is verified during the call. Ask your team to agree on the staffing and the script before the cutover date.
Enrollment logging and review
Record every WebAuthn enrollment, removal and failed validation against the user and the device type, then review the trail on a fixed schedule. Confirm which events authentik writes to its logs and how your log platform receives them, since an allowlist you cannot audit gives little assurance. Look for enrollments outside normal onboarding, sudden spikes and devices added to accounts that do not match the holder's role.
Keeping allowlists current
Key vendors release new models and retire old ones, and an allowlist that predates them will block legitimate users or quietly accept unapproved hardware. Assign an owner for the approved list, set a review cadence tied to procurement, and check each authentik upgrade for changes to WebAuthn stage behavior. Before each change, confirm with the vendor which attestation data their current keys report.
Re-enrollment of older devices
Devices enrolled before authentik 2024.4 have no stored device type, so they cannot match an allowlist and must be re-enrolled. Build an inventory that separates pre-2024.4 keys from newer ones, and schedule re-enrollment before enforcement is turned on. Confirm the exact procedure for your version in the validation stage documentation.
Questions teams ask before restricting WebAuthn keys
Can I enforce an approved security key list in authentik without an Enterprise license?
Confirm this before you design the flow. The WebAuthn device type restriction is part of the authenticator validation stage, and the authentik pricing page lists Enterprise-only features such as Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging. The pricing page does not name device type restrictions as an Enterprise-only feature, but it also does not state that they are available in the Open Source edition. Check the authentik pricing page and the stage documentation against the release you plan to run, and ask the vendor to confirm in writing if the allowlist is a compliance requirement.
How long does re-enrolling older security keys take?
No duration is fixed, and the work depends on how many users hold keys and how they are contacted. The key technical driver is that only devices with a stored device type, enrolled in authentik 2024.4 or later, can match an allowlist. Every key enrolled before that version has to be registered again before the restriction takes effect for that user. Drivers include the number of users, whether enrollment can be done in a single supervised session, how many users are remote, helpdesk capacity for lost or replaced keys, and whether you plan a grace period in which both old and new keys work. Ask any partner for a breakdown of these steps in the written scope.
Can users re-enroll their own keys, or does an administrator need to do it?
Users can usually re-enroll their own keys through the WebAuthn setup stage, but only if the flow and the allowlist are designed for self-service. Self-service keeps helpdesk load down, but it needs clear instructions, a fallback for users who have lost their key, and a recovery path that does not weaken MFA. Administrators are often needed for users who cannot complete enrollment, for shared or departmental devices, and for exceptions. Decide the split before rollout, and confirm how the setup stage behaves for keys that are already registered, because that behavior changed in authentik 2026.8 with the removal of the Prevent duplicate devices option.
Why did authentik remove the duplicate device check from the WebAuthn setup stage?
The authentik 2026.8 release notes say that attestation certificates are shared across production batches, so the duplicate check blocked legitimate second keys from the same batch. Teams that relied on that option should not expect it to protect against a user registering a second key. The allowlist of device types is the control to use for approved models, and you should test that a user with two valid keys from the same approved model can enroll both. Read the authentik 2026.8 release notes before you finalize the design.
What does a partner need from our team before quoting this work?
A partner needs enough detail to write a fixed scope. Typically that means the authentik version and deployment type (Docker Compose or Kubernetes), the list of approved key models with their device types, the user population and how many hold each key, the applications and flows that must enforce the restriction, and any LDAP or RADIUS clients that will use the keys. You should also share your helpdesk process, your policy on lost keys, and whether any compliance requirement applies. Ask for the list of items the partner will need before work starts, so the quote reflects your environment rather than a generic estimate.
What does a fixed-scope DeployOpen engagement for this work cover?
Most DeployOpen engagements are fixed-scope, and scope, deliverables and timelines are agreed in writing before work starts. For this topic, a written scope would normally cover reviewing the current authenticator and WebAuthn configuration, designing the allowlist for login and enrollment, updating the flows, planning and supporting re-enrollment of older devices, testing user verification and duplicate key behavior, and documenting the operating procedure for lost keys. It does not include issuing audit reports or certifications. If compliance evidence is needed, DeployOpen prepares systems, controls and evidence, and an independent auditor or certification body makes the assessment.
Does restricting keys to approved models also restrict who can log in?
Yes, if the allowlist is enforced at login and not only at enrollment, a user who holds an unapproved key will be unable to pass that stage. This is the intended control, but it creates a lockout risk. Before you enforce the rule, confirm which stages apply at login, whether a second factor such as TOTP is available as an alternative, and how an administrator clears a user who has only an unapproved key. Test the fallback path in a staging environment with a non-production user before you change the production flow.
How DeployOpen scopes and delivers WebAuthn restrictions
DeployOpen approaches WebAuthn device type restrictions in authentik as a fixed-scope piece of work inside your own infrastructure. We agree which key models are approved, how older devices are re-enrolled and how user verification is set before any configuration changes are made.
How we scope
- Inventory the security key models your users already hold and the ones you plan to approve.
- Confirm which login and enrollment flows must apply the allowlist, and which clients fall outside it.
- Record the re-enrollment window for devices enrolled before authentik 2024.4 in the written scope.
How we build
- Configure the device type allowlist in the authenticator validation stage on a staging instance first.
- Adjust the WebAuthn setup stage so enrollment accepts only the approved models and user verification settings.
- Test enrollment and login with approved keys, unapproved keys and a device enrolled before the change.
How we hand over
- Document the allowlist, flow bindings, user verification settings and the re-enrollment procedure for your administrators.
- Walk your identity team through how to add a new approved key model and how the change is reviewed.
- Provide the test cases used in verification so your team can repeat them after future upgrades.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Review the allowlist and the stage settings when authentik is upgraded to a newer release.
- Confirm the scope, deliverables and timeline in writing before any work starts, with a quote following from that scope.
