What is Microsoft Entra?

What is Microsoft Entra?

Microsoft Entra is not a single product. It is the umbrella brand Microsoft uses for its identity and network access portfolio - a family of services that together answer the questions "who is signing in, what are they allowed to reach, and on what terms."

At the center sits Microsoft Entra ID, the directory of users, groups, and applications that the rest of Microsoft's cloud already runs on. Around it sit the products that extend the model into adjacent problems: governing access to those identities, federating with external ones, granting network access to private and internet resources, managing permissions across multiple clouds.

Microsoft Entra is a family of identity and network access products that helps organizations implement a Zero Trust security strategy.- Microsoft Learn

If you have ever signed into Microsoft 365, deployed something to Azure, or had a corporate laptop joined to your employer's cloud - you have used Entra. You may not have noticed, because for most of the last decade it was called something else.

Azure AD became Entra ID

The rebrand confuses everyone who started before 2023, so it is worth saying out loud: "Azure Active Directory" and "Microsoft Entra ID" are the same product. Microsoft renamed it as part of consolidating the identity family under the Entra umbrella.

Nothing changed about how the service works. The same tenants, the same app registrations, the same OIDC and OAuth endpoints, the same Microsoft Graph APIs. Documentation, blog posts, training material, and the Azure portal itself were updated; the underlying product is the same one that grew out of Azure AD.

The naming convention that follows from the rebrand is consistent. The umbrella is Microsoft Entra. The core directory product is Microsoft Entra ID. The sibling products all share the prefix - Entra External ID, Entra ID Governance, Entra Permissions Management, and so on.

The Entra family

The product family spans identity, access, governance, and network. Each member solves a distinct piece of the access problem; together they form what Microsoft calls a "trust fabric."

Not every organization uses every product. Most start with Entra ID - because Microsoft 365 or Azure forces the issue - and add others as the problems they cover become real.

Going deeper? For a panel per product - what each one actually does, the problem it solves, and when you'd reach for it - read The Entra Family, the field-guide companion to this article.

Entra ID at the center

If you only learn one piece of Entra at first, learn Entra ID. Everything else assumes it. The pieces you spend time on:

• Tenant. Your dedicated instance of Entra ID - a directory of users, groups, and app registrations. Every organization has at least one.
• Users and groups. Identities that sign in, and the collections you assign permissions to instead of assigning them one-by-one.
• App registrations. One per application or API that authenticates against your tenant. Holds the client ID, the redirect URIs, the API scopes the app exposes or consumes.
• Service principals. The runtime identity of an app inside your tenant. The app registration is the template; the service principal is the instance that holds the permissions you grant.
• Managed identities. Service principals that Azure manages for you, attached to a virtual machine, function app, or container. No secrets to rotate.
• Conditional Access. The policy engine that decides who gets in. "If the user is in this group and on an unmanaged device and outside the corporate network, require MFA." All sign-ins flow through it.
• Roles and RBAC. Built-in and custom roles that grant administrative or application-specific permissions, scoped to the tenant, a subscription, a resource group, or a single resource.

These primitives appear in every Entra product. External ID adds an external tenant configuration on top of them; ID Governance adds workflow on top of them; Permissions Management discovers and reduces them. The vocabulary is shared.

The Zero Trust framing

The pitch Microsoft repeats in every Entra doc is Zero Trust. The short version: never trust the network you are on. Verify the identity, verify the device, verify the context, on every request - not once at the firewall.

Entra is how that policy is enforced in practice. Each product owns one verification:

You can adopt Entra without buying the Zero Trust pitch wholesale - most teams do. But the framing explains why the product family is shaped the way it is, and why so much of the docs talks about it.

Admin and developer surfaces

Two surfaces matter to anyone working with Entra day-to-day.

The Microsoft Entra admin center at entra.microsoft.com is the dedicated portal for the family - users, groups, app registrations, Conditional Access policies, external identities, and the rest. Most things in the Entra family are also reachable from the Azure portal under the "Microsoft Entra ID" blade, but the dedicated admin center is the one Microsoft actively designs around now.

The Microsoft identity platform is the developer surface - the OAuth 2.0 and OpenID Connect endpoints your app code calls, plus the official client libraries (MSAL for the major languages) that wrap them. Microsoft Graph is the unified REST API for almost everything inside Entra - reading users, creating groups, listing sign-in logs, managing app registrations, querying External ID flows, the lot. If you can do it in the admin center, there is a Graph endpoint behind it.

The lesson here for newcomers: when an Entra doc says "you can automate this with Graph," it means the same Graph - one API surface for the whole family, one auth contract, one set of SDKs.

You're probably already using it

Entra is foundational to most of Microsoft's cloud, which means it is mostly invisible until you go looking for it. Some places it is already in your stack:

• Microsoft 365. Every Microsoft 365 tenant is backed by an Entra ID tenant. Your users, groups, and Conditional Access live in the same directory as your mailboxes.
• Azure. Every Azure subscription trusts an Entra tenant for sign-in and RBAC. Your `az login` flow is an OIDC authorization against Entra ID.
• SaaS apps. The "Sign in with Microsoft" button on third-party SaaS is OIDC or SAML federation with Entra ID, scoped to the customer's tenant.
• Corporate device sign-in. Windows 11 devices joined to a workplace are Entra-joined; sign-in is to your Entra tenant.

If you are on the customer side of any of those, you have an Entra tenant whether you have opened the admin center or not. The next step is usually less about "should we use Entra" and more about "which Entra products do we need beyond ID."

For the rest of this article series, two directions worth following from here:

• What is Microsoft Entra External ID? - the External ID half of the family, for customers and B2B guests rather than employees.
• What is Azure Active Directory B2C? - the legacy CIAM service that External ID now replaces for new builds.