Password complexity in authentik: what the built-in policy covers
When an auditor asks how passwords are controlled in your self-managed single sign-on, the answer should name the specific checks authentik runs and where each one is configured. authentik's password policy validates complexity, checks whether a password appears in Have I Been Pwned exposure data, or scores it for strength with zxcvbn. You can combine these checks in one policy and bind it to the flows where users set or change passwords, such as enrollment, recovery and password change. Teams need this written down before an assessment, because a policy that exists only as a default is hard to evidence.
Expiry is handled differently from strength checks. According to the authentik policies documentation, password expiry can either deny the login or mark the password as unusable, which pushes the user into a change flow. Decide which behavior fits your user population before you enable it, because a denied login has different support and lockout consequences than a forced change. Password history, which prevents reuse of earlier passwords, is an Enterprise-only feature, so an open source deployment that must show reuse prevention needs either the Enterprise edition or a compensating control that you document and test.
The built-in policy is one part of the authentication design, not the whole of it. Strength rules matter less when MFA, reputation policies and sensible lockout behavior already limit guessing, and the policy does not replace a documented decision on who may change passwords and how. Confirm the current option names and defaults in your installed version, and test the policy against a staging instance before it reaches users. The hardening guide's recommendations for length and breach checks are a useful reference point for that review.
Which password control fits which requirement
This table compares the password controls available in authentik, from complexity rules to breach checks, expiry, history and an offline local list. Read each row for what the control enforces, when it fits an audit requirement, and where it tends to cause lockouts or depend on outside network access.
| Control | What it enforces | When it fits | Trade-off to plan for |
|---|---|---|---|
| Complexity and length rules | Character classes and minimum length checked when a password is set | Written policies that name a minimum length and character mix | Rules alone do not stop common or leaked passwords, so pair them with a breach or strength check |
| Have I Been Pwned check | Rejects passwords found in known breach exposure data | Hardening baselines that ask for breach screening of new passwords | Requires the instance to reach the external breach service; confirm egress rules before enabling |
| zxcvbn strength score | Scores password guessability and rejects weak choices | Programs that want a strength measure beyond character classes | Scores are estimates, so set a threshold your users can meet and test it with real enrollment flows |
| Password expiry | Denies login or marks the password unusable after a set age | Standards or internal rules that require periodic change | Expiry can lock out users, service accounts and LDAP binds; plan the reset path and notices first |
| Password history (Enterprise) | Prevents reuse of recent passwords through uniqueness checks | Audit requirements that ask for reuse prevention | Enterprise feature only, listed on the authentik pricing page; confirm license terms with your team before relying on it |
| Local-list expression policy | Checks candidate passwords against a file or list you host inside the network | Air-gapped instances that cannot reach an external breach service | You maintain the list and its update process, and the check is only as current as your copy |
Breach checks on connected and air-gapped instances
A connected instance can use the Have I Been Pwned check in the authentik password policy. The check tests a candidate password against known breach data, so a password that already appears in public breach collections can be refused when a user sets or changes it. The hardening guide recommends a minimum length of 15 when this check is active, so the length rule and the breach check should be configured together.
- Outbound access: The check runs on the server, so the authentik server and worker containers need a path to the external service over HTTPS. Confirm the destination and whether traffic must pass through your proxy.
- Data sent: Confirm in the policy documentation what leaves your network during a check. Your privacy and legal reviewers will ask this first.
- Failure behavior: Confirm whether the policy blocks password changes or allows them when the external service is slow or unavailable. This decides what users experience during an outage.
- Minimum length: Set the length rule to 15, as the hardening guide recommends, and keep complexity and zxcvbn strength checks enabled alongside it.
- Evidence: Record the policy, the stage it is bound to, and a test password change that the check rejects, so an assessor can see the control working.
Before go-live, test the outbound path from the server containers, since the check runs there and your browser test will not prove it.
An air-gapped instance cannot call the external breach service, so the hardening guide points to a local-list expression policy instead. The policy compares a candidate password against a list held inside your network and rejects matches. Because the logic is an expression in authentik, the policy, the list and its handling become part of your own control set, and they need the same change control as other security configuration.
- No external calls: The list is evaluated inside authentik, so password changes do not generate outbound requests.
- List source: Choose a breach corpus that your organization is permitted to hold and use, obtained through a route your security team approves. Record its origin and date.
- Loading method: Confirm in the policy documentation how the list is supplied to the expression, such as a file the server can read, and test the memory and response time with a list of your actual size.
- Layered rules: Keep the minimum length of 15, complexity and zxcvbn checks in place, so the local list is one layer among several.
- Test set: Verify the policy on a non-production instance with known listed and unlisted test values before it is bound to production flows.
Before writing the expression, confirm the syntax, the available context and the error handling in the policy documentation for the authentik version you run.
A local list is only as current as its upkeep. Without an owner, a source record and a refresh routine, the policy will drift from the threat picture it was meant to cover. The maintenance process should be written down and reviewed like any other control, so an assessor can trace what was in force on a given date.
- Named owner: Assign one accountable role for the list, with a deputy, and record who approves each change.
- Provenance record: Keep the source, retrieval date, format and any transformation steps, so the list can be reproduced.
- Refresh cadence: Set a review interval that your risk owners approve. The right interval depends on your threat model and your change capacity, so agree it in writing rather than copying another organization's schedule.
- Integrity checks: Store a checksum for each version and keep a change log of additions and removals. This shows that the file in use matches the approved file.
- Staged rollout: Deploy each new list version to a test instance first, run the verification set, then promote it to production.
Ask your team to document who can edit the expression and the list file, since a tampered list weakens the control without any visible error.
Both approaches depend on details that can change between releases, and the authentik documentation is the authority on them. Before you commit to a design, confirm the points below against the version you plan to run. Supported versions and security fixes are listed in the authentik security policy, which helps you decide which release line to target.
- Check mechanics: Confirm the exact service the Have I Been Pwned check calls, what it sends, and how it handles timeouts.
- Failure mode: Confirm whether each policy fails open or closed, and whether an administrator can change that behavior.
- Expression context: Confirm which objects the local-list expression can read, how it reports a match, and whether it runs on both set and change operations.
- Scope of application: Confirm which flows and stages the password policy applies to, including recovery and forced reset flows.
- Version drift: Check the release notes for password policy changes after each upgrade, and retest both controls after every update.
Record the answers in your control documentation with the version number, so the evidence matches the configuration an auditor sees.
How to configure a password policy in authentik
This sequence builds a password policy that an auditor can trace from each rule to the flow stage that enforces it, then proves the rules with rejected weak passwords and one successful change. It ends with an expiry setting chosen on purpose and test results from an ordinary user account.
Confirm the authentik version and edition
The administrator checks the running version against the supported releases in the authentik security policy, which lists 2026.5.x and 2026.8.x as receiving security fixes, and confirms the edition in use. Password history is an Enterprise feature, so a team that needs it must hold an Enterprise subscription before building that part. Record the version and edition in the change ticket. Done when the admin interface shows a supported version and the edition matches every control you plan to claim.
Create the password policy with length and complexity
In the admin interface, open the policies area and create a password policy, then set the minimum length and the character rules your standard requires. The authentik hardening guide recommends a minimum length of 15 when the Have I Been Pwned check is active, so use that as the baseline unless your standard sets a higher value. Confirm the final values with your compliance lead before saving. Done when the policy appears in the list and its saved values match the figures you approved.
Add the breach or zxcvbn check
Enable the Have I Been Pwned check, the zxcvbn strength check, or both on the same policy, depending on what your standard asks for. Connected instances can query the external Have I Been Pwned service, but air-gapped instances cannot, so they need a local-list expression policy that screens against a list you maintain. Document which method you chose and why, because the two methods prove different things. Done when a password found in a known breach list or scored as weak is refused in a test change.
Bind the policy to password change and recovery stages
Attach the policy to the password stage used by the change flow and to the stage that handles recovery, so the same rules apply whether a user changes a password or resets one. Check every stage in both flows, because a flow without the binding accepts passwords the policy would otherwise refuse. Export or screenshot the bindings from the flow editor as evidence. Done when the password change flow and the recovery flow each show the policy in their bindings.
Configure password expiry if your standard requires it
Decide with your security lead whether a periodic change requirement applies, since it changes user behavior and support volume. If it applies, set the expiry period on the policy and choose whether an expired password denies login or is marked unusable, because each option produces a different user experience. Confirm the behavior with a test account before it reaches all users. Done when an expired test account shows the behavior you chose and the documented expiry setting matches your decision.
Test with a non-privileged account
Sign in as an ordinary user rather than an administrator so the test reflects what most people experience. Attempt a password that is too short, one that appears in a breach list, and one that scores as weak under zxcvbn, then complete one compliant change. Review the event or audit log for the three rejections and the successful change before closing the ticket. Done when the log records each rejected attempt and the successful change, and the results are attached to the change record.
Security risks in password rules and how to limit them
Password rules can strengthen sign-in or quietly weaken it, lock people out, or send data somewhere it should not go. The cards below cover the four risks that come up most often when teams configure authentik password policies, and the controls that limit each one.
Frequent rotation weakens passwords
Forced expiry on a short cycle often pushes users toward small, predictable changes, such as incrementing a number at the end of a password. Before enabling expiry, decide whether the rule is required by your control framework or by a specific incident. Where expiry is kept, pair it with a length minimum and a breach check so that a rotated password is still hard to guess. Ask your auditor which rotation interval, if any, they expect to see as evidence.
Expiry locks out service and external users
Password expiry can deny login or mark a password unusable, which is useful for employees but damaging for service accounts, integration users and external partners who may not see a reminder in time. Identify every account that authenticates non-interactively or through an LDAP bind before applying expiry to a group. Test a forced expiry against a non-production user first, and confirm which accounts your planned rule will actually reach.
Breach checks send data outside
A Have I Been Pwned check depends on an external lookup, so the password-derived data leaves your network on every check unless you design the flow around it. Confirm with your privacy and security teams whether that outbound request is acceptable for your environment, and check the network path from authentik to the external service. On air-gapped instances, replace the external check with a local-list expression policy that your team maintains and can audit.
Non-admins editing policy bindings
A password policy is only as strong as the binding that applies it, and a user who can edit bindings, expressions or the flow that references them can switch the rule off. Limit policy and flow editing to a small administrator group, review that group's membership on a schedule, and keep a record of changes to bindings. Confirm how your authentik version handles role and permission scoping before you grant anyone delegated access.
Weak rules without a history check
Without password uniqueness, users can cycle between two or three passwords whenever a rule requires a change, which defeats the purpose of expiry. Password history is an Enterprise feature in authentik, so confirm whether your edition includes it before writing a policy that depends on it. If it is not available, document the gap and add a compensating control, such as breach checks on every password change.
Why expiry and history need a deliberate decision
Password expiry and password history are two separate controls, and the authentik documentation treats them differently. The password policy can enforce expiry, and the documented effect is that an expired password either denies login or is marked unusable, so the user must take a further step before signing in. Password uniqueness (history) is an Enterprise feature, which the authentik pricing page lists among its Enterprise-only features. If your auditor expects reuse prevention, that requirement shapes your edition decision before any flow is built, and the Open Source edition should not be assumed to cover it.
Expiry needs a decision for each population it touches. For employees, a denied login can read as a lockout and generate help desk tickets, so you need to decide whether an expired password routes to a self-service change, an administrator-assisted reset, or a forced reset flow. Service accounts and integration bindings that authenticate with a password are a separate case: expiry that blocks a non-interactive account can stop a pipeline or directory sync without warning. Confirm which accounts are exempt, how they are documented, and who owns their rotation. Test the recovery path end to end, since an expired account that cannot reach the recovery flow is a support incident, not a policy outcome.
Map every rule to the control your auditor cites before you configure it. A length minimum, an expiry interval and a history count each answer a different question, and a rule that does not match a cited control is hard to defend. Then confirm the current behavior in your own version, because expiry handling and policy evaluation can change between releases; check the authentik policies documentation and your version's release notes before you write the control narrative. Record the result of a test login for each expiry outcome so the evidence reflects what your deployment actually does.
Limits to confirm before you rely on password rules
Password rules in authentik depend on the release you run, the network your instance sits in, the license you hold and the identity sources feeding it. Each card below is a check to complete in your own environment before you describe these rules to an auditor as settled.
Installed release against supported versions
Compare the authentik version you run with the versions the security policy lists as receiving security fixes. A release outside that list may miss fixes that affect login and policy evaluation. Security releases are announced at least 24 hours in advance, so confirm who on your team watches the announcements and how quickly you can schedule an upgrade. Check the latest published release against your pinned version before you document the rule set.
Breach check reachability
The Have I Been Pwned check needs outbound network access from the authentik server to the breach lookup service. Test that path from the actual container network, including any egress proxy, DNS restrictions and firewall rules, rather than assuming it works. If the lookup fails or times out, decide in advance whether logins and password changes fail closed or proceed, and record that decision. Ask your security team to confirm the behavior during a planned outage test.
Local list currency on air-gapped instances
On networks with no internet access, the hardening guide suggests a local-list expression policy in place of the breach check. The list is only as good as its last update, so define who sources the list, how it is imported into your environment, how often it is refreshed and how a refresh is reviewed. Record the source and date of each import so an auditor can trace the blocked passwords back to a dated source.
History under your license
Password history, which stops users reusing recent passwords, is an Enterprise feature. Confirm with your license terms and the pricing page whether your subscription includes it before you write a history requirement into your standard. The open-source edition does not provide it, so a history control on that edition needs a documented compensating measure or a decision to upgrade. Code under the enterprise directory carries its own license, so check that terms as well.
Interaction with MFA and external sources
Password rules apply only where authentik itself checks the password. Users who sign in through an upstream identity provider, or through a directory that authenticates on its side, follow that system's password policy instead. Map each login path, including LDAP and RADIUS clients, to the place where the password is checked. Confirm that MFA stages run in the order you intend, so a weak password is not the only barrier to an account that has no second factor.
Expiry behavior on each path
Expiry can deny login or mark a password unusable, and the result differs by flow and by client protocol. Test expiry with a sample account on each login path you operate, and confirm what a user sees and how an administrator restores access. Coordinate the expiry setting with your recovery and forced reset flows so users are not locked out in a loop. Document the behavior you tested, not the behavior you expect.
Questions teams ask before setting password rules in authentik
What does password policy work cost, and who pays for what?
Most of the cost is labor: someone designs the rules, builds the policy bindings, tests them against real login flows, and documents the result. Password history (uniqueness) is an Enterprise feature, so if you need it, you pay for an authentik Enterprise license in addition to the work. The pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month, and the Open Source edition does not include password history. Licensing recurs; design and testing are usually one-time, with changes billed as they come up. Ask for a written quote that separates internal or partner labor, license cost, and any recurring support, and confirm the license terms with authentik before you commit.
How long does setting up password rules take?
Duration depends on how many applications share the policy, how many password paths exist (enrollment, change, recovery, admin reset), and whether you need breach checks on a network that cannot reach external services. A single policy bound to one flow is a small change; separate rules for several user populations, plus testing across every flow, takes longer. Expect the test plan to take as much effort as the configuration. Ask for a timeline in the written scope, with the number of flows and policies named explicitly, so you can see what drives it.
What must our team provide before the work starts?
You will need to provide three things. First, named identity owners who can approve the password standard and the user populations it applies to. Second, a test plan with accounts for each group, flow and client type, including LDAP and RADIUS clients if they authenticate against authentik. Third, network rules for breach checks: the Have I Been Pwned check calls an external service, so confirm whether your egress rules allow it. If they do not, the offline alternative is a local-list expression policy, which your team must maintain. Confirm these items in the scope before work begins.
Can our internal team set password rules without a partner?
Yes, if you have someone who knows authentik policies and flows, can test changes safely in a non-production instance, and owns the documentation that auditors will ask for. Built-in policies cover length, complexity, zxcvbn strength, Have I Been Pwned exposure and expiry. Teams usually struggle with the parts that are easy to get wrong: binding policies to the correct stage, avoiding lockouts for service accounts, and proving that every password path enforces the same rules. A partner can take that verification work under a fixed scope, but the decision about the standard stays with your organization.
What makes the effort go up?
Effort rises with the number of password entry points, the number of distinct rule sets, and the systems that consume authentik logins. Air-gapped networks add work because the breach check must be replaced with a maintained local list. Enterprise features such as password history add licensing and test cases. Existing user directories with synchronized passwords, LDAP clients that cannot follow a new rule, and a need to show evidence of enforcement for an assessment all increase the work. Reducing the number of rule sets and documenting the standard before configuration usually shortens the project.
What should we check before we rely on expiry rules?
Check how expiry behaves in your flows. The authentik policies documentation states that expiry can either deny login or mark the password unusable, so the outcome for users differs and must be chosen deliberately. Test each outcome with a sample account, confirm the message users see, and confirm that service accounts and LDAP or RADIUS clients are not locked out. Review the hardening guide's recommended minimum length of 15 with the breach check, and confirm current guidance with your own compliance team before you set expiry periods.
Which version should we target for password rules?
Target a version that receives security fixes. The authentik security policy lists 2026.5.x and 2026.8.x as supported lines, and the project announces security releases at least 24 hours in advance. The GitHub releases page shows 2026.8.4 published on October 14, 2026 as the latest release. Confirm the version you deploy against the release notes and the security policy on the day you configure rules, because policy behavior can change between releases.
Rolling out password rules without locking out users
Password rules that look correct on paper can still strand users at the login screen, so roll them out in stages rather than switching everything on at once. Start on a non-production authentik instance that mirrors your production flows, policies and password stage. Apply the length, complexity, Have I Been Pwned or zxcvbn settings, then sign in as test users with a range of existing passwords to see which ones are refused, which ones trigger a change, and what the error message tells the user. Confirm that the same policy binding is attached to the password change flow and any recovery flow, because a rule enforced in one path but not another is a common source of confusion. If you plan to use a local-list expression policy on an air-gapped instance, test that list in the same way before it reaches production.
Next, pilot the change with a small, willing group, such as an IT team or a single business unit, and keep it there long enough to cover a normal password change cycle. Before the wider rollout, write the new rules in plain language, state the date they take effect, and explain what happens to existing passwords. If you configure password expiry, the documented behavior is that it can deny login or mark the password unusable, so users must know whether they will be blocked at sign-in or prompted to change their password first. Ask your authentik administrators to confirm which behavior your version applies, and publish that answer alongside the rules. Your help desk should have the script and the escalation path ready before the first user is affected.
During the rollout, watch the event log for failed password changes and rejected logins, grouping them by policy and by flow so you can see which rule is causing friction. Keep an administrator recovery path that does not depend on the policy you are changing, such as a break-glass account held under separate controls, and test it before go-live. Any user locked out by an expiry or reset should have a documented path back, which connects to the work in the forced password reset at next login guidance and the self-service password recovery design. Treat those pages as the next read, and only widen the rollout once the failure rate in the pilot is understood and explained.
