Identity-First Security: Replacing Perimeter Thinking with Conditional Access

Every Microsoft 365 tenant we audit either has too few Conditional Access policies (and nothing is protected) or too many badly-designed ones (and half the company is locked out at random). The practical middle is a stack of 10-12 well-designed policies that produce defensible security without operational friction.

This is the practitioner write-up. The policy stack we deploy by default, the rollout sequence that does not break the business on day one, the break-glass procedure that survives an outage, and the operational discipline that keeps the stack honest over 18 months.

What Conditional Access actually does

Conditional Access (CA) is Entra ID's policy engine. Every authentication request runs through the policy stack. Each policy evaluates conditions (user, application, device, location, risk) and produces an action (allow, allow-with-MFA, allow-if-device-compliant, block).

The model is "if-then": if these conditions are met, then apply these controls. Multiple policies can match a single sign-in; their controls are combined (all required controls must be satisfied).

This sounds simple. The complexity comes from edge cases: service accounts that cannot do MFA, legacy applications that do not support modern auth, B2B guests with weaker identities, break-glass scenarios, the inevitable Microsoft 365 outage. The 10-12 policy stack handles each.

The 10-policy baseline stack

Numbered for reference and rollout order. Each policy gets its own naming convention: CAxx-AudienceDescriptor-Action.

CA01 — Block legacy authentication

Name: CA01-AllUsers-BlockLegacyAuth
Assignment:
  Users: All users
  Cloud apps: All cloud apps
Conditions:
  Client apps: Other clients (legacy authentication clients)
Access control:
  Block access

The foundation. Until this is enforced, the rest of the stack has a bypass route. Inventory legacy clients first; communicate; enforce.

CA02 — Require MFA for all users on all cloud apps

Name: CA02-AllUsers-RequireMFA
Assignment:
  Users: All users
  Exclude: Break-glass accounts; service accounts in dedicated group
  Cloud apps: All cloud apps
Conditions: (none, applies always)
Access control:
  Grant → Require multi-factor authentication

The bedrock policy. Every user, every app, MFA. The exclusion list is short and tightly governed (more below).

CA03 — Phishing-resistant MFA for admin roles

Name: CA03-AdminRoles-RequirePhishResistantMFA
Assignment:
  Users: Directory roles → Global Admin, Privileged Auth Admin, User Admin,
         Conditional Access Admin, Security Admin, Exchange Admin,
         SharePoint Admin, Teams Admin, etc. (the standard 12+ admin roles)
  Cloud apps: All cloud apps
Access control:
  Grant → Require authentication strength: Phishing-resistant MFA

FIDO2 / Windows Hello for Business / certificate-based authentication. Roll out after FIDO2 key procurement. Every admin role must have at least one phishing-resistant method registered before this policy enforces.

CA04 — Block sign-ins from disallowed locations

Name: CA04-AllUsers-BlockDisallowedCountries
Assignment:
  Users: All users
  Exclude: Break-glass accounts; documented exception group
  Cloud apps: All cloud apps
Conditions:
  Locations → Include: All locations
              Exclude: Allow-listed countries
                       (named locations defined per geofence)
Access control:
  Block access

The geofence is the allow-list (where you do business + countries employees travel to). Excluded employees (occasional travellers to non-allow-listed countries) get added by ticket workflow with documented justification + time-bound exception.

CA05 — Block high sign-in risk; MFA on medium

Name: CA05-AllUsers-SignInRiskHigh-Block
Conditions:
  Sign-in risk → High
Access control: Block access

Name: CA05b-AllUsers-SignInRiskMedium-MFA
Conditions:
  Sign-in risk → Medium
Access control: Grant → Require MFA

Requires Entra ID P2. The sign-in risk signal combines impossible-travel detection, leaked-credentials match, anonymous-IP detection, and behaviour anomaly. High-risk sign-ins are almost always actual compromises; blocking is correct.

CA06 — User risk requires password change

Name: CA06-AllUsers-UserRiskHigh-PasswordReset
Conditions:
  User risk → High
Access control:
  Grant → Require password change + Require MFA

User risk is a cumulative score (leaked creds, multiple suspicious sign-ins over time, etc.). High user risk triggers password reset workflow. The MFA requirement prevents the attacker from completing the reset themselves.

CA07 — Require compliant device for sensitive applications

Name: CA07-AllUsers-SensitiveApps-RequireCompliance
Assignment:
  Users: All users (or specific high-privilege groups)
  Cloud apps: SharePoint Online, Exchange Online, Teams,
              Office 365, [your sensitive line-of-business apps]
Conditions:
  Device platforms: Windows, macOS, iOS, Android
