Force a password reset at next login in authentik

How to force a password reset at next login in authentik

Teams usually need a forced reset after a directory migration, after a set of credentials has leaked, or when a shared account has to be retired and its users moved to individual logins. authentik documents a pattern for requiring users to reset their password on next login, and the work is a flow and policy design task, not a single switch. You build the behavior from a flag on the user, a policy that reads that flag, and a password change stage that runs in the sign-in flow when the policy matches. The page you need is the authentik password reset on login documentation, which sets out the pattern for the version you run.

Plan the flag before the flow. Decide who gets the forced reset (all users, one group, or users imported from a specific source), who sets the flag (an administrator, a migration script, or a bulk update through the API), and when the flag clears, which should happen only after a successful password change. Confirm the exact stage, policy and attribute names in the current docs for your running version, because names change between releases and an incorrect attribute key will silently never match. Test the flow with a disposable user before you apply it to a population.

A forced reset does not replace the other steps that a compromise or migration requires. It does not end existing sessions, so you still need to revoke active sessions for affected accounts. It does not rotate API tokens, service account credentials, or secrets stored in applications, which must be rotated separately. It also does not add a second factor: a user with a leaked password can still be stopped only by MFA or a risk-based policy if those controls are in the same flow. Treat the forced reset as one control in a sequence, and write down which of these steps your incident or migration runbook covers.

Which triggers justify forcing a password reset in authentik

A forced reset at next login is a targeted control, not a cure-all. Each trigger below changes what the reset protects against and what it leaves open, so match the trigger to the control before you build the flow. The documented pattern for requiring a reset on next login is the same in every case; the decision lies in who gets the prompt, when, and what else you revoke.

Directory or identity migration

When users move from another directory or identity provider, imported password hashes may not match the rules or hashing you want going forward. A forced reset at next login lets each user set a credential that lives in authentik. Check that the migrated hash still authenticates, that the reset flow is bound only to the migrated group, and that users who never return are handled by a deadline you have agreed with the business.

Suspected or confirmed credential leak

After a leak, a reset removes the password an attacker may hold, but it does not end sessions, OAuth2 tokens or refresh tokens already issued. Confirm which accounts are affected, then reset those accounts and review active sessions and provider tokens separately. Ask your security team whether MFA enrollment also needs to be re-verified before the reset takes effect.

Shared or inherited accounts

When several people have used one account, or a role changes hands, the old holder may still know the password. A reset at next login gives the new owner sole control, but only if the account is not used by a service process that depends on the old password. Identify automated consumers first, since a reset can break scripts, LDAP binds or integrations that read the same credential.

Temporary passwords set by administrators

Help-desk resets and onboarding often issue a temporary password that a user should replace immediately. Forcing a change at next login makes sure the administrator never keeps the user's final credential. The reset does not verify the person behind the account, so pair it with your identity proofing for the initial credential and confirm the temporary password is delivered through a channel that is not email alone.

Policy change requiring new credentials

When a new password rule, minimum length or banned-password check takes effect, existing passwords may no longer meet it. A reset at next login applies the new rule only to users who sign in after the change, so active users with old passwords may stay unaffected for a long time. Decide whether you need a forced cutover for all accounts or a reset triggered at the next sign-in, and document which one you chose for auditors.

Account recovery after a compromised mailbox

If an attacker controlled a user's email, a password reset alone can be undone by an attacker who still receives the recovery link. A forced reset at next login helps only after the mailbox is recovered and verified, so confirm the mailbox owner before the user sets a new password. Coordinate this with your recovery flow so a reset does not hand control back to the wrong person.

Choosing how to trigger the reset: flow pattern, user attribute or manual action

This table compares four ways to decide which users must change their password at next sign-in: the documented flow pattern, a per-user attribute, a group or policy scoped trigger, and a one-time administrator reset. Read each row against your own user population and your authentik version, since behavior depends on how the flow is bound. The main takeaway is that the trigger choice determines who controls the reset and how much ongoing work it creates.

