Entra ID federation with Zitadel: what it does and when to use it
Zitadel federates login to Microsoft Entra ID through its Microsoft identity provider template, using OpenID Connect. Users choose Microsoft on the Zitadel login page, authenticate with their Microsoft account, and Zitadel then issues its own tokens to the applications that trust it. Entra ID handles the upstream sign-in, while your applications keep validating Zitadel tokens. This section is for teams that already run Zitadel for workforce or customer identity and need people with Microsoft accounts to sign in without a second password. The documented guide is OIDC-based, so if your design depends on SAML from Entra ID, confirm those details with Zitadel before you plan the work.
The setup involves four decisions. The first is the app registration in Entra ID: you create an application, set its redirect URI to the Zitadel callback URL for your instance, and generate a client secret. Someone must own that secret, store it in your secrets manager, and rotate it before it expires. The second is the tenant type. Zitadel's Microsoft provider can target the Common tenant type, which accepts all Microsoft accounts, the Organizations type, which accepts Entra ID tenants only, or the Consumers type, which accepts personal accounts only. Choosing the wrong type either admits accounts you did not intend to accept or blocks the users you need.
The third decision covers claims and account linking. The guide asks for optional claims in the ID token, including email, family_name, given_name and preferred_username. Each claim you request must be enabled in the Entra ID app configuration and then mapped inside Zitadel. Ask which claim will serve as the stable key for matching an incoming Microsoft identity to an existing Zitadel user, because email addresses change and can be reassigned. Test this with real accounts from your tenant before you decide whether automatic creation of new users is acceptable.
The fourth decision is whether each customer organization gets its own provider. Zitadel allows a different identity provider per organization, so a B2B customer can sign in with its own Entra ID tenant while other customers use different providers or local accounts. Plan this in the design phase, because it changes how you name providers, assign roles to organizations, and test sign-in. Before work starts, confirm with Zitadel which options apply to your version, and list the Entra ID tenants, account types and claims your first users will need.
Prerequisites for Zitadel and Microsoft Entra ID federation
Federating Zitadel with Microsoft Entra ID touches your Zitadel deployment, your database, your public URL and your Microsoft tenant at the same time. Confirm each item below before anyone opens the Microsoft admin center, because a mismatch in any one of them usually shows up later as a failed sign-in rather than a clear error.
A running self-hosted Zitadel instance
The federation is configured inside an existing Zitadel instance, so that instance must be installed, reachable and able to serve the console and hosted login before work starts. Confirm which deployment method you use (Linux binary, Docker Compose or Kubernetes with the official Helm chart) and the exact Zitadel version. Check that version against the current release notes before work starts, because the steps in the Entra ID guide depend on it.
A supported PostgreSQL version
Self-hosted Zitadel stores its data in PostgreSQL, and versions 14 through 18 are supported. Confirm the major version your database runs, not only the server package, and check that the Zitadel release you plan to use supports it. A database outside that range should be upgraded or resolved before you add a new identity provider, since a fault there affects every sign-in, not only Entra ID logins.
A public HTTPS callback URL
Microsoft redirects users back to a Zitadel callback URL after they authenticate, so Zitadel must serve that address over HTTPS and Microsoft must be able to reach it from the internet. Record the exact external hostname, including the path Zitadel uses for the identity provider callback. The redirect URI you register in Entra ID must match this value character for character, including scheme, host, port and trailing slash, or sign-in fails at the Microsoft step.
Administrator rights in Microsoft Entra
Registering an application in the Microsoft Entra admin center requires an account with permission to create app registrations in the target tenant. Confirm with your Microsoft 365 or Entra administrator who will perform the registration and who will approve any admin consent the app needs. If your tenant restricts user app registrations, plan for an administrator to complete that step while your team supplies the redirect URI and the required claims.
A decision on tenant type
Zitadel's Microsoft provider can target the Common, Organizations or Consumers tenant type, which decides whether sign-in accepts all Microsoft accounts, only Entra ID work or school tenants, or only personal Microsoft accounts. Decide this before registration, because the tenant type determines which users can sign in and which endpoint Zitadel calls. Record the decision and the reason, since changing it later means revisiting the app registration and the provider configuration.
A named owner for the client secret
The Entra ID app registration issues a client secret that Zitadel stores to authenticate token requests, and that secret expires. Name one owner who is accountable for recording the secret's expiry date, rotating it before it lapses and updating the value in Zitadel. Store the secret in your approved secrets system, not in a shared document. Without a named owner, a silent expiry is a common cause of a federation that worked at launch and fails months later.
Choosing a Microsoft tenant type for Zitadel sign-in
The tenant type is the first decision in the Microsoft provider setup because it determines which Microsoft accounts can reach Zitadel at all. Zitadel's Microsoft provider can target three options. Common accepts every Microsoft account, including work and school accounts in Entra ID tenants and personal Microsoft accounts. Organizations accepts only accounts from Entra ID tenants. Consumers accepts only personal Microsoft accounts. Each option answers a different question about your users, so start by listing who will sign in and what kinds of Microsoft account they hold. The Zitadel provider configuration and the Entra app registration are both built around this answer, so settle it before either one is created.
A workforce that signs in with company-issued accounts usually fits the Organizations option. Employees and contractors who hold accounts in your tenant can authenticate, and personal accounts are excluded. This keeps the set of accepted identities small and tied to your directory, which simplifies the conversation with your identity and security teams. The trade-off is that anyone holding a personal Microsoft account, or an account in a tenant you did not plan for, will be turned away. Ask your identity team which tenants actually hold your users before assuming that one tenant covers everyone, particularly where staff from partner organizations need access.
A customer-facing product may need a broader choice. Customers who use personal Microsoft accounts for everything will not hold an Entra ID account, so the Organizations option would block them, while the Consumers option would admit them but exclude work accounts. Common is the widest choice and suits a platform that must accept both personal and work accounts from a mixed audience. It also widens the set of identities you must trust and support. As an illustrative example, a consumer portal that serves both individuals and small businesses may need Common, while a supplier portal used only by a client's staff would fit Organizations. Map your audience against these cases before you choose.
The tenant type also constrains other settings. The account types your app registration supports must match the option you configure in Zitadel, so a mismatch usually appears as sign-in failures for one group of users rather than a clear error. Consider who can approve the app as well. Depending on how the tenant is governed, administrator consent may be required before users can sign in, and that approval belongs to the tenant administrator, who needs to be involved early in the plan.
Before building, check the tenant type against the current Zitadel Entra ID guide, because provider options and the Microsoft-side settings they require can change between releases. Record the decision with the user groups it covers, the account types set on the app registration, and the owner who approves later changes. Confirm how the choice interacts with the email and name claims your login flow depends on, and test sign-in with one account from each user group before rollout. This test catches tenant and account mismatches while they are still cheap to fix.
Setup sequence for Zitadel and Microsoft Entra ID federation
This sequence connects a Microsoft Entra ID app registration to a Zitadel identity provider in a controlled order. Each step ends with a check, so the team can confirm sign-in, claims and user records before the provider reaches real users.
Register the application in Microsoft Entra ID
A Microsoft Entra administrator creates an app registration for the Zitadel sign-in and records the application (client) ID and the directory (tenant) ID. The supported account types must match the tenant type you plan to select in Zitadel, so agree on that choice with the tenant owner before registering. This step is complete when the registration appears in the app registrations list, the IDs are saved in your change record, and the tenant owner has confirmed who may consent to the application.
Set the redirect URI to the Zitadel callback
In the registration's authentication settings, add a web redirect URI that matches the callback URL shown in Zitadel's Microsoft provider configuration for the instance or organization that will use it. Copy the value from Zitadel, since a single character difference in scheme, host or path causes sign-in to fail at the callback. To check, compare the two values side by side and confirm they match exactly before saving the registration.
Create the client secret and record its expiry
Under certificates and secrets, the administrator creates a client secret and copies its value immediately, because Entra shows the value only once. Store the value in your organization's secret store, and record the expiry date in the team's renewal calendar with a named owner. The step is complete when the secret is stored with its expiry metadata and a renewal reminder is in place ahead of that date. Confirm the expiry with your own policy, since the secret lifetime is set when it is created.
Add the Microsoft provider in Zitadel
In Zitadel, the administrator creates an identity provider from the Microsoft template in the instance or organization that will use it. Enter the application ID and client secret, then select the tenant type that matches the registration: Common accepts all Microsoft accounts, Organizations accepts Entra ID tenants only, and Consumers accepts personal Microsoft accounts only. The step is complete when the provider appears in the list with the expected name and tenant type, and the reason for the chosen tenant type is written into the change record.
Select optional claims and test the token
Enable email, family_name, given_name and preferred_username as optional ID token claims in the Entra registration, then select the matching claims in the Zitadel provider settings. Optional claims may be missing for some accounts, so user mapping should not depend on email unless your tenant confirms it is always supplied. Check the setup by signing in with a non-admin test account and inspecting the ID token in a test tool or the Zitadel logs to confirm each selected claim arrives with the expected value.
Set linking and automatic creation options
Decide whether an incoming Entra identity links to an existing Zitadel user, whether Zitadel creates a new user on first sign-in, and in which organization. Linking on an email address that the other party has not verified creates an account takeover risk, so prefer matching on a verified attribute or a manual linking step. Check the options with two test users, one that already exists locally and one that does not, and confirm the first links to the expected record and the second is created once, with no duplicate.
Confirm the created user record and grants
Open each test user in the Zitadel console and inspect the external identity link, the organization, and any project roles. Confirm that no administrator or project roles were granted automatically, and that each person has one linked identity rather than several. The step is complete when the records match the expected design for each test case, and any unexpected grant or duplicate is traced to its cause and corrected before the next step.
Test in a non-production instance first
Repeat the steps in a non-production Zitadel instance with a separate Entra app registration and test tenant. Cover admin and non-admin sign-in, existing and new users, a denied or unlicensed account, and disabling the provider as a rollback. Record each outcome with the owner's sign-off. Enable the provider for real users only after the results are documented and the rollback has been tested in that environment.
How Entra ID claims map to Zitadel user fields
This table shows which ID token claim from Microsoft Entra ID fills which Zitadel user field, and whether each one is required. Read the requirement column first, since the identifier and email decide how Zitadel links a returning user to an existing account. Every claim here depends on how the Entra app registration is configured, so confirm the claims in a test token before the team relies on them.
| Claim or field | Zitadel user field and requirement | Notes for the team |
|---|---|---|
| sub (user identifier) | External identity link for the Entra user. Required. | Stable per-application subject from the ID token. Confirm in the Zitadel guide whether linking uses this value alone or also checks email. |
| Human user email. Optional, but needed for linking to an existing account by email. | Only link on email if Entra marks it as verified in your tenant. Check the value in a test token. | |
| given_name | Profile first name. Optional. | Returned only when requested as an optional claim in the Entra app registration. Blank names are common for guest accounts. |
| family_name | Profile last name. Optional. | Same request requirement as given_name. Confirm it arrives for both member and guest users in your tenant. |
| preferred_username | Username. Optional. | In Entra this is often the sign-in name, which may differ from email. Decide whether it should drive the Zitadel username before go-live. |
| Claim missing from the token | Field stays empty after first sign-in. Action required. | Add the claim as an optional claim in the Entra app, sign in again to get a fresh token, then confirm it appears in the test token. |
| Claims not listed in the guide | Not mapped by default. Verify before use. | Decode a test token, confirm the claim exists and its format, then decide whether to map it in Zitadel. |
What changes for users at first sign-in and when accounts link
The first Microsoft Entra ID sign-in is the moment most likely to surprise users, so the team should decide its behavior before the federation goes live. Under automatic creation, a user who has never signed in through this provider gets a new Zitadel user in the organization the provider is attached to. Zitadel builds the profile from the claims the provider returns, such as email, given name, family name and preferred username, if those claims are configured in the identity provider settings. The user then returns to Zitadel and continues to the application they requested. Confirm in your Zitadel version whether a profile completion step, terms acceptance or a verification prompt appears on that path, because each one changes what the user sees and how long the first sign-in takes.
The harder case is a sign-in where a matching Zitadel user already exists. If the configuration links accounts on email alone, Zitadel attaches the Entra identity to the existing user whenever the addresses match. That creates two risks. The first is duplicate accounts: a user whose Entra address differs in spelling, alias or casing from the address stored in Zitadel may receive a second, empty account with no roles or grants. The second is account takeover. If the existing Zitadel account was created with an address nobody verified, such as an administrator entry or a self-registration, anyone who can sign in to a Microsoft account with that address could be linked to it. The Microsoft tenant type matters here. The Common and Consumers options admit personal Microsoft accounts, which widens the set of identities that can assert an address. Check whether the provider returns a verified email claim and whether your version can require it before linking.
The team must then choose between two models. Pre-provisioning creates the Zitadel users in advance, with roles and grants already set, so the first Entra sign-in binds to an identity someone has approved. This suits workforce deployments where HR or the directory owns the list of people, and it moves the risk into the provisioning process. Explicit linking requires each user to sign in to an existing Zitadel account first, then authenticate with Entra ID to attach the external identity. This adds a step for users but avoids automatic binding by address alone. For customer or partner organizations, where the owner of the list may be outside your company, explicit linking is often the safer default. Document which model applies to each organization, because a single instance can hold several organizations with different provider settings.
On the login screen, users see a button labeled with the provider name, then the Microsoft sign-in page, and possibly a consent prompt the first time. If linking is explicit, they also see a Zitadel prompt for their existing password or passkey. Users who already have an account, or who use a different address for Microsoft than for Zitadel, may end up with a second account and assume the system is broken. The team should communicate which button to use, what to do if they already have an account, which address to use, and who to contact when access is missing. Provide a short help desk script that covers these cases, and label any example message as illustrative when you share it internally.
Before go-live, confirm the exact option names, labels and defaults in your Zitadel version, because automatic creation and linking behavior has changed between releases. Then test a matrix in a non-production environment: a new user, an existing user with a matching verified address, an existing user with a different address, a personal Microsoft account where your tenant type allows it, and a user with an unverified local address. Record what each case produces and whether the resulting account has the expected roles. Those results should decide the linking model, and they should be reviewed by the team that owns identity governance before any user is directed to the new login path.
Securing the Entra ID client secret and sign-in path
The federation depends on three things: the client secret that Entra ID issues, the Zitadel provider configuration that decides how sign-in behaves, and the Entra app registration that defines which accounts can authenticate. The cards below cover how to protect each of them, along with the database and release baseline Zitadel depends on. Confirm each setting against your own Zitadel and Entra ID configuration before go-live.
Store the client secret securely
The Microsoft provider in Zitadel uses a client secret issued for the Entra app registration. Store it in a secrets manager your platform team already operates, and reference it from the deployment instead of writing it into Helm values, environment files or Terraform state, where it is easily copied. Check who can read the secret in the manager, and confirm that the Zitadel pods or hosts can retrieve it at startup without a shared administrator credential.
Tie rotation to secret expiry
Entra ID client secrets expire, and a lapsed secret stops sign-in for every user who relies on the provider. Set a rotation schedule that starts from the expiry date recorded in the app registration. Create the replacement secret before the current one lapses, confirm in your Entra tenant that more than one secret can be active during cutover, update the secrets manager, roll the Zitadel deployment, and test a sign-in before deleting the old secret. Record an owner and the expiry date in your change calendar.
Restrict and log provider changes
The identity provider settings decide where Zitadel sends users and which claims it trusts, so editing them is a privileged change. Limit provider administration in Zitadel to a named group of administrators, separate that group from application owners, and require a second reviewer for changes to the client ID, the secret reference or the claims mapping. Confirm which of Zitadel's audit and logging options are available in your deployment, where administrative events are stored, and how they reach your central log platform.
Set the right tenant type
Zitadel's Microsoft provider can target the Common, Organizations or Consumers tenant type. Common accepts all Microsoft accounts, Organizations accepts Entra ID tenants only, and Consumers accepts personal Microsoft accounts only. For a workforce deployment, choose the narrowest option that matches who should sign in, and confirm that the supported account types on the Entra app registration agree with the Zitadel setting. A mismatch produces sign-in errors or wider access than you intended.
Review scopes and claims requested
The Zitadel guide for Entra ID requests optional claims in the ID token, including email, family_name, given_name and preferred_username. Request only the claims your user mapping needs, and decide for each one whether a missing value should block sign-in or leave the field empty. Email is often the claim used to match or link existing users, so confirm what it represents in your Entra tenant before you enable automatic linking. Repeat this review whenever the attribute mapping changes.
Keep PostgreSQL and Zitadel supported
Self-hosted Zitadel stores its data in PostgreSQL, and the documentation lists versions 14 through 18 as supported. Run a PostgreSQL version in that range, and plan a major upgrade before your version leaves the supported list. Keep Zitadel on a current release so security fixes in the sign-in path reach your deployment, and read the release notes for changes that affect federated login before each upgrade. Confirm the current support matrix with Zitadel before you choose versions, because support windows change.
Per-organization Entra ID providers for B2B customers
In Zitadel, each customer can be its own organization inside a single instance, and each organization can use a different identity provider for login. For a B2B platform, that makes it possible to design one pattern where Customer A's workforce signs in with its own Microsoft Entra ID tenant while Customer B signs in through another provider, such as Okta or a generic OIDC provider. Treat this as a design pattern to validate in your own environment, not as a configuration Zitadel guarantees for your use case. Before you commit, build the model in a test instance and confirm that provider settings, login flows and user linking behave as you expect for each organization.
The first design question is ownership. Decide which organization holds each Entra ID provider: the platform operator's organization, or the customer's own organization with its own administrators. Provider configuration affects who can sign in, so the owner should be the party accountable for that customer's access decisions. Also decide who may view or change provider settings, and confirm in the Zitadel documentation which roles can create and edit providers at instance level and at organization level. Write these answers down before any customer is onboarded, because moving a provider between organizations later is a change to live sign-in.
The second question is domain routing. When a user types an email address or a login name, Zitadel must decide which organization's provider to send them to. Confirm which mechanism your Zitadel version supports for this, such as domain-based discovery or organization-specific login entry points, and test what happens when a domain is claimed by more than one organization or when a user already has an account elsewhere. On the Entra ID side, the tenant type matters. Zitadel's Microsoft provider can target the Common, Organizations or Consumers tenant type, which cover all Microsoft accounts, Entra ID tenants only, or personal accounts only. Workforce customers usually point toward Organizations, but confirm that choice matches the population of accounts each customer actually uses.
The third question is app registration ownership and rotation. Each customer needs an application registration in its Entra ID tenant with a redirect URI set to the Zitadel callback for that organization's provider, plus a client secret that Zitadel stores. Agree in writing who creates the registration: the customer's IT team, which hands over the client ID and secret, or a DeployOpen team working under the customer's delegated access. Client secrets expire, so set a rotation owner and a calendar entry before the first secret is issued. Confirm the maximum secret lifetime allowed by the customer's Entra ID tenant policy, then test a sign-in against the new secret in Zitadel before the old one lapses.
The fourth question is offboarding. When a customer leaves, removing its provider should stop new sign-ins without destroying records that projects, grants or audit trails still depend on. Plan the steps in order: disable the provider in Zitadel, decide how linked user accounts are deactivated or retained, confirm that existing sessions end as expected, and ask the customer to delete the application registration in its tenant. Check the Zitadel documentation for how deleting or deactivating a provider affects linked users in your version. Ask for a written offboarding runbook as part of the fixed scope, and test it in staging with a dummy customer organization before you rely on it in production.
Common Entra ID federation failures and fixes
This table lists the failures teams most often hit when they connect Zitadel to Microsoft Entra ID, with the likely cause, the check that confirms it and the fix. Read each row in sign-in path order: app registration first, then tenant type, then claims and account linking. The main takeaway is that most of these failures can be confirmed from the Entra sign-in log or the decoded ID token before any configuration changes.
| Failure | Likely cause | Check that confirms it | Fix |
|---|---|---|---|
| Redirect URI mismatch | The redirect URI in the Entra app registration does not match the Zitadel callback URL for your instance and provider. | Read the redirect error in the Entra sign-in log, then compare it character by character with the callback URL shown in Zitadel's provider settings. | Register the exact Zitadel callback URL under the web redirect URIs in the app registration, then retry the sign-in. |
| Expired or wrong client secret | The client secret has passed its expiry date, or the secret ID was copied where the secret value belongs. | Check the expiry under Certificates and secrets in the app registration, and look for an invalid client credentials error in the Zitadel log during the token exchange. | Create a new secret, copy its value (the secret ID is a separate field) into the Zitadel provider, and set a reminder before the new expiry date. |
| Tenant type rejects the account | The provider's tenant type (Common, Organizations or Consumers) does not cover the account type the user signs in with, such as a work account against Consumers or a personal account against Organizations. | Identify whether the user has a work or school account or a personal Microsoft account, then compare it with the tenant type set in the Zitadel Microsoft provider. | Use Common to accept both account types, or match the tenant type to the account type you support. Create a separate provider per customer organization where their tenants differ. |
| Empty profile fields after sign-in | The optional email, given_name, family_name or preferred_username claims are not included in the ID token because they are not added in the Entra token configuration. | Decode the ID token from a test sign-in and list which of these claims are present. Compare the result with the user's profile in Zitadel. | Add the missing optional claims to the ID token under the app registration's token configuration, sign in again, and confirm the profile fields update. |
| Duplicate users created | Automatic creation ran for an Entra identity that had no link to an existing Zitadel user, often because a user with the same email already existed from a password or another provider. | Search Zitadel users by email and look for two accounts, one with an external Entra identity and one without. Compare the external user identifiers on each. | Set the account linking behavior for the provider before go-live, decide whether a matching verified email may link automatically, and merge the duplicate accounts already created. |
| Users outside the Entra tenant cannot sign in | The user is a guest from another tenant, or the Entra enterprise application requires user assignment and the user or their group is not assigned. | Check the Entra sign-in log for a user-not-assigned result or a guest account marker, and review the assignment settings on the enterprise application. | Assign the user or their group to the enterprise application, or confirm with your Entra administrator how guest access should be granted for these users. |
Questions buyers ask before hiring help with Entra ID federation
What drives the cost of Entra ID federation work for Zitadel?
The main drivers are how many tenants and organizations need sign-in, which tenant type you choose, how user accounts are linked, and how much testing you require. Each one changes the design, the configuration and the test matrix.
Number of tenants and organizations: A single workforce provider is a bounded job. Each customer organization that brings its own Entra ID tenant adds a provider configuration, its own redirect and claim checks, and its own test pass.
Tenant type: Zitadel's Microsoft provider can target the Common, Organizations or Consumers tenant types. The choice determines which accounts can sign in, so it needs written sign-off.
Linking rules and testing scope: Automatic creation and linking of accounts, plus test cases for each path, usually take more time than the initial sign-in. Ask for a quote built from written scope that lists each of these items separately.
What part of Entra ID federation is one-time and what recurs?
Design, app registration, initial configuration and testing are one-time work. Recurring work includes client secret rotation, upgrades of Zitadel and its database, and changes to providers when a customer moves tenants or its Entra ID configuration changes.
One-time: Deciding the tenant type and linking rules, registering the application in Entra ID, setting the redirect URI to the Zitadel callback URL, configuring the Microsoft provider with the client secret and claims, and testing sign-in and account linking.
Recurring: Rotating the client secret before it expires, applying Zitadel upgrades on your schedule, and re-testing after any provider change. Each new B2B customer with its own identity provider repeats the configuration and test steps.
Ask the vendor to separate these items in the quote so you can budget the ongoing portion.
Can an internal team set up Entra ID federation without outside help?
Yes, for a single workforce provider when the team already has Zitadel experience. The configuration follows the documented Entra ID guide: register the application, set the redirect URI, add a client secret and map the optional claims.
The harder case is multi-tenant B2B, where each customer organization may need its own provider, linking policy and test pass. That work needs a repeatable pattern, and mistakes in account linking can grant access to the wrong user.
Consider outside help if you expect several customer tenants, need a documented test record for auditors, or lack someone who owns Zitadel operations. An internal team can still hold the decisions and sign-off while a partner builds the pattern.
What does the client need to provide for Entra ID federation work?
Plan for four inputs before work starts.
Entra admin access to register the application, read tenant settings and confirm the tenant type and consent behavior.
A Zitadel test instance where the configuration and linking rules can be tried before production.
Identity owners who decide how existing accounts should be linked to Zitadel users, since that choice affects who can sign in and what they can access.
Sign-off on tenant type from the people accountable for who may sign in.
Without these, the work stalls at the first design decision. Confirm with the vendor whether anything else, such as Zitadel administrator rights or change windows, is needed in your environment.
How long does Entra ID federation take to implement?
Duration depends on scope, and this page does not give a figure. The main variables are the number of tenants and organizations, the tenant type, the linking rules you need, the depth of testing, and how quickly your identity owners and Entra admins can make decisions.
A single workforce provider with a test instance ready will move faster than a per-customer pattern that needs a repeatable setup for each organization.
Ask for a timeline in the written scope, with milestones for design sign-off, test completion and production cutover. Any timeline you receive should list its assumptions so you can see which inputs would change it.
Does Zitadel's pricing page list a price for federation work?
No. Zitadel's pricing page lists Enterprise pricing as custom, and that is not a quote for federation work. DeployOpen provides a quote from written scope, so the price follows the tenant count, tenant type, linking rules and testing you agree on.
Zitadel's Cloud plans list a Free plan at US$0 per month and a Pro plan at US$100 per month. Those are subscription prices for the platform, so keep them separate from the implementation cost in your budget.
Ask your vendor to itemize one-time design and testing, ongoing secret rotation and upgrade support, and any Zitadel subscription or support agreement you need.
Which settings in the Entra ID guide cause sign-in failures?
The usual causes are mismatches between the app registration and the Zitadel provider settings: the redirect URI, the client secret and the tenant type. Check that the redirect URI matches the Zitadel callback URL exactly, since a small difference blocks sign-in.
Confirm the optional email, family_name, given_name and preferred_username claims are being requested and returned in the ID token. Missing claims often show up as incomplete user profiles rather than a failed login.
Check that the client secret is current, because an expired secret fails later, often after a working test. Test with an account from each tenant type you expect to support. Confirm the exact behavior in your own environment during the test phase.
How DeployOpen scopes and delivers Entra ID federation for Zitadel
DeployOpen plans, implements, documents and supports self-hosted Zitadel in infrastructure you control, including the Microsoft Entra ID federation configured on it. Each engagement starts from a written, fixed scope that names the Entra tenant type, the users who will sign in, and each customer organization that needs its own provider.
How we scope
- The written scope names the Entra tenant type: Common, Organizations or Consumers, with the reasons for each choice.
- It lists which users sign in through Entra ID, which organizations get their own provider and how accounts link.
- Engagements are fixed-scope, agreed in writing before work starts, with ongoing support available as a retainer.
How we build
- Register the Entra application with a redirect URI set to the Zitadel callback URL and a client secret.
- Map optional email, family name, given name and preferred username claims from the ID token into Zitadel.
- Test sign-in for each tenant type in scope, including linking of existing accounts and automatic user creation.
How we hand over
- A runbook covering app registration, secret rotation, redirect URIs and the tenant type chosen for each organization.
- Test evidence for each sign-in path, showing claims received and accounts created or linked.
- Documentation of the Zitadel instance, organizations and projects that the federation depends on.
How we support
- Retainers cover upgrades to the Zitadel release you run and checks on the Entra configuration after changes.
- Support can include reviewing Entra app secret expiry and tenant changes before they affect sign-in.
- Continuous security testing of the sign-in flow is available alongside the retainer.
