The Entra ID Security Stack

Introduction

Seven components is a list, and a list is the least useful thing to know about them. This section is how they connect. You will finish able to describe the estate as a signal-and-enforcement chain, and to say which link a given weakness breaks.

Entra ID is not a single security product. It is a platform of interconnected components that authenticate users, enforce access policies, detect threats, govern access, and protect privileged identities. Understanding how they feed data to each other is what separates an administrator who configures individual settings from an engineer who designs an integrated defense.

Conditional Access is the policy engine at the center of everything. It evaluates every sign-in against policies that consider who is signing in, what they're accessing, from which device, from which location, and at what risk level. Conditional Access consumes signals from Authentication Methods, Identity Protection, device compliance, and named locations. It then makes an enforcement decision: grant, block, or require additional controls. Every other component either feeds signals into Conditional Access or is enforced by it. EI3, EI4, and EI8 cover Conditional Access in depth.

Identity Protection is the risk detection engine. It evaluates every sign-in and every user account for suspicious behavior using machine learning trained on Microsoft's 1.2 billion daily authentications. It produces two risk scores, sign-in risk and user risk, that feed directly into Conditional Access policies. A sign-in from an unusual location at an unusual time can trigger additional MFA or a block without requiring a static rule for every scenario. As of mid-2026, risk policies are migrating from the Identity Protection blade to Conditional Access. EI5 covers both the current configuration and the transition.

Authentication Methods determine the quality of the initial authentication. The strength of the method determines which attacks are possible. Password plus SMS MFA can be defeated by AiTM. Password plus push notifications can be defeated by MFA fatigue. FIDO2 and passkeys are phishing-resistant, they cryptographically verify the domain. EI2 covers the full method hierarchy and deployment planning.

PIM provides just-in-time access for administrative roles. Instead of permanent Global Administrator assignments, PIM makes privileged roles eligible: the user activates the role with additional verification for a limited time. This reduces the attack surface because privileges exist only when actively needed. EI6 covers PIM design and monitoring.

Token Protection binds tokens to the device that completed the authentication. If an attacker captures a token and replays it from a different device, validation fails. This directly mitigates the most dangerous phase of AiTM attacks. EI7 covers token security.

Identity Governance provides access reviews, entitlement management, and lifecycle workflows that ensure access remains appropriate over time. Users accumulate permissions as they change roles: a pattern called "permission creep" that creates a steadily growing attack surface. Governance automates the review and removal of stale access. ARC406 covers governance design.

Application and Workload Identity Security covers service principals, managed identities, and application registrations, non-human identities that often have broad permissions and no MFA. These are the fastest-growing attack surface in most tenants. EI9 covers application identity governance, and workload identity is ARC406. governance.

Which tier you hold decides how much of that is available to you at all.

  Authentication methods  HOW the user proved it      ei02
  Conditional Access      the DECISION                ei03
  Identity Protection     a RISK LEVEL from context   ei05
  PIM                     what may be ASKED FOR       ei06
  Sign-in and audit logs  the RECORD                  ei01
  App and workload ID     identities with no user     ei09, ei10
  Governance              whether access should exist ei12

Only one of those seven makes a decision. Conditional Access reads everything else and is read by nothing, which is why it looks like the center of the stack and why treating it as the whole of the stack is the commonest architectural mistake in this space.

The rest divide into two kinds. Authentication methods, Identity Protection and the workload identities supply facts to the decision. Governance and PIM constrain what could have been asked for before the decision is reached at all.

The logs are the odd one out and worth naming as such: the only component that produces nothing at the moment of the sign-in and everything afterwards. Per ei01 that makes them worthless to prevention and indispensable to everything else, which is why they are module 1 rather than an appendix.

Separating the one decision-maker from the six fact-suppliers is what makes the stack legible. Conditional Access is the only component that acts, and everything else either feeds it or writes down what it did, which is why a weakness anywhere upstream reaches the decision without ever looking like a failure.

The components form a signal-and-enforcement chain where a weakness at any point undermines the entire system. Trace how the chain processes a single sign-in.

A user opens Outlook from their corporate laptop at 9:15 AM. The application redirects to Entra ID. The user authenticates with a FIDO2 security key, that fact is recorded as authenticationMethod: "FIDO2 security key" in the sign-in log. Identity Protection evaluates the context: familiar IP address, familiar device, familiar application, normal time of day. Risk assessment: none. Device compliance reports the laptop meets all Intune policies: encrypted, patched, EDR running. Named locations confirm the IP is in a trusted corporate range.

