How to Rationalise Your Entra Conditional Access Policy Estate Safely

In this blog post How to Rationalise Your Entra Conditional Access Policy Estate Safely we will explain how to turn a growing collection of access rules into a simpler, safer and more manageable security framework.

If your business has used Microsoft 365 for several years, you may have dozens of policies created by different projects, employees and IT providers. Some overlap, some contain unexplained exceptions, and others have names such as “New MFA Policy” even though they were created three years ago.

The result is more than an untidy administration screen. A complicated policy estate can create security gaps, increase support costs and make even a small change feel risky.

What Entra Conditional Access policy plans actually do

Microsoft Entra ID is the identity service behind Microsoft 365. It verifies users and controls how they sign in to services such as Outlook, Teams, SharePoint and Azure.

Conditional Access is its decision engine. It checks signals including the user, application, device, location and level of risk, then decides whether to allow access, request multi-factor authentication or MFA, require a secure device, limit the session or block the attempt.

Traditionally, every Conditional Access policy has its own users, applications, conditions, exclusions and access requirements. As more policies are added, the same settings are often copied repeatedly.

Microsoft’s newer Conditional Access policy plans let administrators organise related rules under a shared plan. Common assignments and exclusions can be defined once, while individual rules handle differences between devices, applications or access scenarios.

As of October 2026, policy plans are still a preview feature. That means they are useful for planning and controlled testing, but businesses should not treat them as a reason to rush into a full production migration without proper validation.

Why policy sprawl becomes a business risk

Imagine that your emergency administrator accounts must be excluded from policies to prevent a total lockout. If that exclusion is copied across 25 separate policies, one missed update can leave the business without a reliable recovery path.

Duplicated rules also make troubleshooting harder. When an employee cannot open a critical application, the support team may need to examine several overlapping policies before finding the actual cause.

This increases downtime and support costs. It also makes it harder for leadership to confirm whether access controls support the Essential Eight, the Australian Government’s cybersecurity framework that many organisations use to reduce cyber risk.

Conditional Access can support Essential Eight requirements around MFA and restricted administrative access. However, having many policies does not automatically mean those controls are effective or consistently applied.

Start with outcomes rather than existing policy names

A rationalisation project should not begin by dragging old policies into new folders. First decide which business security outcomes the environment needs to deliver.

Most organisations can group their requirements into a small number of objectives:

• Protect standard employees with MFA and appropriate device checks.
• Protect administrators with stronger controls because their accounts can change systems and security settings.
• Control unmanaged devices so personal or unknown computers cannot freely download company information.
• Manage guests and contractors without giving them the same access as employees.
• Block outdated sign-in methods that attackers can use to bypass modern security controls.
• Respond to risky sign-ins when Microsoft detects unusual or suspicious activity.

Once these outcomes are clear, your team can determine which existing policies support them, which policies duplicate other controls and which rules no longer have a valid purpose.

Our guide to cleaning up Conditional Access without locking out users explains how to build that initial inventory safely. Policy plans are the next step: designing a structure that is easier to operate after the clean-up.

Use shared conditions carefully

The main benefit of a policy plan is that settings shared by every rule can be managed in one place. For example, a workforce device plan could target all employees while excluding approved emergency access accounts.

Individual rules could then apply different controls to Windows computers, mobile devices and browser sessions:

Plan: Workforce device access

Shared scope:
- Include all employees
- Exclude emergency access accounts
- Protect Microsoft 365 services

Rules:
- Windows and macOS: require a compliant company device
- iOS and Android: require approved application protection
- Unmanaged browser: allow limited web access only

A compliant device is one that meets your company’s security requirements. Microsoft Intune, which manages and secures company computers and mobile devices, can check factors such as encryption, supported operating systems and required security settings.

The important rule is to share only conditions that genuinely apply to every scenario. If contractors, administrators or certain applications need different treatment, forcing them into one shared structure can make the plan harder to understand rather than simpler.

For more on the device relationship, see how Conditional Access and Intune work together.

Do not assume a plan removes overlapping controls

Policy plans organise rules, but they do not automatically resolve conflicts. Each applicable rule is still evaluated, along with any traditional Conditional Access policies that remain enabled.

If one rule requires MFA and another requires a compliant device, the user may need to satisfy both. If any applicable policy blocks access, the sign-in can still be stopped.

This is why rationalisation requires more than a neat naming convention. Your team must map how policies combine for employees, administrators, contractors, guests, service accounts and emergency access accounts.

Common design problems are covered in our article on Conditional Access mistakes that put Microsoft 365 at serious risk.

Test each transition before enforcing it

Never replace several live policies with a new plan in one step. A safer process is to build the proposed structure alongside the existing controls and test it against real sign-in patterns.

1. Export the current configuration. Keep a restorable record of every policy, assignment, exclusion and control.
2. Build the proposed plan without immediate enforcement. Document what each shared condition and rule is meant to achieve.
3. Use report-only mode where supported. This records what the rule would have done without fully enforcing the decision.
4. Run What If simulations. Microsoft’s What If tool estimates which rules would apply to a selected user, device and application scenario.
5. Pilot with representative users. Include office staff, remote employees, executives, administrators and contractors.
6. Move in stages. Disable or replace old policies only after the new structure has produced the expected results.

Emergency access accounts should be tested separately and monitored. They are your last route back into the environment if an access policy is configured incorrectly.

A practical example of the business impact

Consider a 200-person professional services company with 30 Conditional Access policies. Six require MFA, four contain slightly different administrator protections, and several repeat the same emergency account exclusions.

A device policy change takes hours because the IT team must compare multiple rules and confirm that contractors, executives and mobile users will not be disrupted. Nobody is comfortable removing the old policies, so the collection keeps growing.

After rationalisation, the company may have a smaller set of security objectives, each with documented ownership and clearly separated rules. This reduces change time, makes support investigations faster and gives management clearer evidence that important access controls are operating as intended.

The value is not simply having fewer policies. It is reducing the cost and risk of every future security change.

Give every plan an owner and review date

Even a well-designed policy estate will become messy again without governance. Each plan should have a business purpose, accountable owner, change record and scheduled review date.

Review plans after major application changes, acquisitions, security incidents or changes to working arrangements. At minimum, conduct a structured review every six months rather than waiting until a user lockout or audit exposes a problem.

CloudProInc brings more than 20 years of enterprise IT experience to this work. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations connect Entra, Microsoft 365, Intune, Defender and wider cloud security controls without turning the environment into an unmanageable collection of rules.

If you are unsure whether your Conditional Access policies form a deliberate security strategy or have simply accumulated over time, we are happy to take a practical look at the current setup and identify where it can be simplified—no strings attached.