The Entra ID Security Stack

Seven components, one signal-and-enforcement chain

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. EI12 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 and EI10 cover application and workload identity governance.

How the chain works in practice

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.

Navigating the Entra admin center

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.

Protect & secure (Identity → Protect & secure) 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. EI13 and EI14 build detection and monitoring on top of them.

Identity governance contains PIM, access reviews, entitlement management, and lifecycle workflows. EI6 and EI12 operate here.

Applications (Identity → Applications) contains app registrations with credentials, permissions, and owners, plus enterprise applications with consent grants and sign-in activity. EI9 and EI10 operate 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. EI14 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 EI13-14 teach you to build detection rules on top of them.

Deployment priority sequence

When you reach EI17, you'll design the complete identity 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 and EI10.

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. This is EI13 and EI14.

Licensing: what enables what

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. EI17 provides deployment architecture guidance for each tier in production environments.