Option	What it covers	Who controls it	Operational effort and when it fits
Documented flow pattern	A password reset on login pattern that forces a change at sign-in for users the flow applies to. Confirm which users the documented pattern reaches in your version.	Administrators who build and bind the flow to the login path	Moderate upfront build and testing, then low upkeep. Fits a defined reset event that applies to a known population.
Per-user attribute or flag	A user attribute the flow checks at login, set individually or in bulk, that marks the account as needing a change	Administrators or automation that set the attribute, often from a migration script or a leak list	Low build effort, but someone must set and clear the flag reliably. Fits selective resets, such as accounts found in a leaked credential list.
Group or policy scoped trigger	Users in a chosen group, or matching a policy, are routed through the reset stage at login	Group owners and whoever edits policy bindings, which needs tight change control	Moderate, with ongoing review as group membership changes. Fits recurring populations such as contractors or a department after an incident.
One-time administrator reset	A manual action that forces a single account to change its password, with no standing flow logic	Individual administrators performing the action case by case	High effort per account at scale, minimal design work. Fits small numbers of accounts or urgent, isolated cases.
Combined approach	Flow pattern for the general event, plus attributes or groups for exceptions	Shared between the identity team and the owners of the attribute or group data	Highest design effort, but clearest audit trail for large events. Fits organizations that reset credentials regularly.
Illustrative: post-migration reset	A hypothetical migration moves 2,000 users, all flagged by an attribute set in the import job	Migration team sets the flag, identity team owns the flow	Effort concentrated in the import job and rollback plan. Confirm the flag clears only after a successful change.

How the reset-on-login pattern fits into authentik flows and policies

A login flow in authentik runs its stages in a fixed order, and each stage either prompts the user, checks something, or passes them along. Policies are bound to flows and to individual stages, and a binding decides whether a stage runs for a given user. For a forced reset, the state that triggers the change is usually a user attribute, such as a flag set by an administrator or a script after a migration or a suspected leak. A policy reads that attribute and, when it is set, lets the password change stage run. Once the user has changed the password, the flag is cleared, so the next sign-in passes straight through. The exact pattern, including which attribute and bindings to use, is described in the authentik password reset on login documentation.

The main design choice is where the check lives. You can attach the reset to the authentication flow itself, so every sign-in evaluates the attribute as part of normal login. Alternatively, you can run a separate check after authentication, in a flow that only handles required actions for signed-in users. The first keeps the logic in one place and covers every entry point that uses that flow, but it means every flow that signs users in must carry the same binding. The second is easier to scope to specific applications or brands, but it can be missed by a login path nobody reviewed. Confirm with your own configuration which flows your applications actually use before choosing.

Stage order is where most mistakes happen. If the password change stage runs before the policy that clears the flag, or if a later stage re-evaluates a condition the reset does not satisfy, users can be sent back into the reset every time they sign in. Test with an account that has the flag set, complete the reset, and sign in again through each application and each flow, including any MFA and consent stages. Also test a user whose password change fails part way through, since that user should stay in the reset and not gain access. Record the expected stage sequence before you change anything, so a later edit to the flow is easy to check against it.

Setting up a forced password reset at next login in authentik

This sequence turns the documented password-reset-on-login pattern into a tested control: you confirm the platform baseline, pick a marker you can audit, wire the flow, prove it on a test account, and leave a rollback path. It produces a forced reset that works for new sign-ins without disrupting sessions that already exist.

