AD1.1 Why Identity Is the Perimeter

5-6 hours · Module 1 · Free

Operational Objective

For twenty years, security was about protecting the network perimeter — firewalls, DMZs, VPNs, intrusion detection systems. The assumption was that anything inside the network was trusted and anything outside was hostile. M365 destroyed that model. Your email, your files, your Teams conversations, your SharePoint sites — all of it is accessible from any device, on any network, from any country. The attacker doesn't need to breach your firewall when they can log in with a stolen password from a coffee shop in another continent. This subsection establishes why identity has replaced the network as the primary security perimeter, what that means for how you think about protection, and why every security decision you make in this course starts with the question: "Can I verify who is authenticating and whether they should have access?"

Deliverable: Understanding of why identity is the primary security perimeter in cloud environments, the specific attack techniques that exploit weak identity controls, and the data that proves MFA is the single highest-impact security control you can deploy.

Estimated completion: 25 minutes

Figure AD1.1 — The perimeter shift from network to identity. In the old model, the firewall was the trust boundary. In the new model, authentication is the trust boundary. Every layer you add to the identity perimeter — MFA, conditional access, device compliance, risk detection — increases the cost and difficulty for the attacker.

The numbers that settle the argument

Microsoft processes over 300 billion authentication requests per month across Entra ID. They have more data on identity attacks than any other organisation on Earth. Their data shows that accounts without MFA are compromised at a rate 99.9% higher than accounts with MFA enabled. That’s not a rounding error. It means that for every 1,000 accounts that get compromised without MFA, only 1 gets compromised with MFA enabled.

The 0.1% that still get through with MFA are not random — they’re sophisticated attacks like adversary-in-the-middle (AiTM) proxy phishing, SIM swapping, and MFA fatigue bombing. These attacks require significantly more effort, tooling, and targeting than a simple password spray. Most attackers hitting most organisations are running commodity attacks — automated password spraying, credential stuffing from breach databases, and basic phishing. MFA stops all of these cold.

This is why identity is the first module you configure, and MFA is the first control you deploy. No other single security control in the M365 stack has a comparable impact. Safe Links reduces phishing click-through rates. Device compliance ensures endpoints meet baselines. DLP prevents data leakage. All important. None of them approaches the 99.9% reduction in account compromise that MFA provides.

How credential attacks work in practice

An attacker who wants access to your M365 tenant has four primary techniques, and understanding each one tells you exactly what MFA does and doesn’t protect against.

Password spraying is the most common automated attack. The attacker takes a list of common passwords (Password1!, Spring2026!, Company123!) and tries each one against every username in your tenant. They try one password per account per hour to stay under lockout thresholds. With 210 users and 10% using weak passwords, the attacker gets 21 valid credentials. Without MFA, each of those is full access to the account. With MFA, each of those is a failed authentication — the attacker has the password but can’t complete the second factor.

Credential stuffing uses username/password pairs from other breaches. When LinkedIn, Dropbox, or any other service gets breached, the stolen credentials end up on dark web markets. If your users reuse passwords (and statistically, 60-65% do), the attacker tries the breached credentials against your M365 login. Same result: without MFA, immediate access. With MFA, blocked.

Basic phishing sends an email with a link to a fake Microsoft login page. The user enters their credentials on the fake page. The attacker now has the username and password. Without MFA, immediate access. With MFA, the attacker has the password but can’t complete the second factor — unless they’re running an AiTM proxy (covered in AD1.2).

MFA fatigue targets accounts that already have MFA enabled. The attacker has the password (from spraying, stuffing, or phishing) and triggers MFA push notifications repeatedly until the user approves one out of frustration or confusion. This attack works against push-based MFA methods and is why Microsoft now enables number matching by default — the user must type a number shown on the login screen into their phone, rather than just tapping “Approve.”

The practical lesson: MFA stops the first three attack types completely. The fourth requires the attacker to already have the password AND to social-engineer the user into approving a push. Each additional defence layer raises the cost and complexity for the attacker.

What happens in your tenant without MFA

Walk through a concrete scenario using NE’s environment. NE has security defaults enabled, which means MFA is partially enforced — Microsoft’s risk engine decides when to challenge. Thirteen percent of users haven’t registered for MFA.

An attacker runs a password spray against NE’s tenant using a list of the 200 most common passwords. They find 15 accounts with weak passwords. For the 13 accounts that have MFA registered, Microsoft’s risk engine might challenge some of them — but “might” is not “will.” Security defaults use probabilistic MFA, not deterministic. The attacker tries from a clean residential IP address, rotates user-agents, and spaces attempts across hours. Some of these sign-ins may not trigger an MFA challenge.

