Revisiting Conditional Access in 2025

Published by Chris Chambers, Managing Consultant & Alan Johnstone, Principal Consultant, Cloud Security & Solutions on 13 August 2025

This blog post shares how to maximise the effectiveness of Microsoft’s Conditional Access — covering common pitfalls like policy overload, exclusion mismanagement, and overlooked scenarios, while exploring actionable strategies to enhance cloud security. From leveraging Entra ID’s insights and reporting to refining zero-trust principles, this post dives into the evolving landscape of Conditional Access and provides practical tips to strengthen your organisation’s defences. Stay ahead of emerging threats and see how CyberCX can assist with expert support in policy fine-tuning, design, and optimisation.

In May 2023, we published a blog article, titled Fickle Multi-Factor Authentication in Microsoft 365 – it explored common occurrences and situations that the CyberCX Security Testing & Assurance team witnessed with Microsoft’s Conditional Access capability during engagements. So, two years on, where are things now? Have they improved? The short answer is a little bit but still nowhere near enough. This blog dives into commonly witnessed scenarios and strategies you can implement to reduce risk with Conditional Access.

Bring me up to speed

Firstly, if Conditional Access is new to you and you haven’t read the initial article, here’s a quick overview:

Entra ID: this is Microsoft’s cloud-based identity service, acting as a central point of identity for applications, systems and more. You might know it under its old name of Azure AD.

Microsoft 365: Microsoft’s cloud-based productivity suite: think email (Exchange Online), communication (Microsoft Teams), collaboration (SharePoint Online, OneDrive for Business) and much more. Importantly, Microsoft 365 uses Entra ID to manage all identities (users, groups, devices) and to enforce security controls.

A key part of Entra ID is Conditional Access – a signals driven engine that makes decisions in real time to control access to applications, data and actions. Broadly speaking, Conditional Access is the responsibility of the customer to configure, though in recent times, Microsoft have introduced ‘Microsoft Managed Policies’ [1], [2] to help close the gap for organisations who have not taken proactive steps with the tool.

Figure 1: Conditional Access Concept, Source Microsoft [3]

With this understanding, below are seven prevalent misconfigurations we encounter and the measures you can implement to mitigate them.

Policy overload – seeing the forest from the trees

It is unfortunately common to review an organisation’s policies and the first thing that greets you is a set of policies with names like Figure 2 below.

Figure 2: Sample Conditional Access Dashboard

Which policy does what? Who knows! This mishmash of policies with similar names and overlapping controls provides no clear and obvious way to assess coverage and highlight gaps, nor does it facilitate good change control. To mitigate against this, organisations should adopt and enforce a strict naming convention. CyberCX can assist with developing this, but in short it should provide five key features:

• Unique identifier, used for change control references.
• Who or what is in scope: users, actions and apps.
• What criteria does it apply to: devices, operating systems, locations and more.
• What is the outcome: is access denied or approved?
• What requirements are imposed: does the policy enforce device compliance or require phishing resistant multi-factor authentication (MFA)?

For example:

MFA - All Apps

Becomes

CAP-100 – All Users – All Apps – Allow – Require Auth. Strength: MFA

Policy overlap: why do things twice?

Another common scenario to witness is overlapping policy. Dovetailing with the issues surrounding naming conventions, overlapping policies create confusion and room for error. CyberCX’s recommendation here is to keep it simple: want to enforce MFA? Have a policy that applies it as broadly as possible – don’t have a guest specific policy, a user policy, administrator policy and so on.

With multiple overlapping and similar policies, identifying what objects are in scope of which policies can become a difficult task and let’s face it, it’s 2025: everyone should be doing MFA.

Trusted locations: why trust them?

Trusted locations are a flag within Conditional Access — specified public IP ranges marked as ‘trusted’, and traffic from them exempted from controls such as MFA.

However, ‘trusted locations’ explicitly violates one of the core tenants of the modern zero trust approach: never trust. Why should an authentication request from a corporate office location be treated any differently from a user on the go or working from home?

