Why Identity Is the New Perimeter

Introduction

This section is the argument for the course. You will finish able to say why identity replaced the network as the thing worth defending, and to name the narrow band of techniques this course is actually about, which is not the band most identity spending goes to.

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 entered and what left. VPN extended that perimeter to remote workers. Intrusion detection systems monitored traffic crossing the boundary. The security model was straightforward: 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. Users authenticate through Entra ID from homes, phones, airport lounges, and hotel lobbies. 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 event: the moment a user proves their identity and Entra ID decides whether to grant access.

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 aren't designed to catch the specific technique the attacker is using, access is granted. The attacker reads email, downloads files from SharePoint, creates inbox forwarding rules, registers OAuth applications for persistent access, and escalates privileges by modifying directory roles. Every action uses legitimate Microsoft 365 APIs. Every action is logged. Most of it is never reviewed until the damage surfaces.

This is not a theoretical risk scenario, it is the operational reality of how cloud breaches happen. In reactive incident response engagements that Microsoft investigated in 2025, 80% involved data theft and 51% confirmed data exfiltration. The entry point was almost always an identity: a stolen credential, a hijacked session, or an abused application permission.

Those two bands are very different sizes, and only one of them is what a course can usefully be about.

So the question to carry into module 2 is not whether a tenant has MFA. It is which method satisfies the requirement when somebody signs in, because that is what the figure above measures and it is not what most tenants have deployed.

The shift from network to identity perimeter is not philosophical, it is measurable. The Microsoft Digital Defense Report 2025 provides the clearest picture available of where attacks actually concentrate in cloud environments.

Identity-based attacks dominate for three architectural reasons. First, they scale. A password spray campaign can target thousands of accounts simultaneously with nothing more than HTTPS requests to login.microsoftonline.com. No network access required. No exploit development. No vulnerability scanning. The attacker needs only a list of email addresses, and those are available from LinkedIn, data breaches, or simple enumeration against the Entra ID login endpoint. Second, they bypass network defenses entirely. There is no firewall between the attacker and the Entra ID authentication endpoint. The endpoint is public by design: every legitimate user authenticates against it, and so does every attacker. Third, they exploit human behavior. Users click phishing links, approve MFA prompts without reading them, and consent to OAuth applications requesting permissions they don't understand.

The MITRE ATT&CK framework maps these 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 adversary-in-the-middle proxy pages, QR code phishing, and device code flow abuse; and Application Access Token (T1550.001), using stolen OAuth tokens or session cookies to bypass authentication entirely. Once initial access is established, persistence techniques include Account Manipulation (T1098), adding credentials to service principals or modifying directory roles, and Steal Application Access Token (T1528), extracting refresh tokens or Primary Refresh Tokens from compromised devices.

The 97% figure: the proportion of identity attacks that are password spray or brute force, carries a specific implication for this course. Those attacks are stopped by basic MFA. The remaining 3% includes AiTM credential phishing, token theft, OAuth consent phishing, MFA fatigue, device code flow abuse, and service principal credential injection. These are the techniques that bypass MFA entirely. They are also the techniques that cause the most damage, because they grant the attacker an authenticated session with full access to whatever the compromised identity can reach. This course focuses on that 3%.

  Microsoft Digital Defense Report 2025
  ------------------------------------------------------------
  identity attacks that are password attacks       >97%
  rise in identity attacks, H1 2025                 +32%
  unauthorized access blocked by phishing-resistant >99%
  ransomware targeting hybrid components             40%   (from <5% in 2023)
  rise in destructive campaigns against Azure        +87%

Read the growth figure against the method figure rather than on its own. Attacks rose by a third while the control that stops more than 99 per cent of them was already available, which makes the gap a deployment problem rather than a capability one, and that is the gap every module after this one works in.

Trace the attack pattern that this course exists to prevent. A finance manager receives an email that appears to come from IT. The link points to an adversary-in-the-middle proxy presenting an identical copy of the Microsoft sign-in page. The user enters credentials. The proxy forwards them to the real Entra ID endpoint. Entra ID challenges for MFA. The user approves the Authenticator push notification. The proxy captures the session token returned after MFA completion.

