Andrew Yeoman / Case studies / Conditional Access baseline
Case study · Identity & access

Access that has to be earned, one numbered policy at a time

A sixteen-policy Conditional Access baseline where device compliance is the gate, personal phones get app-level protection instead of enrollment, and admin rights only exist while they're being used. Shipped report-only first — nobody was locked out by surprise.

Scope
~3,500 endpoints, nine sites
Baseline
CA-001 → CA-016
Admin model
PIM, just-in-time
BYOD
MAM, no enrollment
The thesis

A password proves almost nothing. The device has to vouch for it.

Moving an estate to cloud management (written up separately) only pays off if the cloud is where access decisions get made too. Once Intune knows whether a device is compliant, that signal becomes the thing standing between a stolen credential and the company's data — not the network it happens to be sitting on.

So the access layer got rebuilt around four questions asked in order: who is signing in, what are they signing in from, what can they do once they're in, and how long do they get to keep it. Every rule that answers one of those questions is a numbered policy with a stated purpose, so it can be audited, explained to an auditor or an executive, and reverted in isolation when it turns out to be wrong.

01
Identity
Multifactor for everyone, legacy authentication protocols blocked outright, risk-based challenges for anomalous sign-ins.
Entra ID
02
Device
Corporate resources require a compliant or hybrid-joined device. The compliance signal comes straight from Intune, so posture and access stay in sync.
Intune compliance
03
App
Personal phones and tablets are allowed in through approved apps carrying an app protection policy — corporate data is contained without the device being enrolled.
Intune MAM
04
Session
Unmanaged browsers get a restricted session: no persistent sign-in, shortened sign-in frequency, and download controls on the sensitive surfaces.
Session controls
05
Privilege
Admin roles are eligible, not assigned. Activation runs through PIM behind its own authentication context, time-bound and logged.
PIM + auth context
The baseline

Sixteen policies, numbered so they can be argued with.

An unnumbered Conditional Access estate becomes folklore within a year — nobody remembers which rule blocks what, so nobody touches any of them. Numbering them turns the tenant into a register: each policy has an ID, a single job, and a documented exclusion set, and a change request can name exactly what it wants changed.

Policy IDs
Purpose
CA-001 – 003
Foundation
Multifactor for all users, legacy authentication blocked, elevated requirements on privileged roles.
CA-004 – 006
Device trust
Compliant or hybrid-joined device required for corporate resources, including the admin portals themselves.
CA-007 – 009
Mobile and BYOD
Approved client apps with an app protection policy required on iOS and Android; unapproved clients blocked.
CA-010 – 012
Risk and session
Sign-in and user risk responses, sign-in frequency, and browser persistence limits for unmanaged sessions.
CA-013 – 014
Guests and external access
Separate treatment for guest identities so partner collaboration doesn't inherit employee-level trust.
CA-015 – 016
Guardrails
Location and platform restrictions, plus the break-glass exclusions that keep the tenant recoverable if everything else is wrong.
Conditional AccessEntra ID P1Device complianceSign-in riskBreak-glass accounts
BYOD

Protect the data, not the phone.

Intune MAM · App protection policies

Corporate mail and Teams on personal iOS and Android, without enrolling a single personal device.

iOS · Android · unenrolled

The usual BYOD offer is a bad trade for both sides: enroll your personal phone and hand IT a management channel over it, or get no access at all. App protection policies split the difference. The policy travels with the app, not the device — corporate data lives in an encrypted app container, requires a PIN to open, and can't be copied out into personal apps, saved to personal storage, or backed up to a personal cloud account.

When someone leaves or loses a phone, the corporate container is wiped selectively. Their photos, messages, and personal apps are never in scope, which is exactly what makes the policy acceptable to the people carrying the phones. Conditional Access enforces it: on mobile platforms, access requires an approved client app carrying the policy, so there's no path around it through a browser or a third-party mail client.

App protection policiesSelective wipeApproved client appsiOS / AndroidUnenrolled BYOD
Privileged access

Admin rights that expire on their own.

PIM · Authentication context

Standing global privilege replaced with eligible roles, activated just in time behind a dedicated authentication context.

Time-bound · justified · logged

Standing admin assignments are the quiet risk in most tenants: a role granted once for a project, still live three years later, sitting on an account that reads email all day. Privileged Identity Management flips it — roles are held as eligible, and activating one requires a justification, produces an audit record, and expires by itself.

The part that makes it more than paperwork is the authentication context. Activation is bound to its own context with a stricter Conditional Access rule than everyday sign-in, so stepping up to admin means proving identity again at a higher bar, on a compliant device, at that moment — not riding a session token minted hours earlier over coffee.

PIM eligible rolesAuthentication contextActivation approvalAudit trailLeast privilege
Authentication strength

Retiring the text message before it retires itself.

The weakest link in most MFA deployments is the fallback method. SMS and voice codes are phishable and SIM-swappable, and Microsoft has set an end date for them as authentication methods — which turns a security improvement into a migration with a deadline attached.

The move is to phishing-resistant credentials: Windows Hello for Business on corporate machines, passkeys in Microsoft Authenticator for phones, and a passphrase policy that stops fighting users with quarterly expiry rules that never made anyone safer. I packaged the whole rollout as a SharePoint site — enrollment walkthroughs, per-platform guidance, and the policy change explained in plain language — because a credential migration is a communications project wearing an engineering costume.

Windows Hello for BusinessAuthenticator passkeysAuthentication strengthsPassphrase policySharePoint rollout site
How it shipped

Nobody found out about a policy by being locked out.

Conditional Access is the one place where a good idea deployed badly takes the whole company offline at 8am. Every policy in the baseline went through the same four stages before it enforced anything.

Stage 01
Report-only
Policy runs in evaluation, logging what it would have done against real sign-in traffic.
Stage 02
Read the impact
Sign-in logs and the What If tool surface the accounts, apps, and service principals that would break.
Stage 03
Pilot ring
Enforced against IT and volunteers first, with a named path back if something goes sideways.
Stage 04
Broad enforcement
Rolled out by ring, with break-glass accounts excluded and monitored throughout.
The outcome

What actually changed about getting in.

Admin rights
Standing, always on Just-in-time
Eligible roles activated through PIM, behind a stricter authentication context.
Personal devices
Enroll it or no access App-level only
Corporate data contained and selectively wipeable; the phone stays the employee's.
Access policy
Undocumented, unowned 16 numbered policies
Each with one job, a stated exclusion set, and a report-only history behind it.
Sign-in security
SMS and voice fallback Phishing-resistant
Windows Hello and passkeys, ahead of the retirement of text-message MFA.

The through-line with the rest of my work is the same one as always: the answer to a security problem is a system that holds the line by itself, not a policy document asking people to be careful.

Get in touch

Let's talk.

I'm open to Principal Cloud / EUC Architect conversations, and to work at organizations building things that matter — infrastructure, security, or the mission itself.