Entra ID Identity Architecture

Identity is the control plane

In traditional network security, the network was the control plane. You controlled access by controlling the network — firewalls, VLANs, network segmentation, VPN tunnels. If you were on the right network segment, you had access. If you weren't, you didn't. The network boundary was the security boundary.

That model is gone. Your users authenticate from home networks, coffee shops, airport WiFi, and mobile networks. Your data lives in SharePoint Online, OneDrive, Teams, and Exchange Online — accessible from any network with an internet connection. Your applications are SaaS services that don't know or care what network the user is on. The network still matters for some things, but it is no longer the control plane for access decisions.

Identity replaced it. In M365, every access decision flows through Entra ID. When a user opens Outlook, Entra ID authenticates them. When they access a SharePoint site, Entra ID authorizes them. When Conditional Access evaluates whether to grant or block a sign-in, it evaluates identity signals — who the user is, what authentication method they used, what device they're on, what their risk level is. When PIM decides whether to activate a privileged role, it evaluates the identity requesting activation. When DLP decides whether to block a file share, it evaluates the identity's sensitivity label entitlements. When Sentinel detects an anomalous sign-in, the anomaly is defined against the identity's behavioral baseline.

Identity is not one component of the security architecture. It is the component that every other component depends on. If the identity layer is poorly designed — if identity types aren't categorized, if hybrid sync is misconfigured, if the directory is flat with no administrative boundaries, if stale identities accumulate unchecked, if groups are ungoverned — then every security control built on top of it inherits those weaknesses.

This is why identity is Module 1. Not because it's simple (it isn't), or because it's where Microsoft's documentation starts (it does, but for different reasons), but because every decision you make in MSA2 through MSA14 operates within the identity architecture you design here. Conditional Access policies target identity groups. Privileged access management governs identity roles. Detection rules monitor identity behavior. Governance reviews identity access. If the identity layer doesn't have the structure, the naming, the lifecycle management, and the group architecture that those modules require, you'll be retrofitting the foundation while trying to build the house.

What identity architecture means in practice

An M365 tenant contains far more identities than user accounts. Your tenant has cloud-only user accounts for employees who joined after the cloud migration. It has synced accounts for employees whose identities originated in on-premises Active Directory and were replicated to Entra ID via Cloud Sync. It has guest accounts for suppliers, auditors, and contractors who need access to specific SharePoint sites or Teams channels. It has application registrations and service principals for line-of-business applications, automation scripts, and third-party integrations. It has managed identities for Azure workloads that authenticate to other Azure services without credentials.

Each of these identity types authenticates differently. Cloud-only users authenticate directly against Entra ID. Synced users authenticate against Entra ID using password hashes replicated from on-premises AD. Guest users authenticate against their home tenant and present a cross-tenant token. Application registrations authenticate using client secrets, certificates, or federated credentials. Managed identities authenticate using Azure-issued tokens that never leave the Azure fabric.

Each type has a different attack surface. Cloud-only users are vulnerable to password spray and AiTM phishing. Synced users inherit every vulnerability of the on-premises AD — if an attacker compromises a domain controller and extracts password hashes, every synced identity is compromised. Guest users create cross-tenant trust relationships that attackers can exploit for lateral movement — CVE-2025-55241 demonstrated that guest identity attributes could be used to impersonate users across tenant boundaries. Workload identities are the fastest-growing attack vector — recent research indicates that over 60% of cloud breaches now involve compromised non-human identities, not human user accounts.

Each type requires different architectural treatment. You don't manage a service principal the same way you manage a user account. You don't govern a guest identity the same way you govern an employee. You don't detect anomalies in a managed identity's behavior the same way you detect anomalies in a human user's sign-in patterns. The identity architecture must account for every type, with specific controls, specific monitoring, and specific lifecycle management for each.

That's what this module teaches. Not how to create user accounts — Microsoft Learn covers that. Not how to configure Entra Connect — the setup wizard handles that. But how to design an identity layer where every identity type is categorized, every hybrid sync decision is documented, every administrative boundary is deliberate, every lifecycle stage is automated or governed, every naming convention enables discoverability, and every group serves a specific architectural purpose. The identity layer you build here is the foundation that makes every subsequent module possible.

The identity decisions that shape everything downstream

Identity architecture isn't one decision. It's a chain of connected decisions, each constraining what's possible in the next module. Understanding these dependencies before you start designing helps you see why Module 1 matters for Module 14.

Tenant architecture (MSA1.1) determines the scope of every security control. A single tenant means one Conditional Access framework, one PIM configuration, one Sentinel workspace. A second tenant means duplicating every control with cross-tenant complexity. This decision constrains MSA3 (CA scope), MSA4 (PIM scope), MSA8 (Sentinel scope), and MSA12 (governance scope).