Confirm version, edition and deployment baseline
Record the running authentik version and the edition you license, then confirm the deployment shape your team operates: server and worker containers and PostgreSQL. Check the version against the security policy's list of supported releases and against the upgrade notes for your line, because flow and policy behavior can change between releases. Ask your vendor or check your own environment to confirm whether you run the Open Source edition or Enterprise, since some identity features depend on the edition. Done when you have a written version number, edition, and a list of the flows you expect to touch, approved by the platform owner.
Decide the trigger attribute and its owner
Choose the user attribute that marks a user as needing a reset, for example a flag set by an administrator after a migration or a leak response. Name one owner for the attribute, define who may set and clear it, and decide whether it is set manually, through a script, or by an upstream directory. Restrict edit rights on user attributes to that owner so a user cannot clear their own marker. Done when the attribute name, owner, setter and clearing process are written down and the access rule is tested with a non-admin account that cannot change the value.
Add the reset stage and policy to the flow
Following the pattern in the authentik documentation on password reset at login, add a password change stage to the sign-in flow you use for the affected applications and bind a policy so it runs only when the marker attribute is set. Keep the binding order explicit so the reset check runs after the user has authenticated and before the session is granted. Export or record the flow and binding configuration before saving. Done when the flow diagram in the admin interface shows the policy-gated stage in the expected position and no other flow has changed.
Set the marker on a dedicated test user
Create or pick a test user that is not used by anyone in production, set the trigger attribute on that account, and confirm the account is in the groups the flow applies to. Do this in a non-production or clearly separated tenant if you have one. Record the exact time you set the marker so the audit trail can be matched later. Done when the test user's attributes show the marker and the audit log records the change under the expected administrator account.
Verify the full sign-in and marker clearing
Sign in as the test user to an application bound to the flow. Confirm that the password change prompt appears before access is granted, that the new password is accepted under your password rules, and that the marker attribute is cleared afterward. Then sign in again and confirm the prompt does not reappear. Test one failed attempt as well, so you know the stage does not grant access when the change is abandoned. Done when both sign-ins behave as described and the audit log shows the password change and attribute update.
Check existing application sessions
A policy on the sign-in flow does not end sessions that a user already holds. Inventory the applications and identity sessions that were issued before the marker was set, and decide whether to revoke them through an administrator action, wait for their natural expiry, or accept the risk for a defined period. Confirm the session lifetimes for each relevant provider in your own configuration rather than assuming them. Done when you have a list of affected applications, the chosen session action, and a test showing that a revoked session forces a fresh sign-in through the reset flow.
Document the rollback and communication
Write the rollback steps: unbind the policy or stage, restore the exported flow configuration if needed, and clear any markers that should not remain set. Prepare the user message that explains why the prompt appears, what to expect at sign-in, and who to contact if the change fails, and agree it with the people who will send it. Store the runbook with the change record and review it after the first real use. Done when the rollback has been rehearsed on the test account and the communication text has been approved.

Who sets the flag, who changes the password and what users are told

Administrators decide who is affected, how the marker is set and how the change is recorded. The documented pattern in authentik is a flow that checks a condition at sign-in and routes the user to a password change before the session continues. Read the authentik password reset on login documentation and build the change record around the trigger, the scope and the audit export.

Choose the trigger: Decide whether the marker comes from a bulk action, a migration import or an incident response step, and record which one applies in the change ticket.
Scope it to a group first: Apply the requirement to a named group, test it, and widen it only after the results match the plan.
Test with a pilot account: Sign in as a test user in a non-production instance and confirm the reset screen appears once and clears after the change.
Audit the marker: Export the flagged users and review who set or cleared the marker. Confirm with the vendor documentation which events your version records.
Agree the notice timing: Set the communication plan with the communications owner before the flag is set, so users are not surprised at sign-in.

Check that the flow, the group scope and the audit export match the change record before the flag reaches production users.

Security risks of a forced reset and how to contain them

A forced reset changes the password, but it does not by itself close the paths an attacker or a careless process can use. The cards below cover the places where a reset flag can fail, be bypassed or leave a gap, and the containment step for each. Check each one in your own environment before you rely on the reset as a control.

Unauthorized or stale reset flag

A reset requirement is only as trustworthy as the account attribute or policy that sets it. If an administrator account or an integration can set the flag, a compromised account can force resets on others or keep a legitimate user locked in a loop. Restrict who can change the flag, limit it to a small administrative group, and review changes to user attributes. Confirm which roles in your tenant can edit user attributes and where the flag is cleared once the user has changed the password.

Bypass through other flows

Users may reach a session through an enrollment, recovery or another authentication flow that does not check the reset requirement. Map every flow that can issue a session for the affected users and confirm that each one evaluates the same requirement. Test the reset pattern with a sign-in from a browser, a mobile client and an API-driven login, and record which paths pass the check. Treat any path that skips it as a gap to close before the reset is announced.

Sessions and tokens after a leak