Access control:
  Grant → Require device to be marked as compliant
       OR Require hybrid Azure AD joined device

The bridge between identity and device. A user with valid creds on an unmanaged personal laptop cannot reach SharePoint. Requires Intune (or equivalent MDM) and a published device-compliance policy.

CA08 — Guest users require MFA + compliant device

Name: CA08-GuestUsers-RequireMFAAndCompliance
Assignment:
  Users: Guest or external users → All guest and external users
  Cloud apps: All cloud apps
Access control:
  Grant → Require MFA + Require compliant device
       OR Require approved client app

B2B guests authenticate via their home tenant. Without this policy, a guest with weak MFA at their home tenant is a weak link in yours. The policy forces them to satisfy your bar regardless.

CA09 — Mobile devices require app protection

Name: CA09-AllUsers-Mobile-RequireAppProtection
Assignment:
  Users: All users
  Cloud apps: Office 365
Conditions:
  Device platforms: iOS, Android
  Client apps: Mobile apps and desktop clients
Access control:
  Grant → Require app protection policy
       AND Require approved client app

For BYOD-leaning estates. App-protection policies (Mobile Application Management / MAM) wrap Office mobile apps in encryption, copy-paste restrictions, and selective wipe — without requiring full device enrolment. The lighter-touch alternative to full MDM for personal phones.

CA10 — Terms of use acceptance at first sign-in

Name: CA10-AllUsers-RequireTermsOfUse
Assignment:
  Users: All users
  Exclude: Break-glass accounts
  Cloud apps: All cloud apps
Access control:
  Grant → Require terms of use

Audit-trail requirement, not a security control per se. The auditor wants to see evidence that every user accepted the AUP. Conditional Access produces the evidence.

The two policies most teams add later

CA11 — Browser-only access for unmanaged devices

For estates that want to allow personal-device access to certain apps but restrict download / save / print. Combined with App-Enforced Restrictions in SharePoint, produces browser-only sessions with no offline copies.

CA12 — Service account isolation

Service accounts (where unavoidable) get their own policy: source-IP allow-list, no MFA (because they cannot do it), no interactive sign-in allowed, time-of-day restrictions. The trade-off is documented and time-bound.

The break-glass account architecture

Every policy stack needs an emergency exit. Configure 2-3 break-glass accounts that are excluded from every Conditional Access policy. These accounts are the only way back in if the policy stack itself becomes the problem (e.g., Microsoft 365 MFA service outage).

Break-glass account configuration

