Zero Trust Conditional Access: Where Should an SMB Actually Define and Enforce Policy?

Key Takeaways

• NIST SP 800-207 splits the policy decision point (PDP) from the policy enforcement point (PEP) — deciding and enforcing are different jobs, and they don't have to live in the same product.
• A healthy SMB architecture has one authoritative PDP and several PEPs that inherit from it — not three products each writing their own rules.
• Practical split: the identity provider owns identity and session context, PKI owns device identity, and ZTNA owns what a session can reach and for how long.
• The failure mode that hurts SMBs isn't choosing the wrong layer — it's writing overlapping, contradictory rules in three layers at once.
• NIST SP 1800-35 (finalized June 2025) shows the PDP/PEP roles filled by different vendor products across its reference builds — the architecture is vendor-agnostic, not a product choice.

Why This Question Comes Up in the First Place

If you run IT for a company of 50 to 500 people, you have probably noticed that at least three products in your stack advertise "conditional access" on the box:

• Your identity provider (IdP) — Okta, Microsoft Entra ID, JumpCloud, Google Workspace — will gate a login on user risk, group membership, geography, device compliance signal, and MFA strength.
• Your PKI or certificate management platform — SecureW2, Smallstep, an internal Microsoft CA — will issue a client certificate only to a device that meets enrollment, ownership, and posture criteria, and can revoke it later.
• Your ZTNA or secure access layer — Access Server, CloudConnexa, or a comparable broker — will decide which internal applications and subnets a given authenticated session may touch, and can tear that session down mid-flight.

Each vendor's documentation implies its layer is the natural home for policy. They cannot all be right, and buying all three "for coverage" is how a five-person IT team ends up with 40 policies nobody fully understands.

What NIST and CISA Actually Say About Where Policy Lives

The most useful thing in NIST Special Publication 800-207 is not a product recommendation — it is a vocabulary. NIST's zero trust guidance separates the policy decision point (PDP), which makes "the ultimate decision to grant access to a resource for a given subject," from the policy enforcement point (PEP), which is "responsible for enabling, monitoring, and eventually terminating connections between a subject and an enterprise resource." [1] Deciding and enforcing are different jobs. They do not have to live in the same product.

Two consequences fall out of that split, and they answer most of the question:

• Decision logic should be centralized; enforcement should be distributed. You want one place where a human can read the rules and one place where they are changed. You want enforcement wherever a session physically passes.
• Enforcement is continuous, not a one-time gate. SP 800-207 treats the session as something monitored and revocable, not something blessed at login and forgotten.

NIST SP 1800-35, the NCCoE's implementation guide finalized in June 2025, is the practical companion. Across its reference builds, the policy engine role is filled by different products depending on the build — in build E3B5 it is Microsoft Entra Conditional Access and a Security Service Edge product acting as policy engines together. [2] NIST does not name a winner. It demonstrates that the role is architectural, not vendor-specific.

CISA's Zero Trust Maturity Model v2.0 adds the maturity dimension. Its Traditional stage is characterized by siloed pillars of policy enforcement; the Advanced stage by policy enforcement integrated across pillars, with centralized visibility. [3] Siloed is the accurate diagnosis for most SMB stacks. The problem is rarely too little policy. It is policy scattered across silos with no single view.

What Each Layer Is Genuinely Good At

The identity provider

Best at: user identity, group and role context, MFA strength, impossible-travel and risk signals, per-application access to SaaS.

Weak at: anything after the token is issued. An adversary-in-the-middle phishing proxy sits between the user and the real login page and captures the session cookie after MFA succeeds; because risk scoring often occurs only at initial authentication, the attacker can then replay that token without further prompts and maintain persistence "until session tokens expire or are explicitly revoked." [4] Continuous Access Evaluation narrows the window but coverage is inconsistent across applications and legacy protocols.

The identity and access management layer is your best PDP. It is a poor sole PEP.

The PKI / certificate layer

Best at: proving which device is connecting, in a way that cannot be phished.

NIST SP 800-63B names client-authenticated TLS as an example of a phishing-resistant authentication protocol — the revision retires the older term "verifier impersonation" in favor of "phishing" — and AAL3, the highest assurance level, requires a cryptographic authenticator with a non-exportable private key that provides phishing resistance. [5] A certificate issued only after a device passes posture and ownership checks is a durable, cryptographic device identity — far stronger than a self-reported posture attribute in a token.

Weak at: freshness and granularity. A certificate issued in January says nothing about whether the device fell out of compliance in March, unless you have working revocation and short lifetimes. This is exactly the gap device posture policies are built to close — checking compliance continuously rather than once at issuance. A valid certificate also carries no application-level authorization: it says "this is a trusted device," not "this device may reach the finance server."

PKI is the best answer to device trust. It is not a general-purpose policy engine.

The ZTNA / secure access layer

Best at: resource-level authorization and session lifecycle. This is where you express "contractors reach the ticketing app and nothing else," where east-west movement is actually constrained, and where a session can be terminated mid-flight when signals change. See how ZTNA enforcement actually works for the mechanics — it is the natural PEP in NIST's model.

