Your CISO asks you to justify an identity security investment. You need to explain — with evidence — why identity has become the primary attack surface, why network-centric defenses are insufficient for cloud environments, and which specific attack techniques are targeting Entra ID in production environments today. This subsection provides that evidence and the framework for understanding identity as the control plane that every other defense depends on.
Deliverable: A clear understanding of why identity is the dominant attack vector in cloud environments, the specific MITRE ATT&CK techniques that target Entra ID, and the security architecture shift that makes identity the most impactful area to invest in.
⏱ Estimated completion: 12 minutes
The perimeter that disappeared
The network perimeter model worked when every application ran inside a building and every user sat at a desk inside that building. A firewall at the edge controlled what came in and what went out. VPN extended the perimeter to remote users. Intrusion detection systems watched the traffic crossing the boundary. The security model was simple: inside is trusted, outside is untrusted, and the perimeter is where you enforce the rules.
That model is gone. Not weakened — gone.
When an organization moves to Microsoft 365, the applications live in Microsoft's datacenters. The data lives in SharePoint Online, Exchange Online, and OneDrive. The users authenticate through Entra ID from their homes, their phones, coffee shops, and airport lounges. There is no building to put a firewall around. There is no network boundary between the user and the data. The "perimeter" is the authentication point — the moment a user proves their identity and Entra ID decides whether to grant access.
Expand for Deeper Context
An attacker who compromises a single identity does not need to breach your network. They authenticate through the front door using the same sign-in page your employees use. Conditional access evaluates the sign-in. If the policies are not designed to catch the specific attack technique the attacker is using, access is granted. The attacker reads email, downloads files from SharePoint, creates inbox rules to intercept invoices, registers OAuth applications to maintain persistent access, and escalates privileges by modifying directory roles. Every action is logged. Most of it is never reviewed until the damage is discovered.
This is not a theoretical risk. This is the operational reality of how breaches happen in Microsoft 365 environments.
A real-world attack through the identity perimeter
To understand why identity is the primary attack surface, trace a single attack that follows the pattern seen in production environments every week. This is not a hypothetical — it is a composite based on attack patterns documented in Microsoft's threat intelligence and observed in operational SOC environments.
A finance manager at a mid-size organization receives an email that appears to come from their IT department. The email states that their Microsoft 365 password is expiring and includes a link to "update" it. The link does not point to login.microsoftonline.com — it points to an adversary-in-the-middle proxy server that presents an identical copy of the Microsoft sign-in page. The user enters their email address and password. The proxy forwards these credentials to the real Entra ID endpoint in real time. Entra ID challenges for MFA. The user's phone vibrates with a push notification from Microsoft Authenticator. They approve it — the prompt looks exactly like every other MFA prompt they have approved hundreds of times. The proxy captures the session token that Entra ID returns after successful MFA completion.
Expand for Deeper Context
Within four minutes, the attacker replays this session token from an IP address in a different country. Because the token has already satisfied MFA, Entra ID does not challenge again. Conditional access evaluates the sign-in: the user is a member of "All Users," the application is Office 365, the location is... not in the organization's trusted IP ranges, but the conditional access policy for this group does not require a compliant device or restrict by location. Access is granted.
The attacker opens Outlook Web Access. They create an inbox rule that forwards all emails containing the words "invoice," "payment," "wire," or "bank" to an external email address. They search the mailbox for recent financial correspondence. They find an active vendor payment thread and reply to it from the compromised account, requesting a change to the payment bank details. They then access SharePoint Online and download sensitive documents from the finance team site. They register a new OAuth application with Mail.ReadWrite and Files.Read.All permissions, establishing persistent access that will survive a password reset. They add a set of credentials to an existing service principal that has broad directory permissions — a persistence mechanism that most incident responders miss entirely.
Total time from initial phish to persistent access with data exfiltration: under thirty minutes. Total network perimeter controls bypassed: all of them — because the attacker never touched the network. Every action used legitimate Microsoft 365 APIs through the front door.
Now consider what stops this attack. If the organization required phishing-resistant authentication (FIDO2 or passkeys) instead of push notification MFA, the AiTM proxy could not have captured a usable credential — FIDO2 cryptographically verifies the domain, so authentication against a proxy page fails silently. If conditional access required a compliant device, the attacker's unmanaged machine would have been blocked at the token replay step. If token protection was enabled, the session token captured by the proxy would be bound to the user's device and useless on the attacker's device. If user consent for applications was blocked, the malicious OAuth application registration would have required administrator approval. If the organization monitored the audit log for service principal credential additions, the persistence mechanism would have been detected immediately.
Every one of those defenses is a specific control that this course teaches you to design, deploy, and verify. The attack succeeds when the controls are missing. It fails when they are present. Identity security is not about checking a compliance box — it is about engineering specific defenses against specific attack techniques.
The hybrid identity expansion
The identity attack surface is not limited to cloud-native authentication. Most organizations operate in a hybrid environment where on-premises Active Directory synchronizes with Entra ID through Microsoft Entra Connect (formerly Azure AD Connect). This hybrid architecture creates additional attack paths that span both environments.
An attacker who compromises an on-premises domain controller can extract password hashes and Kerberos keys that are synchronized to Entra ID. Pass-the-hash attacks against synchronized accounts grant cloud access. Golden Ticket attacks forged with the KRBTGT key can generate Kerberos tickets that Entra ID trusts if federation is configured through AD FS. The infamous "Golden SAML" attack forges SAML tokens using the AD FS token-signing certificate, granting access to any cloud application that trusts the federated identity provider — including all of Microsoft 365.
Expand for Deeper Context
The synchronization itself is a high-value target. The Entra Connect server holds credentials for both environments. If an attacker compromises this server, they can manipulate the synchronization process to escalate privileges, modify directory attributes, or inject backdoor accounts that appear in both environments.
This course focuses primarily on cloud-native Entra ID security, but the hybrid attack surface is addressed in context where it matters: conditional access policies that account for hybrid-joined devices (EI3), Defender for Identity integration for on-premises Active Directory monitoring (EI16), and the detection rules that identify synchronization anomalies (EI13). The IR course covers hybrid investigation in depth — particularly IR7 (lateral movement and credential theft), IR11 (Entra ID persistence including Golden SAML), and IR19 (the capstone investigation that spans both environments).
The evidence: identity as the primary attack vector
The shift is not philosophical — it is measurable. Microsoft processes over 65 billion authentication events per day across Entra ID. Their telemetry provides the clearest picture of where attacks actually occur in cloud environments.
Identity-based attacks dominate for three reasons. First, they scale. A password spray campaign can target thousands of accounts simultaneously with no network access required — just HTTPS requests to login.microsoftonline.com. Second, they bypass network defenses entirely. There is no firewall between the attacker and the Entra ID authentication endpoint. Third, they exploit the weakest link in every organization: human behavior. Users click phishing links, approve MFA prompts without reading them, and consent to OAuth applications that request permissions they do not understand.
Expand for Deeper Context
The MITRE ATT&CK framework maps these attack techniques precisely. The initial access techniques that matter most for Entra ID environments include Valid Accounts (T1078) — using stolen or compromised credentials to authenticate as a legitimate user, Phishing (T1566) — credential harvesting through emails, adversary-in-the-middle proxy pages, and QR code phishing, and Application Access Token (T1550.001) — using stolen OAuth tokens or session cookies to bypass authentication entirely.
Once initial access is established, the persistence and privilege escalation techniques include Account Manipulation (T1098) — modifying account attributes, adding credentials to service principals, or changing directory roles, Steal Application Access Token (T1528) — extracting refresh tokens, Primary Refresh Tokens, or session cookies from compromised devices, and Valid Accounts: Cloud Accounts (T1078.004) — maintaining access through legitimate cloud credentials that survive endpoint remediation.
Every one of these techniques leaves evidence in the Entra ID sign-in logs and audit logs. Every one of them can be detected with KQL queries. And every one of them can be prevented or mitigated with the identity security controls this course teaches you to deploy.
Why identity security is the highest-leverage investment
If you have a limited security budget — and every organization does — identity security provides the highest return on investment for one simple reason: identity is the control plane. Every other security control depends on it.
Defender for Endpoint protects devices — but only devices that are enrolled, and enrollment requires identity. Defender for Office 365 protects email — but email access is controlled by identity. Conditional access policies enforce security requirements — but only if the policies are designed correctly and the authentication methods are strong enough. Data Loss Prevention policies restrict what users can do with data — but only if the user's identity is not compromised. If an attacker controls the identity, they control the access, and every downstream security control is circumvented.
// EI0.1 — How many identities are in your tenant?
// Your identity perimeter: every account is an entry point
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == 0
| summarize UniqueUsers = dcount(UserPrincipalName)
// This is your identity attack surface: every unique user who signed in
// An attacker only needs to compromise ONE of these identities
Expand for Deeper Context
This means that a weak identity security posture undermines every other security investment. And a strong identity security posture strengthens every other security investment. Phishing-resistant MFA that prevents credential theft means Defender for Endpoint does not need to detect the post-compromise lateral movement. Token protection that prevents session replay means Defender for Cloud Apps does not need to detect the anomalous mailbox access. Conditional access policies that block sign-ins from unmanaged devices mean DLP policies do not need to prevent the data download.
The controls you build in this course are not one layer in a defense-in-depth stack. They are the foundation that determines whether every other layer gets tested at all.
Beyond this module
The IR course (Practical Incident Response) teaches you to investigate identity compromises after they occur. Specifically, IR8 covers M365 identity compromise investigation, IR11 covers Entra ID persistence mechanisms, and IR13-IR16 include identity components in every investigation scenario. This course teaches you to prevent those compromises from succeeding in the first place. A learner who completes both has end-to-end identity security capability: prevention, detection, and response.
Try it yourself
Try It — Assess Your Own Exposure
Environment: Your M365 developer tenant or your production tenant (read-only access to sign-in logs is sufficient).
Exercise: Open the Entra admin center → Identity → Monitoring & health → Sign-in logs. Look at the last 24 hours of sign-in activity. Answer these questions:
1. How many sign-ins came from outside your expected country? 2. How many used legacy authentication protocols (filter by Client App)? 3. How many were flagged as risky by Identity Protection? 4. How many conditional access policies evaluated as "Not Applied"?
If you cannot answer all four questions from the sign-in logs, that is exactly the gap this course fills. EI1 teaches you to read these logs fluently.
⚠ Compliance Myth: "We have MFA enabled, so our identities are secure"
The myth: MFA is the standard recommendation. We enabled it for all users. Our identities are protected.
The reality: MFA protects against password-only attacks (credential stuffing, password spray with correct passwords). It does not protect against AiTM credential phishing (the attacker captures the session token after MFA completes), MFA fatigue attacks (the attacker sends repeated push notifications until the user approves one), or token theft (the attacker steals the session token from the device after authentication). The authentication method matters as much as the authentication requirement. Push notification MFA and SMS MFA are phishing-capable. Only FIDO2 security keys, passkeys, and certificate-based authentication are phishing-resistant. EI2 covers the full authentication method hierarchy and EI4 teaches the conditional access policies that enforce phishing-resistant authentication where it matters most.
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.
