Building a Conditional Access baseline by persona
Conditional Access built one request at a time ends up unreadable and full of holes. Starting from the populations that sign in rather than from tickets gives you a coherent baseline you can deploy safely and measure over time.
The piecemeal policy trap
In many tenants, Conditional Access was built ticket by ticket: a policy for a project, an exclusion for an executive, a rule copied from a blog post. Three years later there are thirty policies, exclusions nobody can explain and gaps nobody sees. The persona approach restores order: you start from who signs in, not from what was requested.
Define the personas
A robust baseline distinguishes at least:
- Administrators: any account holding a privileged role.
- Internal users: employees, on managed or unmanaged devices.
- Guests: B2B accounts from other organizations.
- Service accounts still used interactively, which should eventually disappear.
- Emergency access accounts, excluded in a controlled way.
Each persona maps to a group, and each policy targets a persona. That is what makes the baseline readable: for any account, you know which rules apply.
The baseline policies
| Policy | Target | Effect |
|---|---|---|
| Block legacy authentication | All users | Shuts IMAP, POP, authenticated SMTP and older protocols that ignore MFA |
| MFA for everyone | All users, all apps | No more password-only sign-ins |
| Phishing-resistant authentication strength | Administrators | FIDO2, Windows Hello for Business or certificates for privileged roles |
| Compliant or joined device | Internal users, sensitive apps | Data stays on managed endpoints |
| MFA and terms of use | Guests | Guests are authenticated and have accepted your rules |
| Sign-in and user risk | Everyone (P2 licence) | Reauthentication or password change when risk is detected |
Deploy without locking yourself out
Every new policy starts in report-only mode. For one or two weeks, the sign-in logs show what would have been blocked: forgotten accounts, legacy applications, technical flows. The What If tool then lets you simulate a specific sign-in before enabling. And emergency access accounts are excluded from day one.
Simple rule. A policy enabled without going through report-only mode is a bet on production. Report-only costs nothing and almost always reveals a surprise.
Name and document
A naming convention turns the policy list into documentation: a number, the persona, the application, the effect. For example CA010-Admins-AllApps-Require-PhishingResistantMFA. Every exclusion is justified in a register, with an owner and a review date.
Measure the drift
A baseline degrades: an excluded group grows, a new application falls outside the scope, a policy stays in report-only "temporarily". A regular audit compares the actual state with the expected baseline: policies present and enabled, exclusions, application coverage, accounts targeted by no rule at all. That drift, far more than a missing policy, is what opens the gaps.