Orchestrating Multi-Factor Authentication Fatigue Attacks Against Authentik Identity Services Through Authentication-Request Rate Controls and User Verification Policies

Modern identity-management platforms use multi-factor authentication (MFA) to provide an additional verification layer beyond usernames and passwords. authentik provides customizable authentication workflows through Flows, Stages, and Policies, allowing organizations to define how users are identified, authenticated, and granted access to applications.

An MFA fatigue attack attempts to overwhelm a legitimate user with repeated authentication or MFA requests until the user accidentally approves one of the requests or otherwise interacts with an unexpected authentication prompt.

The security risk is particularly relevant when an authentication workflow permits repeated authentication attempts without sufficient request-rate controls, user verification, suspicious-activity detection, or user-awareness mechanisms.

In this use case, a controlled authentik identity service is deployed on Ubuntu Linux inside an isolated VirtualBox laboratory. A protected test application is integrated with authentik as the authentication provider.

The laboratory attack generates repeated authentication requests against a dedicated test account. The requests are intentionally limited to the authorized laboratory environment and are designed to reproduce the behavioral pattern of an MFA fatigue attack without targeting real users or external identity services.

The authentik authentication workflow uses an Identification Stage, authentication stages, an Authenticator Validation Stage, and policies that control when authentication stages are executed. authentik documentation confirms that stages can be bound to flows and that policies can determine whether a stage runs.

The defensive architecture introduces authentication-request rate controls, repeated-request detection, suspicious authentication-event monitoring, user-verification requirements, MFA throttling where applicable, CAPTCHA or reputation-based controls for suspicious requests, and security-event monitoring.

For code-based authentication methods, authentik supports throttling of repeated failed verification attempts for device classes such as TOTP, static OTP, email OTP, and SMS OTP. WebAuthn and Duo devices are documented separately and are not subject to that specific code-based throttling mechanism.

The controlled attack is repeated after the security controls are implemented to verify that excessive authentication requests are detected and restricted, unexpected MFA activity is identified, user-verification requirements remain enforced, legitimate authentication continues to function, and security events are available for investigation.

Complete Identity and Access Management Workflow: Authentik Identity Service → Authentication Flow → User Identification → Primary Authentication → MFA Validation → Repeated Authentication Requests → Request-Rate Detection → Suspicious Activity Detection → Authentication Request Restriction → User Verification → MFA Validation → Security Alert → Security Investigation → Remediation → Post-Remediation Validation

authentik provides the controlled identity-management environment for the laboratory. Its authentication architecture is based on Flows, Stages, and Policies. A flow defines the authentication sequence, stages represent individual verification or logic steps, and policies can determine whether a flow or individual stage is allowed to execute. The Authenticator Validation Stage can validate enrolled authenticators, including TOTP, WebAuthn, Duo, SMS, email, and static authenticators.

An authentication workflow may become exposed to MFA fatigue when an attacker repeatedly initiates authentication attempts against a target account and causes the identity service to generate repeated MFA verification events. If repeated authentication requests are not sufficiently detected or restricted, the legitimate user may receive multiple unexpected authentication prompts.

The security problem is therefore:

The proposed security architecture introduces request-rate controls, suspicious-request detection, authentication policies, MFA throttling where supported, user-verification requirements, and centralized security monitoring.

An MFA fatigue attack attempts to generate repeated authentication or MFA requests for a legitimate user. Instead of attempting to bypass MFA cryptographically, the attacker abuses the authentication workflow by repeatedly initiating authentication attempts against the target account. In the controlled laboratory scenario, a dedicated test account is created in authentik. The security-testing system generates repeated authentication requests against the laboratory authentication endpoint. The objective is not to compromise the account. The objective is to reproduce the repeated-request behavior associated with MFA fatigue and determine whether the authentication architecture can identify and restrict the excessive requests. authentik’s flow architecture allows policies to be attached to flows and stage bindings, making it possible to introduce additional controls around authentication-stage execution.

MFA fatigue protection requires more than simply enabling MFA. The authentication workflow should also identify abnormal authentication-request behavior and apply additional controls when repeated requests occur.

authentik provides a flow-based architecture in which authentication consists of ordered stages and policies can be bound to flows or stage bindings. This allows the laboratory implementation to place security decisions around the authentication process rather than treating every authentication request as equally trusted. authentik also provides a Reputation policy designed to react to repeated failed logins or suspicious sign-in activity. Its hardening documentation recommends using reputation-based controls with CAPTCHA or authentication-flow denial for suspicious activity and configuring notifications for login_failed and suspicious_request events. For code-based authenticators, the Authenticator Validation Stage provides exponential back-off after failed verification attempts, with configurable throttling factors. For stronger user-verification assurance, WebAuthn/FIDO2/passkeys can be configured with user-verification requirements. authentik documents user-verification settings that can require, prefer, or discourage verification by the authenticator.

The secure processing flow is: