Is Your Microsoft Entra ID Configured for Maximum Protection?

Microsoft's 2025 Digital Defense Report recorded more than 7,000 password attacks per second against its systems over the past year, part of over 600 million daily identity attacks tracked across Microsoft Entra ID. Phishing-resistant MFA blocks more than 99% of these attacks, even when an attacker already holds a valid username and password.

Here's the uncomfortable part: Proofpoint's 2025 research found that 59% of accounts successfully taken over by attackers already had MFA enabled. Identity is now the primary battleground, and simply switching MFA on isn't the same as configuring it properly. This is a practical review of the three pillars that actually determine your protection level: Conditional Access, MFA, and Identity Protection, plus the specific configuration gaps we most commonly find during Entra ID reviews.

Conditional Access: Why "On" Isn't the Same as "Configured"

Many smaller organisations still rely on Entra ID Security Defaults rather than Conditional Access. Security Defaults are a reasonable baseline for very small tenants, but they apply the same blunt rule to everyone: MFA required, no exceptions, no context. There's no way to account for sign-in risk, device compliance, location, or which application is being accessed, which is exactly the nuance a real security posture needs.

Conditional Access, available from Entra ID P1, replaces that blunt rule with policy logic: require MFA from unmanaged devices but not compliant ones, block sign-ins from unexpected countries, or demand stronger authentication for sensitive applications specifically. The catch is that Conditional Access is only as strong as its scope. Security researchers regularly find policies that technically exist but don't apply everywhere they should, for example a policy scoped to block legacy sign-in methods that fails to account for a specific first-party application making requests outside the expected flow, leaving a quiet gap that looks fine in the policy list but doesn't hold up in practice.

Three Conditional Access policies we consistently find missing during reviews:

• A policy blocking legacy authentication protocols. Basic Auth and SMTP AUTH don't support modern authentication or MFA at all, making them one of the most reliable ways for an attacker to bypass every other control you've put in place. Blocking them is typically a sub-hour change with an outsized impact.
• A policy protecting MFA registration itself. Without this, an attacker who obtains a new starter's password can register their own device as an MFA method before the legitimate employee ever does, quietly taking over the account at the exact moment it's least likely to be noticed.
• A policy requiring compliant, Intune-enrolled devices for access to sensitive resources. Without a device compliance requirement, a stolen or unmanaged laptop with valid saved credentials can access company data just as easily as a corporate device.

MFA: The Method Matters More Than the Toggle

MFA adoption has become the norm. Okta's Secure Sign-in Trends Report puts workforce MFA adoption at 70% as of early 2025. But adoption isn't the same as resilience. Obsidian Security found that MFA failed to actually prevent the attack in 84% of the incidents it responded to, largely because attackers have moved on from guessing a second factor to stealing it outright.

Adversary-in-the-middle phishing kits intercept a real login session, including a completed MFA challenge, and hijack the resulting session token. Microsoft recorded a 146% increase in AiTM phishing attacks in a single year, and SpyCloud tracked 8.6 billion stolen session cookies and artifacts in 2025 alone. Against this technique, SMS codes and push notifications offer very little protection, since the attacker isn't guessing the code, they're capturing the session after a real user has already completed it.

Phishing-resistant MFA, using FIDO2 security keys or passkeys, closes this gap because the cryptographic credential is bound to the specific site being accessed and simply can't be relayed through a phishing proxy. Microsoft's Digital Defense Report puts the effectiveness of phishing-resistant MFA against identity-based attacks at over 99%, even where the attacker already has valid credentials. At minimum, this should be enforced for every administrator role; ideally, it should extend to any account with access to financial systems or sensitive data.

Identity Protection: Moving From Reactive to Risk-Based

Microsoft Entra ID Protection, available from P2 licensing, continuously evaluates sign-ins and user accounts for risk signals, such as sign-ins from anomalous locations, leaked credential matches, or impossible travel patterns, and assigns a risk score in real time.

The gap we see most often isn't a lack of licensing, it's that Identity Protection is left generating risk detections that nobody actively reviews, rather than being wired into Conditional Access to act on them automatically. A properly configured setup uses risk-based Conditional Access policies to require step-up authentication or block access entirely when a sign-in is flagged as medium or high risk, and to force a secure password reset when a user's credentials are found in a breach dataset. Without that link, Identity Protection is a monitoring tool sitting next to your defences rather than part of them.

Common Configuration Gaps Worth Reviewing

Beyond the areas above, a handful of specific gaps come up repeatedly during Entra ID reviews:

1. Permanent privileged role assignments. Standing Global Administrator access, rather than just-in-time elevation through Privileged Identity Management, means a single compromised admin account carries far more risk for far longer than it needs to.
2. Break-glass accounts excluded from monitoring. Emergency access accounts should be excluded from Conditional Access to prevent lockout, but they still need active sign-in alerting and quarterly testing, since an unmonitored account with permanent Global Administrator rights is a serious blind spot if it's ever misused.
3. Legacy per-user MFA instead of Conditional Access. Per-user MFA is an older, less flexible mechanism that can't apply context like device compliance or application sensitivity, and often coexists messily alongside newer Conditional Access policies.
4. OAuth application consent left ungoverned. Users granting broad permissions to third-party apps via OAuth consent prompts is a consistently underestimated way for attackers to gain persistent access without ever needing a password.
5. No regular review cadence. Conditional Access policies and role assignments drift as staff join, leave, and change roles. Without scheduled reviews, exclusions added for a one-off exception have a habit of becoming permanent, unreviewed gaps.

At a Glance

Frequently Asked Questions

Do we need Entra ID P2 to be properly protected? Not entirely. Conditional Access, blocking legacy authentication, and enforcing phishing-resistant MFA are all available from P1 licensing. P2 adds Identity Protection's risk-based detection and Privileged Identity Management, which meaningfully strengthen your posture but aren't the only line of defence.

Is Security Defaults enough for a small business? It's a reasonable baseline if you have no other option, but it applies one blanket rule to everyone with no ability to account for device compliance, risk, or application sensitivity. Most businesses outgrow it quickly once they need any nuance in how access is controlled.

Why did MFA fail to stop most of the incidents you mention? In the large majority of cases, attackers weren't defeating MFA directly, they were stealing an already-authenticated session through adversary-in-the-middle phishing or infostealer malware, which standard SMS or push-based MFA does very little to prevent.

How often should Conditional Access policies be reviewed? We'd recommend at minimum a quarterly review, checking for policy exclusions that have outlived their original purpose, new applications that aren't yet covered, and role assignments that no longer match someone's current job.

Can Protrona review our current Entra ID configuration? Yes. Our security consultancy services include a full Conditional Access, MFA, and Identity Protection review, benchmarked against your current device management setup and the Defender configuration gaps we've written about previously, since the two are closely linked in practice.

Get your Entra ID configuration reviewed

Most tenants we review have some form of MFA and Conditional Access already in place. The gaps are almost always in the detail: which accounts are excluded, which protocols are still allowed, and whether risk detections are actually being acted on. Get in touch to arrange a review.