Zitadel MFA, lockout and login policies: when a multi-organization platform needs them
Login policies are how Zitadel applies multi-factor authentication, account lockout, password and re-authentication rules to the users who sign in to a given organization, and they are set per organization. A platform team running one Zitadel deployment for several customer or partner organizations needs them when those organizations carry different risk and identity rules. A bank partner may require a second factor for every user, while a training customer may accept a password alone for low-risk accounts that already sign in through its own identity provider. Write each organization's rules down before anyone opens the console.
Policy design comes before configuration. For each organization, list which second factors you will allow, such as passkeys or one-time codes, which users must present them, and whether local users and federated users follow the same rule. Federated users authenticate at their upstream identity provider, so decide whether Zitadel should still enforce a second factor for them or whether the upstream provider's controls are the accepted control. Then set the thresholds: how many failed attempts trigger a lockout, how long the lockout lasts, how strong passwords must be, and how often users must re-authenticate.
The exact policy fields, their options and how each one behaves must be confirmed against the Zitadel documentation for the version you run. Behavior around lockout, factor enforcement and re-authentication can change between releases, and a setting that looks equivalent in one version may apply to different sign-in paths in another. Record the version, the field names and the expected behavior in your design document, then test them in a non-production instance before changing any production organization. Confirm also whether a policy change applies to existing sessions or only to the next sign-in.
Map each organization to a policy profile before anything is set. A simple table works: organization, user populations (local, federated, service or partner accounts), required second factors, lockout behavior, password requirements, re-authentication interval and the owner who approves changes. Note which organizations have contractual or regulatory obligations that set a floor, and which the platform team may tighten on its own. Once the map is agreed, configuration becomes a checklist, and reviews have a baseline to compare against when an organization asks for an exception.
Which login policy settings fit local and federated users
This table compares the login policy areas you must decide for Zitadel organizations, separating settings that apply to local password users from those that apply to users who sign in through an external identity provider. Read each row for when the setting fits, what it costs users and the help desk, and what to confirm in the Zitadel docs for your version. The main takeaway is that federated users depend heavily on their identity provider's controls, so confirm where Zitadel's policy ends and the upstream policy begins.
| Policy area | When it fits | Trade-off for users and help desk | What to confirm in the docs |
|---|---|---|---|
| Allowed second factors | Fits when you want users to choose between authenticator apps, security keys and passkeys, or limit choices to stronger options. | More choice reduces lockouts from lost devices, but the help desk must support enrollment and recovery for each method. | Which factor types the policy permits per organization, and whether passkeys count as a second or first factor. |
| MFA enforcement for local password users | Fits when your organization holds its own user records and needs a second factor on every password sign-in. | Each enrollment becomes a support task, and users without a registered factor may be blocked until they enroll. | Whether MFA can be required per organization, when users are prompted to enroll, and what the enrollment flow looks like. |
| MFA expectations for federated users | Fits when users sign in through Entra ID, Okta or another provider that already enforces its own MFA. | If Zitadel adds no second factor after an upstream login, the upstream policy sets your assurance level. | Whether Zitadel can enforce MFA on federated logins, and whether it checks the upstream authentication context. |
| Lockout threshold | Fits when you need to slow password guessing on local accounts, configured per organization. | A strict threshold locks out legitimate users and creates tickets; a lenient one weakens guessing protection. | The number of failed attempts that triggers lockout, and whether a successful sign-in resets the counter. |
| Lockout duration | Fits when you want automatic recovery after a short pause without help desk action. | Long lockouts raise ticket volume, while short ones give attackers more attempts over time. Decide who can unlock early. | Whether lockout is timed or manual, the unit of time used, and which roles can clear a lock in the console. |
| Password complexity | Fits local accounts only, since federated users sign in with credentials held by their identity provider. | Strict composition rules increase reset requests and unsafe workarounds. Length-based rules are usually easier to support. | Which rules are configurable, whether length limits are adjustable, and whether breached-password screening is available. |
| Re-authentication and session lifetimes | Fits when sensitive applications need a fresh sign-in before high-risk actions or after a set period. | Shorter lifetimes protect shared devices but interrupt users mid-task. Federated sessions may also depend on upstream session length. | Which lifetimes Zitadel sets, which apply to federated logins, and how application tokens refresh. |
How organization scope shapes login policy in Zitadel
Where a login rule lives in Zitadel decides who it touches, so the first design task is mapping your tenants before you write any policy. Zitadel organizes tenants as instances, which are virtual tenants with full data isolation, and inside each instance as organizations, which hold the users and projects. Projects group applications, roles and grants. Login settings such as second factor choices, lockout behavior, password rules and re-authentication lifetimes are applied through policy objects, and the level at which a policy is set determines which users receive it. Start by drawing the instance and organization tree you expect, then mark which policy values must differ between branches.
Isolation is the main reason to separate instances. An instance is the boundary for data, so if two business units or regulated populations must never share users, configuration or audit records, they belong in different instances rather than in separate organizations under one instance. Within a single instance, organizations give you a scope for administration and identity, but they do not give you the same separation of data. Confirm in the Zitadel organizations documentation which objects are scoped to an organization and which are shared across the instance, because that boundary decides whether an organization can safely carry its own rules.
Organizations are also where identity sources differ. Zitadel allows each customer organization to use a different identity provider, so one customer may sign in through Entra ID over OIDC while another uses LDAP or a SAML provider. Login rules that assume a password exists, or that expect an MFA prompt, may not fit a federated user whose second factor is enforced by the upstream provider. Before you set a forced MFA rule, list each organization's identity source and decide whether the rule should apply to local users, federated users, or both. Confirm how your Zitadel version treats federated logins against each policy type, because this varies with configuration.
The design consequence is that a policy right for one customer may be wrong for another. A strict lockout threshold suited to a bank may lock out staff at a school district, and a short re-authentication lifetime fits an admin console but frustrates a consumer app. For each organization, decide whether it needs its own rules or can inherit a shared default. A practical split is one instance default for baseline controls, with overrides only where a customer's regulation, identity source or risk profile requires them. Record the reason for each override so later reviews can tell a deliberate exception from drift.
Before go-live, confirm in the Zitadel documentation for your version which policy levels exist, namely the instance default and any organization override, and how inheritance resolves when both are set. Test with one local user and one federated user in each organization, and check the effective setting from each login path. Ask the vendor or your implementation partner to document this inheritance map, and keep it with your change records so that a future policy edit is traced to the scope it affects.
Setting up login policies for each organization
This sequence turns login requirements into tested Zitadel policies, starting from an inventory of organizations and identity providers and ending with sign-in checks for each user type. The result is a documented policy matrix and a recorded effective policy for every organization.
Inventory organizations, users and identity providers
List every Zitadel organization in the self-hosted instance, the projects and applications each one uses, and the user types it holds: local users, federated users from an external identity provider, users who sign in with passkeys, and users who still use passwords. For each organization, record which identity provider handles federated login, because Zitadel lets each customer organization use a different provider. Ask the application owners which sign-in methods their users need and which must be blocked. This step is done when every organization has a row listing its user types, identity providers and application owner, and the team agrees that the list is complete. Confirm the organization model and identity provider behavior against the Zitadel documentation for your version before you rely on them.
Write the login policy matrix
Build one matrix with a row for each organization and columns for allowed factors (password, passkey, second factor types), whether MFA is required for local users, whether MFA is required for federated users, lockout thresholds, password complexity rules, and re-authentication lifetimes. Mark which values are shared across the instance and which vary by organization. Have security, the application owners and the identity team sign the matrix before any change is made in the instance. This step is done when each cell has a value or an explicit decision to inherit the default, and the signed matrix is stored with your change records. Treat the thresholds as decisions your security team owns, and confirm the exact setting names in the documentation for your release.
Set the instance default login policy
Apply the values that every organization shares as the instance-level default login policy, using the Console or the management API as your version documents. Keep the default conservative enough to be safe for the organization with the strictest requirements, then relax it only through overrides. Take a snapshot or export of the current configuration first so you can roll back. Confirm after saving that the policy reads back with the values in your matrix. This step is done when the stored default matches the matrix row for the shared values and the change is recorded with its approver.
Create overrides for organizations that differ
For each organization whose matrix row differs from the default, create an organization-level login policy override and set only the values that differ. Leave the rest inherited so later default changes still reach that organization. Name each override so an administrator can see which organization it governs and why. Check that no organization is left without a deliberate decision, including organizations created after the initial setup. This step is done when every organization either inherits the default or carries a documented override that matches its matrix row.
Verify the effective policy for each organization
For every organization, use a test user and check the effective login policy the instance applies to that user. Compare each value against the matrix, including factors, MFA requirement, lockout threshold, password rules and re-authentication lifetime. Record the observed result, the date, the tester and any mismatch in a test log. If a value differs, fix the default or override, then repeat the check for that organization. This step is done when every organization has a logged result that matches its matrix row, with no open mismatches.
Test sign-in for each user type
Sign in as a local user with a password and second factor, a federated user through the organization's identity provider, a user with a registered passkey, and a password-only user where your matrix allows it. For each path, confirm that MFA is enforced where required, that disallowed factors are refused, and that repeated failed attempts trigger lockout at the configured threshold. Confirm that re-authentication is requested when the lifetime expires. Keep test accounts separate from production users and remove them when testing ends. This step is done when each user type has a recorded pass or fail for each rule in the matrix.
Document the policies and schedule a review
Store the final matrix, the default and override settings, the effective-policy results and the sign-in test log together as the reference for the instance. Record who owns each value and the change process for updating it. Set a recurring review with security and the application owners, and re-run the effective-policy check after any upgrade, identity provider change or new organization. This step is done when the reference set is stored, its owners are named, and the review is on the calendar.
Security trade-offs of MFA and lockout settings
Login policy settings protect accounts in some ways and expose them in others. The cards below cover the decisions that most often need a deliberate choice before a Zitadel login policy goes live for each organization.
Lockout can block valid users
A lockout threshold limits password guessing, but an attacker who fails sign-ins on purpose can lock out real users in the same organization. Pair the lockout setting with rate limiting at your edge proxy or gateway, so repeated failures from one source are slowed before accounts lock. Confirm with your team how a locked user is unlocked, who may do it, and whether that step is logged.
Second factor strength varies
One-time codes sent by SMS or email can be intercepted or entered on a phishing page, while passkeys and hardware security keys bind sign-in to the legitimate site. Decide which second factors each organization may use, and whether administrators should be limited to phishing-resistant options. Check which factors your Zitadel version allows in the login policy before you publish the list to users.
Federated sign-in skips local MFA
When a user signs in through an external identity provider, the MFA requirement in Zitadel may not decide the outcome, so the strength of sign-in depends on that provider. For each federated organization, confirm the upstream MFA policy with the provider's administrator and test a federated sign-in end to end. Record the result in the policy design so the gap is known rather than assumed.
Password rules may conflict upstream
Local password complexity in Zitadel can differ from the password policy of an upstream identity provider, leaving users with two credentials that follow different rules. Local passwords can also remain a fallback path that is weaker than the upstream sign-in. List the password rules for each organization, decide whether federated users need a local password at all, and align or disable the local rules to match.
Policy changes need an audit trail
If changes to MFA, lockout or password settings are not recorded, you cannot later show who weakened a control, when it changed, or why. Zitadel keeps an event history for its objects, and that history can support an investigation or an assessment if it is retained and reviewed. Confirm who may edit login policies, how changes are approved, and how long the event records are kept.
Forcing MFA for federated users without breaking single sign-on
The central design question for federated users is whether Zitadel's second-factor requirement should apply to people who sign in through an upstream provider such as Entra ID, Okta, Google, or a generic OIDC or SAML provider, and if it should, which system enforces it. Zitadel can federate login with each of these, and each customer organization can use a different identity provider. The answer may therefore differ by organization and by provider type. Make that decision before you write the login policy, because a single rule applied across an instance will either prompt some users twice or leave others without a second factor.
The first common pattern is to trust the upstream provider's MFA. Zitadel accepts the authentication result from the upstream and does not prompt for a second factor on its own side. This suits organizations whose identity provider enforces strong MFA through conditional access and whose policies are documented and reviewed. The risk is coverage. Upstream policies may not apply to every sign-in path, such as legacy protocols, guest accounts or service accounts. Confirm with your identity team which authentication context or claims Zitadel receives from each upstream, and whether they show that a second factor was actually used.
The second pattern is to require a second factor at Zitadel for every session, regardless of what the upstream did. This gives you one enforcement point and one set of audit records for every login. The cost is a second prompt for users who already completed MFA upstream, which can frustrate them and encourage workarounds. You also need to decide which factors at Zitadel satisfy the requirement, for example passkeys or one-time codes, and how the prompt appears inside a single sign-on flow. A hybrid approach, enforcing at Zitadel only for certain provider types or certain applications, is also possible if the documented behavior supports it.
Test each identity provider configuration with a real federated sign-in before you rely on it. Use test accounts that represent a user with MFA enrolled upstream, a user without it, and an external or guest user. For each account, record whether the second-factor prompt appears, whether the sign-in completes, and whether silent single sign-on into a second application still works. Repeat these tests after any change to upstream conditional access, to Zitadel login policies or to the identity provider settings of an organization.
Confirm in the Zitadel documentation which behavior applies per organization and per provider type, how policy inheritance works between instance and organization levels, and whether a changed setting affects sessions that already exist. Where the documentation is unclear, ask the vendor and record the answer alongside your test results. Document the final decision, including the owner, the provider types it covers and the review trigger, so that the security and identity teams can audit it later.
Limits to confirm for your Zitadel version
Several Zitadel MFA, lockout and login policy details depend on the release you run and the level at which each setting applies. Verify each card below against the release you plan to deploy, and record the answers in your design before you set production values.
Policy fields and defaults
Login, password, lockout and MFA policy fields and their default values can change between releases, so do not rely on memory of an earlier version. Pin the exact release you plan to run, such as v4.19.5 (released 15 October 2026), and read its release notes on the zitadel/zitadel GitHub releases page next to the policy reference in the official documentation. Record each field name, default value and allowed range, then confirm them on a test instance running the same version.
Instance or organization scope
Check whether lockout thresholds and re-authentication lifetimes are set once for the instance or can be overridden for each organization. Zitadel organizes tenants as instances with organizations inside them, and your multi-tenant design depends on which level a policy applies to. Ask whether an organization without its own rule inherits the instance default, then test two organizations side by side before you promise per-customer behavior.
Available second factor types
Confirm which second factor types your chosen version offers, including one-time codes from an authenticator app, security keys and passkeys. Check whether each type can be required by policy or only offered to the user. Passkeys are documented as passwordless login with fallback to password login, so decide whether a passkey satisfies your MFA requirement or only replaces the password, and verify that choice on a test instance.
Policy changes and active sessions
Test what happens to existing sessions when an administrator tightens an MFA requirement, shortens a re-authentication lifetime or lowers a lockout threshold. Some changes may apply only at the next sign-in, while others may require an existing session to be ended. Sign in a test user in a browser and in an application that holds tokens, change the policy, and record whether access continues and how long the change takes to apply.
Federated and SCIM-provisioned users
Confirm how MFA enforcement applies to users who sign in through an upstream identity provider and to users created through SCIM v2 provisioning. An upstream provider may already perform its own MFA, and a provisioned account may have no local password, which can change which policy path applies. Create a test user through your SCIM client and a test federated login, then check the prompts, lockout behavior and re-authentication timing each one receives.
Operating login policies through upgrades and new customers
Once Zitadel login policies are live, the work that keeps them correct is ongoing. The core artifact is a written policy matrix that records, for each organization, which second factors are allowed, whether MFA is forced for local users and for federated users, the lockout threshold, password complexity rules and re-authentication lifetimes. Keep this matrix under change control like any other production configuration. Each row should name an owner, the reason for the value, the Console location or API object that enforces it, and the test cases that prove it works. Confirm at the outset which settings apply at instance level and which can be overridden per organization, because that determines where a single edit can reach other tenants.
Every Zitadel upgrade is a point where a policy can change behavior without anyone touching it. Before planning an upgrade, confirm the target release notes for changes to login, MFA or password handling, and read them against your matrix. Then run the policy test cases on a staging copy: sign in with each allowed factor, trigger a lockout and confirm it clears as documented, check that re-authentication prompts appear at the expected interval, and confirm federated users still receive or skip MFA as the matrix states. For self-hosted deployments, Zitadel supports PostgreSQL 14 through 18. Confirm your database version falls within that range before and after the change, and schedule the database and Zitadel upgrades with the same test pack in hand.
A new customer organization should start from a baseline policy template, not from whichever tenant was configured last. The template fixes the defaults your security team has approved, and the intake record lists every deviation with a reason. Ask the customer which identity provider they will use. Zitadel lets each organization federate with a different provider, and a federated login can change how MFA enforcement is experienced, so test local and federated sign-in separately for each new organization. Add the new organization's rows to the matrix before go-live, and run the full policy test set against it, not only the cases that changed.
Help desk cases reveal whether the policies are workable. A locked account should be unlocked only after the requester is verified through a channel other than the login being recovered, and the unlock should follow the matrix rather than a temporary override. A lost second factor needs a documented re-enrollment path that includes identity checks and a time-limited recovery state, with no silent removal of MFA for the user. Write these steps as a runbook, reference the matrix rows they touch, and record each case with the requester, the verification method and the action taken. Every change to a policy, whether from an upgrade, a new organization or an exception, should record the approver, the requester, the ticket, and the before and after values. That record is what auditors and incident reviewers will ask for first.
Cost, effort and what to ask before setting login policies
What drives the cost of a Zitadel login policy project?
The main drivers are the number of organizations and identity providers, the number of distinct policy profiles, whether a policy matrix already exists, the testing scope, and the integrations with your help desk and SIEM. Each organization that needs different second factors, forced MFA rules, lockout thresholds or re-authentication lifetimes adds design and test work. Each identity provider also changes how MFA is enforced for federated users, so it adds decisions and test cases. A missing policy matrix usually adds the most design time, because the decisions must be made before anything is configured. Design, configuration and testing are one-time work. Support, policy changes and retained testing recur only if you choose a retainer. Ask the quote to show effort per organization, per profile and per integration so you can see which decisions drive the total.
Can our own team set up Zitadel MFA and lockout policies?
Yes, for a simple single-organization setup with a small number of profiles and one identity provider, your team can usually configure the policies itself if you write the policy matrix and test plan first. The matrix should list each organization, its allowed second factors, whether MFA is forced for local and federated users, lockout thresholds, password rules and re-authentication lifetimes. The test plan should cover each profile with dedicated test accounts, including failed sign-in, lockout recovery, passkey fallback and expired sessions. Multi-organization estates, federated providers that already enforce MFA upstream, and help desk or SIEM integrations add risk that is harder to catch internally. Many teams start in-house and bring in a partner for review or for specific gaps, and that scope can be agreed in writing.
How long does a Zitadel login policy engagement take?
The duration depends on the scope agreed in writing before work starts, so the timeline follows from the number of organizations, profiles, identity providers, test cases and integrations in that scope. Client readiness also matters: a timeline slips when the organization list, provider details or sign-off decisions arrive late. Ask for a timeline that lists each milestone, the client inputs each milestone depends on, and the testing window before go-live. Timelines in a written quote are only as firm as the scope and inputs behind them, so check that changes to scope are handled through a written change process.
What do we need to provide before login policy work starts?
Before work starts, you will need to provide an organization list, identity provider details, your compliance requirements and test accounts. For each organization, provide its name, its intended identity provider or local user base, and the named owner who approves its policy. For each identity provider, provide the connection details, the MFA behavior already enforced upstream and the attribute mapping you expect. Compliance requirements should name the controls your assessor will check, described in your own words. DeployOpen prepares systems, controls and evidence for assessment, but independent auditors issue any audit report. Test accounts should cover each profile and each sign-in path, including local password, passkey and every federated provider. Also agree on a change window and a decision-maker who signs off the policy matrix.
Where do I find current Zitadel Cloud pricing and Enterprise support terms?
Zitadel publishes current Zitadel Cloud pricing and Enterprise support terms on its pricing page, and you should check that page before you budget, because plan details can change. The page describes a Free plan, a Pro plan and an Enterprise plan with custom pricing for self-hosted or cloud deployments, and it notes that Enterprise offers custom support agreements and technical account management. These are Zitadel's charges for the product and its support, which are separate from DeployOpen's fee for policy design, configuration and testing. Confirm which deployment model you run, because that determines which Zitadel terms apply. If a quote mentions licensing or support, ask for it to be itemized so the two sets of charges are never mixed.
What should a written quote for login policy work include?
A written quote should start from a scope statement that lists the organizations, identity providers, policy profiles, test cases and integrations in scope. It should then list the deliverables, such as the policy matrix, configured policies, the test plan with results and the operating notes for your team. Ask it to state the client responsibilities and the inputs each one depends on, the acceptance criteria for each deliverable and how scope changes are priced and approved. Also ask which items are excluded, for example ongoing policy changes, incident support or SIEM rule content. Finally, confirm whether ongoing support is a separate retainer or included, and whether the quote itemizes any third-party charges you would pay directly to Zitadel.
How do help desk and SIEM integrations change Zitadel policy effort?
Help desk and SIEM integrations add effort because lockout and MFA events must reach the people and tools that act on them. Each integration needs its own configuration, field mapping and testing, and each new organization or profile can add event types that the integration must handle. The help desk needs runbooks for lockout recovery and passkey re-enrollment, and the SIEM needs rules that distinguish a legitimate lockout from a credential attack. Before scoping, confirm in your own environment which events Zitadel exposes to your tooling and how your SIEM ingests them, since the exact event coverage should be verified against the current Zitadel documentation and your test instance. Put these integration tests in the scope so their effort is visible in the quote.
What breaks most often when new login policies go live?
The most common failures come from policy rules that interact in ways the matrix did not cover. Lockout thresholds can lock out service accounts or automated clients that sign in with passwords. Forced MFA can prompt federated users twice when their upstream provider already enforces a second factor. Passkey users can be stranded if fallback to password login was removed or never tested. Re-authentication lifetimes that are too short interrupt long-running sessions, and lifetimes that are too long weaken the control your compliance requirements describe. Each of these is found by running a test account through each profile before go-live, not by reviewing the matrix alone. Keep a rollback plan for each organization so one profile can be reverted without changing the others.
How DeployOpen scopes and delivers Zitadel login policy work
DeployOpen plans, configures, tests and documents Zitadel login policies inside your own infrastructure, from second-factor choices to lockout and re-authentication settings. Each organization's policy is designed on paper first, then built, verified and handed to your team with the reasoning recorded.
How we scope
- Engagements are fixed-scope, with the written scope agreed before work starts.
- Scope lists each Zitadel organization, the login paths it uses and which second factors each path may offer.
- Scope records lockout thresholds, password rules and re-authentication lifetimes per organization, with the owner who approves each value.
How we build
- Policies are configured in a non-production instance first, so MFA enforcement for local and federated users can be checked before it reaches users.
- Federated logins are tested per identity provider, confirming that forced MFA applies only where your policy intends it to.
- Lockout and passkey fallback behavior are exercised with test accounts, including the password fallback path, and results are recorded.
How we hand over
- Handover includes a policy register that maps each organization to its settings, approvals and the reason for each value.
- Runbooks cover changing a policy, reviewing lockout events and handling a user locked out of a second factor.
- Your administrators receive a walkthrough and a test checklist so later changes can be verified the same way.
How we support
- Ongoing support, policy reviews and upgrades are available as a retainer after handover.
- Retainer work can cover re-checking policies after Zitadel upgrades, so login behavior is confirmed on each new release.
- Ask whether a support agreement must cover your Zitadel version and which environments it includes before you sign.
