Enforcing MFA for every authentik user

Enforcing MFA for every authentik user: what changes when second factors are optional

Enforcing MFA in authentik means changing what happens when a user has no authenticator, not flipping a global setting. An instance where MFA exists but users can skip it usually has an authenticator validation stage in the login flow that runs only for users who already have a device enrolled. Users without one pass straight through. Closing that gap depends on the not configured action on that stage, which decides whether authentik skips MFA, denies access, or injects enrollment stages so the user sets up an authenticator before continuing. Because the behavior lives in how each flow is built, you need to review every flow that signs users in, not only the default one, and confirm that each path reaches a validation stage with the right action.

Teams usually need this when access to a system carries regulatory or contractual weight, when administrator and privileged accounts must never sign in on a password alone, or when the user population is mixed, with contractors, service-adjacent staff and employees sharing one directory and one login flow. Each of these cases calls for a different answer on who must enroll, who may be excused, and what happens to people who never finish setup. Whether a given control satisfies a particular regulation is a question for your compliance function and independent auditors, not a conclusion this page draws. Start by listing the populations and the applications they reach, then map each one to a flow that either enforces enrollment or denies access.

Before you change anything, confirm in your own instance which flows include an authenticator validation stage, what the not configured action is set to on each, and whether any user groups bypass the stage through policy bindings. The authentik hardening guide recommends requiring enrollment or denying access when no authenticator exists, and limiting device classes, such as WebAuthn only, where your risk model supports it. Test each change with a user who has no device, an existing user with a device, and a privileged account, and record the results. Decide in advance how a user who loses their only device gets back in, because an enforced flow with no recovery path turns a lost phone into a helpdesk backlog.

Not-configured actions and when each fits

This table compares the three not-configured actions on the authenticator validation stage: skip MFA, deny access, and inject enrollment stages. Read each row as a trade-off for users who have no authenticator yet, and use the last row to decide which action matches your policy.

Action	User experience	Main risk	When a team picks it
Skip MFA	User signs in with the password or earlier factors and reaches the application with no second factor.	Any account without an authenticator keeps single-factor access, so enforcement is only as strong as the enrollment backlog.	Short transition periods or pilot groups where the team accepts reduced assurance for a defined set of users and tracks them.
Deny access	User is blocked at login with no route to set up a device unless an administrator intervenes.	Helpdesk load rises and users may be locked out at scale if enrollment was never communicated or pre-staged.	高 assurance applications where no unenrolled session should ever succeed and enrollment is completed before go-live.
Inject enrollment stages	User is prompted to register an authenticator in the same flow, then continues to the application.	Enrollment can be completed by whoever holds the password, so enrollment itself needs identity checks and clear device rules.	Mandatory MFA rollouts where most users self-enroll at next login and the team wants enforcement without manual tickets.
Assurance level during rollout	Users pass through a known, time-limited state before full enforcement.	Forgotten transition states can persist, so the end date should be recorded in change tracking.	Phased rollouts by group, with a documented date when skip or soft modes change to enrollment or denial.
Handling users with no device	Users who cannot enroll see either a skip, a block or an enrollment prompt, depending on the chosen action.	Users who lose a device may fall into the same path as new users, so recovery must be designed separately.	Confirm which recovery method your policy allows, such as administrator reset or recovery codes, before choosing the action.
Effect on device classes	The action interacts with which authenticator types are offered during enrollment.	Restricting classes such as WebAuthn only can block enrollment for users without a compatible key.	Teams limiting enrollment to approved hardware keys, which usually pairs with denial or forced enrollment.
Audit and evidence	Each action produces different logs, such as skipped stages or enrollment events.	Skipped MFA can be hard to prove as a control unless the flow logs and group membership are retained.	Teams that must show an assessor how unenrolled users were handled and when they were brought into scope.
Typical fit	Choose based on the assurance target and the enrollment backlog.	Choosing the wrong action creates either silent weakness or avoidable lockouts.	Denial for strict policies, forced enrollment for most workforces, skip only as a time-limited exception. Confirm the exact behavior in your authentik version.

Configure mandatory MFA in an authentik flow

This sequence turns MFA from an optional prompt into a required step in the login flow, so every user either validates an authenticator or is routed to enrollment before access is granted. The result is a tested flow with a defined behavior for users who have no authenticator.