Conditional Access evaluates all applicable policies. Policy 1 ("Require MFA for all users"), satisfied, FIDO2 is phishing-resistant MFA. Policy 2 ("Require compliant device for Office 365"), satisfied, device is compliant. Policy 3 ("Block access from non-trusted locations for admin roles"), not applicable, this user is not in an admin role. Result: grant access with token protection session control applied. The access token is issued and cryptographically bound to this specific device.

Now trace the same chain when the attack from Section 0.1 occurs. An attacker replays a stolen session token from an unmanaged device in another country. Authentication Methods signal: the token was originally issued after push notification MFA, phishable, not phishing-resistant. Identity Protection evaluates: unfamiliar IP, unfamiliar location, atypical travel pattern. Risk assessment: medium. Device compliance: the attacker's device is not enrolled in Intune: no compliance data available. Named locations: the IP is outside all trusted ranges.

Conditional Access evaluates. Policy 2 ("Require compliant device"): the device is not compliant and compliance data is unavailable. Result: block. The attacker is denied access. If that policy didn't exist, if compliance was only required for "sensitive applications" and the attacker targeted Exchange Online which wasn't classified as sensitive: the chain has a gap, and the attack succeeds despite Identity Protection flagging medium risk.

This is why gap analysis matters as much as component configuration. A Conditional Access policy that covers 90% of applications leaves the remaining 10% unprotected. An authentication method policy that deploys FIDO2 to administrators but leaves standard users on push notifications means the standard users are the attack path. The chain is only as strong as its weakest link.

That recorded method is what every later link reads, which is the dependency the diagram does not show. A weak method does not stop the sequence; it feeds a weaker fact into a decision that runs exactly as designed.

Read the three "breaks if" lines together, because none of them produces an error. A weak method still lets everything downstream run. A device that stopped reporting returns risk low rather than unknown, per ARC402 14.3. No policy matching is silence rather than a denial.

Each of the three produces a weaker or absent fact that the next link reads as true, and that is why a stack diagram with every box green tells you nothing. The failure mode of this architecture is not a component going down; it is a component answering confidently with less than it had.

  09:15:03  authentication      FIDO2, succeeded
  09:15:04  identity protection riskLevelDuringSignIn: none
  09:15:04  conditional access  notApplied
  09:15:05  token issued        access + refresh
  ------------------------------------------------------------
  the middle two rows are the ones to read. neither is an error.

The pattern down the failure lines is the reason a component list misleads. A broken link in this chain does not stop the chain, it feeds the next link a fact that is weaker than it looks, so the sign-in completes, the log records a success, and the weakness is only visible if you know which link was supposed to have said something stronger.

The Entra admin center at entra.microsoft.com is organized into navigation sections. For identity security work, four areas account for the majority of your time.

Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy |
    Select-Object displayName, state,
        @{n='Grant';e={$_.GrantControls.BuiltInControls -join ','}},
        @{n='Users';e={$_.Conditions.Users.IncludeUsers -join ','}}

The blade shows a list you scroll and Graph shows a list you can count. Per ei03 3.1 the order in that blade means nothing to evaluation, which is easier to believe once you have seen the same set arrive with no ordering at all.

Protection (Identity → Protection) contains Conditional Access policies, named locations, Identity Protection with risky users and risky sign-ins, authentication method policies, registration campaigns, and security configuration. Modules EI2 through EI8 operate primarily in this area.

Monitoring & health (Identity → Monitoring & health) contains sign-in logs across four tabs (interactive, non-interactive, service principal, managed identity), audit logs recording every administrative action, and diagnostic settings for routing logs to Sentinel or Log Analytics. EI1 teaches you to read these logs. ARC406 builds detection and monitoring on top of them.

Identity governance contains PIM, access reviews, entitlement management, and lifecycle workflows. EI6 operates here; lifecycle governance is ARC406.

Applications (Identity → Applications) contains app registrations with credentials, permissions, and owners, plus enterprise applications with consent grants and sign-in activity. EI9 operates here.

