Why authentik recovery codes need the same care as the MFA they back up
A user has lost the phone with their authenticator app or the security key they normally use, and needs a way back in without MFA being switched off for everyone. In authentik, the usual answer is a backup factor such as static recovery codes, added through a static authenticator stage. The backup factor is only as strong as its issuance and use. If codes are generated too generously, handed out in email, stored in plain text on shared drives, or accepted without limits, an attacker who has a password can skip the stronger factor entirely. Treat recovery codes as a credential with its own lifecycle: who may receive them, how they are delivered, how long they last, and how they are retired once used.
Before you wire this into a flow, confirm the details against the authentik documentation for the release you run. Where the static stage's settings, the code format, the default number of codes per user, and any regeneration behavior are defined, and whether codes are stored hashed, are not figures this page can state for you. Check the static authenticator stage and its validation behavior in the docs for your version, and test a lost-device scenario end to end in a non-production instance. Also confirm how the static device type interacts with the authenticator validation stage that enforces MFA, because a recovery path that sits outside that stage can become a bypass.
Decide early who can reset or reissue codes. Administrator-driven recovery should follow a documented identity check, be logged, and generate new codes that invalidate the old set. Check that your audit trail records these events, and that alerts exist for repeated failed code attempts. The authentik security policy is a useful reference for supported releases, since recovery paths need the same patching discipline as the rest of the stack. The rest of this page covers the stage itself, validation and throttling, and how administrators recover users without weakening MFA.
Which static token options fit which recovery policy
This table compares the settings a team decides when it adds static recovery codes: who may generate them, how many a user holds, how long they stay valid, where they appear and whether they are replaced after use. Read each row as a decision, then confirm the exact option names and defaults in the authentik admin interface for your installed version.
| Decision | Option to consider | When it fits | Risk to manage |
|---|---|---|---|
| Who may generate codes | Users self-serve from their profile | Large user populations with few help desk staff, and users who already manage their own TOTP enrollment | Users may generate codes on a shared or unmanaged device, or store them where an attacker can read them |
| Who may generate codes | Administrator issues codes only | High-privilege accounts, such as administrators and privileged access holders, where issuance should follow a verified request | Adds help desk workload and a delay for locked-out users, and the issuing step becomes a target for social engineering |
| How many codes a user holds | Small fixed batch, for example ten or fewer (confirm the default) | Users who keep codes in a password manager or a sealed printed copy and need a limited set | Once the batch is used up, users may request more before they lose access, which makes regeneration timing important |
| How many codes a user holds | Larger batch regenerated on demand | Users with unreliable access to their devices or who travel | More unused codes stay valid at once, so each code is a longer-lived secret |
| How long codes remain valid | No expiry on the code set | Shared-responsibility environments where users rarely review their stored codes | A forgotten printout or stale copy remains usable indefinitely, so revoke sets when a user leaves or changes role |
| How long codes remain valid | Expiry tied to a regeneration cycle (confirm the available setting) | Regulated environments that require periodic review of credentials and documented recovery procedures | Users may hit expiry without warning, so pair it with reminders and a clear renewal path |
| Where codes are shown | Displayed once at generation, with a prompt to save them | Most user populations, where the user records codes immediately | Codes that are not saved create lockouts, and screenshots or chat copies widen exposure |
| Whether codes are replaced after use | Each code is consumed on first successful use | Default expectation for recovery material, because a reused code adds no protection | Users may not realize codes are gone, so track remaining count and prompt regeneration |
| Whether codes are replaced after use | Set is reissued only when the user or an administrator requests it | Teams that want a fixed inventory and no surprise changes to stored material | Old sets must be invalidated at regeneration, so confirm that behavior in your version before relying on it |
Setting up static recovery codes in authentik
This sequence adds a static authenticator stage to your authentik MFA flow so users can enroll backup codes, and it confirms that each code works once and only after the primary login factor. The result is a tested recovery path that does not lower the strength of your MFA.
Confirm version and supported status
Before changing any flow, check which authentik release you run and whether it sits in the branches that receive security fixes. The security policy lists the supported versions, and the releases page shows the latest published build. Confirm the exact menu names and stage options for your release in the authentik documentation, since labels can change between versions. Done when you have written down the running version, its support status, and the documentation page you will follow.
Create the static authenticator stage
In the admin interface, an administrator creates a static authenticator stage, the component that generates and stores backup codes for a user. Review the code count and length options the stage exposes in your release, and record your choices so they match your recovery policy. Keep the stage name specific, such as one that names the recovery purpose, so it is easy to find in flow bindings later. Done when the stage appears in the stage list with the settings you chose.
Bind the stage after the primary factor
Add the static authenticator stage to the authentication or MFA flow you use for your users, placing it after the password or primary identification stage. Then bind the authenticator validation stage in the order that lets users choose a backup code when their main device is unavailable. Check the flow diagram or binding order to confirm that the code stage runs only after the primary factor succeeds. Done when a test login with a valid password reaches the second factor and no earlier step can skip it.
Configure enrollment and code display
Set up how users receive their codes: add the stage to an enrollment flow so codes are generated at setup, and confirm the display and download options your release offers. Decide who may enroll codes, and whether users can regenerate them without administrator help. Store the flow definitions and stage settings in version control if your team manages authentik as code, and review changes like any other configuration. Done when a test enrollment shows the generated codes once and the stage is recorded in your repository.
Test with a dedicated account
Create a dedicated test user, enroll backup codes, and log in with the password plus one code. Then confirm the code is accepted once and rejected on a second attempt, which shows that used codes cannot be reused. Also check that a wrong code fails and that the login does not proceed without a valid code. Done when the test account logs in with a code, the used code fails on reuse, and the results are written in your change record.
Document the administrator recovery path
Write down how an administrator resets or reissues codes for a user who has lost every code and device, and confirm that the process requires identity verification outside authentik. Check whether the admin interface lets you clear or regenerate a user's static devices, and test that action on your dedicated account. Record who is authorized and how the action is logged. Done when a second administrator can follow the written steps and the reset appears in your audit trail.
How administrators recover a user who has lost every factor
The user still has a working phone or a device they can use, but cannot find the printed or saved backup codes. Recovery here is mostly about confirming the person is who they claim to be and then helping them regenerate a fresh set. The help desk should not reset the factor on a casual request, and the user should not be asked to read codes aloud or send them over chat.
- Verify identity out of band: Confirm the request through a channel the requester did not start, such as a call to the number in your directory or a callback to the manager.
- Check the active factor first: If the user can still pass a TOTP, WebAuthn or push prompt, have them sign in and regenerate codes from their own profile instead of an administrator action.
- Limit approvers: Name the roles allowed to approve a reset, typically the service desk lead for standard users and a security contact for privileged accounts.
- Log the request and the decision: Record who asked, who verified, which method was used and the time, in the ticket and in authentik's event log.
- Invalidate old codes: Confirm that regenerating the set replaces the previous codes so a found or copied list stops working.
Before closing the ticket, confirm the user has signed in with a working factor and generated a new set of codes.
The user has lost the device and has no usable backup codes. This is the case where administrators are tempted to disable MFA for the account. Do not do that. Removing the second factor leaves a password-only account for as long as the ticket stays open, and it is the most common way recovery becomes the weakest point in the design. A better pattern is a short, supervised re-enrollment in which the user registers a new factor while the session is tightly controlled.
- Use strong identity proof: Require a verification step that is hard to fake, such as an in-person check against an employee badge or a call-back to a number already on file, and document which one was used.
- Restrict the approver: Only designated administrators should trigger re-enrollment, and the approver should not be the same person who verifies the identity.
- Grant time-limited enrollment: Issue a stage or flow that requires the user to enroll a new factor within a short window, after which the grant expires.
- Require a new factor before full access: Keep the account restricted until the new authenticator has been validated, and remove any temporary access once it is.
- Log every step: Record the verification method, the approver, the enrollment event and the expiry in the audit trail.
After re-enrollment, confirm the old device is removed from the user profile and that no temporary grant remains active.
Sometimes a lost factor request comes from someone who is not the account owner. Signs include reset requests from unusual locations, repeated failed logins, or a user who does not recognize recent sign-ins. In this situation the goal is to contain the account first and recover second. A reset that happens too quickly can lock the legitimate user out and also let an attacker enroll their own device.
- Freeze the account: Suspend sign-in or restrict the account while the investigation runs, and end active sessions.
- Review sign-in and enrollment history: Check recent authentication events, failed attempts and any factor changes before approving anything.
- Escalate to security: Hand the case to the security team, who decide whether to reset, rotate credentials or involve incident response.
- Verify through a trusted channel: Contact the user using details already on file, not details supplied in the reset request.
- Preserve the record: Keep logs and tickets intact for later review, and confirm with your own policy and counsel how long they are retained.
Only lift the freeze once security has signed off and the user has re-enrolled a new factor under the supervised process.
How recovery paths can weaken MFA, and how to prevent it
A recovery path is only as strong as the weakest way someone can get past it. Backup codes that sit in a shared drive, a chat thread or a printed sheet under a keyboard give an attacker the second factor along with the password. The same is true when a help desk resets MFA after a caller simply sounds convincing, or when a recovery flow lets a user sign in with a password alone because the MFA stage was skipped. Before rollout, map every way a user can end up with a fresh or bypassed second factor, including administrator resets, self-service regeneration and any LDAP or RADIUS client that never sees the authenticator stage.
The controls that counter these failures are mostly about who holds the power to change factors and how that power is recorded. Restrict which administrator roles can generate, reset or delete a user's static devices, and require a documented identity check before a reset, such as a call-back to a number already on file or manager approval. Keep administrator actions in an audit trail that someone reviews, and treat each code as single use so that a code shown once is spent once. Confirm in your own environment how authentik records administrator changes to authenticators, since the audit capability you need may depend on your edition and logging setup.
Finally, test the recovery path as an attacker would. Attempt a password-only sign-in against every flow and every protocol endpoint, confirm that an unenrolled account either cannot sign in or is forced through enrollment, and check that a regenerated code set invalidates the old one. Ask the help desk to walk through a reset with a convincing but unverified caller, then see whether the runbook stops it. Re-run these checks after each authentik upgrade, because flow and stage behavior can change between releases.
Security and operational risks to design around
Static recovery codes are a deliberate bypass for a second factor, so their risk sits in how they are stored, issued, spent and audited. The cards below cover the failure points that usually matter most, with a control and a check for each. Review them with your identity, help desk and database owners before codes go live.
Code storage by users
Recovery codes printed, screenshotted or saved in a notes app become a second password sitting beside the account they protect. A stolen phone or shared screen can expose every unused code at once. Set a clear user instruction to store codes offline, in a password manager or in a sealed copy kept by the user, and make the enrollment screen state that codes are shown once. Confirm what your enrollment flow displays and whether users can re-view codes after issue.
Help desk social engineering
When a user says they lost both phone and codes, the help desk may be asked to reset MFA by phone or chat. Attackers rely on that path because it bypasses the factor they cannot steal. Require a verified identity check before any MFA reset, log the requester and reason, and route resets through a documented procedure rather than individual judgment. Confirm who holds permission to reset static devices and whether that permission is separate from password reset rights.
Reuse of spent codes
Each recovery code should work once. If a spent code can be replayed, or if the stored value is not marked consumed, a captured code remains valid. Test the sequence explicitly: use a code, then attempt it again, and confirm the second attempt fails. Also check that a code used during a failed or abandoned login is handled consistently. Ask your authentik test plan to cover these cases and record the results with the build version.
Insufficient audit logging
Recovery use is a rare, high-value event, so it needs a visible trail. Without logs of when a static token was enrolled, used, or deleted by an administrator, you cannot tell a legitimate lost-phone case from an account takeover. Confirm that authentik's event log captures static device creation, validation and administrator changes, and that these events are forwarded to your central log store. Note that enhanced audit logging is listed as an Enterprise feature on the pricing page, so confirm which events your edition records.
Backups containing enrolled devices
The authentik database holds all configuration and data except uploaded files, so backups include enrolled static devices and their stored token values. A backup copy is therefore a set of usable second factors. Treat backup files with the same classification as the live database, encrypt them, restrict restore access, and define a retention period. Confirm where backups are stored, who can restore them, and whether a restore into a non-production environment could reactivate codes that were already spent in production.
Version support and patching
Recovery and MFA code paths receive fixes like any other authentication code, and an unpatched release leaves them exposed. The authentik security policy lists the release lines that receive security fixes, and the project announces security releases at least 24 hours in advance. Plan upgrades to stay within a supported line, subscribe to the release feed, and schedule a test window that is short enough to apply fixes in time. Confirm which line your deployment runs today and who owns the decision to upgrade.
Questions teams ask before configuring recovery codes
How much effort does setting up recovery codes in authentik take in-house?
The effort depends mostly on how many moving parts your team already runs and how much policy work is still open. The technical setup is a static authenticator stage bound to an authenticator validation stage in the login flow, plus enrollment and recovery flow changes. A team already familiar with authentik flows and stages can often configure it in a test instance first. The real time sink is usually deciding who gets codes, how many, when they are regenerated, and what happens after a lost device, then testing those paths end to end. Confirm the scope with your own environment and team before committing to a timeline, because no duration is set by the researched facts for this topic.
What makes recovery code setup take longer or cost more?
Four factors drive the effort most. The first is the number of login paths: web SSO, LDAP and RADIUS clients each need a check that recovery codes behave correctly. The second is your user population, since enrollment support for many users, including those who never enrolled a device, adds work. The third is how your flows interact with other MFA methods such as TOTP, WebAuthn or Duo, because a recovery path must not become a bypass. The fourth is your audit and evidence needs. Ask any partner to break the quote into flow design, testing, documentation and handover, and to state which items are one-time and which recur, such as periodic review of codes issued.
Do we need a partner to configure recovery codes, or can our team do it alone?
Many teams can configure recovery codes themselves if they already operate authentik and have someone who can read and change flows and stages safely. A partner is most useful when the recovery design touches several protocols, when you need a documented test plan, or when the team lacks capacity to run the work alongside production changes. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, and it runs the implementation inside your own infrastructure. Decide based on your internal skills and the risk of getting a recovery path wrong, not on the feature alone.
What does our internal team need to provide for this work?
Your team should provide access to a non-production authentik instance that mirrors production configuration, an owner for the login and recovery policy, and a named approver who can accept the test results. Expect to supply the list of applications and protocols that users sign in through, the current MFA methods in use, and the directories or user sources that authentik reads from. Someone must also confirm how help desk staff verify identity before issuing or resetting codes, because that process is the most common weak point in recovery design. Confirm access requirements and change windows with your own team before work starts.
How do we agree a recovery code policy with our compliance team?
Start by writing down the control objective the policy must meet, then map the recovery design to it, rather than starting from the product settings. Compliance teams usually want to know who can receive codes, how codes are stored and shown, how many can be used, how and when they are regenerated, how throttling limits guessing, and how each recovery event is logged and reviewed. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors make those determinations. Agree the policy in writing before configuration, and ask your assessor which evidence they will accept.
Is recovery codes functionality free in authentik, or does it need an Enterprise license?
The core authentik repository is licensed under the MIT license, and the Open Source edition on the pricing page is free, with community support through Discord. Code in the authentik/enterprise/ directory falls under a separate enterprise license. The pricing page lists Enterprise features separately, including enhanced audit logging, password history and ticket-based support for subscriptions over $1k, and Enterprise is listed at $5 per user per month billed annually plus $0.02 per external user per month. Confirm with authentik which features your chosen recovery design depends on, and check the current license file and pricing page before you commit, since the pricing page is the source for edition details.
What operational risks should we check before going live with recovery codes?
Check whether codes can be generated or viewed by anyone other than the account owner, whether an administrator can reset MFA without a verified identity check, and whether recovery events reach your log pipeline. Also test that a user who has used all codes is routed to a supported recovery process rather than a dead end. Upgrades matter too: authentik security fixes are limited to supported version lines, so confirm which release line you run and keep a rollback plan. Ask your team or partner to document these checks as a repeatable test list.
Limits to confirm in your environment before rollout
Recovery codes sit inside your MFA trust boundary, so their behavior has to be confirmed before users depend on them. The items below are checks to run against the authentik documentation for your release and in a test deployment. Each one can change how codes are issued, stored, throttled or audited.
Static token behavior in your release
Confirm how the static authenticator stage in your installed version generates tokens, how many can be issued per user, and whether regenerating the set invalidates the old one. Read the release notes for the version you plan to run, because stage behavior and defaults change between releases. Check that a used code cannot be reused in your test deployment. The exact behavior of your installed release is the basis for every other item on this list.
Throttling and lockout for static codes
Confirm whether authentik applies attempt throttling to static codes and whether it counts failures against the same budget as TOTP or other factors. Ask whether a locked-out user can still sign in with a backup code, and whether a successful code resets failures for other factors. Brute-force protection for one-time codes is handled separately, so verify the static code path specifically with failed attempts in a test environment.
Audit trail and enterprise logging
Decide which events your audit trail must record, such as code generation, code use, regeneration and administrator resets. Confirm in the authentik documentation whether the community edition's event logging covers these, or whether the enhanced audit logging listed on the pricing page is needed. Ask your auditor which evidence they will request before choosing an edition, because the answer determines the license scope.
Display and storage of codes
Confirm how codes are shown to the user at enrollment, whether they can be viewed again later, and whether authentik stores them in plain text or as hashes in PostgreSQL. Check whether administrators can read a user's codes in the interface or through the API. Plan how users save codes, such as a printed sheet or password manager, and whether your policy allows screenshots. Verify each point against your release, since storage behavior determines your incident response steps.
Database and worker behavior during recovery
Recovery flows write to PostgreSQL and may depend on the worker container for background tasks. Confirm which steps run synchronously in the server container and which depend on the worker, and test what happens when the worker is stopped during an administrator reset. Check connection limits after upgrades, as the 2025.10 notes warned of more PostgreSQL connections. Rehearse a restore from backup to confirm that generated codes survive it as expected.
LDAP and RADIUS client compatibility
Confirm whether a static code can be used as the second factor for LDAP binds or RADIUS requests, since these clients typically send one password field and may not support a separate prompt. Test the bind flow with a real client in your environment. If the protocol cannot carry a second factor cleanly, decide whether those clients will rely on another method or a separate account. Do not assume a backup code path works for these clients until you have tested it.
How DeployOpen scopes and delivers recovery design for authentik
DeployOpen plans and builds backup code recovery for authentik inside your own infrastructure, starting from a written scope that names the users, flows and administrator actions involved. The work covers the static authenticator stage, validation and throttling behavior, and an administrator recovery procedure that keeps MFA enforced.
How we scope
- Engagements are fixed-scope, with the recovery population, flows and admin actions agreed in writing before work starts.
- The written scope lists which MFA methods recovery codes must back up, such as TOTP, WebAuthn or Duo.
- Scope names who may issue, regenerate or reset codes, and how those actions are logged and reviewed.
How we build
- Static authenticator stages, code generation settings and flow bindings are configured and reviewed in a non-production instance first.
- Throttling and failed-attempt behavior are tested against the authenticator validation stages in your deployment.
- Administrator recovery paths are built so MFA stays enforced, with no bypass that skips the second factor.
How we hand over
- Handover documents the configured flows, stage bindings, code storage rules and the exact administrator recovery steps.
- Test records show how valid, reused and expired codes behave, along with the lockout and alerting results.
- Operators receive a runbook for issuing replacement codes and an evidence set for your compliance assessors.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover re-testing recovery flows after authentik version upgrades, which change flows and stages.
- Ask any provider to confirm how recovery settings are re-verified after each security release you apply.