Define the allowed device classes
Before touching the flow, the security owner and the identity administrator agree which authenticator types count as acceptable for your risk level, for example WebAuthn only, or a mix of TOTP and WebAuthn. Write the list down with the reason for each class and the hardware you will accept. Done when the list is approved and each class has a named owner for support questions. Confirm in your installed version which device types the validation and enrollment stages expose, because the available options depend on the release you run.
Create or reuse the enrollment stages
In the admin interface, identify the authenticator enrollment stages that match the device classes from the previous step. Reuse existing stages where they already fit, and create new ones only for classes that are missing. Keep the device restrictions in the enrollment stage aligned with the validation stage so a user cannot enroll a device that the login flow will later reject. Done when each allowed class has one enrollment stage and you have a short table mapping class to stage name. Confirm the exact stage type names and field labels in the version you have installed.
Attach the validation stage with a not-configured action
Add an authenticator validation stage to the login flow, limit it to the device classes you approved, and set the not-configured action. The options are to skip MFA, deny access, or inject enrollment stages so the user registers an authenticator before continuing. For mandatory MFA, choose the enrollment or deny option, never skip. Done when the stage shows the chosen action and the device classes match the table from the earlier steps. Confirm the labels for these options in your version, since wording differs between releases.
Bind the flow to the login path
Bind the flow to the login path your users actually reach, usually the default authentication flow for your brand or the flow attached to the applications in scope. Check the stage order so identification and password stages run before the validation stage, and confirm that no earlier stage can end the flow without reaching MFA. Done when a sign-in attempt walks through the stages in the order you designed, visible in the flow inspector or the logs. Include any other flows that could sign users in, such as recovery or enrollment, and decide whether they need the same rule.
Test with a user that has no authenticator
Create a test user with no registered authenticator, assign it to a group that the flow applies to, and sign in through a browser. The expected result is that the user is sent to enrollment for an allowed device class, and access is denied or delayed until enrollment completes. Repeat the test with the not-configured action set to deny to confirm the user is blocked. Done when both outcomes match the design and the audit or event log records the enrollment and the denial. Also confirm that a user who already has an allowed authenticator reaches the validation prompt.
Check the lost-device path
Test what happens when a user with a registered authenticator loses the device. Your design should say who can reset or remove an authenticator, how the user proves identity, and whether the removed device forces the user back into enrollment through the same flow. Run a test where an administrator removes the test user's authenticator and confirm the user is routed to enrollment rather than given a bypass. Done when the procedure is written, the test passes, and the support team knows the steps. Recovery codes and other backup methods are covered on separate pages, so confirm that any backup you add does not weaken this rule.

Which device classes to allow and why

Every authenticator you allow becomes a path an attacker may try, so the list should be short and deliberate. The methods below differ mainly in phishing resistance, how easily a code can be guessed or intercepted, and how much the device itself can be trusted.

WebAuthn with user verification

Passkeys and hardware security keys bind the login to the site origin and require a PIN, biometric or similar check on the device. Phishing a code is not possible against this method, which makes it the default to aim for. Check that the WebAuthn stage requires user verification, and confirm which authenticator attestation and device types your users will actually have before you rely on it.

Restricted hardware keys only

The hardening guidance suggests limiting allowed devices to WebAuthn and restricting the hardware itself, for example to company-issued FIDO2 keys. This removes personal devices and unknown models from the attack surface, but it adds procurement, shipping and replacement work that your team must plan for. Decide who pays for keys and how lost keys are replaced before you enforce the list.

TOTP authenticator apps

Time-based codes from an app are widely supported and work offline, but the code can be phished in real time and the seed lives on a phone that users may back up or share. Repeated guessing is a concern for any six-digit code, so confirm throttling is in place. Treat TOTP as acceptable for most staff but weaker than WebAuthn for administrators and privileged roles.

Duo push and passcodes

Duo adds an external service to the login path, so availability and the Duo account become dependencies for every user. Push approvals are convenient but susceptible to fatigue attacks if users approve prompts they did not start. Confirm with Duo how the integration handles outages and whether your Duo edition supports the admin features you plan to use.

Email and SMS one-time codes

These methods depend on mailboxes and phone numbers that can be taken over through SIM swapping, account compromise or number recycling. They are useful for recovery or low-risk populations, but they should not be the only second factor for privileged access. Make them a documented exception, with expiry, throttling and a named owner for the risk decision.

Static tokens and recovery codes

Backup codes prevent lockouts but are secrets that can be copied, stored in plain text or shared. Each unused code is a standing bypass of the other factors, so their use should be rare and logged. Confirm how many codes users receive, how they are regenerated, and that an administrator reset is recorded before you allow them as a fallback.

