🛡️ Conditional Access Implementation – scratching the surface.
Published: [31/7-2025]
Author: Niels Jakobsen, Senior Microsoft Security Consultant
🔐 Introduction
Todays post, is another post in my Microsoft Zero Trust series, where we talk about Microsoft Security features, and how the products work together. Today we will talk about something most people have set up, but in a very limited manner, Conditional Access. And have the opportunity to set up with no additional cost to licensing, and drastically improve their security posture.
I have developed, a modular, persona-based Conditional Access framework that aligns with Microsoft’s Zero Trust principles and scales across enterprise environments. This post provides a technical deep dive into our methodology, policy structure, and phased implementation process. I’ve used this with several customers, to make their M365 resources more secure.
🧱 Framework Architecture
The framework draw inspiration from :
- Joey Verlinden’s CA Framework (2025.2.3)
- Claus Jespersen’s Microsoft CA for Zero Trust Resources
- But primarily it comes from real world experinces implementing Conditional Access.
- So why use this, instead of just implementing Claus Jespersens Framework?
- first off, Claus is not maintaining his framework anymore
- But more importantly, this is just a “Baseline” for what you should implement. This is a simplyfied version of Claus Jespersens great work. It contains more policies in Global, and less policies in the rest of the categories. The reason for doing it like this, is simply that it is easier for customers to manage, with less granular policies and more global policies.
- With that being said, this is just a “baseline” framework. As you will see in my implementation methodlogy is an assessment of the tenant. In this Phase you will need to assess which policies is fine putting in the global Persona, and which policies you will need to put in the other persona groups. This will depend on wether or not different personas will need different settings.
📛 Naming Convention
We use a strict naming convention for traceability and automation:
<CA Number>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>Example:CA0004-Global-AttackSurfaceReduction-AllApps-AnyPlatform-BlockLegacyAuth
👥 Persona-Based Policy Design
We segment policies by user personas, each with a dedicated CA number range:
| Persona Group | Range | Description |
|---|---|---|
| Global | CA001–CA099 | Org-wide baseline |
| Admins | CA100–CA199 | Privileged roles |
| Internals | CA200–CA299 | Employees |
| Externals | CA300–CA399 | External collaborators |
| Guests | CA400–CA499 | B2B guest users |
| M365 Service Accounts | CA600–CA699 | Microsoft 365 automation |
| Azure Service Accounts | CA700–CA799 | Azure-based services |
| Corp Service Accounts | CA800–CA899 | On-premises integrations |
| Workload Identities | CA900–CA999 | App registrations |
| Developers | CA1000–CA1099 | Dev/test environments |
📜 Baseline Policy List
🔹 Global Policies
| Policy | Description (EN) | Impact (EN) | Rationale (EN) |
|---|---|---|---|
| CA0001-Global-BaseProtection-AllApps-AnyPlatform-BlockNonPersonas | A blocking policy that blocks all NONPersonas | Blocks all users who are not defined as a persona | Enforces Zero Trust by denying access to any identity not explicitly authorized, reducing shadow IT and identity sprawl |
| CA0002-Global-AttackSurfaceReduction-BlockCountries | Geoblocking of specific countries | Blocks access from high-risk regions | Reduces exposure to threat actors operating from high-risk geographies, especially where no business operations exist |
| CA0003-Global-AttackSurfaceReduction-AllApps-AnyPlatform-BlockLegacyAuth | Blocks legacy authentication protocols | Legacy apps and devices cannot log in | Legacy protocols bypass MFA and are vulnerable to brute-force attacks; blocking them closes a major attack vector |
| CA0004-Global-AppProtection-MicrosoftIntuneEnrollment-AnyPlatform-MFA | Requires MFA for Intune enrollment | Devices must use MFA to enroll | Prevents rogue device registration and ensures only verified users can onboard devices into management |
| CA0005-Global-DataProtection-AllApps-iOSorAndroid-AppProtection | Requires MAM policy for mobile login | iOS/Android apps require app protection for login | Protects corporate data on mobile devices, even in BYOD scenarios, by enforcing app-level controls |
| CA0006-Global-AttackSurfaceReduction-AllApps-AnyPlatform-BlockUnknownPlatforms | Blocks access from Linux or Windows Phone | Users cannot log in from unsupported platforms | Ensures only secure, supported platforms are used to access corporate resources |
| CA0007-Global-AttackSurfaceReduction-VariousApps-AnyPlatform-Block | Blocks specific apps | Apps deemed insecure are blocked | Prevents use of applications that pose compliance or security risks within the tenant |
| CA0008-Global-IdentityProtection-AllApps-AnyPlatform-MFAandPWDforMediumandHighUserRisk(P2) | Requires MFA and password reset for high user risk | High-risk users must complete additional verification | Reduces likelihood of account compromise by enforcing strong authentication and credential hygiene |
| CA0009-Global-IdentityProtection-AllApps-AnyPlatform-MFAforMediumandHighSignInRisk(P2) | Requires MFA for risky sign-ins | Risky sign-ins require MFA verification | Validates user identity during suspicious login attempts, mitigating credential theft |
| CA0010-Global-IdentityProtection-SpecificApps-Windows-TokenProtection(P2) | Enables token protection for specific apps | Tokens cannot be reused across devices | Prevents token replay attacks by binding tokens to trusted devices |
| CA0011-Global-AttackSurfaceReduction-AllApps-AnyPlatform-AuthenticationFlowBlock | Blocks manipulation of authentication flow | Authentication flow cannot be transferred between devices | Prevents attackers from hijacking tokens and accessing resources from non-compliant endpoints |
🔹 Admin Policies
| Policy | Description (EN) | Impact (EN) | Rationale (EN) |
|---|---|---|---|
| CA0100-Admins-BaseProtection-AllApps-AnyPlatform-CompliantandMFAPasskey-PhishingResistant | Requires compliant device and phishing-resistant MFA for admin accounts | Admin accounts must use secure devices and phishing-resistant MFA | Admins have elevated privileges and are prime targets; enforcing strong authentication and device compliance reduces risk significantly |
| CA0101-Admins-IdentityProtection-AllApps-AnyPlatform-CombinedRegistration-CompliantorMFAPasskey | Requires compliant device or MFA passkey for registering security info | Admins must use secure methods to register authentication info | Prevents registration from compromised endpoints and ensures secure identity lifecycle for privileged users |
| CA0102-Admins-DataProtection-AllApps-AnyPlatform-SessionPolicy | Requires MFA every 8 hours for admin accounts | Admins are prompted for MFA periodically | Limits session duration to reduce exposure from hijacked sessions and enforces accountability for privileged access |
🔹 Internal Users
| Policy | Description (EN) | Impact (EN) | Rationale (EN) |
|---|---|---|---|
| CA0200-Internals-BaseProtection-AllApps-AnyPlatform-Compliant | Requires compliant device for login | Blocks BYOD and non-compliant devices | Ensures corporate data is accessed only from managed, secure devices, reducing risk of data leakage |
| CA0201-Internals-IdentityProtection-AllApps-AnyPlatform-CombinedRegistration-CompliantorMFA | Requires compliant device or MFA for registering security info | Users must use secure methods to register authentication info | Prevents unauthorized registration and ensures secure onboarding of employee identities |
🔹 External Users
| Policy | Description (EN) | Impact (EN) | Rationale (EN) |
|---|---|---|---|
| CA0300-Externals-BaseProtection-AllApps-AnyPlatform-Compliant | Requires compliant device for external users | External users must use secure devices | Ensures external collaborators meet the same security standards as internal users |
| CA0301-Externals-IdentityProtection-AllApps-AnyPlatform-CombinedRegistration-CompliantorMFA | Requires compliant device or MFA for registering security info | External users must use secure methods to register authentication info | Prevents identity spoofing and ensures secure onboarding of external identities |
| CA0302-Externals-DataProtection-AllApps-AnyPlatform-SessionPolicy | Prompts external users for sign-in every 30 days | Increases login frequency for external users | Reduces risk of persistent access and ensures regular identity verification for higher-risk external accounts |
🔹 Guest Users
| Policy | Description (EN) | Impact (EN) | Rationale (EN) |
|---|---|---|---|
| CA0400-Guests-BaseProtection-AllApps-AnyPlatform-MFA | Requires MFA for guest users | Guest users must use MFA to log in | Adds a critical layer of security for temporary or external access, reducing risk of unauthorized access |
| CA0401-Guests-IdentityProtection-AllApps-AnyPlatform-TOU-CombinedRegistration | Requires Terms of Use acceptance for registering security info | Guest users must accept TOU before registration | Ensures legal and policy compliance before granting access to sensitive systems |
| CA0402-Guests-AttackSurfaceReduction-AllApps-AnyPlatform-BlockNonGuestAppAccess | Blocks access to non-guest apps | Guest users are restricted to guest-specific apps | Prevents lateral movement and unauthorized access to internal resources |
| CA0403-Guests-ComplianceProtection-AllApps-AnyPlatform-RequireTOU | Requires Terms of Use acceptance | Guest users must accept TOU | Reinforces policy awareness and legal accountability for guest access |
| CA0404-Guests-DataProtection-AllApps-AnyPlatform-SignInSessionPolicy | Prompts guest users for sign-in every 14 days | Increases login frequency for guest users | Ensures regular re-authentication for temporary users, reducing risk of stale sessions or account misuse |
🔹 Service Accounts
| Policy | Description (EN) | Impact (EN) | Rationale (EN) |
|---|---|---|---|
| CA0600-Microsoft365ServiceAccounts-BaseProtection-AllApps-AnyPlatform-BlockUntrustedLocations | Blocks service account logins from untrusted locations | Service accounts can only log in from known IP ranges | Prevents misuse of automation accounts by restricting access to trusted environments, reducing exposure to credential theft or abuse |
🔹 Emergency Access Users
| Policy | Description (EN) | Impact (EN) | Rationale (EN) |
|---|---|---|---|
| CA2000-EmergencyAccessUser-BaseProtection-AllApps-AnyPlatform-CompliantandMFAPasskey-PhishingResistant | Requires compliant device and phishing-resistant MFA for emergency accounts | Emergency accounts must use maximum security | These accounts are critical for recovery and must be protected with immutable, high-assurance controls |
| CA2001-EmergencyAccessUser-IdentityProtection-AllApps-AnyPlatform-CombinedRegistration-CompliantorMFAPasskey | Requires compliant device or MFA passkey for registering security info | Emergency accounts must use secure methods for registration | Ensures emergency access credentials are managed securely and cannot be tampered with during a crisis scenario |
🧭 Implementation Methodology
I implement Conditional Access in three structured phases:
🔍 Phase 1: Discovery & Planning
Objective: Understand the customer’s current CA posture and readiness.
Activities:
- Review existing CA policies
- Identify gaps and risks
- Determine need for customer-specific policies
- Validate prerequisites:
- ✅ Log Analytics workspace for CA monitoring
- ✅ MFA rollout across all users
- ✅ Break-the-glass (BTG) emergency access accounts
Tools:
- Jasper Baes’ Conditional Access Blueprint
- Persona flow diagrams
- Microsoft Graph API for policy export
⚙️ Phase 2: Framework Deployment (Report-Only Mode)
Objective: Deploy all policies in Report-Only mode to simulate enforcement.
Activities:
- Deploy full Danoffice IT CA framework
- Deploy customer-specific policies
- Monitor sign-in logs and policy impact
Why Report-Only? - Prevents accidental lockouts
- Enables safe testing of enforcement logic
- Provides visibility into potential disruptions
📊 Phase 3: Monitoring, Tuning & Activation
Objective: Gradually activate policies based on telemetry and customer feedback.
Activities:
- Review policy impact in Insights & Reporting
- Identify failed sign-ins and root causes
- Collaborate with customer to:
- Reclassify accounts (e.g., to workload identities)
- Add justified exclusions
- Activate stable policies every 14 days
- Repeat until full enforcement is achieved
🧠 Technical Considerations
- Token Protection (P2): Prevents token replay attacks by binding tokens to devices.
- Authentication Strengths: Use Passkey or phishing-resistant MFA for admins.
- Session Controls: Apply Conditional Access App Control or sign-in frequency limits.
- Named Locations: Use trusted IPs and country-based blocks.
- Custom Controls: Integrate with third-party MFA or SIEM tools via Conditional Access APIs.
📌 Final Thoughts
I have seen countless of times on customer tenants, that they implemented CA policies 4 years ago and never touched it since. So now they have 3 policies, Blog Legacy Auth, Geo-Blocking and MFA. And several accounts are excluded that are not supposed to be.
Conditional Access is not just a feature—it’s a security architecture. With a structured framework, persona-based segmentation, and phased rollout, organizations can enforce Zero Trust principles without disrupting productivity. Most people have the oppurtunity to use Conditional Access through their licenses, and could drastically improve their security posture by implementing a proper framework. And you can do it all without risk because of the report-only feature. So what are you waiting for?
Next week, i will dive further into conditional access. Giving examples of the different policies, and how we can do granulate the policies even more.