Self-service password recovery in authentik

Self-service password recovery in authentik: why an email link alone is not enough

A recovery flow that sends a reset link and nothing else lets anyone who controls the mailbox take over the account. The emailed link proves only that someone can read the inbox, not that the person asking is the account holder. Self-service recovery fits when your users are numerous enough that help desk tickets for forgotten passwords would be costly, and when the mailbox itself is well protected by its own provider and MFA. It is a poor fit when the account reaches sensitive applications and the mailbox is shared, weakly protected, or reachable by a former employee. The authentik hardening guide advises against letting an emailed link alone reset an account, so treat email-only recovery as a finding to remediate, not a default to accept.

A safer flow adds two things before the password can change. The first is email verification, where the user proves control of the address with a one-time code or link that expires. The second is MFA before reset, where the user must also complete a second factor already enrolled on the account. Build this as a dedicated recovery flow with its own stages and bind it to the policies that decide who may use it, so that accounts without an enrolled second factor are routed to a path your help desk controls instead of a weaker one. Confirm in your authentik version which stages can be chained in this order and how the flow behaves when a user has no enrolled factor, because that edge case is where recovery flows most often fail open.

Before go-live, confirm the account enumeration settings with the hardening guide in hand. Keep Pretend user exists enabled so the recovery page gives the same response for real and unknown usernames, and disable Show matched user so the flow does not reveal which accounts exist. Plan recovery for administrators separately: privileged accounts should not use the self-service path at all, and their reset should go through a supervised process with a verified out-of-band check. Ask your implementation partner or internal team to test each path with a real mailbox, an enrolled factor and a locked-out account, and record the results as evidence for your access control reviews.

Recovery settings and when each one fits

This table compares the recovery approaches and the two account enumeration settings from the authentik hardening guide. Read each row as a choice: what it controls, the risk it addresses, and what it costs to run. Confirm exact setting names and behavior in your authentik version before you change anything.

Option	What it controls	Risk it addresses	Operational cost
Email-only reset	A reset link sent to the registered address lets the user set a new password without a second check	Low friction for users who have lost a password and have no other factor enrolled	Lowest effort, but anyone who controls the mailbox can take over the account, so the hardening guide advises against it
Email plus second factor before reset	The user must pass an MFA stage in the recovery flow before the password can change	Mailbox compromise alone is not enough to reset the account	Needs enrolled factors for every user, help desk handling for lost devices, and testing of each factor path
Administrator-initiated recovery	An administrator resets or verifies the identity of the user outside the self-service flow	Highest assurance for privileged accounts and users without enrolled factors	Ties up administrator time and needs a documented identity check and audit trail
Pretend user exists (kept on)	The recovery and login responses look the same whether or not an account exists	Attackers learning which email addresses hold accounts for phishing or spraying	Usually no added cost; confirm the response behaves the same in your version and proxy setup
Show matched user (disabled)	Whether the interface reveals the username or email that matched the input	Account enumeration through the recovery screen	Users who mistype their identifier get less feedback and may need help desk contact
Recovery flow with stage ordering	The order of identification, verification and password stages in the flow	Reset completing before the second factor is checked	Every flow change needs regression tests for each login path and each enrolled factor

Four ways an email-only reset takes over an account

An emailed reset link proves control of a mailbox, not control of the person who owns the account. The four cards below describe where that gap appears in a recovery flow built in authentik and what the team should verify before go-live.

Compromised or forwarded mailboxes

Anyone who can read the mailbox can complete the reset, including an attacker who has phished the mail password, a former employee with a forwarding rule still active, or a mail administrator. In authentik, the recovery flow should place an MFA challenge between the emailed link and the password form, so the link alone cannot set a new password. Verify that the stage order in the flow is correct, that the MFA stage is bound to the recovery flow, and that a test account without a second factor is blocked from completing the reset.

Shared or delegated inboxes

Team mailboxes, helpdesk queues and assistant-managed inboxes let several people read the same reset email. A reset link sent to such an address therefore reaches people who are not the account owner. Decide which accounts may use email recovery at all, and keep privileged and service-linked identities off the email path. Verify that accounts tied to shared addresses are routed to an administrator-assisted recovery path, and that the email address stored on each user is one that belongs to that user alone.

Account enumeration through differing responses