Handling users who lose their device without weakening MFA

Forcing enrollment creates a lockout problem the moment a user loses or replaces the only authenticator they have. If the policy simply denies access in that state, the user is stuck, and the help desk will be pressured to relax the rule. The design goal is to make recovery a controlled, documented path that proves identity and issues a new authenticator, so that no one ever reaches the application without a second factor. Decide this before enforcement goes live, because the first lost phone will arrive within days of the change.

Plan three layers. First, recovery methods are enrolled in advance, such as the static authenticator stage covered in the recovery codes topic, so a user can get back in without an administrator. Second, when no recovery method exists, re-enrollment is driven by an administrator who verifies identity through a channel independent of the locked account, such as a manager confirmation or a call-back to a number already on file, and then sends a single-use enrollment path. Third, avoid silent bypasses: do not create a flow that skips the authenticator validation stage for users flagged as lost, and do not leave a broad exception group in place after the incident. Confirm in your own environment how your administrators reset or re-enroll a user's authenticator and who is allowed to do it.

Keep the detail in the sibling topics. The authentik hardening guide explains the device class and verification choices that affect how strict recovery can be. The recovery codes, WebAuthn restriction and brute-force protection topics cover how codes are validated, throttled and reissued. Test the full path in a staging instance: lose a device, recover, re-enroll, and confirm that the old authenticator no longer validates.

Security and operational risks of enforcement

Mandatory MFA fails in predictable ways: administrators get locked out, some login paths bypass the stage, and version differences change behavior. The cards below cover the checks that catch these problems before users are affected, and the records you need afterward.

Administrator lockout risk

If enforcement applies to the admin group, an administrator who loses every authenticator can be shut out of the tenant that would recover them. Keep at least one break-glass administrator with a separately stored credential and a documented recovery path before you change the not-configured action. Confirm in a staging instance that a global administrator can still reach the admin interface and reset another user's authenticator. Treat this as the first test in the rollout plan, not an afterthought.

Paths that bypass the stage

A validation stage bound to one flow protects only the requests that flow handles. LDAP binds, RADIUS requests and API token clients may take a different path and never reach the stage you configured. List every application and protocol that authenticates against authentik, then trace each one through its flow and confirm whether MFA is applied. Illustrative example: a web login is enforced while an LDAP bind for a legacy app still accepts a password alone.

Enrollment audit trail

Mandatory enrollment means you need a record of who enrolled which authenticator, when, and whether the user was forced to do it at login or chose to. Review events in the audit log for enrollment and deletion of authenticators, and decide who may remove a device without an approval step. Enhanced audit logging is listed as an enterprise feature on the pricing page, so confirm which events your edition records and where they are forwarded before you rely on them for review.

Testing before rollout

Run enforcement in a staging instance that mirrors your production flows, identity sources and applications. Use test accounts for each group, including users with no authenticator, users with only one device class, and service accounts that should be exempt. Verify each path end to end, including password reset, invitation and recovery flows, because enforcement often changes these too. Record the expected result for each test so a failed case is easy to spot during the production change window.

Version-specific behavior

Enforcement behavior and the settings that control it can change between releases, so the version you test on must match the version you run. The security policy lists 2026.5.x and 2026.8.x as supported lines receiving security fixes, and it announces security releases at least 24 hours in advance. Confirm your running version against that list, schedule upgrades so they do not coincide with an enforcement change, and retest the MFA flow after every upgrade.

Device classes and hardware limits

Restricting device classes narrows who can comply, so an overly strict setting can lock out users with older phones or unsupported keys. Decide which classes are acceptable for your risk level and whether user verification is required on hardware keys. The hardening guide recommends limiting device classes such as WebAuthn only and restricting allowed hardware, but you should verify in staging that each approved device can complete enrollment and login before you enforce the restriction.

Questions buyers ask about enforcing MFA in authentik

How much effort does enforcing MFA in authentik take, and who does the work?

Enforcing MFA is mostly flow and policy configuration, so the effort sits in deciding the rules before anyone touches the flows. Your team or a partner typically covers four pieces: choosing the allowed device classes, setting what the authenticator validation stage does when a user has no authenticator, building the enrollment path, and testing each application that signs users in. The configuration itself is small compared with the rollout planning, communication and helpdesk preparation around it. Ask any partner to split the quote into design, configuration, testing and rollout support so you can see which parts your staff would handle.