For a real world example, CyberCX recently witnessed an organisation bypassing all MFA requests across eight /24 IP blocks – broadly disabling policy enforcement for the majority of the organisation.

One argument that crops up frequently is MFA fatigue: prompting users to authenticate too many times. However, with adoption of near seamless MFA solutions such as Windows Hello for Business, there are ways to provide class leading authentication solutions without worrying about MFA fatigue.

Exclusion management: who cleans it up?

Occasionally there’s a requirement for an exclusion to be implemented. Perhaps it’s a user travelling outside of the approved operating countries or a new user being onboarded to phishing resistant authentication methods – ordinarily required by existing policy.

Most organisations currently approach this in a very manual way: a security group is associated to the Conditional Access policy; the user object is added to the group and thus the exclusion is given. Hopefully, a separate service request is then actioned sometime later, removing this exclusion. However more often than not, CyberCX witness this all-important removal never occurs. Thus, allowing a user to accumulate exclusions to critical security policies over time.

While some service management tools such as ServiceNow [4] can add and remove users to Entra ID Security Groups, not all organisations have such capability. Where not available, consider using Entra ID’s Entitlement Management feature. Originally intended to automate identity workflows and user lifecycles, Access Packages can be used to schedule the assignment and removal of exclusions to Conditional Access policy; greatly reducing the manual overhead and closing those policy loopholes.

Dynamic risk signals

Often policies only evaluate static inputs to determine risk. Microsoft provides two real time risk signals, “sign-in risk”, reflecting risk related to this specific sign-in, and “user risk” reflecting a broader risk related to the user. All too often these signals are not evaluated. Requiring “risky” users to perform additional actions to verify their authenticity is an effective control.

If Intune is used for management of devices, the use of the “Device Compliance” signal can meaningfully reduce risk by requiring devices to be up to date with active security tooling before accessing sensitive data.

Forgotten scenarios and exclusive policy design

So you’ve done it all: naming convention? Enforced. Trusted locations? Removed. Exclusion management? Implemented. Your organisation has secured all scenarios for authentication on Windows, iOS, Android and macOS endpoints? Great. What about Linux or worse, ‘unknown’ endpoints?

Commonly we witness scenarios where customers have made great efforts to secure authentication scenarios that their users routinely undertake – think browser access on a personal device or a managed Windows endpoint. However, attackers don’t behave like users: they’re going to use any and all means available to attempt to breach the environment. Because of this, we need to think like an attacker and ensure that we don’t accidentally leave the side door open for them.

How does one do this with Conditional Access though?

• Block device code flow: this feature is rarely used and should be permitted on an as needed basis, not by default.
• Block unused or unknown operating systems: only permit the operating systems that you support in the environment.
• Restrict Azure and Microsoft 365 administrative API access: only specific users and devices need access to this.
• Consider missed scenarios: while you may have implemented controls on iOS and Android client apps, do browser sessions have applicable controls applied?

While an attacker would still need valid credentials and potentially meet a MFA challenge, as CyberCX’s 2025 Threat Report highlighted, such challenges are not slowing attackers down. Thus, if we can prevent access to endpoints that a user should never need to access, this is yet another layer added to the security perimeter.

Not monitoring policy effectiveness

Organisations often lack awareness on the effective coverage levels of their Conditional Access policy. Metrics such as “percentage of sign-in events in scope for policy” or “percentage of sign-in events with MFA” are not tracked. CyberCX often encounters Conditional Access policy where actual configuration does not match design intent, due to mistakes related to policy scope and exclusions.

Entra ID provides an “Insights and Reporting” feature, organisations should review this information on a regular basis, checking that policy is functioning as intended and capturing sign-in events.

Putting it all together

Conditional Access is an ever-evolving tool — it shouldn’t be viewed as a set and forget security control. Microsoft continue to make improvements to its capabilities, thus requiring continual investment from security teams to ensure the most relevant policies are in place to secure the organisation.