Your organization has an E5 license but is using Entra ID primarily for user management and basic MFA. Leadership asks what identity security capabilities are available and which should be prioritized. You need to map the complete Entra ID security stack — not just what each component does, but how they work together as an integrated defense system and what sequence to deploy them in.
Deliverable: A clear map of every identity security component in Entra ID — what it does, what license unlocks it, and how it integrates with the other components — so you can design a deployment plan and justify the investment.
⏱ Estimated completion: 12 minutes
The components and how they connect
Entra ID is not a single security product. It is a platform of interconnected components that work together to authenticate users, enforce access policies, detect threats, govern access, and protect privileged identities. Understanding what each component does — and crucially, how they feed data to each other — is the foundation for designing an identity security architecture that works as a system rather than a collection of disconnected settings.
Conditional Access is the policy engine at the center of everything. It evaluates every sign-in against a set of policies that consider who is signing in, what they are accessing, from which device, from which location, and at what risk level. Conditional access consumes signals from Authentication Methods (how the user proved their identity), Identity Protection (the risk level of this sign-in), device compliance (from Intune), and named locations (network context). It then makes an access decision: grant, block, or require additional controls. Every other component either feeds signals into conditional access or is enforced by conditional access. Modules EI3, EI4, and EI8 cover conditional access in depth.
Expand for Deeper Context
Identity Protection is the risk detection engine. It uses machine learning to evaluate every sign-in and every user account for suspicious behavior. It produces two risk scores — sign-in risk (how suspicious is this specific authentication attempt) and user risk (how likely is it that this user account has been compromised). These risk scores feed directly into conditional access policies, enabling adaptive access decisions: a sign-in from an unusual location at an unusual time can trigger additional MFA or be blocked entirely, without requiring a static policy for every scenario. Module EI5 covers Identity Protection configuration, tuning, and operationalization.
Authentication Methods are the credentials users present to prove their identity. The strength of the authentication method determines which attacks are possible. Password + SMS MFA can be defeated by AiTM phishing. Password + Authenticator push can be defeated by MFA fatigue. FIDO2 security keys and passkeys are phishing-resistant — they cryptographically verify the domain, so a fake sign-in page cannot capture the credential. Module EI2 covers the full method hierarchy and deployment planning.
Privileged Identity Management (PIM) provides just-in-time access for administrative roles. Instead of permanently assigning users to the Global Administrator or Security Administrator role, PIM makes those assignments eligible — the user must explicitly activate the role, with additional verification, for a limited time period. This reduces the attack surface of privileged accounts because the privileges only exist when they are actively needed. Module EI6 covers PIM design and monitoring.
Token Protection is a conditional access session control that binds authentication tokens to the specific device that completed the authentication. If an attacker captures a token through AiTM or malware and attempts to replay it from a different device, token protection causes the token validation to fail. This directly mitigates the most dangerous phase of AiTM attacks. Module EI7 covers token security comprehensively.
Identity Governance provides access reviews, entitlement management, and lifecycle workflows that ensure access remains appropriate over time. Users change roles, leave the organization, and accumulate permissions that they no longer need. Identity Governance automates the review and removal of stale access. Module EI12 covers governance design and compliance mapping.
Application and Workload Identity Security covers the non-human identities — service principals, managed identities, and application registrations — that often have broad permissions and no MFA. These identities are the fastest-growing attack surface in most tenants. Modules EI9 and EI10 cover application security and workload identity governance.
Sign-in logs and audit logs are the telemetry that makes everything verifiable. Every authentication attempt, every conditional access evaluation, every admin action, and every consent grant is recorded. Module EI1 teaches you to read these logs fluently, and modules EI13-EI14 teach you to build detection rules and monitoring workflows on top of them.
Defender XDR and Sentinel provide the correlation and response layer. Identity signals from Entra ID feed into the unified incident queue, where they are correlated with endpoint, email, and application signals. Module EI16 covers this integration.
How the components work together in practice
The components described above are not independent tools — they form a signal-and-enforcement chain where each component both consumes and produces data that other components use. Understanding this chain is what separates an administrator who configures individual settings from a security engineer who designs an integrated defense.
The chain works like this: Authentication Methods determine the quality of the initial authentication. A user authenticates with a FIDO2 key — that fact is recorded in the sign-in log's authentication details. Identity Protection evaluates the sign-in context — location, device, time, behavior patterns — and produces a risk score. Conditional Access consumes both signals (the authentication method strength and the risk level) along with device compliance state from Intune and network location from named locations. Based on all these signals, conditional access makes an enforcement decision: grant access, require additional verification, apply session controls (like token protection), or block.
Expand for Deeper Context
After access is granted, the enforcement continues. Token Protection binds the issued token to the device. Continuous Access Evaluation monitors for critical events (password change, user disable, risk elevation) and can revoke access mid-session. The sign-in log records the complete evaluation — which policies applied, what they decided, and why. If something goes wrong, these log entries become the detection telemetry for Sentinel analytics rules and Defender XDR alerts.
This means that a weakness at any point in the chain undermines the entire system. If authentication methods are weak (password + SMS), then Identity Protection can detect risk but conditional access cannot enforce phishing-resistant re-authentication because the user does not have a phishing-resistant credential registered. If conditional access policies have gaps (some applications not covered, some user groups excluded), then the enforcement decisions are incomplete regardless of how good the risk detection is. If sign-in logs are not being routed to a SIEM, then detection rules cannot fire regardless of how obvious the attack pattern is in the data.
Deployment priority sequence
When you reach EI17 (the capstone architecture module), you will design the complete identity security architecture for your environment. But even at this early stage, the deployment priority is clear:
The first priority is authentication methods and legacy authentication blocking. Deploying Authenticator with number matching (at minimum) and blocking legacy authentication protocols eliminates the two most common attack paths — MFA fatigue and password spray via legacy protocols. This can be done in weeks, not months, and has the highest security impact per hour invested.
Expand for Deeper Context
The second priority is conditional access foundation policies. Require MFA for all users on all applications, require compliant devices for sensitive applications, and block access from countries where you have no operations. These policies close the broadest gaps.
The third priority is Identity Protection and risk-based policies. Once you have conditional access in place, adding risk-based signals makes your policies adaptive — they respond to suspicious behavior without requiring static rules for every scenario.
The fourth priority is privileged access protection. PIM for Global Admin and Security Admin roles, conditional access policies that require phishing-resistant MFA from compliant devices for all admin sign-ins, and monitoring for role changes.
The fifth priority is application and workload identity governance. This is where most organizations have the largest blind spots — hundreds of application registrations with stale credentials, service principals with excessive permissions, and no consent governance.
The sixth priority is detection engineering and operational monitoring. Once the preventive controls are in place, you build the detection rules and monitoring workflows that verify the controls work and catch anything that slips through.
This course follows this deployment priority. The module sequence is not arbitrary — it mirrors the order in which you would deploy these controls in a production environment.
Licensing: what unlocks what
Not every component is available at every license tier. The licensing model determines what you can deploy, and understanding it prevents the frustration of designing a security architecture that your license does not support.
Entra ID Free (included with every M365 subscription) provides basic authentication, basic MFA with Security Defaults, and basic sign-in logs. It does not provide conditional access, Identity Protection, PIM, or advanced audit logging.
// EI0.3 — Are your identity logs flowing to Sentinel?
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
// Each table should return 1 row — confirming logs are ingesting
// Missing tables = diagnostic settings need configuration
Expand for Deeper Context
Entra ID P1 (included with M365 E3, Business Premium, or available as an add-on) provides conditional access, custom banned password lists, self-service password reset, and token protection. This is the minimum tier for meaningful identity security.
Entra ID P2 (included with M365 E5, or available as an add-on) adds Identity Protection (risk-based conditional access), PIM, access reviews, and entitlement management. This tier enables the full adaptive security model where access decisions respond to real-time risk.
Workload Identities Premium (separate license) adds conditional access for workload identities and workload identity health monitoring.
Entra ID Governance (separate license or part of Entra Suite) adds lifecycle workflows, advanced access reviews, and entitlement management for external users.
The developer tenant you use for labs includes E5 licensing, which means you have access to every component. For production deployment, EI17 provides architecture guidance for each license tier.
Try it yourself
Try It — Map Your Current Coverage
Environment: Your M365 developer tenant.
Exercise: Open the Entra admin center and navigate to each of the following areas. For each one, note whether it is configured or in its default state:
1. Identity → Protect & secure → Conditional Access — are any policies configured? 2. Identity → Protect & secure → Identity Protection — is it active with any risk policies? 3. Identity → Protect & secure → Authentication methods — which methods are enabled? 4. Identity governance → Privileged Identity Management — are any roles protected? 5. Identity governance → Access reviews — are any reviews configured? 6. Identity → Applications → App registrations — how many applications exist?
If most of these are in their default state, your tenant has the components available but not deployed. This course teaches you to deploy each one systematically — starting in EI2 with authentication methods and building through conditional access, Identity Protection, PIM, and governance.
⚠ Compliance Myth: "Security Defaults is sufficient for identity security"
The myth: Microsoft provides Security Defaults as a baseline. It requires MFA for all users. That is enough for most organizations.
The reality: Security Defaults provides a useful baseline for small organizations that have no security staff — it enables MFA, blocks legacy authentication, and protects admin accounts. But Security Defaults is a blunt instrument. It does not allow policy customization, does not provide risk-based access decisions, does not support device compliance requirements, does not offer session controls like token protection, and does not enable phishing-resistant authentication enforcement. For any organization with security responsibilities, conditional access policies (which require P1 licensing at minimum) replace Security Defaults with granular, verifiable, attack-specific controls. This course assumes conditional access rather than Security Defaults. Starting June 30, 2026, new tenants will have Security Defaults enabled by default for the first 90 days — but operational security requires moving to conditional access as soon as the organization has the licensing and the expertise.
Decision point
You are reviewing NE's Entra ID security posture. You find 4 accounts with Global Administrator role, but NE's policy says maximum 2. The extra 2 were added during the AiTM incident for emergency response and never removed. Do you remove them?
Remove them — but through the proper process, not unilaterally. Notify the account owners that their emergency GA assignment is being revoked, confirm they have their standard role assignments restored, and document the removal with the rationale ('emergency assignment during INC-NE-2026-0227-001, no longer required'). Then add a PIR action item: 'Implement PIM time-limited role assignments for future incident response — emergency GA assignments auto-expire after 8 hours rather than persisting indefinitely.' The stale emergency assignment is a governance failure, not a technical failure — the fix is procedural.
NE's Entra ID security audit reveals: 4 Global Administrators (policy says 2), 23 users with Global Reader from a completed project, a break-glass account with no monitoring rule, and 3 guest accounts with no expiry date. Which finding is the highest priority?
The 4 Global Administrators — 2 extra GAs doubles the attack surface.
The break-glass account with no monitoring rule. The 4 GAs and stale Global Readers are governance issues that should be remediated — but they are existing conditions, not active threats. The unmonitored break-glass account is a critical detection gap: if the break-glass account is compromised or misused, the SOC has no alert. A break-glass account is excluded from CA policies by design — it is the most powerful and least restricted account in the tenant. Without monitoring, its compromise or misuse is invisible. Deploy the monitoring rule (any sign-in to the break-glass account = Severity 1 alert) before addressing the other findings.
The 23 stale Global Readers — this is the largest number of affected accounts.
The 3 guest accounts — external accounts without expiry are the highest risk.
You've mapped the identity threat landscape and learned to read sign-in logs.
EI0 established that every cloud attack starts with identity. EI1 took you through the signal that matters most — interactive, non-interactive, service principal, and managed identity sign-ins. Now you engineer the defences.
