Why TOTP authenticator apps are the starting point for authentik MFA
If you need a second factor that works offline, costs nothing per message and does not depend on a phone carrier, start with time-based one-time passwords. authentik's TOTP authenticator validation stage checks a six-digit code generated by an app such as Google Authenticator or Microsoft Authenticator, using a secret the user enrolled once. It is usually the right first method because it covers most workforce users, needs no third-party service, and can be enforced through the same flows you already use for password login. Confirm in your own tenant which stage and flow names your version exposes, since these change between releases.
TOTP is a code-based method, so it carries risks that a hardware key or a push approval does not. A six-digit code can be guessed if an attacker can submit repeated attempts, which means you need to confirm how authentik throttles failed codes in your version and whether that limit is enough for your risk level. You also need a recovery plan before rollout, because a user who replaces a phone loses the secret that generated their codes. Decide in advance who verifies a replacement device and how that re-enrollment is logged.
TOTP is one method in the wider MFA hub. Duo push, SMS and email codes, WebAuthn hardware keys and static backup codes each solve a different problem, and some do not work for LDAP or RADIUS clients at all. Treat TOTP as the baseline for most users, then decide which groups need stronger factors and which methods are acceptable as fallbacks. Read the sibling guides on enforcement, recovery and brute-force protection before you publish a policy, because the choices interact.
Which TOTP configuration fits which organization
This table compares the main TOTP configuration choices in authentik: where enrollment lives, how many device classes to allow, and who creates the enrollment. Read each row against your user population, your help desk capacity and how much you want to rely on administrator action. The main takeaway is that the simplest setup, TOTP only with self-enrollment in the login flow, is the easiest to run, but it places more recovery work on users and help desk staff.
| Configuration choice | When it fits | Operating trade-off |
|---|---|---|
| Enrollment in the login flow | Workforce with a single managed sign-in path and users who must enroll before reaching any application | Users enroll at first sign-in, so the flow must be reviewed before rollout; fewer flows to maintain |
| Separate settings flow for enrollment | Users who already have accounts and need to add or change an authenticator later without re-running sign-in | Requires a second flow and stage bindings to keep consistent; confirm the settings flow exposes the right stages in your version |
| TOTP only | Organizations that want one predictable method and no SMS or email codes in scope | Lowest configuration effort; recovery depends on backup methods you add separately, so confirm what users fall back to |
| Several device classes offered | Mixed populations, such as users with managed phones and contractors on personal devices | More stages and policies to test; each added class needs its own recovery path and support script |
| Self-enrollment by users | Large, distributed user bases where administrators cannot touch each device | Lowest admin workload at rollout; help desk still handles lost phones and enrollment errors |
| Administrator pre-provisioned enrollment | Regulated or high-privilege groups where enrollment must be witnessed or tied to a verified identity | Adds administrator effort per user and a handoff step; ask your team to estimate this from your own headcount |
| Recurring cost of operation | Every option | Ongoing work is help desk recovery, flow maintenance and testing after each authentik upgrade; confirm your team's capacity for these before choosing |
Setting up TOTP enrollment and validation in authentik
This sequence creates a TOTP setup stage and an authenticator validation stage, binds them into enrollment and login flows, and confirms that a real authenticator app works while wrong codes are refused. The result is a tested TOTP path you can extend with lockout, recovery and device replacement rules.
Confirm stage names and version in the admin interface
Sign in to the authentik admin interface as an administrator and check the installed version under the system or about information. Stage names, field labels and menu locations change between releases, so use the names you see in your own instance rather than names copied from older guides. Open the Flows and Stages area and confirm that you can create a new stage of the TOTP setup type and an authenticator validation type. Done means you have written down the version and the exact stage type names you will use, and that you have a test account you can change without affecting real users.
Create the TOTP authenticator setup stage
Create a TOTP authenticator setup stage that presents a QR code and a secret to the user during enrollment. Name it clearly, for example with the word TOTP and the environment, so it is easy to find when you bind it to flows. Review the options that control how the device is named and whether the setup stage is allowed to run again for a user who already has a device. Done means the stage exists in the stage list with the settings you chose, and a test enrollment can be started from a flow that uses it.
Create the authenticator validation stage
Create an authenticator validation stage that asks for a code from an enrolled device at login. Set it to accept TOTP devices and restrict device classes to the ones you intend to allow, leaving other device types off until you have decided on them. Review the not-configured action, which determines what happens when a user has no device yet; treat this as a decision to make deliberately, because it affects whether enrollment can be skipped. Done means the stage exists with the device classes and not-configured behavior you documented.
Bind the stages into enrollment and login flows
Add the TOTP setup stage to your enrollment flow after identification and password stages, and add the authenticator validation stage to your authentication flow after the password stage. Check the order of bindings in each flow, since a validation stage placed before a password stage will not protect the password step. Use a test policy or a dedicated test group if you do not want every user to see the change while you work. Done means both flows show the stages in the intended order, and a test user reaches the enrollment prompt when they have no TOTP device.
Enroll and log in with a real authenticator app
As the test user, complete enrollment by scanning the QR code with an authenticator app such as Google Authenticator or Microsoft Authenticator, then enter the six-digit code the app displays to confirm the device. Sign out, sign in again with the password, and enter the current code when prompted. Use your own phone and app rather than a simulator so the check reflects what end users will do. Done means the test user can enroll once, and a fresh login succeeds with a code generated by the app after enrollment.
Verify that wrong and reused codes are refused
Attempt login with an incorrect code, then with the previous code from the same time window, and confirm that authentik rejects both and does not grant a session. Review the authentik log entries for the failed attempts so you can see that they were recorded. Also confirm the behavior of your test account after several consecutive failures, noting the message shown to the user. Done means the failed attempts are rejected, appear in the logs, and you have recorded what the user sees after repeated failures so the throttling review in the next steps has a baseline.
Record the configuration and roll out carefully
Export or document the names, settings and bindings of both stages and both flows, including the authentik version you tested on. Keep a note of any settings you could not confirm in the interface, and check them against the documentation for your release before a wider rollout. Limit the first production rollout to a pilot group, and watch enrollment and login errors during that period. Done means you have a written record of the tested configuration and a pilot group has completed enrollment without unexplained failures.
How authentik limits repeated TOTP guesses
A six-digit TOTP code is only one million possibilities and stays valid for a short window, so a login flow that accepts unlimited attempts can be guessed. The cards below cover what to confirm about attempt limits, how failed logins interact with reputation controls and alerting, and where the brute-force article in this group takes over.
Attempt limits on TOTP codes
Confirm whether the authenticator validation stage limits repeated wrong TOTP codes for a user, and for how long a lockout or delay lasts. Ask whether the limit applies per user, per flow, or per source address, because each choice leaves a different gap. Test it with a deliberately wrong code sequence on a staging tenant before you rely on it in production.
Throttling and the code window
Time-based codes are valid for a short window with some tolerance for clock drift, which widens the set of codes an attacker can try in that period. Check the drift tolerance your installed version applies, and confirm whether a code that has already been accepted can be reused within the same window. Record your findings as settings you can audit.
Reputation policies and login risk
Reputation policies score sources and users based on earlier failures, and they can block or challenge a login before the MFA prompt appears. Confirm which signals your version uses to raise a score, how quickly scores decay, and whether a blocked source also blocks legitimate users behind the same address. Note which policy bindings apply to administrator accounts.
Failed-login alerting
Throttling slows guessing, but you still need to know when it happens. Confirm that failed TOTP attempts appear in the event log with the user, source and outcome, and that you can forward those events to your monitoring system. Set an alert on bursts of failures for one account, since a single account receiving many wrong codes is a clear signal.
Where brute-force protection continues
Code-based methods beyond TOTP, including SMS and email codes, have their own attempt handling, and the brute-force protection article in this group covers those methods and the 2026.5 changes. Read it next for email and SMS throttling, then return here to confirm the TOTP settings in your installed version. Each method should be checked separately.
Confirm behavior on your version
The exact attempt limits, lockout durations and reputation thresholds can change between releases, so do not copy values from this page or from older guides. Check the documentation for the version you run, and repeat the test sequence after every upgrade. Keep the test results with your change records so reviewers can see what was verified and when.
Recovering users who replace or lose their phone
When a user knows they are changing phones, the cleanest path is to enroll the new device while the old one still works. The user signs in with the existing TOTP code, adds a fresh TOTP device through the enrollment flow, confirms a code from the new app, and then removes the old device from their profile. Nothing about the account's authentication strength changes during the swap, and the audit trail shows a normal, user-initiated enrollment.
- Enroll before you retire: The new device should be registered and validated before the old one is deleted, so the user is never without a working second factor.
- Confirm the new code: Require a successful validation on the new device before the old device is removed.
- Remove the old device explicitly: Stale TOTP devices left on an account are an unnecessary way in, so delete them rather than leaving them attached.
- Check the migration of other factors: If the user relies on a static token or backup codes, confirm they still work after the swap.
- Keep the change traceable: Make sure your event logs record the enrollment and deletion for later review.
Before you rely on this path, confirm in your own environment that the user can manage their own authenticators in the flow you deploy and that the deletion event is logged.
A lost or broken phone is different from a planned swap when the user still has another working device or a copy of the authenticator. The goal is to get the user back in quickly while keeping the enrollment itself trustworthy. Where a user can still sign in with a second factor, they should enroll a replacement device through the same self-service flow used for planned changes.
- Verify identity before changing anything: Confirm the request through your help desk process, such as a call-back to a known number or manager approval, before you touch the account.
- Remove the lost device: Delete the TOTP device that is no longer in the user's hands so it cannot be used by whoever has the phone.
- Prompt re-enrollment at next login: Use the flow that forces enrollment so the user registers a new authenticator straight away.
- Review recent sign-ins: Look for failed or unusual sign-ins on the account around the time the phone was lost.
- Record the reason: Note the ticket, the verification step and the new enrollment in your records.
Confirm which administrator actions your authentik version exposes for removing individual authenticators, since menu locations change between releases.
The hardest case is a user who has lost the phone and has no working second factor, no recovery codes and no other enrolled method. Recovery here must rely on strong, documented identity proof, not on a shortcut that skips MFA. Treat each request as a potential account takeover attempt until identity is established through your defined process.
- Use a defined identity check: Require verification against records your organization trusts, and log who approved the exception.
- Limit the window: Where your flows allow it, issue a temporary path to enroll a new device rather than disabling MFA for the account.
- Do not turn off the factor: Setting the account to skip MFA for a period is a weakening of control and should be avoided or tightly governed.
- Force a fresh enrollment: Once back in, require the user to register a new TOTP device and review whether a static token is needed for the future.
- Watch for repeated requests: Repeated recovery requests from the same account are a signal worth investigating.
Confirm with your security and compliance leads which identity proofing and approval steps are acceptable for your risk level before you publish the procedure.
Most lockouts that reach a help desk could have been avoided by giving users a second route in before they need it. Static tokens and recovery codes are the usual backup, but they are only useful if the user stores them securely and if validation is throttled so the codes cannot be guessed. Set this up during enrollment, not after the user has already lost the phone.
- Issue backup codes at enrollment: Make the static token step part of the same flow as TOTP setup so every user has one.
- Store codes outside the phone: Advise users to keep codes in a password manager or printed copy, separate from the authenticator app.
- Use codes once: Confirm that each code is consumed on use and that regeneration invalidates older codes.
- Protect the codes: Apply throttling and alerting for failed code attempts, as covered in the brute-force protection guidance.
- Plan regeneration: Give users a way to regenerate codes after use, and log each regeneration.
Confirm the exact static token behavior and throttling options for your authentik version before you write the user guidance.
Every recovery path is an alternative way to sign in, so each one must be at least as strong as the factor it replaces. The principle is that recovery restores access to the same protected account under the same controls, and that no administrator action quietly reduces the MFA requirement for the user. Auditors and security reviewers will look at whether recovery changed the account's assurance level.
- Keep the policy unchanged: The authenticator validation stage and enforcement rules should apply the same way after recovery.
- Avoid blanket bypasses: Do not create broad exceptions that skip MFA for a group during an incident.
- Separate duties: Where possible, have one person verify identity and another approve privileged changes.
- Audit every recovery action: Keep records of who changed which authenticator and when.
- Review exceptions regularly: Remove temporary exceptions as soon as the user has re-enrolled.
Before you finalize procedures, check them against your organization's access control and authentication requirements with your compliance lead.
Security and operational risks of TOTP in authentik
TOTP is only as strong as the secret it relies on, the clocks that generate codes, and the records kept when devices change. The cards below cover the risks that connect enrollment, storage, recovery and audit for authentik deployments, with the checks to run before users depend on them.
Secret handling in the database
Each TOTP enrollment creates a shared secret that authentik must hold to verify codes. Because PostgreSQL stores all configuration and data except uploaded files, a database dump or replica without the same protections exposes those seeds. Confirm with the authentik documentation how TOTP device secrets are stored and whether any field-level encryption applies in your version. Restrict database access, encrypt backups, and limit who can read exports that include authenticator data.
Clock drift on phones and servers
TOTP codes depend on both the phone and the authentik server agreeing on the current time window. A phone with a skewed clock produces codes that fail, which users often read as a wrong password and retry until throttling applies. Keep server time synchronized with NTP on every node, and include a phone clock check in the enrollment troubleshooting runbook. Test the tolerance your version applies before setting expectations with users.
Shared authenticator apps
A TOTP seed copied to a second phone, a shared team device or a password manager that a colleague can open turns one factor into several unaccounted ones. Authenticator apps rarely show who holds a seed, so the audit trail cannot distinguish the user from anyone else with access. Set a written policy on where seeds may live, and ask your team whether your authenticator choice allows export or cloud sync that breaks this policy.
Backup and restore effects
Restoring an authentik database from an older backup can revert TOTP enrollments, so a device registered after the snapshot may stop working while a removed device may come back. Users who enrolled a new phone may then fail login without any change on their side. Document the restore procedure with a step that reviews MFA devices for affected accounts, and test a restore before relying on it.
Logging of enrollment changes
Adding, removing or re-enrolling a TOTP device changes how an account can sign in, so these events should be visible to security staff. Confirm which enrollment, deletion and failed validation events authentik records in your version and whether they reach your log platform. Forward them with user, time and source details, and alert on bursts of device changes followed by logins from new locations.
Recovery paths that bypass TOTP
Administrator resets and backup factors are needed when a phone is lost, but each one is also a way around the second factor. A reset performed by a help desk without identity checks lets an attacker remove TOTP and enroll their own device. Define who may reset enrollment, what proof they must see, and how the reset is logged, and confirm which recovery flows your authentik version offers before you publish the procedure.
Questions buyers ask about TOTP with authentik
What does a TOTP setup with authentik cost, and what drives the price?
The software cost depends on the edition you choose, and the services cost depends on the written scope. authentik's Open Source edition is free to use, and its pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month, with Enterprise Plus starting at $20k annually. The services side is driven by the number of user populations, the flows you need to design, how many applications sit behind TOTP, the hosting model, and whether your team wants enrollment guidance or a fully handled rollout. One-time work covers design, configuration and testing. Recurring costs include hosting, the time your staff spend on support, and any retainer you choose. Ask for a quote that lists each of these items separately.
How long does planning a TOTP enrollment rollout usually take?
The planning period depends mostly on how many user groups and applications need the new second factor, and on how much testing your help desk needs before users are asked to enroll. Planning typically covers the enrollment flow, which users must enroll and when, the policy for lost phones, communication to staff, and a pilot group. Organizations with a single directory and a small set of applications usually plan faster than those with several user sources or legacy clients. No fixed duration is set here, so ask any partner for a timeline in the written scope, and check which dependencies, such as an email or support channel, must be ready first.
What does our team need to provide before a TOTP project starts?
You need to provide the access and information that let the work proceed safely. This includes a running or planned authentik deployment, administrator access to the instance, the list of user groups and their directory sources, and the applications that will sit behind the second factor. You also need a decision on which users must enroll, which devices are allowed, and who approves recovery requests. Hosting details matter too: the Docker Compose guide calls for at least 2 CPU cores and 2 GB of RAM for test setups and small production use, and the Kubernetes guide recommends a separately managed PostgreSQL for production. Your team should also name a contact who can test enrollment with real devices.
Can our own team set up TOTP in authentik without outside help?
Yes, a capable team can configure TOTP in authentik, because the authenticator setup and validation stages are part of the product and are documented. The work involves creating an enrollment flow, binding the authenticator validation stage to login, and testing the result with each authenticator app your users run. Teams often find the harder parts are the operational decisions: how to handle users who lose a device, how to limit repeated code guesses, and how to keep a recovery path that does not weaken MFA. If your staff lack time or experience with identity flows, a fixed-scope engagement can cover those decisions and the testing in writing.
Does the Enterprise edition change how TOTP works in authentik?
The supplied pricing information does not list TOTP itself as an Enterprise-only feature, so confirm the current feature split with authentik before you assume either way. The pricing page does list Enterprise-only items such as Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, password history, enhanced audit logging and ticket-based support for subscriptions over $1k. Those items may matter to your rollout if you need audit trails of enrollment or ticket support during go-live. Ask the vendor to confirm which TOTP capabilities, audit events and support levels apply to your chosen edition.
What happens to TOTP access when a user replaces their phone?
A replaced phone means the old authenticator secret no longer exists on a device the user controls, so the user must enroll again through a process your policy defines. Good designs decide before go-live whether the user re-enrolls after verifying identity through another factor, through an administrator, or through a recovery method such as static backup codes. Each option has a different risk, and the choice should match your user population and threat model. Confirm how your administrators reset a TOTP device, how the change is logged, and how repeated failed codes are throttled during recovery. Detailed recovery design is covered on separate pages in this group.
How should we limit repeated guesses against TOTP codes?
Limiting guesses protects the six-digit codes that TOTP apps produce from brute-force attempts during a short validity window. The main controls are failed-attempt limits on the validation step, alerting on repeated failures for one account, and reputation or policy rules that slow traffic from suspicious sources. Confirm which throttling behavior authentik applies to TOTP in your version, because protections for other methods may differ. Your security team should also decide the lockout length, who can unlock accounts, and how those events reach your monitoring system.
How TOTP enrollment works after a phone is replaced
A TOTP device in authentik moves through four stages: enrollment, use, replacement and removal. Enrollment happens inside a flow that gives the user a setup secret, usually as a QR code, then asks for a first code to prove the app holds the same secret before the device is saved. The saved device is a record tied to the user and stored in PostgreSQL, which holds all configuration and data except uploaded files. The server container serves the enrollment and login pages and handles the code check at sign-in, so every step that touches a device record passes through the server to the database. Confirm in your version which stage handles the confirmation code and where the QR code is generated.
Replacing a phone is where lifecycles usually go wrong, because authentik does not transfer a secret from the old handset to the new one. The new phone needs its own enrollment, which creates a second device record, and the old record stays valid until someone removes it. Decide before rollout whether users remove the old device from their own account settings, whether an administrator removes it after an identity check, or both. Your flow and policy configuration determines what a user is allowed to do, so test a replacement the way a user would perform it, with the old phone unavailable. Also confirm whether removing a device ends any sessions that relied on it.
Backups add a second lifecycle. Because PostgreSQL holds the device records, restoring a backup taken before a phone was replaced can bring back a retired device, and its secret will validate again until the record is deleted. Include a post-restore check that compares active TOTP devices with your current user list, and record who may delete devices. The worker container runs background tasks, so confirm in the vendor documentation whether any device cleanup runs there in your version instead of assuming it does. Sessions also live in PostgreSQL from the 2025.10 release notes onward, so restore planning covers them too.
How DeployOpen scopes and delivers TOTP MFA
This sequence turns a TOTP rollout idea into a written scope, a tested authentik flow set running in your infrastructure, and a handover your team can operate and upgrade. Each step ends with a check you can review before the next one starts.
Agree the written scope
DeployOpen and your team define which applications and user groups receive TOTP, which flows are in scope (enrollment, validation, and recovery), and which authentik version and deployment model apply. DeployOpen drafts the scope in writing and your security and identity leads approve it before any build work starts. The step is done when the signed scope lists flows, user populations, recovery procedure, test cases, and deliverables.
Confirm the target environment
DeployOpen reviews the authentik deployment in your own cloud accounts, data centers, or air-gapped network, including the version in use, the time synchronization of hosts, the reverse proxy, and how users reach the login page. Your team confirms access to the test tenant and the stored PostgreSQL data. The step closes with a short environment record that shows which version and topology the flows will be built against, so later behavior can be traced to a known setup.
Design enrollment and recovery flows
DeployOpen designs the authenticator setup flow, the validation stage that users meet at login, and the recovery path for a replaced phone. Decisions include what happens when a user has no authenticator yet, who can reset enrollment, and which identity checks an administrator performs before a reset. The design is written up for your approval so that support staff know exactly what a user will see. The step is complete when the flow diagrams and recovery runbook are accepted by your team.
Build flows in your infrastructure
DeployOpen configures the authentication flows, stages, and policies in authentik using your change process, and where your team uses configuration as code, stores the definitions in your repository. Build work runs in the test environment inside your infrastructure, so no authenticator secrets or user data leave it. The step closes when the flows are deployed to test, and the configuration diff is reviewed and committed by your team.
Test enrollment, validation, and throttling
DeployOpen runs the written test cases against the test environment, covering enrollment with common authenticator apps, repeated wrong codes, lockout behavior, clock drift on user devices, and each recovery path. Results are logged against each test case with the observed behavior and any defects. Your team repeats the critical cases to confirm them independently. The step is done when every in-scope case has a recorded pass or an agreed fix.
Pilot with a controlled user group
DeployOpen and your team enable TOTP for a small, named group chosen in the scope, and collect support tickets and failed-login data from that group. Any problem found is traced to the flow, the policy, or the user device, and fixed through the same change process. The pilot ends when your team agrees the enrollment and recovery experience is working as designed. This is a validation step, and the exit criteria come from the written scope.
Hand over runbooks and roll out
DeployOpen delivers the documentation for administrators and help desk staff, including the enrollment guide, the recovery runbook, the test evidence, and the change record. Your team takes over the rollout to the remaining user populations under your own approval process. The step is complete when the handover package is accepted and your operators can reproduce the recovery procedure without DeployOpen.
Agree ongoing support through a retainer
If your team wants continued help, DeployOpen and your organization can agree a retainer covering support, authentik version upgrades, and repeat testing of the MFA flows after changes. The retainer scope, its recurring cost, and the response arrangements are written before it starts, and the work is performed in your environment. The step is done when the signed retainer names the systems, versions, and test cases it covers. Ask for the retainer terms in writing, because the cost and coverage depend on that scope.
