Microsoft Entra ID Conditional Access: The 8 Gaps We Find in Every Audit

# Microsoft Entra ID Conditional Access: the 8 gaps we find in every audit

Think about the attack surface your Entra tenant represents. Email. Teams. SharePoint. OneDrive. SSO into Salesforce, Okta downstream apps, the AWS console. Every time we run a Microsoft-focused engagement for a mid-market client, the compromise path is the same. Phish a user. Steal the session. Pivot to M365. Pivot to Azure. Own the company.

Conditional Access is the control that's supposed to stop this. Microsoft calls it the "zero trust engine" for Entra. It does work. When it's configured. Correctly.

It rarely is.

We've run dozens of Entra ID audits over the last two years. The same 8 gaps show up in basically every one. Not cutting-edge bypass techniques. Not zero-days. Just misconfigurations baked in during the M365 rollout that nobody has gone back and fixed. Here's the list.

#Gap 1: "All users" exclusions silently neuter policies

Common pattern: CA policy requires MFA for all users. Then there's an exception for the emergency break-glass account. Then another exception for the service account used by the CI/CD system. Then another for the executive who complains about MFA. Then the legacy app that can't support MFA.

Each exception is defensible individually. Together they mean the policy covers maybe 85% of users. The 15% excluded are often the highest-value targets.

How to find it:

• Entra admin center → Protection → Conditional Access → Policy → Assignments → Users → Exclude
• Review every exclusion
• For each: is the exception still necessary? When was it last reviewed?

Fix: document every exclusion with an owner, a justification, and an expiration date. Review quarterly. Approach zero exclusions asymptotically.

#Gap 2: Phishing-resistant MFA not required for privileged access

Most organizations have MFA enabled. Many have it set to "any method". User can satisfy with authenticator app push, SMS, TOTP, or FIDO2 key. Attackers choose the weakest path.

Specifically: if SMS is allowed for privileged roles (Global Admin, Security Admin, Exchange Admin, etc.), you're exposed to SIM swap.

Fix: deploy Authentication Strengths (general availability since 2023) requiring phishing-resistant methods for:

• Global Administrator
• Privileged Role Administrator
• Security Administrator
• Application Administrator
• Conditional Access Administrator
• All privileged application access (Security Reader, Helpdesk Administrator, etc.)
• Break-glass accounts. Explicitly require hardware FIDO2 for these

#Gap 3: Legacy authentication not fully blocked

"Legacy authentication" in Microsoft terminology = any protocol that doesn't support modern authentication (OAuth 2.0 with MFA). This includes Basic Authentication, older Exchange protocols (POP3, IMAP, SMTP AUTH, EWS), older versions of Office that predate ADAL.

Legacy authentication entirely bypasses MFA. An attacker with a stolen password can authenticate via IMAP, SMTP AUTH, or older Outlook and get email access regardless of your MFA policy.

Microsoft deprecated basic auth for Exchange Online in 2022-2023 for most tenants. But: tenants provisioned before that deprecation, with active connections using legacy auth at the time, may still have legacy auth enabled in specific configurations.

Fix:

• Entra sign-in logs, filter by Client App = "Other clients" or Legacy Auth. Any recent events?
• Conditional Access policy blocking legacy authentication: "All users" + "All cloud apps" + "Other clients" condition + Block access
• Test: try authenticating via IMAP with a test account. Must fail

#Gap 4: No device compliance requirement for sensitive apps

Conditional Access can require a device to be compliant (Intune-managed + policy-compliant) before allowing access. Most organizations have this configured for general access but not for sensitive apps.

Specifically: HR tools, finance tools, admin consoles, SharePoint sites with sensitive data. These should require not MFA but also a compliant device. Otherwise, a stolen password + MFA prompt trick is still game over.

Fix: build CA policies that require "Device marked as compliant" for specific app groups:

• Admin consoles (Exchange Admin Center, Security Admin Center, Azure Portal)
• Finance SaaS (if federated)
• HR SaaS
• SharePoint sites containing regulated data
• Specific CRM / ERP applications

#Gap 5: Service accounts without IP restrictions

Service accounts (like the one your backup tool uses, the integration between your CRM and Microsoft 365, the monitoring script that checks mailbox health) typically can't use MFA. They authenticate with username and password or OAuth client credentials.

Most organizations create a service account, grant it broad permissions, and leave it. A compromised service account credential (leaked in source code, intercepted in logs, or stolen from a developer workstation) is long-term access.

Fix:

• Enumerate all service accounts (Entra admin → Users → filter for accounts with specific naming conventions or flags)
• For each: restrict authentication to specific trusted IP addresses via Named Locations + Conditional Access policy
• Migrate away from password authentication to certificate-based authentication or managed identity where possible
• Consider using Workload Identity (Microsoft's service principal best practices) instead of human-style user accounts

#Gap 6: No session control policies for risky access

Conditional Access supports session controls beyond block/allow. You can:

• Limit session lifetime (require re-auth every N hours)
• Apply Defender for Cloud Apps session policies (monitor, restrict, or block risky actions in-session)
• Use app-enforced restrictions (SharePoint sensitivity, Exchange mobile access, etc.)

Most organizations don't use session controls. A user authenticates in the morning and has a valid session all day. If the device is compromised 2 hours in, the attacker has full session access.

Fix:

• Reduce session lifetime for privileged roles (8 hours max, re-auth required after)
• Reduce session lifetime for sensitive apps (2-4 hours for admin consoles)
• Deploy Defender for Cloud Apps session policy for download restrictions on sensitive documents
• Consider "sign-in frequency" requirement on app categories

#Gap 7: No Identity Protection risk-based policies

Entra ID Identity Protection (included in P2 licenses, expensive) generates sign-in risk and user risk signals. Conditional Access policies can act on these signals. Block, require password change, require MFA, etc.

Many organizations have P2 licenses (or P1 with some features) but never configured the risk-based CA policies.

Fix:

• Entra admin → Protection → Conditional Access → New policy
• Create "Block high risk sign-in". Blocks access when sign-in risk is High
• Create "Require password change on high risk user". User is flagged, must reset password and re-enroll MFA
• Create "Require MFA on medium risk sign-in". Additional verification when behavior is suspicious

These policies use Microsoft's machine-learned risk signals and catch a lot of credential theft and AITM phishing attacks.

#Gap 8: No detection or alerting on CA policy changes

Conditional Access policies themselves are the target. A compromised admin account that modifies CA policies to remove MFA requirements, whitelist attacker IPs, or disable protection creates persistent access.

Most organizations don't alert on CA policy changes. They should.

Fix:

• Configure Entra audit log export to SIEM (Sentinel, Splunk, etc.)
• Alert on conditionalAccessPolicy object changes (create, update, delete)
• Alert on changes by accounts other than known CA administrators
• Alert on changes outside business hours
• Require multi-admin approval for CA policy changes where technically feasible (currently requires custom workflow)

#Bonus: break-glass account hygiene

Break-glass accounts are the "get out of jail" accounts for when CA locks out legitimate admins (broken policy, vendor outage, MFA system down). Best practice:

• 2-4 break-glass accounts (not 1, in case one is compromised. Not 10, because volume = attack surface)
• Strong unique passwords stored in physical safe at two separate locations
• FIDO2 hardware keys for MFA, stored with the passwords
• Excluded from CA policies that might lock them out, BUT:
• Alerting on any use. Every sign-in generates an immediate high-severity alert
• Regular testing (quarterly) to verify they still work
• Credentials rotated after every test or use

Common failure: break-glass account exists, no alerting, credentials saved in 1Password (now vulnerable to 1Password compromise), no FIDO2 requirement. Defeats the purpose.

#Audit checklist

For a rapid Entra ID health check, run through:

[ ] Conditional Access policy inventory. List every policy
[ ] User exclusions audited. Each has owner + justification + expiration
[ ] MFA required for all users (with documented exceptions)
[ ] Phishing-resistant MFA required for all privileged roles
[ ] Legacy authentication blocked by policy
[ ] Device compliance required for sensitive app access
[ ] Service accounts restricted to trusted IPs
[ ] Session lifetime limits in place for privileged + sensitive apps
[ ] Identity Protection risk-based policies active (if P2 licensed)
[ ] CA policy changes alerted to SIEM
[ ] 2-4 break-glass accounts with FIDO2 + physical safe + alerting
[ ] Privileged Identity Management (PIM) for just-in-time admin elevation
[ ] Guest access scoped and reviewed regularly
[ ] Application consent policies restrict user-consented OAuth scopes

Most organizations score 4-8 out of 14 on first audit. Fixing the gaps is typically 40-80 hours of Entra configuration work.

#What we do in an Entra ID engagement

Our Microsoft-focused engagements:

• Full Entra ID configuration audit against the above checklist + Microsoft's Identity Secure Score
• Sign-in log review for indicators of legacy authentication, risky sign-ins, suspicious patterns
• Privileged access review including PIM configuration, Global Admin count, Break-glass hygiene
• Application and service principal audit. OAuth consents, API permissions, sprawl
• Federated SaaS audit. What apps are federated, what scopes, what conditional access
• Remediation advisory with specific policy configurations

Typical Entra ID audit engagement: 1-2 weeks, $12-25K for mid-market organizations.

#Resources

• Microsoft Identity Secure Score: https://security.microsoft.com/securescore
• Microsoft Conditional Access documentation
• Microsoft Entra recommendations blade (built into the admin center)
• CISA's Microsoft 365 Security Configurations
• DISA STIG for Microsoft 365

#Hire Valtik Studios

If your organization runs on Microsoft 365 and hasn't had a dedicated Entra ID audit, the gaps will surprise you. We run focused Entra engagements that produce a specific configuration roadmap to close the 8 gaps above and the organization-specific ones that only show up on detailed review.

Reach us at valtikstudios.com.