Within minutes, the attacker replays that session token from a different IP address. The token has already satisfied MFA. Entra ID does not challenge again. Conditional Access evaluates the sign-in: the user belongs to "All Users," the application is Office 365, and the location policy doesn't require a compliant device. Access is granted.

What follows is methodical. The attacker creates an inbox rule forwarding emails containing "invoice," "payment," or "wire" to an external address. They search the mailbox and find an active vendor payment thread. They reply from the compromised account requesting a change to the payment bank details. They download documents from the finance team's SharePoint site. They register an OAuth application with Mail.ReadWrite and Files.Read.All permissions, persistent access that survives a password reset. They add credentials to an existing service principal with broad directory permissions.

Total time from phish to persistent access: under thirty minutes. Network perimeter controls bypassed: all of them. Every action used legitimate Microsoft 365 APIs.

The evidence of this attack exists in your sign-in logs. The attacker's token replay produces a sign-in record that looks like this:

{
  "userPrincipalName": "j.martinez@contoso.com",
  "appDisplayName": "Office 365 Exchange Online",
  "ipAddress": "185.220.101.xx",
  "location": { "countryOrRegion": "NL" },
  "status": { "errorCode": 0 },
  "conditionalAccessStatus": "success",
  "authenticationRequirement": "singleFactorAuthentication",
  "isInteractive": true,
  "tokenIssuerType": "AzureAD",
  "riskLevelDuringSignIn": "none"
}

Notice what this record reveals. The sign-in succeeded (errorCode: 0) from a Dutch IP address for a user who normally signs in from the United States. The authentication requirement shows singleFactorAuthentication. MFA was not required for this sign-in because the session token already satisfied it during the original authentication. Conditional Access evaluated and passed. The risk level shows none because the sign-in used a valid session token and didn't trigger any anomaly detections. To an analyst glancing at the sign-in logs, this looks like a legitimate sign-in from an employee traveling abroad. Without a query that correlates the location change with the authentication method and the session token characteristics, this attack is invisible.

Section 0.2 explains the authentication flow that produces these records. EI1 teaches you to read every field. EI4 teaches the Conditional Access policies that block the token replay before it reaches this point. ARC406 teaches the detection rules that catch it when prevention fails.

Consider what stops this attack at each stage. Phishing-resistant authentication (FIDO2 or passkeys) prevents the AiTM proxy from capturing a usable credential. FIDO2 cryptographically verifies the domain, so authentication against a proxy page fails silently. This is EI2. A compliant device requirement blocks the token replay from the attacker's unmanaged machine. This is EI3 and EI4. Token protection binds the session token to the user's device, making it useless on any other device. This is EI7. Blocking user consent for applications prevents the malicious OAuth registration. This is EI9. Monitoring audit logs for service principal credential additions catches the persistence mechanism. That is detection work, and it is ARC406.

Every one of those defenses is a specific control this course teaches you to design, deploy, and verify. The attack succeeds when the controls are missing. It fails when they are present.

Take them one at a time, because each is a different kind of gap.

The policy is the control, and enabling one is not deploying one. Proving a policy does what you believe, to the population you believe, turns out to need a module of its own, which is why three of them carry this thread.

Not all MFA resists the same attacks. Module 2 is the difference between a push notification and a passkey, and per module 4 that difference decides whether a proxy attack works at all.

Sign-in succeeding is where most tenants stop looking. A token is a bearer credential, and nothing about it asks who is holding it. Everything after the sign-in page is module 7's subject and it is the half most identity programs never reach.

Standing privilege is the one that compounds. Six permanent Global Administrators is six permanent targets, and per module 6 the fix is not fewer administrators but privilege that is not switched on when nobody is using it.

The fifth is where the scenario actually failed, and it is worth being precise about that. The estate had the evidence and not the question, so nineteen days of mailbox access sat in logs that were working correctly and nobody interrogated.

If your security budget is limited, and every organization's is, identity security provides the highest return on investment because identity is the control plane. Every other security control depends on it.

Defender for Endpoint protects devices, but only enrolled devices, and enrollment requires identity. Defender for Office 365 protects email, but email access is controlled by identity. Data Loss Prevention policies restrict what users do with data, but if the user's identity is compromised, DLP policies protect against the wrong actor. Conditional Access enforces security requirements, but only if the policies are designed correctly and the authentication methods are strong enough. Information Barriers restrict communication between departments, but if an attacker holds a valid identity in the finance team, the barriers allow the access they were designed to permit.

