Entra Conditional Access Policy Plans That Tame Policy Sprawl

In this blog post Entra Conditional Access Policy Plans That Tame Policy Sprawl we will explain how mid-market organisations can simplify access security without opening gaps, disrupting employees or creating another large IT project.

Many businesses reach the same uncomfortable point. Conditional Access started with a few sensible protections, but it has grown into dozens of overlapping rules that nobody feels confident changing.

That creates a business problem, not just an administrative one. Security changes take longer, support issues become harder to diagnose, and one missed exclusion can lock out an administrator or stop employees accessing critical systems.

What Conditional Access policy plans actually do

Microsoft Entra Conditional Access is the security gatekeeper for Microsoft 365 and other connected applications. When someone signs in, it checks signals such as who they are, which application they want to use, whether their device is secure and whether the sign-in appears risky.

It then applies an appropriate control. That might mean asking for multi-factor authentication, requiring a company-managed device or blocking access entirely.

Traditionally, each Conditional Access policy has been configured separately. A business might therefore have different policies for Windows, macOS, iPhones and Android devices, even though all four policies cover the same employees and applications.

Conditional Access policy plans, currently a preview feature, introduce a better organisational model. Common settings are defined once at the plan level, while individual rules handle the differences between scenarios.

Think of a plan as a folder with intelligence. Instead of copying the same users, applications and emergency exclusions into five policies, you define that shared foundation once and place the scenario-specific rules underneath it.

Why policy sprawl becomes a business risk

Policy sprawl rarely happens because an IT team made one bad decision. It develops gradually as new threats, applications, device types, acquisitions and compliance requirements appear.

A new rule is often added because changing an existing one feels risky. After several years, the organisation may have policies created by different internal administrators, consultants and managed service providers, each following a different naming or design standard.

The result is usually more serious than an untidy administration screen:

• Security gaps: One employee group, application or device type may be missing from an important rule.
• Unexpected lockouts: Emergency administrator accounts may be excluded from some policies but not others.
• Higher support costs: Diagnosing why one employee cannot sign in can require checking many overlapping policies.
• Slow business change: Connecting a new application or onboarding an acquired company takes longer because nobody knows what a policy change might break.
• Weak compliance evidence: It becomes difficult to show an auditor which controls apply and who approved them.

If your environment is already difficult to understand, start with our guide on rationalising your Entra Conditional Access policy estate safely. Policy plans are an organisational tool, not a substitute for understanding what your existing rules do.

A practical policy plan model for the mid-market

A 50-to-500-person organisation does not need an elaborate enterprise framework. It needs a small number of clearly owned plans, each connected to a recognisable security outcome.

1. Organise plans around outcomes

Avoid creating a plan called “General Security” and placing everything inside it. A future administrator will have no idea what can safely be changed.

Use clear objectives such as “Protect administrator access,” “Require secure employee devices” or “Control access to finance applications.” This makes ownership, testing and audit reviews much easier.

2. Put only truly shared settings at the plan level

Plan-level settings should apply to every rule beneath them. These might include the employee population being protected, the applications in scope and exclusions for carefully controlled emergency access accounts.

This is where plans can eliminate dangerous duplication. An emergency account added to the shared exclusion list applies across the plan, rather than relying on an administrator to remember the same exclusion in every rule. Individual rules cannot remove plan-level exclusions.

That consistency reduces lockout risk, but it also raises the impact of a mistake. Every shared condition should therefore have a documented reason, owner and approval record.

3. Use rules for genuine differences

Rules underneath the plan should describe the exceptions or variations. For example, Windows and macOS computers might need to meet device compliance requirements, while mobile devices may use different application protection controls.

Microsoft Intune, which manages and secures company devices, supplies important device information to Conditional Access. Our article on how Conditional Access and Intune work together explains why access rules are only as reliable as the device information behind them.

4. Migrate in small groups

Do not attempt to convert the entire policy estate in one weekend. Start with a well-understood group of policies that share the same users, applications or security purpose.

Microsoft’s migration experience can analyse selected policies and propose a plan structure without immediately changing the original policies. That provides a useful starting point, but the suggested structure still needs human review and business context.

A sensible first project might consolidate device-access policies for ordinary employees. Privileged administrator access, external users and critical service accounts can follow after the team has proven its testing and rollback process.

Test the user journey, not just the configuration

A policy can look correct in the administration portal and still cause problems in real life. Employees may access Microsoft 365 from managed laptops, personal mobiles, meeting-room devices, virtual desktops and third-party applications.

Testing should cover what people actually do. Include office and remote access, new device enrolment, password resets, administrator tasks and access to important applications such as payroll or customer management systems.

Use report-only mode, which records what a policy would have done without enforcing it, before turning on new controls. The What If tool can also simulate how policies apply to selected sign-in scenarios.

Then roll out to a pilot group before broader enforcement. Our guide to cleaning up Conditional Access without locking out users covers the operational safeguards in more detail.

A typical mid-market scenario

Consider a 200-person company with separate Conditional Access policies for Windows, macOS, iOS, Android, contractors and senior managers. Each policy contains slightly different employee groups, application selections and emergency exclusions.

When the company changes its emergency administrator accounts, the IT team must update every relevant policy. Missing one creates either a security gap or a future lockout risk.

Under a plan-based design, the company could create a “Secure workforce devices” plan. Shared employee targeting, protected applications and emergency exclusions would sit at the plan level, while individual rules would handle the requirements for computers, mobile devices and approved exceptions.

The immediate benefit is not simply fewer items on a screen. The company gets faster security changes, lower support effort, clearer accountability and a design that is easier to explain to management and auditors.

How this supports Essential 8 obligations

Conditional Access policy plans do not make an organisation compliant with the Essential 8, the Australian Government’s cybersecurity framework that many organisations use to reduce common attack risks.

They can, however, make identity controls such as multi-factor authentication more consistent and easier to demonstrate. Clear plans, named owners, testing records and regular reviews provide stronger evidence than a collection of unexplained policies.

For leadership teams, that means fewer surprises during customer security reviews, cyber insurance applications and formal compliance assessments.

Do not treat preview as automatic approval

Policy plans are currently in preview, which means Microsoft may still change their capabilities before general release. Organisations should assess preview features against their own risk appetite, support requirements and change-control obligations.

A practical approach is to document the target design now, test plans in a controlled environment and migrate lower-risk policy groups first. Critical controls should not be redesigned simply because a new feature is available.

What good governance looks like

Every plan should have a clear business purpose, accountable owner, review date and rollback process. Changes should be tested, approved and recorded rather than made directly in response to a support ticket.

CloudProInc applies this practical approach using more than 20 years of enterprise IT experience across Microsoft Entra, Microsoft 365, Intune, Defender, Azure and Wiz. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we focus on security controls that remain manageable after the project is finished.

Conditional Access policy plans can help tame policy sprawl, but the real outcome is confidence. Your team should know who can access company data, under what conditions and what will happen when the business changes.

If you are not sure whether your current Conditional Access setup is protecting the business or simply creating more complexity, CloudProInc is happy to take a practical look with you — no strings attached.