Docs

Appearance

Entra Conditional Access Policy Reference ​

Overview ​

Conditional Access (CA) policies are Entra ID's primary access control layer. They evaluate every sign-in against a set of conditions (who, what app, what device, what risk level) and decide whether to allow, require MFA, or block the request.

Owner: Rory — CA policy changes require Rory review.
Do not modify CA policies without understanding the blast radius. A misconfigured policy can lock all users out of all apps. Always use report-only mode first, and always verify break-glass exclusions before enabling.

Break-Glass Account Exclusion ​

Critical: All CA policies must exclude the break-glass accounts:

  • cirius-breakglass@ciriusgroup.com
  • cirius-breakglass@ciriusdde.com

Without this exclusion, a misconfigured CA policy could lock out the break-glass accounts at the same time it locks out everyone else — leaving no recovery path.

Verify exclusions are in place before enabling any new policy: Entra ID → Security → Conditional Access → [policy] → Users → Exclude → confirm break-glass accounts listed

How to View Current Policies ​

Entra ID Portal → Security → Conditional Access → Policies

Shows all CA policies with their status (On / Off / Report-only) and a summary of conditions and grant controls.

Click any policy to see:

  • Assignments: which users, groups, apps the policy applies to
  • Conditions: device platforms, locations, sign-in risk, user risk, client apps
  • Grant: block, require MFA, require compliant device, or a combination
  • Session: persistent browser session, sign-in frequency

Policy Inventory ​

How to Read This Table ​

FieldMeaning
StatusOn = enforcing; Report-only = logging but not blocking; Off = disabled
AssignmentsWho and what the policy covers
GrantWhat happens when the policy matches

To enumerate the full current policy set:

powershell
# List all CA policies with status
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | Select DisplayName, State |
  Sort-Object DisplayName | Format-Table

Common Policy Patterns at Cirius Group ​

Require MFA — All Users

  • Assignments: All users, all apps
  • Exclude: break-glass accounts, service account exceptions (if any)
  • Grant: Require MFA
  • Purpose: Baseline MFA for all authentications

Block Legacy Authentication

  • Assignments: All users, all apps
  • Conditions: Client apps = legacy auth clients (Exchange ActiveSync, other)
  • Grant: Block
  • Purpose: Legacy protocols don't support MFA — block them entirely

Require MFA — Azure Management

  • Assignments: All users, app = Microsoft Azure Management (portal, CLI, PowerShell)
  • Grant: Require MFA
  • Purpose: Extra protection for cloud infrastructure access

Require Compliant or Hybrid-Joined Device

  • Assignments: All users, specific apps (e.g., SharePoint, Teams)
  • Grant: Require device to be marked compliant (Intune) OR hybrid-joined
  • Purpose: Ensure only managed devices can access sensitive data

Block Sign-In — High User Risk

  • Assignments: All users, all apps
  • Conditions: User risk = High (Identity Protection detected credential compromise)
  • Grant: Block
  • Purpose: Automatic block when Entra Identity Protection flags account as compromised

Require MFA — Risky Sign-In

  • Assignments: All users, all apps
  • Conditions: Sign-in risk = Medium or High (suspicious location, impossible travel)
  • Grant: Require MFA
  • Purpose: Step-up authentication when sign-in looks unusual

Named Locations ​

Named locations define trusted IP ranges that can bypass or reduce CA policy requirements.

Entra ID → Security → Conditional Access → Named locations

Cirius Group named locations typically include:

  • Office network IP ranges (if applicable)
  • Specific IP ranges for service integrations

To view current named locations:

powershell
Get-MgIdentityConditionalAccessNamedLocation | Select DisplayName | Format-List

Do not add broad IP ranges as trusted locations — this bypasses MFA for anyone on that network, including an attacker who has network access.

Report-Only Mode ​

Before enabling a new CA policy, always test it in report-only mode:

  1. Create the policy with State = Report-only
  2. Let it run for 24–48 hours
  3. Entra ID → Sign-in logs → filter by CA policy — see which sign-ins would have been affected
  4. Investigate any unexpected matches (e.g., a service account that would have been blocked)
  5. Add necessary exclusions, then enable the policy

This prevents service outages from misconfigured policies.

Troubleshooting a Sign-In Blocked by CA ​

Step 1 — Check Sign-In Logs ​

Entra ID → Users → [user] → Sign-in logs

Or from Sign-in logs directly: Entra ID → Monitoring → Sign-in logs → filter by username and date

Find the failed sign-in. Click it → Conditional Access tab. This shows:

  • Which policies were evaluated
  • Which policies were satisfied (✓) or failed (✗)
  • The specific requirement that caused the failure

Step 2 — Common Failure Reasons ​

CA FailureLikely CauseFix
MFA required but not completedUser skipped or couldn't complete MFAUser registers MFA or resets method
Device not compliantIntune reports device non-compliantRemediate compliance issue in Intune
Client app not supportedLegacy app (no MFA support)App must be updated or use modern auth
Risky sign-in blockedUnusual location or compromised credential signalVerify identity; reset password if compromised
User not in scopeExpected — policy doesn't apply to this userNo action
Excluded by named locationSign-in from a trusted location bypassed policyExpected behavior — verify location is correct

Step 3 — Temporary Exclusion (Emergencies Only) ​

If a legitimate user is blocked and needs access immediately:

  1. Entra ID → Security → Conditional Access → [policy] → Users → Exclude
  2. Add the user temporarily
  3. Note the reason and time in the Exclude field comment
  4. Schedule removal of the exclusion — do not leave temporary exclusions in place

This is an emergency-only path. The root cause (missing MFA registration, non-compliant device) must be fixed before the exclusion is removed.

Sign-In Risk and User Risk ​

Entra Identity Protection generates risk signals that CA policies consume:

Sign-in risk — per-sign-in anomaly detection (impossible travel, unfamiliar location, malicious IP, anonymous proxy).

User risk — per-user credential risk (leaked credentials, password spray detection).

To view current risk: Entra ID → Security → Identity Protection → Risky sign-ins / Risky users

If a user is flagged as High risk:

  1. Review the risk detections to understand what triggered it
  2. If legitimate compromise: reset password, revoke sessions, investigate
  3. If false positive: dismiss the user risk to clear the flag

Policy Change Process ​

  1. Draft the change — document which users, apps, and grant controls are affected
  2. Create in report-only mode first
  3. Monitor report-only logs for 24–48 hours
  4. Enable the policy
  5. Monitor sign-in logs for 1 hour after enabling — watch for unexpected blocks
  6. Document the change in the monthly security review

Never enable a CA policy without verifying break-glass exclusions.

Document History ​

DateChangeAuthor
May 2026Initial draft — break-glass exclusion requirement, policy inventory (common patterns), named locations, report-only testing, troubleshooting, risk-based policies, change process.Rory

Internal use only — Cirius Group