If the recovery page answers differently for registered and unregistered addresses, an attacker can build a list of valid accounts before attempting any reset. The hardening guide recommends keeping Pretend user exists enabled and disabling Show matched user, so that the response looks the same either way. Verify both settings in the stage configuration, submit a known and an unknown address, and confirm that the page text, timing and next step match for both.

Sessions that survive a password change

A successful reset that leaves existing sessions and tokens active lets an attacker who already holds a session keep access after the owner changes the password. The recovery flow should end all other sessions for the user, and the team should confirm how long issued tokens remain valid for each application. Verify by signing in on a second browser, completing a reset, and checking that the older session is rejected. Also confirm the behavior of any refresh tokens issued by connected applications, because those may need separate revocation.

Build the password recovery flow in a safe order

This sequence builds the recovery path so that a reset link alone cannot change a password, and each control is checked before the next one depends on it. The result is a tested flow bound to the right brand, with known enumeration settings and a verified path for a test account.

Confirm the authentik version and release line
Before any configuration, record the authentik version your deployment runs and check it against the release line the project lists as receiving security fixes in its security policy. Confirm the exact stage names and settings in the admin interface for that version, because flow and stage options change between releases. Check the GitHub releases page for the newest release and read the notes for any release newer than yours that touches flows or email. Done means you have a written version number, a supported-line confirmation, and a note of the release notes you reviewed. Ask your platform team to keep this record with the change ticket.
Configure and test outbound email
Recovery depends on email, so set up the outbound SMTP settings in authentik and send a test message to a mailbox your team controls. Confirm the sender address, the TLS mode and the credentials with your mail team, and check that the message arrives with the expected sender and link host. Send a second test to an address outside your domain to confirm external delivery. Done means both test messages arrive, the links point to your authentik hostname, and the delivery log shows no errors. If delivery fails, fix it here, because every later test depends on it.
Create the recovery flow with email verification
Create a dedicated recovery flow in the admin interface and add an identification stage, an email verification stage that sends a one-time code or confirmation, and a password change stage. Keep the verification stage before any stage that lets the user set a new password. Do not reuse the login flow for this purpose. Done means the flow shows the stages in that order, and a test run asks for the user identifier and then sends a verification message before it shows a password form.
Require MFA before the password change
Add an authenticator validation stage that runs after email verification and before the password change stage, so the user must prove possession of a registered second factor before choosing a new password. Bind the stage to the factors you have enrolled for your users, and decide with your security owner how users without a factor are handled, such as an administrator-assisted path. Confirm the policy on that stage so it does not skip for accounts that have never enrolled, unless you have decided that is acceptable. Done means a test account with MFA is prompted for its factor before the password form, and a test account without MFA reaches the path you chose.
Set account enumeration options
Open the identification stage settings and follow the hardening guide's guidance: keep Pretend user exists turned on, and turn off Show matched user. With these settings, a request for an unknown address produces the same visible response as a request for a real one, and the page does not reveal which accounts exist. Check the same behavior in the login flow, since attackers probe both. Done means a request for a known address and a request for an unknown address return the same screen and the same wording, and the test confirms no account name appears on the page.
Bind the flow to the correct brand or domain
Assign the recovery flow to the brand that serves the domain users will reach, and confirm the brand's default flows do not point users to another flow by mistake. If you run several brands, repeat the check for each one. Use a private browser session and open the recovery link from each domain to confirm the right logo, text and flow load. Done means every brand in scope opens the intended recovery flow, and no brand falls back to a default flow you did not review.
Test each recovery path with test accounts
Using test accounts you create for this purpose, run each path end to end: a user with MFA, a user without MFA, a request for an unknown address, a link that is expired or already used, and a repeated request. For each run, record the screens shown, whether the password changed, and the event log entries written. Confirm that no path lets an email link alone complete a reset. Also check that administrator accounts follow the recovery path you have documented for them, since they are often excluded from self-service. Done means every path produces the expected result in your test record, and any gap is fixed and retested before the flow goes live.

Account enumeration settings by deployment situation

On a login page reachable from the internet, anyone can submit an address and compare the responses. If the recovery form, the confirmation page or the error text differs for an existing account, an attacker can build a list of valid usernames before trying any passwords. Treat the recovery entry point as public and assume it will be probed.

