The framework
How the CA Framework Builder works
Understanding the building blocks helps you make better decisions in the wizard and get more out of your generated framework.
Persona-based architecture
The framework is built around the concept of personas — distinct user groups with different risk profiles, access needs, and trust levels. Instead of applying one-size-fits-all policies, each persona gets its own tailored set of Conditional Access policies. This approach was pioneered by Claus Jespersen and has become a widely adopted best practice in the Microsoft security community.
Internals
Regular employees
Admins
Privileged users
Externals
Contractors & partners
Guests
B2B guest users
GuestAdmins
Guest administrators
Developers
Azure & DevOps users
ServiceAccounts
Automated processes
WorkloadIdentities
Service principals
AI Agents
AI workload identities
Policy types
Each persona can have multiple policy types, applied in a logical order from base protection to advanced compliance controls.
Base Protection
The foundation — MFA, compliant device, or hybrid join requirement. Adapts to your workplace maturity.
Identity Protection
Risk-based policies using Entra ID Identity Protection signals (user risk, sign-in risk). Requires P2.
Data Protection
Session controls and MCAS/MDCA integration to protect sensitive data in transit.
App Protection
Controls for specific applications and platforms, including MAM for mobile devices.
Attack Surface Reduction
Block legacy auth, restrict unknown platforms, limit credential registration.
Compliance
Terms of Use, sign-in frequency, persistent browser session controls.
Naming convention
All policies follow a strict naming convention for consistency and manageability:
CA0001–CA0099
Global
CA0100–CA0199
Admins
CA0200–CA0299
Internals
CA0300–CA0399
Externals
CA0400–CA0499
Guests
CA0500–CA0599
GuestAdmins
CA0600–CA0699
Developers
CA0700–CA0799
ServiceAccounts
CA0800–CA0899
WorkloadIdentities
CA0900–CA0999
AI Agents
Build principles
The framework follows these Zero Trust principles — applied within the boundaries of your chosen licenses and workplace maturity.
Report-only first
Always start in report-only mode. Validate impact before enforcing.
Zero Trust by default
Never trust, always verify. No implicit access for any identity.
Block legacy authentication
Legacy auth bypasses MFA. Block it globally as a first step.
Protect all platforms
CA has no implicit deny-all. Ensure every app and platform is covered.
Protect privileged users
Admins get the strictest policies across all M365 RBAC systems.
Limit block mode
Use block sparingly for general access. Prefer grant controls with conditions.
Resilience by design
Consider session resilience defaults to prevent lockouts during outages.
Ring deployment
Roll out policies in rings: break glass → IT admins → pilot → broad.
Ring deployment model
Never roll out CA policies to everyone at once. Use a ring-based approach to validate impact and catch issues early.
Break Glass
Emergency access accounts. Always excluded from all CA policies. Create at least 2.
IT Administrators
Your IT team validates the policies first. They can recover from mistakes.
Pilot group
A representative sample of business users. Typically 5–10% of the organization.
Broad deployment
All remaining users. Only after Ring 2 has been validated for at least 2 weeks.
Ready to build your framework?
The wizard takes about 5 minutes and generates a complete, tailored CA framework.
Start the wizard →