Weak at: knowing who someone is, on its own. A ZTNA gateway maintaining its own local user list is a second identity system you now have to deprovision from — a classic offboarding gap.

At a Glance: Which Layer Owns Which Question

The Decision Framework

Rather than picking a layer, assign each layer the question it is qualified to answer, and make the others consume that answer instead of re-deriving it.

A workable SMB sequence:

• IdP as the single PDP. All human-identity conditions — MFA, group, risk, geography — are written once, here. Nowhere else.
• PKI as the device attestation source. Certificates are issued only to enrolled, compliant devices, with lifetimes short enough that revocation is a real control — see how device attestation works in practice.
• ZTNA as the primary PEP. It federates to the IdP via SAML/OIDC, requires the device certificate as a second factor of device trust, and holds the only authoritative map of which identity groups reach which internal resources.
• Logging into one place. If you cannot answer "why was this session allowed?" from a single query, you do not have an architecture — you have three products.

Where SMBs legitimately deviate: if you are almost entirely SaaS with no internal apps, the IdP can be both PDP and PEP and a ZTNA layer is premature. If you are heavily on-premises with a thin SaaS footprint, the ZTNA layer carries more weight and the IdP is mostly an identity source.

The Failure Modes to Plan Around

• Policy sprawl. Microsoft ships an agent whose stated job is "to minimize policy sprawl" by recommending you modify an existing policy rather than add another, and by flagging spikes or dips that indicate a misconfiguration. [6] Practical365's field write-up devotes a whole section to sprawl for the same reason. [7] Conflicting rules across three layers make this worse — troubleshooting becomes archaeology.
• Exceptions that never expire. The temporary exclusion group for the one executive with an old laptop is the most common permanent hole in an SMB tenant. [7]
• No break-glass account. A conditional access policy that requires a compliant device, applied to all users, will lock you out of your own tenant the day compliance reporting breaks. Excluded, monitored, hardware-key-protected emergency accounts are not optional.
• Deploying without report-only mode. Every mature rollout guide says the same thing: run new policies in report-only, read the sign-in logs, then enforce. [7]
• Silent enforcement gaps. Legacy protocols, service accounts, and unmanaged contractor devices routinely fall outside every policy you wrote. Audit for what is not covered, not just what is.

For a broader, phased rollout approach that goes beyond conditional access alone, see our guide to zero trust architecture implementation.

Frequently Asked Questions

Can I just use my identity provider's conditional access and skip ZTNA?

If your applications are all SaaS and reachable only through the IdP, yes. The moment you have internal applications, servers, or a network a user reaches after logging in, the IdP has no visibility into that traffic and cannot enforce anything about it.

Does NIST recommend a specific product for conditional access?

No. SP 800-207 defines the PDP and PEP roles; SP 1800-35 demonstrates those roles filled by a range of vendor products across its reference builds. [1][2]

Should device posture be checked in the IdP or the PKI?

Ideally both, at different times. PKI binds trust to the device cryptographically at issuance; the IdP or ZTNA layer checks current posture at connection time. A certificate answers "is this our device"; a posture check answers "is it healthy right now."

How many conditional access policies should a 200-person company have?

Fewer than you think — typically under a dozen, each with a clearly stated purpose. If you cannot explain each policy in one sentence, consolidate.

What is the single highest-value first step?

Inventory every place a policy is currently enforced, then write down which layer owns which question. Most SMBs discover duplicate and contradictory rules in that exercise alone.

What's the difference between a policy decision point and a policy enforcement point?

The policy decision point (PDP) evaluates identity, device, and context signals and decides whether access should be allowed. The policy enforcement point (PEP) is the product that sits in the traffic path and actually allows, blocks, or terminates the connection based on that decision. An SMB should have one PDP and can have several PEPs.

Further Reading

• Zero Trust with Microsoft Entra ID: A Practical Integration Guide
• Device Identity Verification & Enforcement (DIVE), Explained
• Announcing Device Posture Policies for CloudConnexa
• Announcing Location Context Policy
• 7 ZTNA Best Practices for SMBs

Notes

[1] NIST Special Publication 800-207, Zero Trust Architecture. nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf

[2] NIST Special Publication 1800-35, Implementing a Zero Trust Architecture, final, June 2025 — build detail at Enterprise 3 Build 5 (E3B5): SDP and SASE, Microsoft Entra Conditional Access (formerly Azure AD Conditional Access) and Microsoft Security Service Edge as policy engines.

[3] CISA, Zero Trust Maturity Model, Version 2.0, April 2023. cisa.gov/sites/default/files/2023-04/zero_trust_maturity_model_v2_508.pdf

[4] ThreatLocker, "AitM phishing attacks against Microsoft 365: MFA bypasses, session hijacking, and BEC."

[5] NIST Special Publication 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management.

[6] Microsoft Learn, "Microsoft Entra Conditional Access optimization agent."

[7] Practical365, "The 5 Most Common Conditional Access Misconfigurations."