How reputation policies help stop password spraying in authentik
Picture a team whose login page logs a steady stream of failed sign-ins. Each account sees only a few wrong passwords, spread across hundreds of usernames and arriving from a handful of addresses. This is password spraying: an attacker tries one common password against many accounts so that no single account trips a lockout. This page answers one question: how do you respond to low-reputation clients in authentik before the spray succeeds? The reputation policy is the control built for that signal. According to the authentik policies documentation, it responds to failed logins or suspicious sign-in activity, for example by showing a CAPTCHA to requests whose reputation score is low. Reputation is tracked per client, so it fits spraying better than per-account lockout, which a spray is designed to avoid.
Teams usually need a reputation policy when failed logins come from many accounts and the attacker stays under per-user thresholds. Per-account rules, such as password rules or account lockout, protect a single user well but do little against a slow, wide spray. Geography and network allowlists are also useful, yet they cannot separate a legitimate user on a home connection from a hostile client in the same country. A reputation policy adds a challenge that cost-sensitive attackers find expensive to pass at scale. Before you attach one, confirm in your authentik version how reputation scores are recorded and decayed, and whether your login flow is the one the policy is bound to. The authentik hardening guide, linked from this page, also recommends notifications for login_failed and suspicious_request events so the team sees the spray as it happens.
Choosing a response: CAPTCHA, deny binding or notification
A reputation policy checks the reputation of the client making the request, which builds up from failed logins and other suspicious activity. When the score is low, the flow can present a CAPTCHA before it continues. Legitimate users with a clean history never see the challenge, so this response adds friction only where the signals suggest a problem. It fits sign-in flows that serve a large, mostly trusted population, where a password sprayer should be slowed down without blocking ordinary people. The trade-off is that a user on a shared address who has been caught up in someone else's failed attempts may still be challenged, and a bot that solves CAPTCHAs will get through.
- Best fit: public or partner-facing login flows with many users who sign in from varied networks.
- User experience: most users see nothing; affected users see one extra step that they can usually complete.
- Limit: a CAPTCHA raises the cost for automated attacks but does not stop a determined actor.
- Dependency: the CAPTCHA provider must be reachable from your network, which matters in restricted or air-gapped environments.
- Tuning point: the score threshold decides how many clients get challenged, so test it against real traffic.
Before you choose this response, confirm which CAPTCHA provider your deployment will use and how the reputation threshold behaves on your authentik version.
A deny binding attaches a policy to a flow or stage so that a request is refused when the policy evaluates to a match. The hardening guide describes a negated form, where the reputation check is inverted so that clients with a low score are rejected outright. This response is the strictest of the options. It suits applications where no legitimate user should be signing in from a client with a poor record, such as administrative consoles. The cost is that a false positive becomes a hard lockout, and the user cannot finish the flow even after proving who they are, so the threshold and the affected population need careful review.
- Best fit: administrative interfaces and sensitive applications with a small, known user base.
- User experience: blocked users get a refusal, not a challenge, so support requests rise if the threshold is too aggressive.
- Shared addresses: a corporate NAT or a carrier-grade address can inherit a low score from others, so deny bindings need the most tuning.
- Recovery: plan how an administrator clears a score or unblocks a legitimate user before you go live.
- Testing: apply the binding first to a test brand or flow to observe its effect.
Confirm the exact binding behavior and policy order on your authentik version in the policy documentation before applying a deny to production flows.
The hardening guide lists an optional unconditional CAPTCHA, which presents the challenge to every request on a flow rather than only to low-reputation clients. This removes the dependence on reputation scoring and is simple to reason about, because the same step applies to everyone. It is a reasonable choice for an enrollment or recovery flow that attackers abuse heavily, or for a login page that is exposed to the internet with a small number of users. The trade-off is constant friction. Every user pays the cost of the challenge on every attempt, and accessibility concerns become a broader issue because more people encounter the challenge.
- Best fit: enrollment, invitation or recovery flows where abuse is high and volume is low.
- User experience: every user completes the challenge, which can slow sign-in and frustrate users with assistive technology needs.
- Accessibility: check that the chosen CAPTCHA method works with your accessibility requirements before rollout.
- Coverage: it protects against spraying that a reputation score might miss, such as attempts from fresh addresses.
- Scope: apply it to the specific flow, not to every login, to keep the friction contained.
Ask your authentik team which flows the CAPTCHA stage will wrap, and confirm how the challenge behaves for users on your identity provider's supported clients.
Notifications do not block anything. The hardening guide recommends notifications for the login_failed and suspicious_request events, so that your team learns about spraying activity while it happens. This response is the least disruptive for users, and it gives security staff the visibility they need to act. Its value depends entirely on someone reading and responding to the alerts. Without an owner, notifications become noise, and a spraying campaign can run for a long time before anyone notices. Notifications work well alongside a CAPTCHA or deny binding, because they tell you whether the other controls are firing and where to adjust the threshold.
- Best fit: every deployment as a baseline, paired with one of the blocking responses.
- User experience: users see no change at all.
- Routing: decide who receives alerts and whether they go to a ticketing queue, chat channel or security information tool.
- Volume: a password sprayer can generate many events, so group or throttle alerts to avoid fatigue.
- Evidence: retained notifications support investigations and can help show that monitoring operated as designed.
Confirm which notification transports your authentik version supports and how they reach your monitoring stack, because that determines who sees each event and how quickly.
In practice, the four options are not mutually exclusive, and most deployments combine them. A typical pattern is to send notifications for every relevant event, challenge low-reputation clients with a CAPTCHA on general login flows, and reserve deny bindings for sensitive applications. Unconditional CAPTCHA fits narrow enrollment or recovery flows rather than the main login. The right combination depends on your user population, how often shared addresses appear in your traffic, and how quickly your team can respond to a lockout. Start with the least disruptive layer and tighten only where testing and monitoring show a clear need.
- Layering: notifications first, then a reputation CAPTCHA, then deny bindings for the highest-risk applications.
- Shared networks: if many users share one address, avoid deny bindings on general login flows.
- Staged rollout: test each control on a non-production flow or a limited population before widening it.
- Ownership: assign a person to review alerts and handle lockout requests.
- Review cycle: revisit thresholds after traffic patterns change or after a new application joins.
Before finalizing the mix, ask your implementation partner or internal team to document each flow, its chosen responses, and the process for clearing a block.
Reputation policy configuration options and when each fits
This table compares the main choices for a reputation policy against password spraying: the threshold, where the policy is bound, the response (CAPTCHA, deny or notification) and tuning for shared IP addresses. Read each row against the situation it suits, then confirm the exact setting names and defaults in your authentik version before you rely on them.
| Option | What it does | When it fits | Check before you rely on it |
|---|---|---|---|
| Reputation threshold | Sets the score below which a client is treated as suspicious, so the response triggers | Lower thresholds suit tenants with few shared networks; higher thresholds suit offices or carriers behind NAT | Confirm the scoring behavior and the default value in your version's policy documentation |
| Binding to a login flow | Evaluates the reputation policy during sign-in, before the password or MFA stage | Protecting the password step against spraying across many accounts from one source | Confirm the binding order so the policy runs before the password stage |
| Binding to an enrollment flow | Evaluates the policy when a new account is being created or invited | Stopping automated sign-ups or invitation abuse on public-facing enrollment | Only bind where enrollment is open; invitation-only flows may not need it |
| Negated deny binding | Denies access when the client's reputation is not low enough to pass, so the threshold acts as a gate | Strict environments where a suspicious client should get no challenge at all | Test with a known-good client first; a wrong threshold denies legitimate users |
| CAPTCHA stage for low reputation | Shows a CAPTCHA only to clients whose reputation is below the threshold | Balanced setups that want users with a clean history to sign in without extra steps | Confirm the CAPTCHA stage order and the provider available in your version |
| Unconditional CAPTCHA | Shows a CAPTCHA to every login attempt on the bound flow | Active campaigns or public portals where attacker traffic is hard to separate from users | Expect more friction for all users, including service-related sign-ins that cannot solve it |
| Notification binding (login_failed, suspicious_request) | Sends an alert to administrators when failures or suspicious requests occur | Any deployment, as the first signal that spraying is happening | Confirm the event names and the notification transport configured in your instance |
| Shared IP tuning | Adjusts thresholds, exemptions or GeoIP conditions for offices, VPN egress and carrier NAT | Organizations where many users share one public address | Test with a group of users on the same egress IP before widening the rule to production |
How to configure reputation policies step by step
This sequence takes a running authentik instance from a version check to a tested reputation policy that challenges or denies clients with poor reputation during login. Each step ends with a check so the team knows the layer works before it relies on it.
Confirm the version and the login flow in use
Start by recording the authentik version the instance runs and the authentication flow that users actually pass through for password login, including any stages already attached to it. Check the version against the security policy so you know whether it receives security fixes, and confirm the version on the releases page before you change anything. Export or screenshot the current flow bindings so you can roll back. The step is done when you can name the version, the flow slug, and the stages in order, and when a test login through that flow succeeds on the unchanged configuration.
Create the reputation policy
In the admin interface, open the policy section and create a reputation policy. Set a name that says what it does, such as the flow it protects, and set the threshold that decides when the policy matches. Keep the first version narrow so you can see which clients it affects. Do not add a deny action yet. The step is done when the policy appears in the policy list with its settings saved and no errors shown, and when the policy's reputation configuration matches what you wrote down in the design notes.
Bind the policy to the login flow
Attach the policy to the password or identification stage of the login flow as a policy binding, not to the whole application. Set the binding order and the failure behavior so that matching clients reach the next decision point you add in the following step. Leave the binding disabled for the moment if your change process requires a review before activation. The step is done when the flow editor shows the binding in the expected position and a login from a clean test client still completes without a challenge.
Add the CAPTCHA or deny path
Decide how low-reputation requests are handled. The documented options are a CAPTCHA stage for matching clients, or a negated deny binding that blocks them. Many teams start with the CAPTCHA path because it lets real users with a shared address continue. If you use CAPTCHA, attach a CAPTCHA stage that you have already configured and verified. Confirm the CAPTCHA provider and its keys with your own team, since provider setup is covered separately. The step is done when a low-reputation test client is shown the challenge or denied as designed, and a clean client is unaffected.
Add notifications for login failures
Create notification rules for the events the hardening guidance points to: login_failed and suspicious_request. Route them to a transport your security team monitors, and restrict the rule to the affected flow or severity so the channel is not flooded with noise from unrelated events. Confirm the recipient list with the people who will act on alerts. The step is done when a deliberately failed test login produces a notification in the configured channel and the message contains the event type and the client details your responders need.
Test with controlled failed logins
Use a test account and a test client that you control to generate failed logins from one address until the reputation score drops. Confirm that the policy triggers at the expected count, that the CAPTCHA or deny path behaves as designed, and that a successful login from a different clean client still works. Check the authentik event log for the matching entries and confirm the notification arrived. Record the results, including any client that was affected unexpectedly. The step is done when the expected behavior is documented for each case and no legitimate test user was blocked.
Review shared address impact before enforcing
Before you switch the deny path to enforcement or extend the policy to more flows, review the logs for clients that share an address, such as offices, VPN exits or carrier-grade NAT. Ask your identity and network teams which address ranges are shared and decide whether those clients should receive a CAPTCHA instead of a deny. Tune the threshold or add exceptions only where the evidence supports it. The step is done when you have a written list of shared ranges, the chosen handling for each, and a rollback path that another administrator can execute.
Security and operational risks of reputation policies
A reputation policy is only as good as the signals behind it and the operations around it. The cards below cover the ways attackers adapt, the ways legitimate users get caught, and the platform and alerting checks that keep the control working over time.
Attackers rotating source addresses
Password spraying campaigns often distribute attempts across many IP addresses, so each address accumulates only a few failures. A reputation score built on per-address history can stay low for longer than the attack lasts. Review whether your scoring window and thresholds would catch a slow, distributed spray, and pair reputation with account-level signals such as failures against many different usernames from one source. Test this with a controlled spray from several addresses in a staging environment.
Shared addresses blocking legitimate users
Corporate NAT gateways, branch offices, mobile carriers and VPN egress points can place many honest users behind one address. A single user's typos can then lower the reputation of everyone behind it. Before enforcing a deny binding, list the known shared egress addresses in your environment, and decide whether those sources get a CAPTCHA challenge rather than a block. Confirm with your network team which addresses are shared.
CAPTCHA bypass and tampering
A CAPTCHA stage only helps if the flow cannot skip it. Check that the reputation policy binding sits on the stages that matter, that no alternate flow or direct API path reaches authentication without the challenge, and that only administrators with the right permissions can edit the stage or its provider settings. Also confirm how your chosen CAPTCHA provider verifies responses on the server side.
Notification fatigue
The hardening guide recommends notifications for login_failed and suspicious_request events. If every event produces an alert, administrators will stop reading them, and a real spray will look like routine noise. Decide which events go to a person, which go to a log store for review, and how often a threshold should page someone. Revisit alert volume after the first few weeks of production traffic.
Running an unsupported version
Reputation logic, flow stages and security fixes change between releases, and an unpatched authentik can carry known weaknesses. The security policy lists 2026.5.x and 2026.8.x as the supported versions receiving security fixes, and the project announces security releases at least 24 hours in advance. Confirm which release line you run, subscribe to release notices, and plan a window to apply security releases on that schedule.
Lockouts without a recovery path
A deny binding that catches a shared address or a misconfigured policy can block administrators as well as attackers. Keep at least one break-glass administrative route that does not depend on the policy under test, and document how to remove or disable a binding from the database or the admin interface. Rehearse this recovery before enforcing deny rules in production, not during an incident.
Limits to confirm in your environment before relying on reputation
How does the authentik reputation score change after failed logins in my version?
The exact scoring behavior depends on the authentik version you install, so confirm it against the documentation for that release before you set thresholds. The policies documentation describes the reputation policy as responding to failed logins and suspicious sign-in activity, but it does not give you a reason to assume a specific score change per event. Test the behavior in a non-production instance by triggering failed logins from a known address and recording when the policy starts to match. Keep that record with your change documentation so that a later upgrade can be compared against it.
Can an authentik reputation policy match on attributes other than the client IP?
Confirm this in your installed version before you design around it. Reputation is commonly associated with the client address, and most of the planning in this topic assumes that key. If you need to react to a specific username pattern, device, or user group, check the policy and expression options in the policies documentation and decide whether a separate rule is needed. Do not assume that a reputation rule can see user attributes unless you have tested it in your environment.
Will reputation work correctly behind a reverse proxy that passes client IPs?
It depends on whether authentik sees the real client address. If a reverse proxy or load balancer in front of authentik does not pass the original client IP in a header that authentik trusts, every login may appear to come from the proxy, and one attacker can affect everyone. Verify the forwarded-address settings in your reverse proxy and authentik configuration, then run failed logins from two different source addresses and confirm that the scores are tracked separately. Also confirm that untrusted clients cannot spoof the forwarded header, because a spoofed address would let an attacker avoid the policy.
Which CAPTCHA provider should we choose for a low-reputation challenge?
The provider choice depends on your data residency rules, whether you can accept an external service call during login, and whether you need a self-hosted option. The authentik CAPTCHA stage documentation covers the supported providers, and the self-hostable Cap provider was added in 2026.8, so confirm that your version includes it before planning around it. Check how each provider handles user data, its availability, and how it behaves for users with assistive technology. Test the chosen provider end to end, including the failure path when the verification service is unreachable.
How do GeoIP rules and reputation policies interact in one flow?
They are separate controls, and their order and bindings decide what a user experiences. A GeoIP restriction may deny a login before reputation is evaluated, or the reverse, depending on how the policies are bound to the stages in your flow. Map the order of every policy in the flow, then test one login from an allowed country with a poor reputation and one from a blocked country with a clean record. Also confirm what happens if the GeoIP database is missing or outdated, because that affects the country signal that your rules depend on.
Do password rules change how reputation policies behave during a spray?
Password rules and reputation controls address different failures. Password complexity and breach checks reduce the chance that a guessed or leaked password works, while reputation slows repeated attempts from one source. Neither replaces the other. Confirm in your environment whether a rejected password attempt counts as a failed login for reputation purposes, because that determines how quickly the policy reacts. Test it with a deliberate series of wrong passwords and record the outcome.
How much effort will tuning take to avoid locking out shared IP addresses?
The effort depends on how many users sit behind shared addresses, such as corporate NAT, carrier gateways, or a branch office, and on how many applications authentik protects. The main work is measuring legitimate failure rates for each network segment, choosing thresholds, and testing with real user patterns in a pilot group. Ask any implementation partner for a written scope that includes the test plan, the lockout recovery procedure, and who approves threshold changes. Recurring effort continues after go-live as your traffic changes.
Which authentik release should we validate against before going to production?
Validate against the release line your organization will run, and check that it is in the supported set listed in the security policy. The security policy lists 2026.5.x and 2026.8.x as the supported versions receiving security fixes, and the project announces security releases at least 24 hours in advance. Because the latest release shown on GitHub is 2026.8.4, confirm the version you plan to deploy and read its release notes for any changes to policies, stages or the CAPTCHA provider list before you rely on those behaviors.
How DeployOpen scopes and tunes authentik reputation controls
DeployOpen plans reputation policies against password spraying as part of the wider login flow, not as a standalone rule. We scope the failed-login and suspicious-request responses, build them in your own authentik deployment, and hand over documented settings your team can tune.
How we scope
- Inventory the login flows, providers and user populations that reputation policies will protect before any rule is written.
- Agree in writing which events trigger CAPTCHA, deny bindings or notifications, and which shared IP ranges must be exempted.
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts. Ongoing tuning is available as a retainer.
How we build
- Configure reputation policies, CAPTCHA stages and deny bindings in a staging instance, following the hardening guidance for login_failed and suspicious_request events.
- Test each path with failed-login sequences from representative clients, including shared NAT addresses, to confirm lockouts stay contained.
- Review GeoIP and notification settings alongside reputation rules so that overlapping controls do not block legitimate users twice.
How we hand over
- Document each reputation threshold, binding and exemption with its purpose, owner and the change process that governs it.
- Provide a runbook for responding to alerts, reviewing reputation scores and clearing a wrongly blocked address.
- Walk your security and identity operations staff through the configuration so they can adjust settings without relying on us.
How we support
- Confirm the authentik version in use and plan upgrades against the supported release list before changing policy configuration.
- Review login failure notifications and reputation trends with your team on the schedule agreed in the retainer or handover.
- Re-test controls after authentik upgrades, new providers or changes to your reverse proxy or IP addressing.
