Is it possible to enable Two-Factor Authentication (2FA) for specific users in ZITADEL?

From the docs, it looks like 2FA can only be configured at the organization login settings level, which enforces it for all users in that org. What I want is to require 2FA only for selected users instead of everyone.

Does ZITADEL support user-level 2FA enforcement, or is there any workaround to achieve this?

Ask Inkeep•12/8/25, 9:13 AM

Hi @Shanil Sasikumar, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.

Ask Inkeep•12/8/25, 9:13 AM

Answer

I can’t directly answer this from the available sources.

The material I have only covers:

How to list second factors configured on the instance login policy (instance‑level / default login policy) , not per user. (1)
How to add second factors to the instance login policy (again, instance / default login policy scope) , not per user. (2)
A description that 2FA/MFA types are enabled/disabled on the login policy and then respected (or not) by various UIs/APIs, but still in the context of policy‑level settings, not user‑level enforcement. (3)

None of these explicitly document a feature to enforce 2FA on a per‑user basis or describe a pattern to do so, so I can’t confirm that such a capability or official workaround exists.

I recommend clicking the “Ask for help” button so a ZITADEL team member can confirm current capabilities and potential workarounds for your exact use case.

I wasn't able to find a direct answer, here are some relevant sources:

[List Second Factors (2FA) ] [(1) ](<https://zitadel.com/docs/apis/resources/admin/admin-service-list-login-policy-second-factors>) : Describes how to list second factors configured in the default login policy of the instance, indicating configuration at policy/instance scope.
[Add Second Factor (2FA) ] [(2) ](<https://zitadel.com/docs/apis/resources/admin/admin-service-add-second-factor-to-login-policy>) : Describes how to add a second factor to the default login policy, again at policy/instance scope rather than per user.

Ask Inkeep•12/8/25, 9:13 AM

To learn more, see the sources I considered:

[1] List Second Factors (2FA)
[2] Add Second Factor (2FA)
[3] MFA self management does not respect login policy

Ask Inkeep•12/8/25, 9:13 AM

Feel free to tag @Ask Inkeep with additional questions.

AAsk Inkeep To learn more, see the sources I considered: [[1] List Second Factors (2FA)](...

Ask InkeepAPP•12/8/25, 9:40 AM

Got it. Tagging @Rajat for additional help.

Rajat•12/8/25, 9:43 AM

hey @Shanil Sasikumar good morning, yes you are right, 2FA (second factors / MFA) is configured and enforced at the org login policy level, not per user.

Rajat•12/14/25, 8:49 AM

hey @Shanil Sasikumar you can mark my answer with

and it will auto close this thread.

Thank you

Joebeurg•12/14/25, 12:41 PM

@Rajat how does this scenario work:
User A belongs to the default ORG A, and was granted roles and projects in ORG B and ORG C.
DEFAULT ORG A: optional MFA,username/password the deafult
ORG B: enforces MFA
ORG C: has SSO
How does the user then login? Will they be able to use MFA/SSO even though they belong to a different org but has grants from other ones with such policies?
This setup scenario is to have one account across multiple ORGs.

JJoebeurg <@1346540274674827395> how does this scenario work: User A belongs to the defaul...

Rajat•12/15/25, 4:26 AM

So I spent some time thinking and it's a pretty interesting use case

When User A logs in, they authenticate according to org A's login policy (optional MFA, username/password). The user would not be forced to use mfa during login, even though they have grants in org B which enforces mfa.

If the authentication request includes an organization scope parameter (like ‘urn zitadel

iam:org:id:{orgB_id})‘ the login policy of that specified organization (org B) would apply
Without an explicit organization scope, the user's home organization (org A) policy should apply.

Grants determine authorization (what the user can access/do in other orgs), but the authentication policy is determined by the orgs context, basically the user's home organization unless explicitly overridden by scope parameters(like above)

Just having grants in org C doesn't automatically make org C's SSO providers available when logging in from org A

RRajat So I spent some time thinking and it's a pretty interesting use case 🤗 When Us...

Joebeurg•12/15/25, 8:08 AM

Well explained, thanks man

Rajat•12/15/25, 8:27 AM

Awesome!
Feel free to start a new thread and I'll close this meanwhile
Thank you :))