DE

Microsoft Best Practices - Entra ID

Plan Conditional Access properly: why resource exclusions and report-only matter

Practical article on Conditional Access planning, resource exclusions, report-only testing, break-glass and controlled enforcement preparation.

Start Quick CheckBack to best-practice library

Upcoming Conditional Access change: Improved enforcement for policies with resource exclusions

Context

Conditional Access is flexible, but that flexibility can become dangerous. Resource exclusions, legacy special cases and poorly documented policies quickly create a state that nobody can confidently explain.

Typical scenario

A tenant has accumulated several Conditional Access policies over the years. Some apps are excluded, certain user groups are treated differently and nobody knows whether a policy really applies. When Microsoft changes enforcement logic or new risks must be evaluated, uncertainty and operational risk appear.

Technical implementation steps

  1. Export or document all Conditional Access policies and group them by purpose: admin, users, guests, devices, risk and legacy.
  2. Review resource exclusions per policy: which app is excluded, why, who owns the exception and when will it be reviewed?
  3. Use What If analysis to test typical users, admins, guests, service accounts and room accounts against the policies.
  4. Enable new or changed policies in report-only first and review sign-in logs for several days.
  5. Exclude break-glass accounts, but protect them with separate monitoring, strong authentication and regular testing.
  6. Introduce block policies gradually: pilot group first, then business units, then broad enforcement.
  7. After changes, verify whether legitimate apps are blocked or risky sign-ins still pass.

Microsoft best practices in implementation

  • Model policies by purpose: admin protection, user access, device state, risk, external users and legacy.
  • Use report-only consistently before enforcing blocks.
  • Review resource exclusions regularly and require a business reason.
  • Secure, monitor and test break-glass accounts properly.
  • Use sign-in logs and What If analysis as mandatory inputs for every change.

Common mistakes

  • Combining block policies and broad resources without testing.
  • Never revisiting exclusions.
  • Building policies by incident instead of architecture principles.

Azuric perspective

Azuric would not only read a CA landscape technically, but evaluate it as risk architecture: which policies really protect, which are historical and which exception may become a problem?

Key takeaway

Conditional Access must remain explainable. Only then can security become stricter without harming productivity and operations.

Sources

This article is an original Azuric perspective. The following sources are used as technical references; content is not copied.