Conditional Access: getting beyond the basics

Conditional Access is one of those security features that organisations tend to set up once, declare victory, and rarely revisit. The problem is that the threat landscape doesn't stand still, and neither does your environment.

I've reviewed a lot of Conditional Access configurations over the past year. Here's what I consistently find.

What "basic" Conditional Access looks like

Most organisations that have implemented Conditional Access have some version of:

• Require MFA for all users (often with named location exclusions for office IPs)
• Block legacy authentication protocols
• Maybe a policy requiring compliant devices for some users

That's a reasonable starting point. It's not a mature Conditional Access posture.

The named location trap

Named location exclusions ("users on the office network don't need MFA") are extremely common and are a significant security gap. The reasoning seems sensible: if the user is on the corporate network, they must be in the office, so the risk is lower.

The problems:

• Corporate office IPs can be spoofed if an attacker is on the network
• "In the office" doesn't guarantee the right person is at the device
• VPN clients often appear as named locations, meaning remote workers connecting to VPN bypass MFA
• The office IP list is often stale

My recommendation: stop using named location MFA exclusions. MFA is cheap (in terms of user friction) relative to the security it provides. Require it everywhere, always.

If users complain about MFA frequency, use Microsoft's authentication strength features to allow passwordless methods (Windows Hello, FIDO2 keys, the Authenticator app without number matching) that are lower-friction than push notifications.

Session controls most people aren't using

Beyond access controls, Conditional Access supports session controls that persist after sign-in:

Sign-in frequency: How often users must re-authenticate, even with a persistent session. The default in many tenants is 90 days or "until the browser is closed." For sensitive data, you may want this shorter.

Application-enforced restrictions: For Exchange Online and SharePoint, you can require that sessions enforce a download restriction policy: users can view data but not download it if they're on an unmanaged device.

MCAS integration: If you have Defender for Cloud Apps (MCAS), you can route sessions through the reverse proxy to get real-time session monitoring and control.

Most organisations aren't using these. They represent significant additional security value without blocking access.

Risk-based Conditional Access

If you have Azure AD Premium P2 (now Entra ID P2), you have access to Identity Protection's risk signals. These allow policies like:

• If sign-in risk is medium or high → require MFA step-up
• If user risk is high → require password reset
• If sign-in risk is high and the device is unmanaged → block

Risk-based policies are more sophisticated than simple attribute-based policies and respond to actual signals rather than static conditions. They do require P2 licensing, which is an additional cost.

The policy audit you should be running

If you haven't done this recently: export your Conditional Access policies and work through them with fresh eyes. Ask:

• What was the intent of each policy?
• What users, apps, and conditions does it actually cover?
• What are the exclusions, and are they still justified?
• Are there gaps (apps or users not covered by any policy)?
• Are there conflicts (policies that contradict each other)?

The sign-in logs are your best tool for this. Filter for failed sign-ins, Conditional Access failures, and legacy authentication attempts, and use them to validate that your policies are actually doing what you think they're doing.

Conditional Access is not a one-time project. It's an ongoing security control that needs regular review.