Microsoft Entra vs ClavionX: An Identity Platform That Is Really a Directory

Every engineer who integrates with Microsoft Entra for the first time asks the same question within the hour: which of these is my application?

In the portal, the application shows up twice. There's an App registration, with its client ID, redirect URIs, certificates and API permissions. There's also an Enterprise application, which holds user assignment, single sign-on settings, provisioning and conditional access. Set something on one and it doesn't appear on the other. The docs explain that one is the application object and the other is the service principal. After a while it clicks.

The confusion isn't a UX accident. It's the most revealing thing about Entra's architecture. Entra is a directory first, with protocols attached. Everything, including your app, is a directory object, and every directory object lives in exactly one tenant. Once you see that, most of Entra's strengths and most of its awkward edges follow from it.

Disclosure: I work on ClavionX. For most workforce identity in a Microsoft shop, the right answer is Entra, and this post says so. The comparison gets interesting elsewhere.

What Entra actually is

Microsoft Entra ID, formerly Azure Active Directory, is the identity plane for Microsoft 365 and Azure. That alone makes it the most widely deployed enterprise identity system in existence. Around the directory sit:

• Conditional Access, a mature policy engine that combines user, group, application, location, device compliance from Intune, and sign-in risk.
• Continuous Access Evaluation, so resource providers can react to revocation events rather than wait for token expiry.
• Privileged Identity Management, for just-in-time admin roles.
• Managed identities and workload identity federation, which let Azure resources and external CI systems such as GitHub Actions obtain tokens without storing secrets.
• External ID, Microsoft's customer-identity product, generally available since May 2024. Azure AD B2C stopped being sold to new customers on 1 May 2025.

No other identity platform has this depth of integration with an operating system, an office suite and a cloud. That integration is the product.

A directory first

In a directory-first design, the tenant is the organization. Users, groups, devices and applications are all objects in it. Authentication is a service the directory provides to its objects.

Multi-tenant applications show the consequence clearly:

flowchart LR
    subgraph Home["Publisher's tenant"]
        AO["Application object<br/>(the definition)"]
    end
    subgraph T1["Customer tenant A"]
        SP1["Service principal<br/>(consent, assignment,<br/>CA policies)"]
    end
    subgraph T2["Customer tenant B"]
        SP2["Service principal"]
    end
    AO -- "admin consent<br/>instantiates" --> SP1
    AO -- "admin consent<br/>instantiates" --> SP2

There's one definition in the publisher's tenant and one instance in each customer tenant that consents. The customer's administrators govern their instance. They decide who's assigned, which Conditional Access policies apply and whether consent is granted at all. The publisher governs the definition.

This happens to be structurally very close to how ClavionX models applications. In ClavionX, a client or resource server can be declared global and made available across tenants. The tenant is the security domain in which it's used, with its own issuer and signing keys.

The difference is who holds the pen on security posture. In Entra, the consuming tenant can wrap the app in its own policies, such as requiring a compliant device or blocking a country. That's right for Entra's world, where the consuming tenant is a sovereign enterprise. In ClavionX, the canonical definition fixes redirect URIs, grant types, PKCE and token policy, and a tenant can't loosen them. That's right for ClavionX's world, where one product team serves many customer tenants and needs one guaranteed posture. The two platforms reached a similar shape from opposite ends and made the governance decision differently, and for good reasons in each case.

Extensibility: a callout with a two-second clock

Entra, like ClavionX, doesn't let customers run code inside the token service. It offers claims mapping policies, directory extension attributes for data that lives in the directory, and group and role claims for everything else.

For data that doesn't live in the directory, Entra offers a custom claims provider. This is a custom authentication extension on the token-issuance-start event. When a token is about to be issued, Entra calls your REST API, waits for claims and adds them to the token. Your API has two seconds to answer. If it doesn't, Entra retries. If every retry times out, the authentication fails.

That design is worth studying next to the others, because the timeout number is effectively a statement of philosophy:

Entra's position sits between the other two, and it's a thoughtful one. It accepts that some data must come from outside, but it won't run your code, it gives you a budget a user could actually tolerate, and it makes the failure mode an explicit platform decision rather than an accident of someone's try/catch. If a callout has to exist, this is close to the right shape for it. It's still a synchronous dependency, and the two seconds come out of your latency budget on every sign-in that triggers it. The Identity Latency Budget shows how little room that leaves.