Can our team enforce MFA in authentik without outside help?

Yes, a team with administrator access and someone who understands your login flows can do it alone. The authentik documentation covers the authenticator validation stage and the hardening guidance, which together describe the options for users without an authenticator and the device classes you can restrict. The risks usually come from the surrounding work: testing every application that signs users in, deciding how lost devices are recovered, and keeping support staff ready for the first wave of enrollments. If none of those have an owner on your side, an outside review of the design before go-live is often the cheaper step.

What do we need to provide for an MFA enforcement project?

Three inputs decide whether the project moves quickly. First, an identity owner who can approve the policy: which user groups must enroll, which device classes are acceptable, and whether any exceptions exist. Second, a set of test users covering each group, each application and each client type, including any LDAP or RADIUS clients that bind without a browser. Third, a written helpdesk procedure for lost or replaced devices, including how identity is verified before an authenticator is reset. Without the helpdesk procedure in place before enforcement, the first lost device becomes an incident.

How does the cost of enforcing MFA depend on scope and edition?

Cost depends on the amount of design and testing, the number of applications and clients involved, and the edition you run. The authentik pricing page lists an Open Source edition at no license fee with community support only, an Enterprise edition at $5 per user per month billed annually plus $0.02 per external user per month, and an Enterprise Plus edition starting at $20k annually. The MFA enforcement settings described in the authentik documentation are available in the open-source code, so the license choice does not change the enforcement design itself. Ask for the license cost and the implementation cost as separate lines, and note which ongoing items recur each year, such as licenses and support retainers.

How long does an MFA rollout take with our user count and client types?

Duration depends mainly on how many user groups need to enroll, how many clients must be tested, and how many people your helpdesk must support during enrollment. Browser-based applications that use the standard flows usually move faster than LDAP or RADIUS clients, which need separate bind flow design. No duration figure is supplied for this work, so ask any partner for a schedule based on your user groups and client list, with a pilot phase, a staged rollout and a fixed date for denying access to users who have not enrolled. Also ask how the schedule changes if one application fails testing.

What happens to existing users who have no MFA when we enforce it?

Existing users without an authenticator are handled by the not-configured action on the authenticator validation stage, which you choose before enforcement. The options are to skip MFA, deny access, or inject enrollment stages so the user registers an authenticator before continuing. Most rollouts use enrollment rather than denial at first, so users can finish setup at their next login, then move to denial once the deadline passes. Plan a communication to users before the change, and confirm with your team how users who are on leave or work on shared devices will be handled.

Which device classes should we allow when enforcing MFA in authentik?

The right set depends on your risk level and what your users already own. The authentik hardening guide recommends limiting device classes, for example allowing WebAuthn only, requiring user verification and restricting allowed hardware. Weaker options such as code-based methods may be acceptable for some groups, but each one adds recovery and guessing considerations. Decide the allowlist before enrollment starts, because changing it later forces users to re-enroll. Confirm with the authentik release you run that the device types you choose are available in your version, and test each one with your real sign-in paths.

How DeployOpen scopes and delivers MFA enforcement

DeployOpen treats mandatory MFA in authentik as a written scope covering flows, stages, device policy and recovery, not a single setting change. We design the enforcement path, build it in your own infrastructure, test it against real login paths, and hand over documentation your administrators can run without us.

How we scope

Inventory every flow and application that signs users in, including any LDAP or RADIUS clients that need MFA
Agree in writing how the not-configured action should behave for users with no authenticator
Define which device classes are allowed, and whether hardware keys must meet a stated requirement
Document the lost-device recovery process and who may approve it before work starts

How we build

Configure the authenticator validation stage and enrollment stages in your own authentik instance
Restrict allowed device classes and user verification settings to the approved list in the written scope
Test enrollment, login and lost-device paths with test accounts before any production change
Confirm the authentik version in use and check its security policy for the supported release line

How we hand over

Deliver a runbook for the enforcement flow, device policy and recovery steps your help desk follows
Provide configuration records and a test script your team can rerun after upgrades
Walk your administrators through changes, with a written record of what was built and why
Document open decisions, such as accepted methods, that need sign-off from your risk owners

How we support

Ongoing support, upgrades and continuous testing are available as a retainer
Retest the enforcement path after each authentik upgrade or change to flows and stages
Review new device classes and recovery requests against the agreed device policy
Engagements are fixed-scope, so any additional work is agreed in writing before it starts

Enforcing MFA for every authentik user