Keep Pretend user exists on: The authentik hardening guide recommends this setting, so the recovery step returns the same confirmation whether or not the address matches an account.
Disable Show matched user: With this off, the flow does not echo back a matched identifier, which would otherwise confirm an account to whoever submitted it.
Compare the whole path: Check page text, status codes, timing and any redirect for a known and an unknown address, since a difference at any step can reveal an account.
Expect support questions: With a neutral response, a user who mistyped an address sees the same message as everyone else and may assume an email is on its way. Give support a way to find the account without confirming it publicly.

Run these comparisons from outside your network, using a test account you control and an address that does not exist, and repeat them after every flow or stage change.

Recovering administrator accounts without a backdoor

Administrator accounts should not use the same self-service recovery path as regular users. A recovery flow that a user can complete from a mailbox alone is a takeover path for anyone who controls that mailbox, and administrator accounts can change flows, providers, policies and signing keys. For that reason, the recovery design for administrators should be a separate process with a human decision in it. The practical options are an administrator-initiated reset, where another administrator sets a temporary credential after verifying the request out of band, a break-glass account kept outside the normal sign-in path with its credential stored offline, and logging of every recovery action so that each reset can be traced to a person and a ticket. Most organizations need a combination of these, and the choice depends on how many administrators exist and whether they hold MFA devices that can be lost.

Before go-live, document the recovery runbook in writing. It should name who may approve an administrator recovery, the identity check that must happen before approval (for example, a call-back to a number on file rather than a number in the request), which accounts are break-glass accounts and where their sealed credentials and second factors are stored, and how a recovered account is reviewed and returned to its normal state. Keep the approval rule separate from the people who perform the reset where your size allows it, and confirm that your audit logging captures the reset, the approver and the session that followed. Confirm the exact audit fields and retention with your own compliance owner, since those requirements come from your environment rather than from authentik.

Test the break-glass account on a schedule and after every upgrade, because an upgrade can change flows, stages and the way MFA devices are bound. Sign in with the break-glass account on a non-production copy after each upgrade, complete the MFA step, and record the result. Check that the account still belongs to the groups that grant administrator rights, that the flow it uses has not been changed by a default flow update, and that the offline credential still matches the account. Upgrades in authentik should follow the sequence described in its security policy, which is where supported versions and advance notice of security releases are listed, so schedule the break-glass test as part of each upgrade window rather than as an afterthought.

Limits to confirm in your environment before go-live

A recovery flow is only as safe as the assumptions behind it. The cards below list the behaviors we recommend you confirm in a test tenant or your own environment, not assume from the flow diagram. Each one names where the answer should come from.

Email delivery and link expiry

A recovery link is only as trustworthy as the mail path that carries it. Confirm how long the reset link stays valid in your configured flow, whether delivery is retried when a message bounces or is deferred, and how users see a failed send. Test with your real mail relay and with at least one external mailbox provider, and record the timestamps so you can show expiry behavior to an auditor. Ask whether a stale link can still complete after a newer reset request.

Password history on your edition

Password history is listed on the pricing page as an Enterprise-only feature, so a recovery flow that blocks reuse of earlier passwords depends on your license. Confirm the edition you are licensing includes it before you write it into a policy or control narrative. If you run Open Source, plan a compensating control or document the gap. Ask the vendor in writing which features the license covers.

Recovery with external identity sources

If a user authenticates through an upstream directory or identity provider, a local password reset may not change what they actually sign in with. Map each account type to its authoritative source, then test recovery for a local user, a user sourced from LDAP, and a user federated from another identity provider. Confirm which of these the flow can reset, which it should redirect, and what the user sees in each case. Do not assume the outcome.

Flow changes across upgrades

Stage bindings, policy order and prompt fields can change between releases, and an upgrade may silently alter how recovery behaves. Before each upgrade, export the recovery flow and its bindings, read the release notes for the versions between your current and target release, and rerun your recovery test cases on a staging instance. Confirm the upgrade order required by the project, since the security policy lists which versions receive fixes.

Mail provider rate limits

