CohenHolmes

Conditional Access Policy Builder

Describe a Conditional Access policy in plain terms and get the equivalent Microsoft Graph conditionalAccessPolicy JSON as you type, a readable summary, and the Entra ID licence tier it needs. Below the builder: how CA connects to Purview, Defender for Cloud Apps and Entra Suite.

This is a learning tool. It builds the JSON so you can see the shape and copy it into your own tenant — it never connects to anything or changes a setting. Treat the output as a starting point: review it in report-only mode first, and check the current Microsoft Conditional Access documentation before you enforce anything, because the schema and the licensing move over time.

Your IDs are yours. Group, app and named-location IDs are specific to your tenant, so this tool emits <PLACEHOLDER> tokens for them — swap in your own before you run the policy. Well-known IDs (admin role templates, the Azure management app, built-in authentication strengths) are filled in, because they’re identical in every tenant.

Fills the form with a known-good starting point — adjust anything below. Based on Microsoft's documented Conditional Access templates.

Basics
Assignments · Users

Adds excludeGroups: ["<YOUR-BREAKGLASS-GROUP-ID>"] — replace with your real emergency access group. Every policy should exclude it.

Assignments · Target resources

The bridge from Purview — sensitivity labels and sensitive SharePoint sites stamp an auth context (c1–c99); this policy steps up on it. Targets a context instead of specific apps.

New to auth context? Where the IDs come from →
  1. Entra admin center → Conditional Access → Authentication context → New authentication context.
  2. Give it a display name (e.g. "Compliant device required") and tick Publish to apps.
  3. Entra assigns a read-only ID — c1, c2, … c99. That short ID is what you paste above.
  4. Tag a resource with it: a Purview sensitivity label, a SharePoint site, a Defender for Cloud Apps session policy, a custom app, or a PIM role activation.
  5. This policy, targeting that context, fires whenever someone hits the tagged resource.
Example: label a SharePoint site "Highly Confidential" → the label requires auth context c1 → a CA policy on c1 requires a compliant device + phishing-resistant MFA. Normal sites are unaffected.
Conditions

Leave all unchecked for "all client apps" (["all"]).

The portal renamed this condition Network; the Graph property is still conditions.locations. "All Compliant Network locations" (Global Secure Access) isn't modelled here.

Leave all unchecked to omit the platform condition.

Risk signal from Purview Insider Risk Management / Adaptive Protection. Emitted as a single string.

Grant controls

Emits authenticationStrength@odata.bind. Can't be combined with "Require multifactor authentication" — that box is ignored while a strength is set.

"Block access" overrides everything else. Require risk remediation (riskRemediation) is Microsoft's current high-user-risk control — it self-applies an authentication strength and sign-in frequency = every time, and works for passwordless users; it's the modern alternative to "Require password change" (which must pair with MFA using AND). "Require approved client app" (approvedApplication) is intentionally omitted — read-only for new/edited policies since 30 June 2026; use "Require app protection policy" instead.

Session controls

Routes the session through the Defender for Cloud Apps reverse proxy for in-session control (download / print / copy / DLP).


          

          

          


          

            
            
          

        

      


    


    
    

      
A baseline model — deploy in order

      

        A coherent starter set, not a parts bin. Each layer builds on the ones above it. Every
        policy: report-only → pilot group → all, and exclude your break-glass accounts from all
        of them. "Load into builder" drops that policy into the form above so you can adjust it.
      


      

        