A weak identity security posture undermines every other security investment. A strong one strengthens all of them. Phishing-resistant MFA that prevents credential theft means Defender for Endpoint doesn't need to detect post-compromise lateral movement. Token protection that prevents session replay means Defender for Cloud Apps doesn't need to detect anomalous mailbox access. Conditional Access that blocks unmanaged devices means DLP doesn't need to prevent the data download. Each identity control you deploy reduces the load on every downstream defense.

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.

Here is what your identity attack surface looks like as raw telemetry: every unique identity that authenticated successfully in the last 30 days is a potential entry point:

// Your identity attack surface: every account that signed in is an entry point
// An attacker needs to compromise ONE of these identities
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "0"
| summarize
    UniqueUsers = dcount(UserPrincipalName),
    UniqueApps = dcount(AppDisplayName),
    UniqueLocations = dcount(LocationDetails.countryOrRegion)
// Run this in your own Sentinel workspace or Advanced Hunting
// The UniqueUsers number is the size of your identity perimeter

That query returns the boundary of your identity perimeter: every unique user who successfully authenticated in the last 30 days, the applications they accessed, and the locations they signed in from. An attacker only needs to compromise one of those identities to gain access to everything that identity can reach.

The identity attack surface extends beyond cloud-native authentication. Most organizations operate in a hybrid environment where on-premises Active Directory synchronizes with Entra ID through Microsoft Entra Connect. This hybrid architecture creates additional attack paths spanning both environments.

An attacker who compromises an on-premises domain controller can extract password hashes synchronized to Entra ID. Pass-the-hash attacks against synchronized accounts grant cloud access. Golden SAML attacks forge 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. The Entra Connect server itself is a high-value target: it holds credentials for both environments, and compromising it enables manipulation of the synchronization process to escalate privileges or inject backdoor accounts.

Microsoft is actively migrating organizations from Entra Connect to Entra Cloud Sync: a cloud-managed synchronization service that reduces the on-premises footprint and eliminates some of these attack paths. Beginning in July 2026, Microsoft is reaching out to organizations to plan their transition. But for the majority of environments today, the hybrid attack surface remains real.

The Microsoft Digital Defense Report 2025 highlighted this convergence: 40% of ransomware attacks now target hybrid components, up from less than 5% in 2023. An 87% increase in destructive campaigns targeting Azure customer tenants reinforces that cloud identity infrastructure is no longer a secondary target, it is a primary one.

This course focuses on cloud-native Entra ID security, but the hybrid attack surface is addressed where it matters: Conditional Access policies that account for hybrid-joined devices (EI3), Defender for Identity integration for on-premises monitoring (ARC406), and detection rules that identify synchronization anomalies (ARC406).

Hybrid adds an on-premises directory that synchronizes into the thing you are defending. That is the whole of why it matters here: compromise on-premises becomes compromise in the tenant, and the sync account is the bridge between the two.

This course covers hybrid only where it changes a cloud outcome. A hybrid join changing a device claim. A synced account behaving differently from a cloud-only one. Password hash sync as an authentication path with its own failure modes. Each of those alters something you would otherwise get wrong in the cloud.

Everything on the left of that figure alters something you would otherwise get wrong in the tenant. Everything on the right is a separate discipline and a separate course.

That border is worth stating once here rather than negotiating in module 9. An on-premises fact is in scope when it changes what Entra ID decides and out of scope when it does not, which keeps a course about cloud identity from becoming a course about Active Directory.

One question, asked of your own tenant, and it decides whether the headline figure applies to you.

The network perimeter is gone because there is no longer a boundary between the user and the data, so the perimeter is the authentication event itself. That reframing matters because of how the attacks divide: 97 per cent are password spray and brute force, which any MFA answers, and three per cent are AiTM, token theft, consent phishing and device code flow, which succeed against a tenant with MFA enabled because none of them attacks the password. This course is about the three per cent, which needs Conditional Access designed rather than switched on, sessions understood rather than trusted, and detection for what prevention does not stop. And the figure everybody quotes belongs to phishing-resistant methods specifically, not to MFA in general, which is the difference between the scenario's estate and a defended one.