For identity security work, you need appropriate admin roles. Security Administrator provides read/write access to Conditional Access, Identity Protection, authentication methods, and security-related settings. Security Reader provides read-only access to the same areas, sufficient for monitoring and investigation. Privileged Role Administrator is required for PIM configuration. Global Reader provides read-only access to everything in the tenant. The course labs use Global Administrator in the developer tenant for simplicity, but EI6 covers the principle of least privilege and the specific roles needed for each operational task.

Every operation the admin center performs uses the Microsoft Graph API. For security operations at scale, querying sign-in logs across thousands of events, exporting Conditional Access policies for backup, auditing application permissions across hundreds of registrations, you need programmatic access. The Microsoft Graph PowerShell SDK provides cmdlet access to every Entra ID operation. Key commands include Get-MgAuditLogSignIn for sign-in log queries, Get-MgIdentityConditionalAccessPolicy for policy export, Get-MgApplication for app registration audit, and Get-MgRiskyUser for programmatic risk triage. KQL in Log Analytics provides the analytical query layer for Sentinel-connected environments. This course teaches both approaches: portal for where things are, Graph and KQL for how to operate at scale.

// Verify your identity logs are flowing to Sentinel
// Each table should return at least 1 row
union withsource=TableName
    (SigninLogs | where TimeGenerated > ago(1h) | take 1),
    (AuditLogs | where TimeGenerated > ago(1h) | take 1),
    (AADNonInteractiveUserSignInLogs | where TimeGenerated > ago(1h) | take 1)
| project TableName, TimeGenerated
// Missing tables = diagnostic settings need configuration
// All 3 present = your identity telemetry pipeline is working

This query confirms that the three critical identity log tables are ingesting into your Sentinel workspace. SigninLogs captures interactive authentication. AADNonInteractiveUserSignInLogs captures background token refreshes and service-to-service calls. AuditLogs captures directory changes, role assignments, policy modifications, consent grants. If any table is missing, your diagnostic settings in the Entra admin center need configuration. ARC406 covers the complete log routing architecture.

Every configuration change in Entra ID produces an audit log entry. When you modify a Conditional Access policy, assign a directory role, or approve an application consent, the AuditLogs table records who made the change, what changed, and when. This is what a role assignment looks like in the raw data:

{
  "ActivityDisplayName": "Add member to role",
  "Category": "RoleManagement",
  "Result": "success",
  "InitiatedBy": {
    "user": {
      "userPrincipalName": "admin@contoso.onmicrosoft.com",
      "displayName": "Global Admin"
    }
  },
  "TargetResources": [
    {
      "displayName": "Alex Security",
      "userPrincipalName": "alex.security@contoso.onmicrosoft.com",
      "modifiedProperties": [
        {
          "displayName": "Role.DisplayName",
          "newValue": "\"Security Administrator\""
        }
      ]
    }
  ],
  "ActivityDateTime": "2025-11-14T09:23:17Z"
}

The audit log is how you detect unauthorized changes, role assignments you didn't approve, policy modifications during off-hours, consent grants for applications you've never seen. Every governance control in this course produces audit log entries, and ARC406 teaches you to build detection rules on top of them.

By EI9 you will have read every layer of this stack. The complete architecture design sits in ARC406. security architecture for your environment. But even at this stage, the deployment priority is clear, and it matches the course module sequence. The ordering isn't arbitrary: each priority enables the next.

The first priority is authentication methods and legacy authentication blocking. Deploy Authenticator with number matching at minimum, and begin FIDO2 or passkey rollout for administrative and high-value accounts. Block legacy authentication protocols. IMAP, POP3, SMTP AUTH, ActiveSync with basic auth, which bypass MFA entirely and account for the majority of successful password spray attacks. This eliminates the two most common attack paths and can be completed in weeks, not months. This is EI2.

The second priority is Conditional Access foundation policies. Require MFA for all users on all cloud applications: no exceptions except break-glass accounts. Require compliant or hybrid-joined devices for Office 365 access. Block access from countries where you have no operations. These three policies close the broadest gaps with the least complexity. This is EI3 and EI4.

The third priority is Identity Protection and risk-based policies. Once Conditional Access is in place, enabling risk-based policies makes your access decisions adaptive, they respond to suspicious behavior in real time without requiring a static rule for every scenario. When Identity Protection detects a medium-risk sign-in, Conditional Access can require re-authentication with a phishing-resistant method. When user risk is elevated, Conditional Access can require a password change. This is EI5.