Changing the password does not end sessions or tokens that were issued before the change. After a leak, an attacker may still hold a valid session cookie or an access token until it expires. Decide which sessions to revoke for affected users, end them as part of the reset, and confirm how long issued tokens remain valid in your provider settings. Document the revocation step so the incident team does not have to work it out during an incident.

Legacy LDAP and RADIUS clients

Clients that bind to LDAP or authenticate over RADIUS do not pass through the web login flow, so a web-only reset requirement may never reach them. A user can keep using an old password in a VPN client, a mail client or a Wi-Fi profile after the web reset. Inventory which clients use directory or RADIUS credentials for these users, confirm how each one handles the reset, and plan a password change on each client. Check the current authentik documentation for how the requirement applies to these protocols.

Password reuse

A forced reset does not stop a user from choosing the old password again or a close variant of a leaked one. Password rules are a separate control and need their own checks. Ask whether your edition supports password history, which is listed as an Enterprise feature on the pricing page, and confirm the feature against the current release before you depend on it. Where history is not available, combine complexity rules and breach checks in the same flow.

Audit trail of the reset

Auditors and incident teams need to show who required a reset, when the user changed the password and whether the old sessions ended. Without events for each step, the reset is hard to prove. Confirm which events authentik records by default for flag changes, password changes and session ends, and whether your edition includes enhanced audit logging. Forward those events to the log platform you already run and test that a reset can be traced end to end.

What to confirm in your environment before you rely on a forced reset

Treat the documented pattern as a starting point to verify, not a guarantee. Before you depend on a forced reset, run it in a test environment built from the same authentik version and configuration as production. Confirm that the steps in the authentik password reset on login documentation match what your release actually does, because flow pattern details and stage names can differ between versions. Record the exact authentik version you tested, since the security policy only covers releases on the supported lines, and plan to repeat the test after each upgrade.

Next, check how the reset interacts with everything else a user must complete at sign-in. Test a user who has no second factor yet, a user with an existing TOTP or hardware key, and a user who is enrolling a new device. Confirm the order of the password stage, any MFA enrollment or validation stage, and any mandatory consent or terms stage, and make sure a user cannot skip the password change by reaching a later stage directly. Also test non-web clients, such as LDAP or RADIUS consumers and applications that keep long-lived tokens, and document whether they honor the change immediately or only after their own sessions expire.

Finally, verify the parts of the design that a reviewer will ask about. Find out where the marker that forces the reset is stored, which attribute or flag holds it, and which administrators and automation accounts can set or clear it. Test what happens to active sessions and refresh tokens when the marker is set, and whether revoking sessions is part of the procedure. Confirm that the password rules and breach checks applied during the forced change are the same ones you apply everywhere else, including any history or expiry settings, and that the rules work in your air-gapped or offline setup if you have one. Keep the test results as evidence, because they show what your environment does, not what the documentation promises.

Questions teams ask before forcing a password reset in authentik

How much effort does forcing a password reset at next login take in authentik?

The effort depends less on the setting itself than on how many flows, applications and client types the reset must touch. Forcing a reset is typically built as a stage bound to the login flow, guarded by a user attribute that marks the account as due for a change. Teams with one login flow and a few OIDC applications have a small change to build and test. Teams with several brands, custom authentication flows, LDAP or RADIUS clients, or applications that cache sessions need more testing, because each client type reacts to a forced change differently. Ask any partner to split the quote into flow design, client testing, user communication and runbook work so you can see what drives each part.

Is the open source edition of authentik enough to force password resets?

The open source edition is the right starting point for building the reset pattern itself, because it is released under the MIT license for most of the code. Confirm the edition boundary on the authentik pricing page before you commit. That page places password history among the Enterprise-only features, so if your policy requires that users cannot reuse recent passwords when they reset, you need to check whether the Enterprise edition is required. Also confirm licensing for any code under the enterprise directory if your design depends on it. Put the edition question to the vendor in writing before the design is signed off.

How long does a forced password reset rollout take?

No fixed duration applies, because the rollout length depends on the number of users, how many of them sign in regularly, and how much notice you give them. A rollout that flags a small internal group can finish quickly. A rollout that flags thousands of customers or contractors needs a communication plan, a support queue for lockouts, and a staged schedule so the help desk is not overwhelmed on day one. Ask your partner for a timeline built around your user counts, your communication owner and your change freeze dates, and confirm which parts depend on your approvals rather than on technical work.