Identity type categorisation (MSA1.2–1.3) determines what Conditional Access can target. CA policies evaluate different identity types differently — member users, guest users, and workload identities each have different policy evaluation paths. If you haven't inventoried and categorized your identity types, your CA policies in MSA3 will have blind spots.

Hybrid identity decisions (MSA1.4–1.5) determine the authentication methods available in MSA2. Password hash sync enables cloud-based authentication and Identity Protection risk detection. Pass-through authentication routes authentication to on-premises agents. Federation delegates authentication entirely. Each choice has different security properties, different attack surfaces, and different failure modes that MSA2's authentication architecture must account for.

Administrative Unit structure (MSA1.6) determines the delegation model for MSA4's privileged access architecture. Without AUs, every admin role has tenant-wide scope. With AUs, you can scope administration to specific sites, departments, or populations — enabling least-privilege administration that MSA4 designs.

Identity lifecycle (MSA1.7–1.8) determines the baseline for MSA12's governance architecture. If joiners are provisioned manually, movers accumulate access, and leavers aren't cleaned up, then MSA12's access reviews and lifecycle workflows are remediating a broken foundation rather than maintaining a healthy one.

Naming conventions and group architecture (MSA1.9–1.10) determine the operability of everything built on top. CA policies target groups. PIM assigns roles to groups. DLP scopes to groups. Sentinel queries filter by group membership. If groups are ungoverned — inconsistent naming, overlapping membership, no documented purpose — then every module that references groups is referencing chaos.

What you'll build in this module

Twelve subsections, each teaching one architectural decision area. Then a lab that builds the baseline, and a guided walkthrough that connects every concept end to end. By module end, your architecture package contains:

3–4 Architecture Decision Records. Tenant architecture (single-tenant rationale for NE). Identity type governance (policies per identity category). Hybrid identity architecture (Cloud Sync with PHS, migration plan for legacy components). Administrative Unit structure (site-based delegation model).

Identity topology diagram. A visual representation of the organization's identity layer — user types, sync flows, guest access patterns, workload identities, administrative boundaries. The diagram you present when explaining the identity architecture to the CISO or an auditor.

Risk register entries. One entry for each identity gap: the stale sync server that hasn't been decommissioned, unreviewed guest accounts, app registrations with no credential rotation, the flat directory with no AU boundaries, the absent lifecycle automation.

A working identity baseline in your lab. The developer tenant configured with the organization's persona groups, Administrative Units, naming conventions, and the intentional gaps you'll diagnose and remediate.

The NE identity layer — what you're inheriting

your organization's identity layer is what happens when an M365 tenant grows for five years without architecture. The gaps are familiar — you'll recognize them from your own environment.

The tenant is a single tenant, which is architecturally correct for NE, but nobody documented why. When the CISO asks whether NE should create a separate tenant for a potential acquisition, there's no ADR to reference — the decision was made by default, not by design.

User accounts exist, but nobody has categorized them. Some are cloud-only (created after the M365 migration). Some are synced from on-premises AD via Cloud Sync. Nobody can produce a count of each type without running a query. The identity census doesn't exist.

The hybrid identity configuration migrated from legacy Entra Connect to Cloud Sync eight months ago, but the old sync server hasn't been decommissioned. Its service account still exists in both AD and Entra ID. Nobody disabled it. If an attacker compromises that server, they have a service account with directory synchronization permissions — and nobody is monitoring it because it's supposed to be retired.

Guest accounts represent suppliers, auditors, contractors, and project collaborators from the past five years. Some are active. Some belong to people who completed their work and left. Nobody reviews them. Each one is an external identity with access to your organization's resources — and each one's home tenant is a trust relationship accepted without documenting the risk.

34 application registrations and 12 service principals exist for integrations, automation, and third-party applications. Many were created during initial M365 deployment or by developers building internal tools. Credential rotation isn't tracked. Permission scopes haven't been reviewed. Some registrations still have client secrets from 2022 — four years without rotation.

No Administrative Units exist. Every admin role has tenant-wide scope. A Helpdesk Administrator can reset any user's password in any site. An Exchange Administrator can manage any mailbox. There's no delegation boundary between the Manchester head office and the five regional sites.

No lifecycle automation exists. Joiners are provisioned manually by the IT team. Movers change role and keep their old group memberships, app access, and SharePoint permissions — access accumulates until someone notices (which is rarely). Leavers are disabled but not deleted, and their group memberships and app access aren't revoked — creating stale identities with residual access.

No naming convention exists. Security groups are named by whoever created them — IT-Admins, AdminGroup, SG_GlobalAdmins, GlobalAdmins-All, ga-admins. Five groups for approximately the same purpose, created at different times by different people, with overlapping but non-identical membership. Nobody knows which one is authoritative.

This is the starting state. By the end of this module, every one of these gaps will be diagnosed, documented, and architecturally addressed — with ADRs, risk register entries, and a working lab baseline that MSA2 builds on.