Learn

Entra Foundation

Microsoft Entra is the identity authority in this topic, not the full runtime platform. It owns tenants, identities, groups, application registrations, role assignments, provisioning configuration, and the administrative surfaces used to govern them. The rest of the Azure platform shows up when those identity decisions need compute, storage, messaging, analytics, or private connectivity to become a working system.

This page sets the mental model for the rest of the topic: treat Entra as the control surface for identity, treat Microsoft Graph as the programmable API over that control surface, then add Azure infrastructure only when the workload needs somewhere to run, persist, queue, stream, or inspect data.

Where Entra Sits In The Family

Microsoft Entra is a family brand, not a single feature. In practice, builders most often encounter:

  • Microsoft Entra ID for workforce identity, applications, groups, and directory-backed access decisions.
  • Microsoft Entra ID Governance for lifecycle governance, access reviews, entitlement management, and related controls.
  • Microsoft Entra Verified ID for verifiable credentials and decentralized identity scenarios.
  • Microsoft Entra Internet Access and Microsoft Entra Private Access for network access controls under the Global Secure Access umbrella.

This topic is mostly about Microsoft Entra ID and the Azure services that usually surround systems built on top of it. It does not try to cover the full Entra family in product depth.

Identity Control Plane vs Workload Infrastructure

The most useful boundary is this one:

  • Identity control plane: tenant configuration, users, groups, applications, service principals, provisioning jobs, audit records, directory policies, and admin actions that live inside Entra and are usually reached through the Entra admin center or Microsoft Graph.
  • Azure workload infrastructure: functions, queues, topics, streams, databases, storage accounts, analytics clusters, VMs, VNets, and private connectivity that run the supporting automation around those identity objects.

For example, creating a group in Entra is a control-plane action. Starting a worker that notices the new group, enriches metadata, stores reconciliation state, sends commands to downstream systems, and writes operational telemetry is workload infrastructure.

Where The Entra Admin Center Intersects With Azure

The Entra admin center is where operators configure identity behavior, but many real systems cross into Azure-hosted components immediately after that configuration is saved.

Common intersections include:

  • A provisioning job in Entra updates users or groups, and Azure-hosted workers pull status, reconcile mismatches, or react to failures.
  • Administrators create or update applications, groups, or directory settings, and a Graph-driven automation pipeline in Azure Functions applies companion changes elsewhere.
  • Hybrid sync or provisioning components need private reachability to on-premises systems, which pushes the design into VNets, private endpoints, or VM-hosted agents.
  • Operational teams need to inspect large event or log volumes, which pushes diagnostic data into Azure Data Explorer rather than keeping everything inside the Entra portals.

The portal is therefore the administrative start point, not the whole system boundary.

The Builder Mental Model

Use this topic’s pages with a simple sequence in mind:

  1. Entra defines the identity source of truth for the part of the system you are automating.
  2. Microsoft Graph exposes the programmable surface for reading and changing that state.
  3. Azure compute runs the automation that calls Graph or responds to related events.
  4. Messaging and streaming shape the workload depending on whether you need durable coordination or high-throughput event handling.
  5. Datastores hold the surrounding state that Entra does not model for you, such as checkpoints, job progress, reconciliation results, or exported artifacts.
  6. Networking and machine boundaries appear only when required by hybrid targets, locked-down systems, or software that cannot run comfortably in the default serverless model.

That model keeps the topic bounded. If a service does not help explain one of those six layers, it is probably outside scope.

What Entra Does Not Give You

Entra handles identity data and policies, but it does not replace general application infrastructure. It does not give you:

  • A general-purpose workflow engine for custom downstream jobs.
  • Durable queue semantics for your own worker coordination.
  • Arbitrary state storage for onboarding pipelines or reconciliation records.
  • A streaming backbone for high-volume telemetry.
  • Full network isolation for hybrid agents that need to reach private systems.

That is why Azure Functions, Service Bus, Event Hubs, Cosmos DB, Storage, Data Explorer, and VM or networking choices appear around Entra-backed systems.

Where To Go Deeper

When the problem shifts from platform architecture into product-specific sync or provisioning behavior, use the local Entra topics that already cover that depth:

The rest of this topic assumes those systems exist, then explains the Azure platform pieces that commonly surround them.