What does the customer team need to provide for this work?

The work needs named owners on your side more than it needs large amounts of time. You will need an administrator who can create flows, stages and attributes in the authentik instance, a person who controls which users are flagged, and a communication owner who writes the notice users receive. Your application owners must confirm how each application handles a password change mid-session and whether it uses a separate directory. A security reviewer should approve the trigger conditions and the fallback for users who cannot complete the change. Agree on a test tenant or staging instance so changes are tried before they reach production users.

Can our own team force password resets without outside help?

Yes, a team that already runs authentik and has an engineer comfortable with flows, stages and user attributes can build a basic version internally. The documented pattern gives the starting point, and the vendor documentation describes the reset-on-login behavior. Where teams struggle is in the edge cases: service accounts, LDAP binds, RADIUS clients, API tokens, and applications that keep their own sessions. Those cases are where mistakes cause lockouts. If your team has no one who has tested authentication flows across these client types, a short review or a fixed-scope engagement can cover the gaps while your team keeps ownership of the running system.

When is outside help worth paying for on a password reset project?

Outside help is most useful when the forced reset is tied to a migration, a suspected leak, or a regulated population where the change must be documented and repeatable. A partner can document the flow design, test each client type against the change, prepare the runbook for help desk staff, and hand over a tested configuration. Ask for a written scope with deliverables and a clear list of what is excluded, such as your identity source changes, application code changes or your communication approvals. If you need ongoing support after the first rollout, that is a separate retainer to agree on in advance.

What can go wrong when forcing a password reset at next login?

The most common problems are lockouts for users whose applications do not expect a mid-session password change, service accounts that get flagged by mistake, and LDAP or RADIUS clients that cannot complete an interactive reset. Users who have forgotten their password may also loop between the reset stage and recovery. Test with a pilot group, confirm how each client reports a required change, and keep an administrator path to clear the flag. Review the logs during the first days of rollout and confirm how your team will forward and retain them. Also confirm that flagged accounts cannot be used to bypass the change through other flows.

Should we combine the forced reset with a password policy change?

Usually yes, but treat them as two decisions with separate owners and tests. A forced reset changes when users must act, while a complexity, breach-check or expiry rule changes what a valid password looks like. Combining them in one rollout means users face two changes at once, which increases support load. Confirm with your security and compliance owners which rules are required, then sequence the reset and the rule change so the first notice explains exactly what users must do.

How DeployOpen scopes and delivers a forced password reset

DeployOpen treats a forced password reset as a scoped change to your authentik flows, user attributes and communication plan, not a single setting. We agree the trigger, the affected users and the rollout in writing, then build, test and hand over the working configuration inside your own infrastructure.

How we scope

Confirm which users, groups or applications the forced reset applies to and why it is triggered
Record whether the reset follows a migration, a suspected leak or a policy change, since each shapes the flow
Agree in writing the deliverables, exclusions and acceptance checks before any configuration changes begin
Identify who communicates with users and which channels and notice periods your organization already uses

How we build

Configure the documented password reset on login pattern in a non-production authentik instance first
Define the user attribute or flag that marks an account for reset, and test how it clears after the change
Test sign-in for representative accounts across each application and provider that authenticates against authentik
Keep changes in version-controlled configuration where your team uses that approach, so they can be reviewed

How we hand over

Document the flow steps, attributes, bindings and rollback steps so your administrators can repeat the process
Provide a runbook for support staff covering locked-out users, failed resets and users who never signed in
Walk your team through the test results and confirm the production change window with them in advance
Record which settings must be reviewed again after an authentik upgrade, using the release notes for your version

How we support

Agree whether follow-up help is needed as a one-time engagement or through an ongoing retainer
Use a retainer to cover upgrades, periodic checks of the reset flow and changes to user populations
Ask any support provider to confirm response expectations and escalation paths in the written scope
Reassess the flow when a new password policy, MFA method or identity source is added to the deployment

Forcing a password reset at next login in authentik