Conditional Access — building a policy library that survives audit

Conditional Access — Okta calls it Authentication Policies, Microsoft calls it Conditional Access, Ping calls it Risk Policies — is the workhorse of modern workforce identity. Done well, it is the highest-leverage zero-trust intervention an organization can ship. Done poorly, it is a tangle of exceptions that defies audit and creates more risk than it mitigates.

This piece covers the policy library design pattern we use across the major platforms. The pattern is platform-independent; the implementation details differ.

What goes wrong

The failure mode is reliable. An organization rolls out Conditional Access with a sensible baseline (require MFA, block legacy auth, require trusted device for sensitive apps). Then the exceptions start.

• The CFO travels frequently and gets locked out by the location policy
• A specific application breaks under MFA prompts and gets an exception
• A vendor needs access from outside the corporate network and gets carved out
• Engineering needs CLI access without browser-based MFA and gets an exception
• The break-glass account needs to bypass everything

Six months later, the policy library is 30 policies. Twelve months later, it is 50. The auditor asks "show me which users are required to have MFA and under what conditions." Nobody can answer in a single query.

The library design pattern

What we recommend on every engagement:

1. Layered baseline policies, not per-user exceptions.

Every policy applies to a layer, not a user. The layers we use:

• Foundation: Block legacy auth, require MFA for cloud admin operations, require known device for high-risk apps. Every user is subject to the foundation.
• Persona: Engineering, sales, executive, contractor. Each persona has a defined posture; users belong to personas, policies attach to personas.
• Application risk tier: Tier 1 (no friction needed), Tier 2 (MFA required), Tier 3 (trusted device + MFA + step-up for sensitive actions).
• Path risk: A specific access path (admin elevation, financial transaction, data export) gets policy attached to the path, not the user.

A user who triggers a high-risk policy is not exempted via a per-user override. The user changes persona temporarily (executive travel persona for the CFO trip) or the application changes tier (the broken app moves to Tier 1 with compensating monitoring).

2. Every policy has a written rationale.

Each policy in the library has a one-paragraph rationale: what risk it mitigates, what audit-evidence requirement it satisfies, what business event triggered it. The rationale lives in version control alongside the policy definition.

The rationale is the artifact that survives engineer turnover. Policies without rationale get deprecated.

3. Every policy has an expiration date.

Default policy expiration is 12 months. At the expiration date, the policy is reviewed against the current threat model, current audit framework, and current business state. Many policies renew. Some get retired. None drift indefinitely.

4. Policy as code, deployed via CI.

The console UI is fine for prototyping a policy. Production policies live in Git. They are reviewed, tested in a staging tenant, and deployed via CI. The audit trail is the commit history.

This is non-negotiable for any Conditional Access program at scale. If your tenant has more than 15 policies and they are not in version control, the next audit will hurt.

5. The library is bounded.

A healthy Conditional Access library has 12-20 policies for a 5,000-employee enterprise. Above 20 policies, the program is almost always leaking exceptions. We treat policy count as a fitness metric.

Platform-specific notes

Microsoft Entra Conditional Access:

• Use named locations and trusted device signals from Intune
• Templates are useful as starting points but production policies should be derived from your library, not the template
• Test in report-only mode against a representative population before enforcing
• Microsoft Graph + Bicep templates for as-code deployment

Okta Authentication Policies:

• Per-app authentication policies attach to applications; global session policies attach to the org
• The interaction between session policies and app policies is non-obvious; document the precedence in your library
• Okta API + Terraform with the Okta provider for as-code deployment

Ping (PingOne / DaVinci):

• DaVinci flows are the canonical orchestration layer for risk-adaptive policy
• The flow definition is the policy artifact; version control the flow JSON
• PingOne API for as-code deployment

The audit-readiness test

A Conditional Access program is audit-ready if it can answer the following questions in under five minutes:

1. "Show me every user required to have MFA and the conditions under which it applies."
2. "Show me every policy that touches a specific application."
3. "Show me every change to the policy library in the last 90 days, who made it, and why."
4. "Show me the exception list and the expiration date of each exception."
5. "Show me the report-only impact of a proposed new policy on the workforce."

If your tenant cannot answer these questions in under five minutes via standardized queries, the policy library has work to do.

The bottom line

Conditional Access is the highest-leverage workforce identity control most organizations have. Building the policy library well — bounded, rationaled, expiring, version-controlled — is the difference between a program that survives audit and one that becomes a liability. Plan the library before you ship the policies.