Lesson 36 — Microsoft Entra Conditional Access Best Practices

Learning objectives

After completing this lesson, you should be able to operate and improve Conditional Access using repeatable best practices.

• Reduce policy sprawl and overlapping intent.
• Use broad coverage with controlled exclusions.
• Protect privileged users and emergency access.
• Apply meaningful naming and documentation standards.
• Validate policy impact in report-only mode.
• Use representative pilots and rollback plans.
• Investigate policy outcomes in Sign-in Logs.
• Review, simplify and retire policies safely.

The operational challenge

Conditional Access environments often begin with a small number of clear policies and gradually become difficult to understand.

New administrators, temporary exceptions, duplicated controls and forgotten report-only policies can create gaps even when every individual policy appears technically valid.

Use a policy architecture

Conditional Access should be managed as a coordinated framework rather than a collection of independent portal objects.

Document baseline controls, specialised controls, exclusions, emergency access and policy ownership before adding more policies.

One policy, one purpose

Each policy should have one clearly stated security outcome.

A policy that mixes unrelated populations, applications, conditions and controls becomes difficult to test, troubleshoot and approve.

Prefer baseline policies

Baseline policies should protect broad populations and resources against common risks such as legacy authentication, missing MFA and weak privileged access.

Specialised policies should exist only when a resource, population or risk condition genuinely requires different treatment.

Avoid policy sprawl

More policies do not automatically create stronger security.

Before creating a new policy, determine whether the requirement can be met by safely updating an existing policy without obscuring its purpose.

Use meaningful policy names

Policy names should communicate scope, resource, control and deployment state without opening the policy.

A consistent naming standard improves reviews, troubleshooting, audit evidence and administrator handover.

Document intent and dependencies

Record why the policy exists, who owns it, what applications depend on it, which exclusions are approved and how success is measured.

Portal configuration alone is not sufficient operational documentation.

Minimise exclusions

Every exclusion is a deliberate reduction in policy coverage.

Use exclusions only where the identity or application cannot satisfy the control and the risk is accepted with a compensating safeguard.

Do not use exclusion groups as storage

Broad groups named “MFA Exempt” or “Conditional Access Exclusions” often accumulate accounts long after the original problem has disappeared.

Each member should have an owner, reason and expiry or review date.

Protect emergency access

Emergency access accounts exist to recover administrative control when normal authentication or policy dependencies fail.

They should be cloud-only, highly privileged, tightly monitored and excluded from restrictive enforced policies where necessary for recovery.

Test emergency access regularly

An emergency account that has never been tested may fail because of expired credentials, unexpected policy scope or operational confusion.

Perform controlled access tests and generate alerts whenever these accounts are used.

Protect privileged identities differently

Administrators should not receive the same minimum access controls as ordinary users.

Use stronger authentication, separate administrative accounts, least privilege and Privileged Identity Management where available.

Use authentication strengths

Authentication strengths allow policies to require selected authentication methods rather than accepting every MFA method as equivalent.

Use phishing-resistant methods for privileged roles and high-value resources wherever operationally possible.

Treat location as context

Named locations can reduce unnecessary prompts or support location-based restrictions, but a trusted network is not proof of a trusted identity or device.

Avoid building the entire access strategy around IP address assumptions.

Use device controls deliberately

Device compliance and join state can strengthen access decisions, but only when device enrolment, health reporting and exception processes are mature.

Test guests, mobile devices, virtual desktops and emergency workflows before broad enforcement.

Report-only is a testing stage

Report-only mode evaluates most policies without enforcing the access controls and records the result in Sign-in Logs.

Every report-only policy should have an owner, testing objective and deadline for enforcement, redesign or removal.

Test alongside enforced policies

New report-only policies should be evaluated with existing enforced policies still active.

This exposes the combined real-world effect rather than analysing the new policy in isolation.

Use representative pilots

A pilot should include different roles, devices, locations, authentication methods, guest scenarios and business applications.

A pilot consisting only of identity administrators creates false confidence.

Define rollback before enforcement

Document how the policy can be disabled, narrowed or replaced if production access fails.

Rollback authority and emergency communication should be agreed before the change window begins.

Monitor Sign-in Logs

Sign-in Logs show whether each Conditional Access policy applied, did not apply, failed, succeeded or was evaluated in report-only mode.

Use the evidence to investigate unexpected prompts, blocks and apparent bypasses.

Monitor for configuration drift

Changes to group membership, application assignments, authentication methods and device management can change policy behaviour without editing the policy itself.

Policy reviews must include these external dependencies.

Use formal change control

Conditional Access changes can affect every user and application in the tenant.

Record the reason, configuration change, test evidence, approver, implementation window and rollback plan.

Retire obsolete policies

Disabled and superseded policies should not remain indefinitely without documentation.

Archive their configuration and approval evidence, then remove them according to the organisation's change process.

Investigation evidence

• Conditional Access policy inventory and states
• Policy creation and modification history
• Included and excluded group membership
• Directory role assignments
• Sign-in Logs and Conditional Access results
• Report-only outcomes
• Authentication details and device state
• Exception register and policy ownership

Operational warning signs

• Policies named Test, Copy or New Policy.
• Report-only policies with no planned decision date.
• Large exclusion groups with no owner.
• Multiple policies implementing the same control.
• Privileged identities covered only by general user policies.
• No recent emergency access test.
• Unexpected policy results in Sign-in Logs.

Common mistakes

• Creating a new policy for every support problem.
• Using exclusions instead of remediation.
• Leaving pilot and report-only policies indefinitely.
• Relying on unclear policy names.
• Failing to test emergency access.
• Reviewing policies without checking group membership.
• Assuming more policies always mean more security.

Best-practice summary

• Manage Conditional Access as one architecture.
• Give every policy one purpose and one owner.
• Prefer broad protection with minimal exceptions.
• Apply stronger assurance to privileged access.
• Use report-only mode with real evaluation criteria.
• Pilot across representative users and workloads.
• Investigate actual policy outcomes in Sign-in Logs.
• Review, simplify and retire policies continuously.