Machine identity: Entra's strongest territory

Workload identity is where Entra is well ahead of most of the field, ClavionX included.

Managed identities mean an Azure VM, function or container gets tokens without anyone handling a secret. Workload identity federation extends that beyond Azure. A GitHub Actions run or a Kubernetes service account presents its own OIDC token, and Entra exchanges it for an Entra token based on a configured trust. There's no client secret anywhere. Why Operations Teams Eventually Hate Client Secrets describes the problem this eliminates, and it's fair to say Entra eliminated it at scale before most platforms started.

Delegation is where the approaches diverge. Entra's service-to-service delegation is the On-Behalf-Of flow, a Microsoft extension of the JWT bearer grant. A middle-tier API exchanges the user's token for one addressed to a downstream API. It works well inside the Microsoft ecosystem. It isn't RFC 8693 token exchange, and the resulting token doesn't carry a standard act chain recording which services acted along the way. For multi-hop agent workflows, that matters for auditing agent actions. Microsoft has announced dedicated agent identities under Entra Agent ID. Check its current availability against Microsoft's documentation rather than any blog post, this one included.

ClavionX's agent and MCP model is at the design stage, and RFC 8693 token exchange is planned rather than built. ClavionX has no equivalent of workload identity federation today. Clients authenticate with secrets or certificates, managed with rotation policies. On machine identity as it can be deployed today, Entra is simply further along.

Conditional Access vs what ClavionX has

The same honesty applies to policy. Conditional Access with device compliance from Intune is a signal source ClavionX can't match. ClavionX doesn't manage devices and never will. Its network access policies and adaptive MFA are planned rather than built. Today ClavionX offers TOTP, email and SMS one-time passcodes, passkeys and tenant-level MFA enforcement, which is solid but static. If your access policy depends on "is this a managed, compliant laptop?", that signal lives in Microsoft's stack.

Comparing them is often a category error

The most useful thing to understand about Entra vs ClavionX is that, in most real architectures, they aren't alternatives. They sit on opposite sides of a federation.

Entra is where your customers' employees live. A B2B SaaS product built on ClavionX has customers whose staff sign in with Entra. ClavionX acts as the SAML service provider to each customer's Entra tenant. Entra pushes users into ClavionX through SCIM, and each customer tenant in ClavionX keeps its own issuer and keys for tokens issued to the product.

flowchart LR
    E1["Customer A's Entra"] -- "SAML sign-in" --> CX
    E2["Customer B's Entra"] -- "SAML sign-in" --> CX
    E1 -. "SCIM provisioning" .-> CX
    CX["ClavionX<br/>(tenant per customer)"] -- "tokens" --> APP["Your product"]

The genuine comparison is narrower. It applies if you're building a product and considering Entra External ID as the identity layer for your customers. That's a directory-first platform applied to customer identity. It works best when your organization is already invested in Azure, and you should evaluate it against the tenancy and extensibility questions above rather than against workforce features you won't use.

When Entra is the better choice

Pick Entra when:

• It's workforce identity and you run Microsoft 365. It's already your directory, and adding a second one for employees is almost always a mistake.
• Device posture belongs in access decisions, through Intune and Conditional Access.
• Your workloads run in Azure, or you want secretless CI/CD through workload identity federation.
• You need mature privileged access management with just-in-time roles and access reviews.
• Customer identity lives in the Azure estate and External ID's model fits your tenancy needs.

ClavionX fits better when you're building a multi-tenant product whose customers bring their own IdPs, often Entra. It also fits when you need each customer isolated with its own issuer and keys, a canonical security posture that tenants can't loosen, a runtime you can self-host outside any single cloud, or a login path with no synchronous callouts at all.

The actual difference

Entra answers who is this person in the organization, and what may they reach? from inside a directory that already knows their laptop, their mailbox and their manager. ClavionX answers which customer's user is this, and what may they do in this product? from a runtime designed to know nothing it wasn't told ahead of time.

Most companies of any size will run Entra. The question worth asking isn't whether to replace it. It's whether the identity layer of the product you're building should also be a directory, or whether it should be the thing that federates with all of them.

Vendor details are from Microsoft's public documentation as of September 2026; Entra features and product names change often, so verify specifics before relying on them. ClavionX capability status is taken from its public docs and feature matrix. I work on ClavionX.