How authentik slows guessing attacks on MFA codes
A one-time code is only as strong as the number of guesses an attacker can make against it. In authentik, the control that limits those guesses sits in the authenticator validation stage, which throttles repeated failed attempts. Starting with authentik 2026.5, that throttling applies to email and SMS OTP devices as well as the protection that already covered TOTP and static authenticators. If your users sign in with emailed or texted codes, this release changes how quickly an attacker can work through a code space, so confirm that you are running 2026.5 or later before you rely on it.
The practical question is whether the default protection for your authenticator types is enough for your risk. TOTP and static codes were already throttled, so a deployment that relies mainly on authenticator apps and recovery codes had less to change. A deployment that accepts email or SMS codes as a fallback for a large user population, or that exposes the login flow to the internet without other limits, should treat the new email and SMS throttling as one layer rather than a complete answer. Ask your team to read the 2026.5 release notes against the exact stage configuration in your flows, and test a failed-attempt sequence in a staging instance to see the lockout behavior your users would experience.
Throttling slows a guesser but does not tell you that a guess is happening. The hardening guide recommends reputation policies that respond with a CAPTCHA challenge or a deny binding, and notifications for login_failed and suspicious_request events. Pair the stage settings with those policies and alerts so that repeated failures from one source are both slowed and visible to the team that operates the system. Plan who receives the notifications, how quickly they are reviewed, and how a user locked out by throttling is verified before the lockout is cleared. The authentik hardening guide sets out the policy and notification options to check against your own setup.
Which authenticators have attempt throttling
authentik's attempt throttling does not apply the same way to every second factor. TOTP and static codes have had protection for some time, and email and SMS one-time codes gained it in 2026.5, so the method you enroll determines how much guessing protection you inherit. Confirm the details for your version before you depend on them.
TOTP authenticators
TOTP codes are six-digit values that rotate on a short time window, so a guesser has a narrow target at any moment. authentik has throttled repeated failed attempts against TOTP devices for longer than the 2026.5 change. Check how the authenticator validation stage in your version counts failures, how long a lockout lasts and whether it applies per device or per user. Test a deliberate series of wrong codes in staging before you publish the policy to users.
Static recovery codes
Static tokens are the backup codes users keep for when their primary device is lost. Because they are fixed values rather than time-based codes, they are a higher-value target if throttling is weak, and they are often used in recovery moments when a user is already stressed and more likely to retry. Confirm that throttling covers static devices in your version and that an attempt limit does not lock out an administrator who needs to recover the account.
Email one-time codes
Email codes are sent to a mailbox, so their security depends heavily on the mailbox itself. authentik 2026.5 added throttling of repeated failed attempts for email OTP devices, which closes a gap that previously existed for this method. Confirm the thresholds, the lockout duration and whether a locked device blocks the user from requesting a new code. Also review token expiry, since a long-lived code gives a guesser more time even when attempts are limited.
SMS one-time codes
SMS codes are protected by the same validation stage throttling introduced in 2026.5, but the delivery channel adds its own risks, such as SIM swapping and repeated send requests that cost money. Attempt throttling limits guesses against a code, while it does not stop an attacker from triggering many sends. Check whether your gateway or the authentik settings limit resend frequency, and confirm the lockout behavior for SMS devices in your deployed version.
Verify the version before relying on it
Throttling for email and SMS codes is a 2026.5 feature, so a deployment on an earlier release has no such protection for those methods, whatever its configuration says. The project's security policy lists 2026.5.x and 2026.8.x as supported for security fixes, which matters for planning upgrades. Record the exact version in your environment, read the release notes for that version, and test with a non-production account before you assume coverage.
Enabling throttling and reputation controls step by step
This sequence confirms your authentik version supports email and SMS attempt throttling, tightens the authenticator validation stage, adds reputation controls on login, and sends alerts for failed logins, so each layer can be tested before you rely on it.
Confirm the running authentik version
An administrator checks the version shown in the authentik admin interface and compares it with the release notes. Email and SMS attempt throttling in the authenticator validation stage arrived in 2026.5, so the running version must be 2026.5 or later. Check the supported versions in the security policy as well, and confirm your upgrade path if you are behind. The step is done when the version is recorded in your change ticket and matches the target release.
Review the authenticator validation stage for email and SMS
In the admin interface, an administrator opens the authenticator validation stage used by your MFA flow and checks which device classes it validates, including email and SMS devices. Confirm that throttling of repeated failed attempts is enabled for these classes, and note the settings that already apply to TOTP and static authenticators so the three methods are consistent. Save the change in a non-production tenant first if you have one. Verify by signing in with a test user, entering a wrong email code several times, and confirming that the next attempt is refused for a time instead of being checked again immediately.
Test the throttle with a wrong code
Using a test account that has an email or SMS device enrolled, an administrator enters a deliberately wrong one-time code repeatedly and records what the login page shows at each attempt. The expected result is a rejected code followed by a lockout or delay message once the threshold is reached, with no successful sign-in. Repeat with a correct code after the delay ends to confirm legitimate users can still complete MFA. Record the outcome in your test log before moving to the next step.
Add a reputation policy with CAPTCHA or deny binding
An administrator creates a reputation policy under policies and binds it to the login flow or the relevant stage, following the hardening guidance. Choose CAPTCHA for suspicious sources where you want to slow automated attempts without blocking people, or a deny binding where your risk model allows it. Set the threshold and scope with the reputation rules in the hardening guide, and test on a non-production flow first. The step is done when the policy appears in the binding list for the flow and the reviewer has documented which option was chosen and why.
Verify the reputation policy blocks a test source
From a source address that the test plan designates, an administrator runs repeated failed logins against the test account and confirms the chosen control takes effect: a CAPTCHA challenge appears or the binding denies the attempt. Then sign in from a normal address to confirm the policy does not affect ordinary users. Check the reputation list in the admin interface to confirm the source was scored. Keep the test address and the observed behavior in your change record so that a later change can be compared against it.
Configure notifications for login_failed events
An administrator creates a notification transport and an event matcher rule in the admin interface that selects login_failed events, then binds the rule to the destination your security team monitors, such as email or a chat channel supported by the transport. Confirm the destination is reachable before saving. Check that the rule fires for the test failures from the previous steps. The step is done when the test notification arrives and shows the username, source and time in the message.
Configure notifications for suspicious_request events
The same notification approach is repeated for suspicious_request events, using a separate rule or a combined rule that matches both event types, as your monitoring design requires. Trigger a suspicious request in the test environment, such as a request the reputation policy flags, and confirm the notification arrives at the monitored destination. Review the alert volume during test traffic and adjust the matcher if it is too noisy to act on. The step is done when both event types produce a confirmed alert and the alert owner knows the response procedure.
Which protection layer fits which risk
This table compares the built-in throttling on each authenticator type with reputation policies, CAPTCHA and deny bindings, and failed-login notifications. Read each row as a layer: what it fits, what it leaves open, and what your team must configure before it protects anything.
| Protection layer | When it fits | What it does not stop | What the operator must configure |
|---|---|---|---|
| Built-in throttling for TOTP and static codes | Guessing of six-digit codes or static backup codes against a single account over repeated attempts | Attackers who already have the user's password and can reach the MFA prompt from many sources at a slow pace | Confirm the authenticator validation stage is attached to the flows that need it and that your authentik version includes these checks |
| Throttling for email and SMS codes (added in 2026.5) | Repeated guessing of emailed or texted one-time codes on a single device, which the earlier releases did not throttle | Attempts spread across many accounts, and interception of codes sent to the user's own mailbox or phone | Run 2026.5 or later, set the authenticator validation stage on each flow using email or SMS, and test that lockout behavior matches your policy |
| Reputation policy with CAPTCHA | Automated login traffic from suspicious sources where you want a human check before a password or MFA attempt continues | Low-volume, targeted attacks that stay under the challenge threshold, and bots that solve CAPTCHA services | Create reputation policies in the flow, define the score conditions that trigger the CAPTCHA stage, and choose which flows it covers |
| Reputation policy with deny binding | Sources that repeatedly fail logins or show hostile patterns and should be refused outright | Distributed attacks from many addresses, and legitimate users behind shared NAT or VPN addresses who may be blocked | Define the reputation threshold, bind the deny outcome to the right stages, and review the rule for false positives before enforcing |
| Notifications for login_failed and suspicious_request events | Detecting patterns early so administrators can investigate, reset accounts or block sources | Stopping any attempt by itself, since alerts depend on someone reading and acting on them in time | Enable the event notification rules, route them to a monitored channel, and assign an owner for triage and response |
| Failed-login alerts and log forwarding | Feeding failed MFA and login events into your central logging or SIEM for correlation across users | Attacks that stay below your alert threshold, and events that are lost if the log pipeline fails | Forward authentik events to your logging platform, set thresholds per account and per source, and test that alerts fire during a controlled test |
Trade-offs of stricter throttling and deny rules
Aggressive lockouts punish the users who are most likely to be guessing wrong by accident. A throttle that counts failed code attempts per account cannot tell a patient attacker from a user who mistyped a six-digit code three times while switching between phone apps. The same applies to help desk staff who re-enroll a device and then watch a user burn through attempts during a recovery call. Before you lower a threshold, decide what a locked user does next: wait for a timer, call the help desk, or use a recovery method. Confirm in your own environment how long a lockout lasts and who can clear it, because a lockout with no fast, verified recovery path turns a security control into a support queue. Check that your help desk procedure verifies identity through a channel other than the locked factor.
Reputation policies carry a different risk because they act on the network, not the account. Many users share an address through a corporate NAT, a branch office, a carrier-grade NAT on mobile networks, or a VPN concentrator. One noisy device or a misconfigured app behind that address can push legitimate users into a deny binding or a CAPTCHA challenge. Remote workers and users who route through a corporate VPN egress may appear to come from a single shared address, while home users may share addresses with strangers. Review how the reputation score accumulates for each of these sources before you add a deny binding, and treat CAPTCHA as the softer option where the population is mixed. Log the score and the triggering events so you can see who was affected.
Test thresholds against real traffic before you enforce them. Run the new policy bound to a notification or a monitor-only binding for a defined period, then compare the failed-login events with support tickets and recorded lockouts. Segment the results by user group, location, and network path, and ask the identity team and the help desk to flag false positives they see. Plan the rollout in stages, starting with a small pilot group, and keep a documented rollback. Do not decide thresholds from a vendor default or from a single attack simulation, since neither reflects your user population. Ask your DeployOpen or internal team to define the success criteria in writing before the test begins.
Questions teams ask before enabling MFA throttling
Do we need to upgrade to authentik 2026.5 to get email and SMS throttling?
Yes, the throttling for email and SMS one-time codes was added in authentik 2026.5, so earlier versions do not have it. The release notes describe the authenticator validation stage gaining throttling of repeated failed attempts for email and SMS OTP devices, which extends the protection already present for TOTP and static authenticators. Before you upgrade, confirm which version you run today and whether it is still in the supported set listed in the security policy, because authentik supports upgrades in sequence and a jump across several releases needs its own plan. Read the 2026.5 release notes for any breaking changes that touch your flows or stages before scheduling the change.
What does it cost to get MFA throttling configured?
The cost depends on how much work sits around the setting, not on the setting itself. Throttling is a configuration change on the authenticator validation stage, so the main cost components are internal staff time for the change window, testing of login flows, and any upgrade work needed to reach 2026.5. DeployOpen does not publish a price list. A quote follows from a written scope that lists the environments, the flows affected, the authenticator types in use and the testing you expect. Ask any provider to separate one-time work (configuration, testing, documentation) from recurring work (upgrades, monitoring, support), and to state what is excluded.
How long does configuration usually take?
No duration has been established for this work, so confirm it against your own environment rather than a generic figure. The main drivers are the number of authentication flows that use the validation stage, whether you run one authentik instance or several, how many authenticator types you need to cover (email, SMS, TOTP, static codes), and whether an upgrade to 2026.5 comes first. A single flow in a test environment is far quicker to change than a production estate with LDAP and RADIUS clients that also depend on the same stages. Ask for a timeline that lists each stage of work and the test gates between them.
What do we need to provide before the work starts?
Prepare administrator access to the authentik instance with rights to edit flows, stages and policies, plus access to the logs that will show throttling events. For email codes, have your SMTP settings and a test mailbox ready. For SMS codes, collect the provider details for Twilio or your HTTP SMS gateway, including the sender configuration and any approved test numbers. Also name the destinations for logs and alerts, such as your SIEM or log platform, and the people who receive failed-login notifications. Finally, provide a change window, a rollback plan and a list of users or service accounts that rely on code-based MFA so testing covers them.
Can our own team enable MFA throttling without a partner?
Yes, if your team already administers authentik and has tested changes to flows and stages. The throttling setting is part of the authenticator validation stage, so an experienced administrator can make the change in a test instance first. Where a partner adds value is in the surrounding work: checking which flows and clients share the stage, confirming the upgrade path, building reputation policies and alert rules, and documenting the result for audit evidence. Decide which of these your team has capacity to own, and write down who answers when a legitimate user is locked out after a throttled attempt.
Is throttling enough, or do we also need reputation policies?
Throttling limits how many guesses an attacker can make against one-time codes, but it does not stop password spraying or suspicious login traffic on its own. The authentik hardening guide recommends reputation policies that respond with a CAPTCHA challenge or a deny binding, and notifications for login_failed and suspicious_request events. Treat throttling as one control in a set: it slows code guessing, reputation policies reduce hostile traffic reaching the flow, and alerts give your security team the signal to investigate. Confirm the thresholds you choose with your own risk owner, since no default value is set by this guidance.
What should we check after throttling is enabled?
Test the change with real login attempts in a non-production instance before you touch production. Confirm that a correct code still succeeds, that repeated wrong codes trigger the throttle, and that the user receives a clear message rather than a confusing error. Check the logs to confirm failed attempts are recorded and forwarded to your destination, and that alerts fire for login_failed and suspicious_request events. Verify behavior for TOTP and static codes, which already had protection, so you know the overall picture. Keep the test results as evidence of what you changed and when, and schedule a review after the first weeks of production traffic.
Does a fixed-scope engagement cover ongoing monitoring?
Most DeployOpen engagements are fixed-scope, which means the scope, deliverables and timelines are agreed in writing before work starts. A fixed scope for this change would normally cover the configuration, testing and documentation you list in the statement of work, and it would state what is excluded. Ongoing monitoring, upgrades and continuous testing are available as retainers, which is the right route if you want someone to review throttling events and alert volume over time. Ask for the scope to name the release you will run after the work, the environments it covers and who signs off the result.
Security and operational risks to plan for
Throttling slows guessing, but it creates its own work: noisy logs, lockouts that users can trigger against each other, and containers that fall behind on fixes. The cards below cover the risks to design for before you tune thresholds, so the protection stays useful after go-live.
Alert fatigue from login_failed events
Every failed code and password attempt can emit a login_failed event, and busy tenants generate large volumes from ordinary typos and expired codes. If every event pages someone, real guessing activity gets lost in the noise. Decide which thresholds raise an alert, which only land in a dashboard, and who owns triage. Review the alert rules after the first month, when you know what normal failure volume looks like for your user population.
Attackers rotating source addresses
IP-based reputation scores and per-address limits assume one attacker uses one address. Attackers who rotate through proxies, cloud egress ranges or residential networks can spread guesses across many addresses, each under the threshold. Combine address signals with per-account failure counts, since the targeted account is the constant. Test this with a scripted attempt against a non-production user before you rely on address-based rules.
Lockout abuse as denial of service
Throttling that locks an account after repeated failures lets anyone who knows a username block that person from signing in. This is most painful for administrators and service-account owners. Decide whether a lockout should expire on a timer, require an administrator to clear it, or trigger a challenge such as CAPTCHA instead of a hard deny. Document the recovery path for each choice so help desk staff can act without improvising.
Log retention for investigations
A failed-login spike is only useful if the events still exist when someone investigates it. Confirm where authentik events are stored, how long they are kept, and whether they are forwarded to a log platform outside the authentik host. Check that the retention period covers the time it takes your team to notice and scope an incident. Decide who can read these events, because they contain usernames and client addresses.
Keeping containers on a supported version
Throttling fixes only help if the server and worker containers run a release that receives security patches. The security policy lists 2026.5.x and 2026.8.x as supported, and security releases are announced at least 24 hours ahead. Pin both containers to the same supported release, subscribe to the release feed, and schedule a test window so you can apply security updates quickly. Check the release notes for breaking changes before each upgrade.
Alerting on failed logins and suspicious requests
Route login_failed and suspicious_request events to an operations channel before you tune any thresholds, because throttling only slows an attacker down and the alert is what tells your team a guessing run is underway. The hardening guide recommends notifications for both event types, so start by creating an event-based notification transport and a notification rule that matches each event type, then send it to the channel your on-call engineers watch. Confirm the exact event names, filter fields and notification options in your version's interface, since the rule builder changes between releases. Test the path by triggering a deliberate failed login against a non-production user and confirming the message arrives.
Set escalation thresholds around the pattern, not the single event. A single failed OTP is normal noise from a mistyped code, so reserve paging for a burst against one user account, a run of failures from one source across many accounts, or any suspicious_request tied to an MFA stage. Choose the counts and time windows with your security team and record them in your runbook, because the right numbers depend on your user population and how often legitimate users mistype codes. Pair these alerts with the reputation policy and CAPTCHA or deny bindings described in the hardening guide so that an alert leads to a defined action, such as blocking a source address or forcing a password reset on a locked account.
Review the event stream weekly rather than relying only on pages. A recurring review lets you spot slow, low-volume guessing that never crosses a paging threshold, repeated failures against accounts that lack MFA enrollment, and false positives from a new office or VPN range. Keep the review notes with your change records. Before you promise audit evidence from these events, confirm with authentik whether enhanced audit logging is available on your edition, because the pricing page lists it among enterprise-only features, and decide where you will retain events for longer than your default log window.
How DeployOpen scopes and delivers MFA throttling work
DeployOpen treats brute-force protection as a set of configured controls in your own authentik deployment, not a single switch. We start from the authenticator types you allow, then design throttling, reputation policies and alerting around them so each layer is tested and documented.
How we scope
- Inventory which second factors your users and LDAP or RADIUS clients actually use, including email and SMS codes
- Confirm your authentik version supports email and SMS attempt throttling before committing to a design
- Agree in writing which throttling, reputation policy and alerting controls are in and out of scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts
How we build
- Configure authenticator validation stages and reputation policies in a non-production instance first
- Test failed-attempt behavior for each OTP type, including lockout and recovery paths for legitimate users
- Wire login_failed and suspicious_request events to notifications your security team monitors
- Keep configuration exported so changes can be reviewed and reproduced across environments
How we hand over
- Deliver a written record of each throttling setting, its value and the reason it was chosen
- Provide test evidence showing blocked guessing attempts and confirmed normal sign-in behavior
- Document the runbook for unlocking users, reviewing alerts and adjusting thresholds safely
- Walk your operations and security staff through the configuration and the alert triage steps
How we support
- Retest throttling after each authentik upgrade, since release behavior can change between versions
- Review alert volume and reputation policy tuning with your team on a schedule you agree
- Ongoing support, upgrades and continuous testing are available as a retainer
- Confirm which version receives security fixes on the authentik security policy before planning upgrades