For the 2 accounts in the 13% that haven’t registered for MFA, the attacker gets immediate access. They can’t be challenged for MFA because they haven’t registered an MFA method. These accounts are fully compromised with just the password.

Now walk through the same scenario with conditional access enforcing MFA for all users. Every sign-in, regardless of risk assessment, requires MFA. The 15 accounts with weak passwords get challenged on every attempt. The attacker can’t authenticate without completing the second factor. The 2 unregistered accounts are blocked entirely — conditional access can be configured to block accounts that haven’t registered for MFA rather than letting them through with password-only authentication.

That’s the difference between security defaults and conditional access. Not theoretical. Not marginal. The difference between “some attacks might be blocked” and “all password-only attacks are blocked, deterministically, every time.”

Detecting active password sprays in your tenant right now

You can check whether your tenant is being targeted by a password spray attack right now. Navigate to entra.microsoft.com → Monitoring → Sign-in logs. Add a filter for “Status: Failure” and set the time range to “Last 7 days.” Now look at the IP address column.

If you see a single IP address appearing repeatedly against multiple different user accounts — the same IP trying one password against dozens of accounts over several hours — that’s a password spray in progress. The attacker is testing common passwords (Password1!, Spring2026!, Welcome123!) one at a time across your entire user list, staying under lockout thresholds by trying one password per account per hour.

With MFA enforced, every one of these spray attempts fails even when the password is correct. The attacker enters the right password, gets prompted for MFA, can’t complete it, and the sign-in fails. This is MFA working exactly as designed. But the spray tells you two things: your tenant is being actively targeted (which means your MFA enforcement is not optional — it’s preventing real attacks right now), and some of your users have weak passwords (the spray wouldn’t be worth running if common passwords never worked).

To quantify the spray, run this in PowerShell:

1
2
3
4
5
6
7
Connect-MgGraph -Scopes "AuditLog.Read.All"
$start = (Get-Date).AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogSignIn -Filter "createdDateTime ge $start and status/errorCode eq 50126" -Top 500 |
    Group-Object IpAddress |
    Where-Object { $_.Count -gt 10 } |
    Select-Object Name, Count |
    Sort-Object Count -Descending

Error code 50126 is “Invalid username or password.” IPs with more than 10 failed attempts against your tenant in a week are likely automated attacks. If you see IPs with 50, 100, or 200+ attempts, you’re looking at a sustained spray campaign. The good news: MFA is stopping it. The action item: check whether any accounts in the spray targets have weak passwords and haven’t registered for MFA — those are the accounts at risk.

Expand for Deeper Context

The identity perimeter concept connects to a broader security model called zero trust. Zero trust eliminates the concept of implicit trust — no user, device, or network location is automatically trusted. Every access request is verified based on identity, device health, location, and the sensitivity of the resource being accessed.

You don’t need to implement a full zero trust architecture to benefit from the identity perimeter model. The three conditional access policies you’ll build in this module — MFA for all users, block legacy authentication, and require compliant devices — are the foundation of zero trust for M365. They verify identity (MFA), eliminate unverifiable protocols (legacy auth blocking), and check device health (compliance). If anyone asks you about zero trust, you can honestly say you’re implementing the identity pillar.

The Entra ID Security course covers zero trust architecture in depth — trust frameworks, continuous access evaluation, workload identities, and cross-tenant trust. For this course, the practical takeaway is simpler: verify every authentication, trust nothing by default, and add layers (device, location, risk) that make it progressively harder for an attacker to satisfy all the conditions required for access.

Compliance Myth: "MFA is inconvenient for users so we only enforce it for admins"

The inconvenience argument was valid in 2015 when MFA meant typing a 6-digit code from a hardware token every time you signed in. It's not valid in 2026. Microsoft Authenticator uses push notifications — the user taps "Approve" on their phone. Windows Hello uses a fingerprint or face scan. FIDO2 security keys require a touch. Most users complete MFA in under 5 seconds. The inconvenience is measured in seconds per sign-in. The cost of a compromised account is measured in days of incident response, potential data breach notification, and reputational damage. Any executive who refuses MFA because of "inconvenience" is making a risk decision they almost certainly wouldn't make if they understood the alternative is a 99.9% higher chance of account compromise.

The cost of getting this wrong