1. Cloud-only Entra ID accounts (not synced from on-prem AD).
2. Username pattern that does not match employee naming convention.
3. Very long, random passwords (60+ characters). Stored in a sealed envelope or a vault that requires two-person approval to access.
4. Global Admin role assigned permanently (not via PIM — PIM itself can fail).
5. FIDO2 key in a physical safe, separate from the passwords.
6. Excluded from every Conditional Access policy (in the policy's "Exclude" section, never relying on group membership which can drift).
7. Alerting: any sign-in to a break-glass account pages the security team immediately.
8. Quarterly test: confirm the account can sign in successfully without using anyone's documented procedure.

The rollout sequence that does not break the business

Six weeks for a 200-seat company with no prior CA policies. Faster if there are some policies to build on; slower if the user base is geographically distributed or includes many BYOD personas.

Week 1: Foundation + inventory

• Inventory: list all users, all admin roles, all applications, all devices (managed + unmanaged), all locations.
• Define the geofence (countries where you do business + travel patterns).
• Create break-glass accounts; document the procedure; secure the credentials.
• Configure named locations (office IPs, geofence countries).
• Configure authentication strengths (FIDO2 / phishing-resistant MFA).
• Configure terms of use document.

Week 2: Deploy in Report-only mode

• Deploy all 10 policies in Report-only mode.
• Monitor sign-in logs daily. Filter on "Result: Report-only [policy name] would have [action]".
• Identify edge cases: service accounts that need exclusion, legacy clients that need migration, geofence exceptions that need approval.

Week 3: Pilot enforcement on IT team

• Enable CA01-CA03 in "On" mode for the IT team only.
• This is the safest pilot — the IT team can self-remediate if their own policies lock them out.
• Validate the break-glass account works.
• Capture lessons.

Week 4: Broader enforcement

• Enable CA01-CA06 for all users in "On" mode.
• Communicate broadly. Provide self-help docs ("if you see this message, here is what to do").
• Staff a "CA helpdesk" channel for the first week.

Week 5: Device + guest policies

• Enable CA07 (compliant device for sensitive apps). Coordinate with Intune compliance state.
• Enable CA08 (guest user requirements). Communicate with partner companies whose guests are affected.
• Enable CA09 (mobile app protection). Coordinate with Intune app-protection policies.

Week 6: Audit + governance

• Enable CA10 (terms of use).
• Document the policy stack with naming, rationale, exclusions per policy.
• Establish the operating cadence (see below).
• Hand over to the operate team.

The "Microsoft 365 MFA service outage" question

What happens if the MFA service itself is unavailable? Conditional Access fails closed — sign-ins requiring MFA cannot complete. The team is locked out.

This is the scenario the break-glass accounts solve. The break-glass account is excluded from all policies; it can sign in without MFA; the team uses it to disable the relevant Conditional Access policy until the MFA service recovers, then re-enables the policy.

Document this procedure. Test the procedure quarterly. Make sure the people who would need to execute it are reachable on weekends.

The operational cadence

Conditional Access policies are not write-once. The policy stack accumulates entropy: new applications get added without policy coverage, users get added to exclusion groups and forgotten, geofence allow-lists drift from business reality.

Weekly

• Review report-only data on any policies still in pilot.
• Review blocked sign-ins for false positives.
• Review exclusion group memberships for stale entries.

Monthly

• Sign-in log review: top blocked countries, top failed MFA users, anomaly patterns.
• Break-glass account test (sign in successfully, log out, verify no alerts missed).
• New application onboarding review: any new app deployed last month covered by appropriate policies?

Quarterly

• Full policy stack review. Each policy still needed? Each exclusion still justified?
• Geofence allow-list refresh against current business locations.
• Admin role inventory: who has each admin role, are PIM activations being used?
• Authentication method audit: which users still have weak MFA methods (SMS) registered?

Annually

• Full Conditional Access design review against threat model and business changes.
• Tabletop: what happens if the MFA service is down? If an admin's FIDO2 key is lost? If a guest user is compromised?

The integration with risk-based access

For Entra ID P2 estates, Identity Protection produces sign-in-risk and user-risk scores. The CA stack consumes those scores (CA05, CA06).

The non-obvious calibration: risk scores are noisy in the first weeks of operation. The platform is still building user-behaviour baselines. Expect false positives in weeks 1-4. Tune the policy actions (warn vs block) based on the false-positive rate. By week 8 the signal-to-noise ratio stabilises.

The licensing reality, condensed

For regulated SMB, M365 E5 (which includes Entra P2 + Intune + the rest) is usually cleaner than assembling the parts.

What we have learned from a dozen rollouts

1. The 1-2 week Report-only phase is not optional. Every rollout that skipped it produced helpdesk pain in week 1 of enforcement.
2. The break-glass account procedure has to be tested before you need it. Three rollouts found bugs in their procedure on the first test.
3. The exclusion groups grow. Without quarterly cleanup, "temporary exclusion for the migration project" becomes "permanent exclusion that nobody remembers the reason for".
4. The communication matters as much as the technology. Users who know what to expect submit fewer helpdesk tickets and complain less about the new friction.
5. The geofence is more useful than expected. Country-based blocking catches more credential-stuffing and password-spray attempts than risk-based policies do. Free and effective.
6. Risk-based policies need patience. The first month is noisy; the third month is signal. Do not abandon them at week 4 because of false positives.

Real outcomes from a recent rollout

A 280-seat hybrid-work company, M365 E5 estate, no prior structured Conditional Access. Six-week rollout. Post-rollout (3 months in):

• Sign-ins blocked by CA policies per month: 4,200 (across all policies combined)
• Confirmed credential-compromise events caught: 8
• Risky sign-ins automatically remediated: 24
• Failed MFA attempts on admin accounts (with subsequent investigation): 11
• Helpdesk tickets related to CA policies: 12 in first month, 4 in third month
• Secure Score improvement: +18 points
• Compliance evidence pack generated for the ISO 27001 audit: complete

The one paragraph version

A practical Conditional Access stack is 10-12 well-designed policies covering legacy auth, MFA, phishing-resistant MFA for admins, geofence, sign-in risk, user risk, device compliance, guest users, mobile app protection, and terms of use. The rollout sequence (inventory → Report-only → IT pilot → broader enforcement → device + guest → audit) is six weeks for a 200-seat company. Break-glass accounts are non-negotiable infrastructure with a tested procedure. The operational cadence (weekly / monthly / quarterly) is what keeps the stack honest over 18 months. Licensing reality: Entra P1 for foundation, P2 for risk-based policies, M365 E5 cleanest for regulated estates.

If you want the rollout done + ongoing operate cadence, that is the engagement shape. Microsoft 365 Defender includes the CA policy stack design + rollout as part of every engagement. The Microsoft 365 Management service covers the ongoing operate cadence. The free Bloodbath Scan includes a Conditional Access posture assessment as part of the security baseline.