Should organisations simplify conditional access before expanding it?

Usually yes, if existing policies already cover the main identity, device, and network trust scenarios. Expanding a fragile policy estate adds confusion faster than it adds security. A better approach is to simplify the baseline first, then add only the exceptions that materially change risk.

Why simplification should come before expansion

conditional access works best when each policy has a clear purpose, a narrow trigger, and an obvious exception path. If the baseline is already difficult to explain or troubleshoot, adding more conditions usually increases policy collisions, hidden bypasses, and support burden before it improves security.

The practical question is whether the current policy set already covers the main trust decisions, such as user, device, location, risk level, and application sensitivity. If it does, the next improvement is usually simplification and normalization, not another layer of logic.

A simpler baseline also makes change control safer. Teams can see which rule caused a block, which exception was intended, and which control gap still needs to be addressed. That is harder to do when the policy estate has grown through ad hoc additions and one-off responses.

When a conditional access estate is too fragile to extend

Fragility shows up when small changes have outsized side effects. Common signs include overlapping policies with unclear precedence, frequent emergency exclusions, inconsistent naming, and exceptions that no one can explain without checking historical tickets or tribal knowledge.

In that state, expansion tends to produce false confidence. The environment may look more controlled because more rules exist, but the real outcome is often less predictability, weaker troubleshooting, and more opportunity for administrators to make compensating mistakes.

That is why baseline cleanup matters before adding new policy logic for new apps, new device classes, or new risk signals. A policy estate should be understandable enough that operators can predict how a request will be treated before they test it in production.

What “simplify first” means in practice

Simplification does not mean removing useful controls. It means consolidating duplicated rules, removing legacy exceptions, and aligning policies around the few trust signals that genuinely change the decision. For many organisations, that means starting with identity assurance, managed device posture, network boundary assumptions, and application sensitivity.

It also means separating structural controls from temporary workarounds. If an exception is compensating for a missing device posture signal, a broken app pattern, or an incomplete onboarding process, that exception should be treated as a control debt item, not a permanent feature of the policy model.

For a deeper identity-centric view of this design problem, the Zero Trust Identity Guide is useful because it frames conditional access as part of a phased trust model rather than a pile of isolated rules. Where the real issue is policy sprawl around directory and sign-in controls, the Identity Provider and SSO Security Guide helps connect access policy to session and federation decisions. If the estate is tied to AD and Entra ID operations, the Active Directory and Entra ID Hardening Guide provides the adjacent hardening context that often determines whether conditional access can stay simple.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Conditional access policy sprawl affects who can access what and under which conditions.
	AC-6 — Least Privilege	Baseline simplification supports narrower access decisions and fewer unnecessary exceptions.
	IA-2 — Identification and Authentication (Organizational Users)	Conditional access depends on reliable user authentication signals before policy branching.
Recommendation — Consolidate access rules so account access decisions remain explicit and manageable. Reduce standing access paths and keep exceptions tightly bounded to business need. Verify user authentication strength before layering additional access conditions.

Practitioner Guidance

What to verify: Confirm that the current policy set has a small number of clearly documented decision points, with no overlapping rules that require tribal knowledge to interpret. If two policies answer the same trust question differently, the design is already too complex.

Decision rule: If the baseline cannot be explained to an administrator, help desk analyst, and auditor in the same way, simplify before adding more conditions. Expand only when the new condition materially changes access risk and cannot be handled by an existing control.

What good looks like: A healthy estate has predictable outcomes, minimal exceptions, and change requests that improve clarity rather than adding another special case. The best sign of maturity is not policy count, but the ability to enforce intent without constant manual interpretation.

Practitioner takeaway: Conditional access should become more selective, not more ornate. Simplify the baseline until the policy behaviour is stable and explainable, then add only the extra logic that clearly changes the risk decision.