intellimetrics Learning
Zero Trust Implementation Module 2 · Identity

The CA Baseline as a PDP

Last reviewed

Intermediate

What you'll learn

~20 min
  • Design the ten-policy conditional access baseline that operationalizes the PDP
  • Roll policies out report-only → enforce, with break-glass accounts excluded and monitored
  • Pair every policy with a verifier so posture and proof change together

The PDP you already own

Lesson 1.1’s policy decision point isn’t something Meridian needs to buy — every major identity platform ships one. In Entra ID it’s called Conditional Access; Okta, Ping, and Google have equivalents. The engine evaluates signals (who, what device, what state, where, what risk) against policies and returns allow / deny / step-up — the 800-207 diagram, productized. What most organizations lack isn’t the engine; it’s a coherent policy set. They accumulate policies like sediment — a rule from the 2023 audit, a rule from the incident, contradictory exclusions nobody dares delete.

The fix is a designed baseline: roughly ten policies that cover the estate’s access logic, named consistently, reviewed as a set.

Prompt first

Design a conditional access policy baseline for this estate. Output as
structured JSON: policy name (numbered, purpose-first naming), target users/
apps, conditions, grant/session controls, and rollout state. Requirements:
- MFA for all users on all apps; phishing-resistant strength for admins
- Block legacy/basic authentication protocols outright
- Require compliant device for corporate apps (defer enforcement - Module 3
  wires the compliance signal)
- Risk-triggered step-up: high sign-in risk => phishing-resistant MFA or block
- Per-app strictness tiers: the dispatch system stricter than the cafeteria menu
- Break-glass: two cloud-only emergency accounts EXCLUDED from every policy
- Every policy ships report-only first
Then list what this baseline does NOT cover, honestly.

The shape that comes back — the canonical ten, compressed:

CA01  Require MFA - all users, all apps        CA06  Block legacy auth protocols
CA02  Phishing-resistant strength - admins     CA07  High-risk sign-in => step-up/block
CA03  Require compliant device - corp apps     CA08  Session limits - unmanaged devices
CA04  Per-app tier: critical apps strict       CA09  Block access from unsupported platforms
CA05  Guest/external: MFA + limited scope      CA10  Admin sessions: no persistence, short TTL

Three design rules carry most of the safety:

Report-only first, always. Every policy runs in audit mode against real traffic before it enforces — the identity-pillar instance of Lesson 1.3’s visibility-before-enforcement rule. The report answers “who would this have blocked?” while blocking nobody; the surprises (the scanner service account that would’ve been locked out, the executive’s ancient iPad) get fixed before they’re outages.

Break-glass is excluded and watched. Two cloud-only emergency accounts sit outside every policy — because the alternative is the identity provider outage that locks every admin out of the tools needed to fix it. The compensating control is monitoring: any use of a break-glass account pages the SOC immediately. Excluded-but-alarmed, never excluded-and-forgotten. And test the accounts quarterly — an emergency credential nobody has verified is a hope, not a control. (A current refinement worth adopting: exclude break-glass from every policy except one requiring a FIDO2 credential for exactly those accounts — emergency access on the strongest auth, not the weakest.)

Exclusions are debt with interest. Every “temporarily exclude the facilities team” carries an owner and an expiry, reviewed monthly. Policy sets die by a thousand permanent exceptions — and the platforms are closing in on the habit: in mid-2026 the major identity platform began evaluating baseline sign-in scopes even under policies carrying resource exclusions, which broke every org whose posture quietly depended on exclusions nobody remembered.

Verifier-coupled policy

The discipline that separates a governed baseline from sediment, drawn from a real high-compliance shop: each policy is paired with an automated probe that proves it, and posture changes require changing both in the same change. CA06’s verifier attempts a legacy-auth sign-in monthly and expects denial; CA02’s verifier confirms the admin role can’t authenticate with a phishable method. A control whose probe is missing is recorded as an explicit typed gap — “verifier: absent” — never silently assumed. You’ll meet this idea again at full scale in Lessons 5.3 (verify by denial) and 6.4 (the rollout plan); here it starts as a column in the baseline table.

One more principle gets a paragraph now and a full lesson later: the targets of these policies should be directory groups, not individuals — one group layer, projected everywhere, so access reviews and policy scoping share a single source of truth. Lesson 6.1 builds that machinery.

💡Have the AI attack the baseline

Generation is half; the other half: “Adversarially review this CA baseline as an attacker with a stolen password. Find the gaps: which combination of user, app, device, and network reaches data without triggering MFA or device checks? Check the exclusions especially.” Common finds: a service account in the MFA exclusion group that owns a mailbox; the legacy-auth block missing one protocol; per-user MFA remnants fighting the policy layer. The attacker-lens review of your own policy set is the cheapest pentest you’ll ever run.

KNOWLEDGE CHECK

Rolling out CA03 (require compliant device), the report-only phase shows it would have blocked 340 sign-ins last week — including the CFO's home PC and every meter-data service account. A teammate says report-only found nothing serious since nothing actually broke. What's the correct read?

Key takeaway

The PDP is real when it runs a designed baseline: ~ten purpose-named policies, group-targeted, report-only before enforcing, break-glass excluded-but-alarmed, every exception owned and expiring, every policy paired with the probe that proves it. That’s the identity pillar’s skeleton — the next three lessons add the strong-auth muscle, remove the standing privilege, and extend all of it to the identities that aren’t people.

Search lessons