Recovery is a common target for abuse, and a flood of reset requests can exhaust your sending quota and lock out legitimate users. Ask your mail provider for its per-minute and per-day limits, how it handles bursts, and whether it throttles by sender or by recipient. Then decide how the flow should respond when limits are hit, and whether rate limiting belongs in front of the flow or in a reputation policy. Record the answers in your runbook.

Questions teams ask before building self-service recovery

What drives the cost of building a self-service password recovery flow in authentik?

The cost depends mostly on how many decisions the build needs and how much of the work your team can absorb. The core flow is a set of stages: an identity step, an email verification step, a second factor check, and a password change step. Each added requirement, such as tying recovery to a specific MFA method, handling several user sources, or writing custom policies, adds design, build and test effort. Ask any partner for a quote built from a written scope that lists the stages, the identity sources, the mail delivery path and the test cases, since those items set the effort. Quotes should separate one-time build work from recurring testing and upgrade work.

How long does a typical recovery flow build take?

Duration follows the number of identity sources and MFA choices more than the flow itself. A recovery flow that uses one directory and one email path is a smaller job than one that must respect separate user populations, LDAP clients, or a mix of TOTP, hardware keys and email codes. Mail delivery work can also take time if the mail server team must approve a sender address or open a relay. Ask for a timeline that shows which steps wait on your mail, identity and security teams, and agree on test accounts early so validation does not stall the schedule.

What does our team need to provide for the build?

Expect to provide access and decisions rather than code. The build needs a sending mail account or relay that authentik can use, a named owner for MFA policy (which factors are allowed for recovery and which are excluded), and a set of test accounts covering each user type, including accounts with and without enrolled second factors. You will also need someone to approve the account enumeration settings and to confirm how administrator accounts are recovered. Agree on these inputs in writing before the build starts, because missing mail access or unresolved MFA rules are common causes of rework.

Can an internal team build self-service recovery without outside help?

Yes, an internal team can build it if it has engineers who know authentik stages and policies, access to a test instance, and time for security review. The work is documented in authentik's hardening guidance, so the design questions are known in advance. The risk lies in the details: a flow that leaves an email link as the only proof of identity, or a setting that reveals whether an account exists, can pass a casual test and still fail review. An outside partner can add an independent review of the flow and a test plan, which is useful when no one on the team has tested recovery against an attacker's view.

What recurs after recovery goes live?

Recovery is not finished at go-live. Each authentik upgrade can change stage behavior or policy handling, so the recovery flow needs regression testing after every upgrade, which follows the supported version policy and the security release notice the project publishes. Enumeration settings also need periodic review, since a change to a related setting elsewhere in the instance can reopen a disclosure. Mail credentials rotate, MFA options change, and new user populations appear. Plan a recurring review that repeats the test accounts and checks, and decide whether that work stays in-house or sits under a support retainer.

Does the open-source edition support every recovery setting?

Not necessarily. authentik's code is largely under the MIT license, but code in the enterprise directory uses a separate license, and the pricing page lists some features as Enterprise only. Password history is one such feature, so a recovery design that requires preventing reuse of older passwords on reset depends on the edition you run. Before design starts, check the current feature list against each setting you need, confirm the license terms that apply to your version, and record which controls rely on Enterprise features so auditors and procurement see the same picture.

How DeployOpen scopes and delivers password recovery in authentik

DeployOpen plans, builds, documents and supports self-hosted authentik inside your own infrastructure, including recovery flows that keep email from becoming the only way to take over an account. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How we scope

Map which accounts, user populations and applications the recovery flow must cover before any configuration starts.
Record the required verification steps, including whether MFA must be completed before a password reset is allowed.
Agree in writing how enumeration settings, administrator recovery and audit evidence will be handled and tested.

How we build

Configure the recovery flow in your authentik instance so a link alone cannot complete a reset.
Set account enumeration options to the hardening guidance, keeping Pretend user exists on and Show matched user off.
Test each recovery path with standard, MFA-enrolled and administrator accounts before release.

How we hand over

Document the flow stages, policy bindings, settings and rollback steps for your team to operate.
Walk your identity and operations staff through test results, known limits and the upgrade checks to repeat.
Provide evidence of configured controls that your internal or external auditors can review.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
Re-test the recovery flow after authentik version upgrades, since flow and stage behavior can change between releases.
Confirm with your team which support tier, response expectations and maintenance windows apply before signing.

Self-service password recovery in authentik