The fourth is privileged access protection through PIM. Convert permanent Global Administrator and Security Administrator assignments to eligible roles that require explicit activation with additional verification. Add Conditional Access policies that require phishing-resistant MFA from compliant devices for all admin portal sign-ins. Monitor role activations and changes through audit log queries. This is EI6.

The fifth is application and workload identity governance, where most organizations have the largest blind spots. Hundreds of application registrations accumulate stale credentials, excessive permissions, and no owner accountability. Service principals run with broad permissions and no MFA. Consent grants from years ago persist without review. This is EI9.

The sixth is detection engineering and operational monitoring. Once preventive controls are deployed, you build the detection rules and monitoring workflows that verify the controls work and catch anything that slips through. That is ARC406.

Step 1 is first for two reasons and both are consequences of the dependency above. Deploying Conditional Access over weak methods enforces decisions made on a weaker fact, so the policy works and protects less than it appears to. And legacy authentication bypasses Conditional Access entirely, which means a policy deployed before the block protects only the traffic that was already going to be evaluated.

Steps 3 and 4 are ordered by what makes the previous one usable. A risk signal is only actionable once a policy exists that can read it. Reducing what a compromised identity can reach matters after you are able to detect the compromise at all.

Step 1 is the one people skip, and the reason is not technical: Conditional Access is the component with a dashboard.

The note at the bottom is the ordering mistake this sequence exists to prevent. Legacy authentication bypasses Conditional Access rather than failing it, so a policy deployed before the block is evaluated only against traffic that was never the problem, and the dashboard reports coverage over exactly the population that did not need it.

Not every component is available at every license tier, and understanding this prevents the frustration of designing an architecture your license doesn't support.

Entra ID Free (included with every M365 subscription) provides basic authentication, MFA with Security Defaults, and sign-in logs with 7-day retention. It does not provide Conditional Access, Identity Protection, PIM, or advanced audit logging. This tier is insufficient for any organization with security responsibilities beyond the smallest.

Entra ID P1 (included with M365 E3, or available standalone) provides Conditional Access, custom banned password lists, self-service password reset, and token protection. This is the minimum tier for meaningful identity security: the point where you can enforce granular access policies rather than relying on Security Defaults.

Entra ID P2 (included with M365 E5, or available standalone) adds Identity Protection with risk-based Conditional Access, PIM for privileged roles, access reviews, and entitlement management. This tier enables the full adaptive security model where access decisions respond to real-time risk signals.

Workload Identities Premium (separate license) adds Conditional Access for workload identities and health monitoring for service principals. Entra ID Governance (separate license or included in Entra Suite) adds lifecycle workflows, advanced access reviews, and entitlement management for external users. The developer tenant you use for labs includes E5 licensing, so you have access to every component. ARC406 provides deployment architecture guidance for each tier in production environments.

Seven days is the number to notice, and it is easy to read past. Per ARC402 11.1, retention is the one telemetry property that cannot be fixed after you need it: an investigation into last month has nothing to read, and no amount of budget approved during the incident changes that.

The paid tiers add Conditional Access, risk-based policies, PIM, access reviews and longer retention. Which feature sits at which tier moves, so verify against current Microsoft documentation before designing against it rather than against this page.

The rule that outlasts the tier names: design against what you have. An architecture requiring a component your tier does not include is a proposal rather than a design, and the difference usually surfaces at the point somebody tries to build it.

The retention line is the one with a deadline attached. Seven days means every question about last month is already unanswerable, and unlike a missing policy that gap cannot be closed retrospectively, which makes it the licensing consequence to raise first rather than the feature list.

The chain is easier to audit than the components, because a chain has a first weak link and a component list does not.

Seven components is a list, and what matters is that they form a signal-and-enforcement chain: the authentication method is recorded, Identity Protection turns context into a risk level, Conditional Access reads both and decides, and token issuance turns that decision into a bearer credential. The useful property is how the chain fails. A weak link does not stop it, it hands the next link a fact that is weaker than it looks, so the sign-in succeeds and the log records success. That also forces the deployment order: methods first, because every later link reads the method, and because legacy authentication bypasses Conditional Access rather than failing it. Check the license tier before designing, since not every component exists at every tier.