Skip to main content

Zero Trust Conditional Access: Phased Enforcement & Break-Glass Architecture

The "Why" Before the "How": Beyond Perimeter Firewalls​

In legacy networking, if a connection originated from inside the corporate office subnet or VPN pool, it was implicitly trusted. Today, with distributed remote endpoints and cloud-hosted SaaS applications, network location is an insufficient security boundary. Compromised credentials bypass firewall rules effortlessly.

Microsoft Entra Conditional Access acts as the intelligent policy engine for Zero Trust:

Signals (Identity, Device, Location, Real-Time Risk) ➔ Verification Decision ➔ Enforced Controls (MFA, Compliant Device, Block)

However, poorly planned Conditional Access policies are the #1 cause of catastrophic administrative lockouts. Before enforcing any access boundary, you must establish an ironclad Break-Glass Emergency Access Architecture and execute a disciplined Report-Only phased rollout.

1. The Break-Glass Emergency Account Architecture​

Before creating a single Conditional Access policy, you must guarantee that an unforeseen configuration error, third-party MFA outage, or federated identity glitch cannot lock administrators out of the tenant.

Design Principles for Break-Glass Accounts​

  1. Cloud-Only Accounts: Never synchronize break-glass accounts from on-premises Active Directory. They must live natively in Entra ID (bg-admin01@yourtenant.onmicrosoft.com).
  2. Permanent Exclusion: Every single Conditional Access policy must explicitly list the Break-Glass security group under Exclude > Users and groups.
  3. Phishing-Resistant Authentication: Use hardware FIDO2 security keys (YubiKeys) stored in physical security safes, with 30+ character random passphrases split into sealed envelopes.
  4. No Phone/App Dependencies: Never register break-glass accounts with cellular SMS or Microsoft Authenticator apps that rely on external telecom or cloud push notification daemons.
  5. Real-Time Automated Alerting: Create an Azure Monitor / Log Analytics alert rule triggered the second an emergency account performs a successful logon.
// Log Analytics KQL Alert Query: Detect Break-Glass Account Activity
SigninLogs
| where UserPrincipalName in ("bg-admin01@lab.dariocruz.dev", "bg-admin02@lab.dariocruz.dev")
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ClientAppUsed, ResultType

2. Phased Rollout Blueprint: Report-Only First​

Never click On when building a Conditional Access policy. Operating in production demands a three-phase transition:

flowchart LR
    Phase1["Phase 1: Report-Only Mode<br>(Audit Telemetry for 14 Days)"] --> Phase2["Phase 2: Pilot Group Enforcement<br>(IT & Endpoint Engineers)"]
    Phase2 --> Phase3["Phase 3: Organization-Wide Enforcement<br>(Excluding Break-Glass)"]

Why Report-Only Mode Matters​

In Report-Only mode, Entra ID evaluates the policy during real user authentications and records the theoretical decision in the sign-in logs without actually prompting for MFA or blocking the connection. This allows engineers to query Log Analytics and identify:

  • Legacy mail clients that cannot negotiate modern authentication.
  • Scheduled automation scripts or service accounts that would break.
  • False positive location exclusions.

3. Baseline Enterprise Policy Matrix​

We deploy a structured four-policy baseline:

Policy IDPolicy NameAssignmentsConditionsGrant Controls
CA001Block Legacy AuthenticationAll Users (Exclude Break-Glass)Client Apps: Exchange ActiveSync, Other clients (POP, IMAP, SMTP)Block access
CA002Require MFA for Cloud AppsAll Users (Exclude Break-Glass)All Cloud AppsRequire Multifactor Authentication
CA003Require Compliant Device or Hybrid JoinAll Users on Windows/macOSDevice Platforms: Windows, macOSRequire device to be marked as compliant OR Require Microsoft Entra hybrid joined device
CA004Strict Admin Elevation & Phishing-Resistant MFADirectory Roles (Global Admin, Security Admin, Intune Admin)All Cloud Apps & Azure ManagementRequire Phishing-Resistant MFA (FIDO2) + Session: Sign-in frequency 1 hour

4. Verification: Trust, but Verify​

Before promoting a policy from Report-Only to Enforce:

1. Test Scenarios Using the "What If" Tool​

  1. Navigate to Microsoft Entra ID > Security > Conditional Access > What If.
  2. Select a target user (e.g., standard employee account), target cloud app (e.g., Office 365), and device platform (e.g., Windows).
  3. Set the IP address to an external untrusted network and click What If.
  4. Review Policies that will apply versus Policies that will not apply. Ensure CA002 triggers MFA and that your Break-Glass exclusion is respected.

2. Inspecting Live Sign-In Telemetry​

# Query recent Sign-in logs for Conditional Access evaluation
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'dario@lab.dariocruz.dev'" -Top 5 | 
    Select-Object CreatedDateTime, Status, ConditionalAccessStatus