Designing Conditional Access Policies in Entra

What Conditional Access is

Conditional Access is the decision engine of Microsoft Entra ID. It works as a series of if-then statements: if a set of conditions is met, then require a control or block access. It is the mechanism that turns raw identity, device and risk signals into enforceable access decisions.

Each policy combines three parts:

• Assignments: who (users and groups), what (applications), and under which conditions (location, platform, risk).
• Grant controls: require MFA, require compliant device, require approved app, or block.
• Session controls: limit sign-in frequency, restrict downloads or enforce browser-only access.

Think in personas, not individual users

Individual policies for every situation become an unmaintainable tangle. The recommended approach is to design around access personas: administrators, internal workers, external workers, service accounts, guests and users on unmanaged devices.

For each persona, define a clear baseline:

Recommended policy structure

Instead of dozens of overlapping policies, keep a lean, consistently named set. A common structure includes:

1. Block legacy authentication for everyone. This is the non-negotiable starting point.
2. Require MFA for administrators, with phishing-resistant methods.
3. Require MFA for all users across cloud apps.
4. Require compliant device to access sensitive data.
5. Risk-based policies that respond to sign-in and user risk.
6. Session controls for unmanaged devices.

Adopt a predictable naming convention, such as persona, platform, control and purpose, so any analyst can grasp a policy's intent in seconds.

Always start in report-only mode

The biggest risk when rolling out Conditional Access is locking legitimate users out. That is why every new policy should be born in report-only mode. In this mode, Entra evaluates the policy and logs what would have happened, without enforcing the control.

The safe rollout flow is:

1. Create the policy in report-only mode.
2. Review the results in the sign-in log for a few days.
3. Adjust exclusions and conditions as needed.
4. Enable the policy in a controlled window.
5. Monitor closely for the first few hours.

Exclusions you cannot forget

Some exclusions are critical so you do not lock yourself out of your own environment:

• Break-glass accounts: at least two emergency accounts excluded from all policies, with long passwords stored securely.
• Directory synchronization accounts, where applicable.
• Service accounts that cannot support interactive MFA, ideally migrated to managed identities.

Monitor these excluded accounts with dedicated alerts, as they represent the largest residual risk.

Frequent mistakes

• Creating conflicting policies that cancel each other out or block unintentionally.
• Enforcing device controls before the fleet is managed by Intune.
• Forgetting mobile platforms when defining platform conditions.
• Not documenting each policy's intent, which hampers audit and review.

Continuous governance

Conditional Access requires upkeep. Establish a quarterly review ritual to validate exclusions, remove obsolete policies and align with new applications. Export the configuration regularly for versioning so changes are traceable and reversible.

Design checklist

• Legacy authentication blocked for everyone.
• Access personas mapped with a clear baseline.
• Every policy tested in report-only mode before enabling.
• Break-glass accounts excluded and monitored.
• Consistent naming and documented intent.
• Quarterly review of policies and exclusions.

RHC, as a Microsoft Solutions Partner, helps design Conditional Access policy sets that balance robust security with a smooth user experience, through phased and monitored rollout.