Conditional Access baseline
In short: a set of [N] Conditional Access policies built around user personas rather than one-off exceptions. It blocks legacy authentication, requires phishing-resistant MFA for admins, and ties access to device compliance. Each policy ran in report-only mode before enforcement.
The problem
Most tenants I see have Conditional Access that grew one policy at a time: a rule for a project, an exclusion for an executive, a policy nobody remembers creating. That leaves gaps that are hard to see, such as legacy protocols still allowed, admins using the same MFA as everyone else, and exclusion groups that only get bigger.
[Add one or two sentences on the specific situation that prompted this, with no customer names.]
Design approach
Personas, not exceptions
Every identity falls into one persona, and every policy targets personas through groups:
| Persona | Who | Key controls |
|---|---|---|
| Standard users | Internal staff | MFA, compliant or registered device for M365, risk-based controls |
| Privileged admins | Anyone holding an Entra admin role | Phishing-resistant MFA, compliant device, shorter sign-in frequency |
| Guests | B2B collaboration users | MFA, limited app scope |
| Break-glass | Two emergency access accounts | Excluded from all policies, with sign-in alerting |
| Workload identities | Service principals | Handled separately, with location restrictions where licensed |
Naming convention
Policies are named so that the sign-in logs explain themselves, for example CA001-Global-BlockLegacyAuth or CA010-Admins-RequirePhishingResistantMFA. The number gives an order, the persona gives scope and the action says what the policy does.
The policies
| # | Policy | Why |
|---|---|---|
| CA001 | Block legacy authentication | Legacy protocols can't do MFA and are a common password-spray target. |
| CA002 | Require MFA for all users | The baseline control that everything else builds on. |
| CA003 | Block device code flow | Closes a phishing path that bypasses normal sign-in. |
| CA004 | Secure security-info registration | Stops an attacker with a password from registering their own MFA method. |
| CA010 | Admins: phishing-resistant MFA | Uses authentication strengths to require FIDO2 or Windows Hello for Business. |
| CA011 | Admins: require compliant device | Admin sessions only from managed, healthy endpoints. |
| CA020 | Users: sign-in risk | Step-up or block on medium or high risk (Entra ID P2). |
| CA021 | Users: user risk | Require secure password change on high user risk (Entra ID P2). |
| CA030 | Guests: require MFA | External identities meet the same bar as staff. |
[Adjust this list to match what you actually deployed.]
Rollout
- Break-glass first. Two cloud-only emergency accounts, excluded from every policy, with an alert on any sign-in.
- Report-only. Every policy ran in report-only mode for [X weeks]. The Conditional Access insights workbook showed what would have been blocked.
- Fix the fallout before enforcing. [e.g. a legacy SMTP relay, a shared device, service accounts]
- Enforce in rings. IT first, then a pilot group, then everyone.
Verification
- The What If tool, for each persona, to confirm the expected policies apply.
- Sign-in logs, filtered by Conditional Access result, to confirm real sign-ins match the design.
- Negative tests: a legacy-auth attempt is blocked, and an admin without a FIDO2 key is refused.
What I'd do next
[e.g. token protection, continuous access evaluation, and a regular review of the exclusion groups.]