To make this concrete: the average cost of a business email compromise incident is $125,000 to $500,000 in direct financial loss, plus investigation costs, legal fees, and regulatory notification costs if personal data was exposed. The average cost of deploying MFA to 200 users is zero dollars (Microsoft Authenticator is free, conditional access is included in E3) and approximately 8 hours of IT administrator time for configuration and user communication.

The return on investment is absurd. Eight hours of work eliminates 99.9% of credential-based attacks. No other security investment in your entire career will deliver a comparable ratio of effort to impact. This is why identity is the first module, MFA is the first control, and conditional access is the first configuration. Everything else in this course matters. This matters most.

Decision point

Your IT manager says: “We should deploy MFA to the executive team first since they have access to the most sensitive data, then roll it out to everyone else over the next quarter.” This sounds reasonable. Is it the right approach?

Option A: Yes — protect the highest-value accounts first, then expand.

Option B: No — deploy MFA to all users simultaneously via conditional access.

Option C: Deploy to IT and security staff first as a pilot, then executives, then everyone else.

The correct answer is Option B. Conditional access policies apply to groups, and the easiest, safest deployment targets “All users” with exclusions only for break-glass accounts. A phased rollout by department creates a window where non-executive accounts are unprotected — and attackers don’t care about org charts. The finance clerk who processes payments is a higher-value BEC target than many executives. The helpdesk technician who can reset passwords is a privilege escalation target. Every unprotected account is a potential entry point. Deploy to everyone at once, with break-glass accounts excluded, and handle exceptions individually rather than by department.

Try it: Check your MFA registration coverage

Navigate to entra.microsoft.com → Protection → Authentication methods → Activity. Click the “Registration” tab. This report shows the total number of users capable of MFA, the number registered, and the registration rate as a percentage.

Click “Users capable of MFA” to see which users have NOT registered. For each unregistered user, determine why: Is it a shared account? A service account? A user who hasn’t signed in recently? An account that should have been disabled? Each unregistered account is a potential entry point for a password-only attack.

If your registration rate is below 95%, you have a gap. Module AD1.3 walks through how to close it — including re-registration campaigns, grace periods, and alternative MFA methods for users without smartphones.

Now navigate to Protection → Authentication methods → Activity → Usage. This shows which MFA methods your users are actually using. If the majority are using “Phone call” or “SMS,” you have a weaker MFA deployment than if they’re using “Microsoft Authenticator” or “FIDO2 security key.” Phone-based methods are vulnerable to SIM swapping. Push notifications with number matching are the recommended baseline.

An attacker obtains a valid username and password for a user account through credential stuffing (the user reused a password from a breached service). The account has MFA enabled with Microsoft Authenticator push notifications and number matching. What happens when the attacker tries to sign in?

The attacker is immediately blocked because MFA detects the sign-in is from an unusual location — Not quite. MFA doesn't evaluate location — that's conditional access. MFA simply requires the second factor to be completed. The sign-in proceeds to the MFA challenge regardless of location.

The user receives a push notification with a number to type in. If the user doesn't recognise the sign-in and doesn't approve it, the attacker is blocked — Correct. The user sees a notification they didn't initiate, with a number they can't see on the attacker's screen. Unless the attacker can social-engineer the user into approving and typing the correct number, the authentication fails. Number matching defeats MFA fatigue attacks because randomly tapping "Approve" doesn't work — the user must type the specific number shown on the sign-in screen.

The attacker bypasses MFA by using the password through an IMAP connection instead — This is possible if legacy authentication is not blocked. IMAP doesn't support MFA, so the password alone grants access. This is exactly why blocking legacy authentication is one of the three critical conditional access policies — without it, MFA has a bypass that attackers actively exploit.

MFA is automatically bypassed because the credentials are valid — No. Valid credentials satisfy the first factor only. The second factor (MFA) must be completed separately. This is the entire point of multi-factor authentication — knowing the password alone is not sufficient.

Operational Artifact — Identity Perimeter Assessment

Before you build conditional access policies, assess your current identity perimeter. Check three things: MFA registration rate (entra.microsoft.com → Protection → Authentication methods → Activity), legacy authentication usage (sign-in logs filtered by legacy client apps), and Global Administrator count (Roles and administrators → Global Administrator). These three data points tell you how exposed your identity perimeter is right now. Record them as your baseline — after you deploy the controls in this module, you'll check the same three metrics to measure improvement.

You're reading the free modules of M365 Security: From Admin to Defender

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.

View Pricing See Full Syllabus