01Block legacy authenticationall users

        
Why / watch out / rollout
          

            
Why
Legacy auth (POP, IMAP, SMTP AUTH, older Office) can't do MFA or device checks. An MFA-for-all policy blocks it as a side effect, but a dedicated block policy is explicit, auditable, and covers apps you don't gate with MFA. Microsoft's first "Secure foundation" policy.

            
Config
Client apps = Exchange ActiveSync clients + Other clients; grant = Block.

            
Watch out
Scan-to-email MFPs, old scanners, LOB apps on SMTP AUTH, shared mailboxes on legacy clients. Find them first — sign-in logs, legacy protocols, both the interactive and non-interactive tabs.

            
Rollout
Report-only 1–2 weeks, review, then enforce.

          

        

        
      


      

        
02Phishing-resistant MFA for adminsprivileged directory roles

        
Why / assumes / watch out / rollout
          

            
Why
Admin accounts are the highest-value target and the smallest population. Do them first and properly — push and SMS are phishable, so "any MFA" isn't enough here.

            
Assumes
Admins have a phishing-resistant method registered (passkey/FIDO2, Windows Hello, or CBA). Provision before enforcing; a Temporary Access Pass covers the gap.

            
Watch out
Break-glass accounts excluded (long random password in a safe, plus a passkey/CBA that differs from your normal admin method). Service accounts with roles — move to workload identity instead of carving exclusions.

            
Rollout
Pilot with 1–2 admins, then all. Keep TAP available during onboarding.

          

        

        
      


      

        
03Secure the MFA registration surfaceall users

        
Why / how / watch out
          

            
Why
If an attacker phishes a password, the next thing they do is register their own MFA method. Lock registration to a trusted network or a compliant device. Do this before you push everyone to register in policy 4.

            
How
CA policy on the Register security information user action (portal only — user actions aren't modelled in this tool), grant = require MFA / authentication strength + a trusted location or compliant device.

            
Watch out
New starters with no method, off-network — issue a Temporary Access Pass. Report-only telemetry is thin for user-action policies, so validate with a live pilot user.

          

        

      


      

        
04Require MFA (or stronger) for all usersall users, all resources

        
Why / assumes / watch out / rollout
          

            
Why
The broad baseline. Everything below refines it. Target all resources with no exclusions. Once passkey adoption is broad, raise this policy's strength to phishing-resistant for everyone — after enforcement, never before.

            
Assumes
The registration campaign ran; policy 3 is protecting registration.

            
Watch out
Guests (policy 8), break-glass (exclude), non-interactive / service sign-ins.

            
Rollout
Report-only, watch the "would have required MFA" volume, pilot, then all. Most likely to generate helpdesk calls — time it.

          

        

        
      


      

        
05Require a managed device for desktop sessionsbrowser + modern clients

        
Why / assumes / watch out / rollout
          

            
Why
MFA proves who. Device compliance proves the endpoint is patched, encrypted and enrolled. Grant control: compliant device or Hybrid AD joined.

            
Assumes
Intune (or hybrid join) deployed and compliance policies are meaningful. Without that, this just blocks people.

            
Watch out
macOS / Linux, contractors on their own kit (policy 6), kiosk / shared devices. A report-only compliant-device policy triggers repeated certificate prompts on macOS/iOS/Android — exclude those platforms from the report-only version.

            
Rollout
Start with the most sensitive apps (finance, HR, admin portals), expand. Report-only essential.

          

        

        
      


      

        
06Contain unmanaged devicesMFA + short sign-in frequency + no persistent browser

        
Why / optional add / watch out / rollout
          

            
Why
Don't block BYOD outright, but an unmanaged browser session shouldn't last 90 days or leave refresh tokens on a personal laptop. This contains it.

            
Optional add
Conditional Access App Control (Defender for Cloud Apps) to block downloads in-session — keeps data off the device entirely.

            
Watch out
On personal (Entra-registered) devices, unlocking the device doesn't satisfy sign-in frequency, so users get prompted on the interval — a few hours, not minutes, and not "every time" without MFA. Turn off "Remember MFA on trusted devices" first.

            
Rollout
Report-only, then enforce alongside policy 5.

          

        

        
      


      

        
07aRisky sign-in → require MFA + reauthenticateEntra ID P2

        
Why / watch out / rollout
          

            
Why
Catches "the credential works but the sign-in looks wrong" — impossible travel, anonymous IP, leaked credentials. Microsoft's template pairs the MFA requirement with sign-in frequency = every time (target High and Medium).

            
Watch out
Risk policies lock people out unexpectedly more than any other. Users must be registered for MFA before a risky session hits them.

            
Rollout
Report-only 2–4 weeks minimum, review the risk detections, then enforce.

          

        

        
      


      

        
07bHigh user risk → require risk remediationEntra ID P2

        
Why / assumes / rollout
          

            
Why
The account itself looks compromised. Microsoft's current template is the Require risk remediation grant control — it auto-applies an auth strength + reauth and works for passwordless users. The older MFA + secure password change (with AND) still works for password-only estates.

            
Assumes
Entra ID P2. No P2? Skip layer 7 — policies 1–6 stand on their own. Confirm SSPR is working before enforcing the password-change variant.

            
Rollout
Report-only, review, enforce. Load into builder uses the password-change variant.

          

        

        
      


      

        
08Guest & external accessMFA (+ Terms of Use)

        
Why / assumes / watch out
          

            
Why
Guests authenticate in their home tenant; you can't assume they have MFA. Require it at your resource. Terms of Use gives an auditable acceptance (add it in the portal — not modelled here). Microsoft's phased plan does this early; ordering it eighth just reflects that it's a smaller job than the internal rollout.

            
Assumes
Cross-tenant access settings reviewed — you can trust MFA claims from partner tenants to cut prompts.

            
Watch out
B2B one-time-passcode users, guest redemption flows.

          

        

        
      


      

        
09Restrict device code flowall users

        
Why / how / watch out
          

            
Why
No longer optional. Microsoft's line is "block device code flow wherever possible"; it ships in Security Defaults and is a Microsoft-managed policy. Attackers start the flow themselves and social-engineer a user into completing it.

            
How
CA → Conditions → Authentication flows → Device code flow → Block (portal only — not modelled in this tool), with a scoped exclusion for genuine device-code cases. Block authentication transfer on the same screen too.

            
Watch out
Protocol tracking — once a session has used device code flow it stays tracked, so the block can also stop later requests in that session. Report-only first.

          

        

      


      

        Cross-cutting rules
        
    
          
  • Break-glass: two-plus cloud-only Global Admin accounts on .onmicrosoft.com, role permanent-active (not eligible via PIM), excluded from every policy that blocks or restricts sign-in, credentials offline, sign-ins alerted on, a phishing-resistant method that differs from your normal admin sign-in. The mandatory-MFA floor still applies to them.
    • 
          
  • Never straight to ON. Report-only → pilot group → all, every time.
    • 
          
  • Keep disabled contingency policies ready to enable during an identity outage (EM01 - ENABLE IN EMERGENCY: ...). Turn on protected actions so editing a CA policy needs fresh MFA.
    • 
          
  • Name policies consistently (sequence, apps, response, who, when); encode the owning team too. 240 policies per tenant — consolidate.
    • 
          
  • Export the JSON to source control. Leave resilience defaults on. Review quarterly.
    • 
        

        
Deliberately left out: location / per-country blocking as a primary control (a proxy or VPN changes the IP Entra sees — Microsoft does recommend "allow known countries, block the rest", but it's a real project); a policy per app (group sensitive apps and target the group). Blocking unknown device platforms is a reasonable early add — Microsoft recommends it.

      

    


    
    

      
How Conditional Access connects to the rest

      

        CA is the enforcement point at sign-in. Other services feed it signals or ride on its
        session controls — this is where a policy stops being a standalone rule and becomes part
        of a model.
      

      

        
          
ServiceHow it connectsIn the policy

        
        
          

            Intune
            Device compliance state feeds the compliant-device grant control.
            grantControls.builtInControls: ["compliantDevice"]
          

          

            Defender for Cloud Apps (MDCA)
            Conditional Access App Control routes the session through MDCA's proxy — monitor, block downloads, or a custom session policy.
            sessionControls.cloudAppSecurity
          

          

            Purview (Insider Risk / Adaptive Protection)
            Insider risk level becomes a CA condition — block, step up auth, or require terms of use as risk rises.
            conditions.insiderRiskLevels
          

          

            Purview (sensitivity labels, sensitive sites)
            A label or protected SharePoint site stamps an authentication context; a CA policy targets that context to force step-up on the sensitive action.
            conditions.applications.includeAuthenticationContextClassReferences
          

          

            ID Protection (Entra ID P2)
            Sign-in risk and user risk as conditions; user-risk policies can drive a secure password change.
            conditions.signInRiskLevels / userRiskLevels
          

          

            Entra Suite (Global Secure Access)
            "Compliant network" signal — require the user to be connecting through GSA; also scope policy to GSA traffic profiles. (Modelled here in prose; the Graph shape is still settling.)
            conditions — network signal
          

          

            PIM
            Privileged role activation can require a CA authentication context, so elevating a role can demand phishing-resistant MFA.
            authentication context (as above)