Zero-Trust Network Access: The Certificate Story Your VPN Replacement Project Forgot

The Standard ZTNA Architecture You Already Drew

Open any 2026 zero-trust network access deployment plan and the diagram is almost identical. Endpoints talk to an identity-aware proxy. The proxy — Zscaler ZPA, Cloudflare Access, Netskope Private Access, Tailscale, Twingate, or a homegrown Envoy with OPA — terminates the connection at the edge of a private network, calls out to an identity provider (Okta, Entra ID, Ping, Auth0) to authenticate the user, queries a posture engine (CrowdStrike, SentinelOne, Jamf, Intune) to assess the device, and forwards the session to an internal application only if both checks pass.

The diagram closes with a fine-grained policy decision point implementing the per-request authorization model that NIST SP 800-207 calls a Policy Decision Point (PDP) feeding a Policy Enforcement Point (PEP).

This is the architecture inherited from Google’s BeyondCorp papers (2014 onward) and codified in NIST SP 800-207 (August 2020). Its premise is correct: the network is no longer a trust boundary; every connection must be authenticated, authorized, and inspected. Its premise is also incomplete.

The vast majority of zero trust network access certificates conversations in mid-VPN-replacement projects collapse identity to the user’s OIDC claim from the IdP. The device is reduced to a posture score: encryption at rest enabled, EDR running, OS version current. The session itself, once authorized, is protected by server-side TLS exactly the way a 2010 reverse proxy protected it. Nothing in that picture binds the cryptographic session to the specific hardware that initiated it.

The result is a ztna deployment that is operationally elegant and cryptographically thin. A stolen refresh token, a session cookie exfiltrated by an infostealer, or a phished OIDC code grant gives an attacker the same access as the legitimate device, because the broker has no cryptographic proof that the TLS client at the other end of the tunnel is the laptop it onboarded. The identity-aware proxy enforces user identity. It rarely enforces device identity in any cryptographically meaningful sense.

Where Certificates Belong (and Why They Are Usually Missing)

A serious ztna pki has certificates at four distinct layers, and each layer answers a different question. At device enrollment, a certificate signed by a private CA proves the endpoint is a fleet-managed device, not an arbitrary host with valid Okta credentials. The certificate’s subject (or, more usefully, its subjectAltName extension carrying a URI SAN like urn:device:fleet:laptop-7a2c or an otherName with hardware attestation) is the durable, cryptographically verifiable device ID. See the digital certificate primer for the X.509 fields that matter here.

At session establishment, the device authenticates to the ZTNA broker using mutual TLS (mTLS). The client sends a Certificate message in the TLS 1.3 handshake (RFC 8446, section 4.4.2), the broker validates the chain against the private root, checks revocation, and binds the user’s OIDC session to the device certificate’s fingerprint via the exporter key material defined in RFC 5705. The handshake produces a session that is cryptographically tied to a specific private key that, ideally, never leaves the device’s hardware root of trust.

At the service-to-service layer behind the broker, workload identity certificates — SPIFFE SVIDs as defined in the SPIFFE/SPIRE specifications, or short-lived X.509 issued by Istio, Linkerd, or a service mesh control plane — carry an spiffe:// URI SAN identifying the workload. The same TLS handshake mechanic that authenticates a laptop to the broker authenticates Pod A to Pod B inside a Kubernetes cluster. Both derive from a chain you control.

The client authentication certificates guide covers the Extended Key Usage id-kp-clientAuth OID (1.3.6.1.5.5.7.3.2) that distinguishes a client cert from a server cert in this flow.

At the API and code-signing layer, the same hierarchy issues signing certificates for CI/CD artifacts, mobile MDM payloads, and configuration profiles. Four layers, one chain, one revocation story.

Cert-light ZTNA deployments typically implement none of them. The broker presents a public-CA TLS server cert to the endpoint, the endpoint presents an OIDC bearer token to the broker, and the entire architecture rests on the assumption that the bearer token cannot be stolen. This is precisely the assumption that adversary-in-the-middle phishing kits (Evilginx, Modlishka, Tycoon 2FA) and infostealers (Lumma, RedLine, Rhadamanthys) have spent five years invalidating.

Device Identity vs User Identity — Why You Need Both

User identity and device identity are orthogonal. Conflating them is the single most consequential mistake in ZTNA design, and it is the one that almost every VPN replacement project makes in its first iteration.

User identity, done properly in 2026, is phishing-resistant. That means FIDO2/WebAuthn with a discoverable credential bound to a roaming or platform authenticator. The user proves possession of a private key, generated inside a TPM 2.0 (laptops), an Apple Secure Enclave (Macs and iOS), an Android StrongBox or Titan M2 (Pixel and most modern Android), or a roaming security key (YubiKey 5, Feitian, Token2) implementing CTAP2.

The IdP receives an assertion signed by ES256 or EdDSA over the relying-party origin and a server-supplied challenge. The assertion is unphishable because the private key never leaves the authenticator and the signature is bound to the origin. This is what NIST SP 800-63B-4 calls AAL3 with verifier impersonation resistance.

Device identity is a different problem with a different solution. The question is not who is at the keyboard, it is what hardware is generating this TLS handshake. The answer is hardware attestation. A TPM 2.0 device produces an attestation key (AK) certified by the manufacturer’s Endorsement Key (EK) certificate. The AK can sign quotes over Platform Configuration Registers (PCRs) — PCR0 captures the firmware measurements, PCR7 captures secure-boot state, PCR11 captures BitLocker state on Windows.

A device enrollment flow that issues a long-lived device certificate without binding the certificate’s public key to a TPM-resident private key, and without checking an attestation statement at enrollment time, is issuing a credential indistinguishable from a software secret on disk. It will be exfiltrated.

Apple devices follow the same pattern with the Secure Enclave Processor (SEP), the Device Attestation API, and the App Attest framework. Android uses Keymaster and the Key Attestation extension defined in the Android CDD: an attestation extension in the X.509 certificate carries the security level (TEE, StrongBox), the verified-boot state (Verified, SelfSigned, Unverified, Failed), and the OS patch level. These attestation fields go directly into your enrollment decision. If the attestation says verifiedBootState=Unverified, you do not issue a fleet certificate; you redirect to remediation.

The point is operational, not theoretical. A FIDO2 credential is bound to a user. A TPM-attested device certificate is bound to hardware. An attacker who phishes the user but has not stolen the laptop fails the device check. An attacker who steals the laptop but cannot prompt the user’s authenticator fails the user check. Both checks must succeed for the ZTNA broker to forward the session.

This is the operational definition of zero trust, and it is the model BeyondCorp described from the beginning — access depends on the user and the device, two independent assertions, both backed by hardware-rooted keys.

The Four Anti-Patterns of Cert-Light ZTNA

Mid-project teams converge on the same four failure modes. They are predictable enough to enumerate, common enough to warrant a checklist, and damaging enough that they undermine the security gains the ZTNA migration was supposed to deliver.

Anti-pattern one: certificates only at the perimeter, not internally. The ZTNA broker presents a TLS server certificate from a public CA at the edge. Behind the broker, traffic flows over HTTP, or over TLS with self-signed certificates that no client validates, or over an IPsec tunnel established at deployment and never rotated. The lateral movement story is unchanged from the VPN era: once an attacker is past the broker, the network behaves like a flat trusted zone.

A serious ZTNA architecture has mTLS everywhere — broker to backend, backend to backend, backend to database — with workload certificates rotated on a 15-minute to 24-hour cadence and validated against the same internal trust anchor.

Anti-pattern two: self-signed device certificates with no lifecycle. The MDM (Intune, Jamf, Workspace ONE, Kandji) generates a device certificate at enrollment, signs it with a built-in self-signed CA, and pushes it to the keystore. The certificate never rotates. The CA private key sits in the MDM database. There is no PKI hierarchy, no offline root, no HSM, no cross-signing path to anything the broker can validate against a real trust store.

When a device is decommissioned, the certificate is “deleted” from the MDM, but no CRL is published and no OCSP responder ever knew about it. A laptop that has been wiped and reinstalled still has a valid client certificate in the eyes of anything that does not query the MDM live. This is not a PKI; it is a directory with cryptographic decoration.

Anti-pattern three: certificates that do not expire. To avoid the operational pain of renewal, teams issue device certificates with validity periods of five, ten, or even twenty years. The justification is always the same: we do not want to break the fleet when certificates expire. The consequence is that revocation becomes the only mechanism for removing access, and revocation, in practice, is not real-time.

Short lifetimes (CA/Browser Forum is driving public TLS to 47 days by 2029) are not just a compliance trend. They are the right operational pattern for device certificates too: 30 to 90 day lifetimes with automatic renewal mean a compromised device loses access by attrition, not by manual revocation that nobody actually does. The automated certificate management guide covers the renewal patterns that make this operationally feasible.

Anti-pattern four: certificates without revocation reachability. The PKI publishes CRLs and runs OCSP, but the ZTNA broker is configured with soft-fail revocation checking, or the CRL distribution point sits behind the same network that the broker is supposed to gate access to. A compromised device whose certificate has been revoked continues to authenticate because the broker cannot reach the revocation infrastructure.

OCSP must-staple (RFC 7633) on broker-presented certificates, short-lived certificates as a CRL substitute, or OCSP stapling at the client side are the operational answers. The certificate lifecycle overview walks through the revocation reachability requirements in more detail.

A Reference Architecture with Certificate-Based ZTNA

The reference architecture for a credible ztna mtls deployment has six components and three certificate hierarchies. Drawn left to right: managed endpoint, ZTNA broker (the PEP), policy engine (the PDP), workload mesh, internal applications, and the PKI and key management plane underneath all of it.

The endpoint holds two keys in hardware. The first is the FIDO2 authenticator key for user authentication: WebAuthn assertion signed by ES256 over the relying-party origin, sent to the IdP, exchanged for an OIDC ID token and access token.

The second is the device-identity private key generated inside the TPM 2.0 (Windows), Secure Enclave (Apple), or StrongBox (Android). The corresponding public key was attested at enrollment via TPM quote or platform attestation, and a private CA issued an X.509 client certificate with the device’s fleet identifier in a URI SAN, EKU set to id-kp-clientAuth, and a 60-day validity. The endpoint’s TLS client uses this certificate for the mTLS handshake to the broker.

The ZTNA broker terminates the inbound mTLS connection. It validates the client certificate chain to a private root that lives in an HSM, checks revocation via OCSP stapling or short-lived certificate semantics, extracts the device identifier from the SAN, and queries the policy engine.

The policy engine combines the device identifier with the user identity (from the OIDC token), the device posture (from the EDR or MDM integration), the requested resource, the time of day, the source geography, and a risk score. If the decision is allow, the broker establishes an outbound mTLS connection to the backend service using its own broker-identity client certificate.

The workload mesh behind the broker runs SPIFFE / SPIRE or an equivalent. Every workload — pod, container, serverless function — receives a short-lived X.509 SVID with an spiffe://corp.example/ns/payments/sa/api URI SAN, valid for one hour, rotated automatically. Pod-to-pod, function-to-database, and service-to-service calls all happen over mTLS using these SVIDs. The internal CA signing the SVIDs chains to the same private root that signs broker certs and device certs — one root of trust, three issuing intermediates.

The PKI and key management plane sits underneath. The offline root is in an air-gapped HSM. Three online issuing CAs — device-identity, broker-identity, workload-identity — sit in network HSMs or cloud KMS (AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM with FIPS 140-3 Level 3). Enrollment happens via SCEP for legacy MDM-managed devices and ACME (RFC 8555) with device attestation extensions for modern endpoints. Renewal is automated. Revocation is published via CRL and OCSP, with broker-side stapling to ensure availability.

Walk the TLS 1.3 handshake step by step to see how all of this composes. The endpoint sends a ClientHello including SNI for the broker FQDN, supported cipher suites (TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256), and signature algorithms including ECDSA-SECP256R1-SHA256 and Ed25519.

The broker responds with ServerHello, its own server certificate chained to a public CA, and a CertificateRequest extension specifying acceptable CA distinguished names — the private device-identity CA. The endpoint TLS stack selects the TPM-resident device certificate matching the broker’s CA list. The TPM performs the signing operation for CertificateVerify (the private key never leaves hardware), and the broker validates the chain to the private root in its HSM-backed trust store, checks the OCSP staple on the device certificate, and extracts the device identifier from the URI SAN.

The broker then queries the policy engine with the tuple (device_id, user_oidc_sub, resource, posture). On allow, the broker binds the OIDC access token to the mTLS session via RFC 5705 exporter material or DPoP (RFC 9449), so a stolen bearer token is useless off this session.

The broker establishes its outbound mTLS to the backend using its broker-identity certificate, and the workload mesh continues mTLS hop by hop downstream.

Migrating from VPN to ZTNA Without Breaking Trust

The realistic migration path is not flag-day. It is a phased dual-stack rollout running 6 to 18 months. The variable that determines duration is not the ZTNA product; it is the certificate enrollment substrate and the heterogeneity of the device fleet. A well-managed fleet of 5,000 endpoints all running Windows 11 or macOS 14, all enrolled in Intune or Jamf, can be done in a quarter. A fleet of 50,000 devices including BYOD, contractors, ten-year-old Linux servers, manufacturing tablets, and three MDMs is an 18-month program.

The phasing is roughly four phases. Phase one (months 0 to 2): PKI foundation. Stand up the private root in an HSM. Issue intermediates for device, broker, and workload identity. Define certificate profiles with concrete fields — subject DN, SAN types, EKU, key usage, validity, renewal cadence. Wire up CRL and OCSP infrastructure with public-internet-reachable distribution points. Without this layer no other phase succeeds.

Phase two (months 2 to 5): enrollment substrate. Choose between SCEP and ACME, or run both. SCEP is the path of least resistance for MDM integration: every major MDM (Intune, Jamf, Workspace ONE, Kandji) speaks SCEP, certificates can be pushed to TPM-backed keystores via MDM payloads, and the rollout requires no changes to the endpoint side.

SCEP’s weakness is its security posture — the static challenge password is a shared secret, and the protocol predates modern attestation. Modern deployments use SCEP with dynamic challenges issued per-device by the MDM.

ACME, originally designed for Let’s Encrypt, has become the modern protocol for endpoint certificate enrollment thanks to the device-attestation extensions (the device-attest-01 challenge type and equivalents) that let the CA verify the requesting device against Apple Device Attestation, Android Key Attestation, or TPM quotes. ACME is the right choice for new fleets; SCEP is the right choice for fleets you cannot rebuild.

Phase three (months 4 to 12): fleet rollout in cohorts. Roll the device certificate to 5%, then 25%, then 100% of the fleet, by cohort (engineering first, sales next, contractors last, executives whenever they will tolerate it). Run the ZTNA broker in dual-mode: accept legacy VPN tunnels for unmigrated devices, accept mTLS for migrated devices, log which is which.

Measure failure modes: certificates that fail to install because the TPM is missing or disabled, devices that fail attestation because of secure-boot state, OS versions that lack ACME client support. Each failure mode produces a remediation ticket or a fleet-management policy change.

Phase four (months 10 to 18): VPN decommission and workload identity. Cut the VPN concentrators offline. Move internal east-west traffic to the workload mesh with SPIFFE SVIDs. Retire the IPsec tunnels between data centers and replace with broker-mediated mTLS.

The workload identity rollout is where ZTNA stops being a network project and becomes a platform engineering project — service meshes, sidecar proxies, mesh CA integration. Many organizations stop at phase three and never finish four; the broker-edge story is complete and the lateral movement story is half-built. The point of doing it properly is that the lateral movement story is where most actual breaches happen.

One frequently neglected dimension: the same certificate hierarchy that authenticates laptops must also authenticate the long tail of IoT and embedded devices behind the ZTNA broker. Printers, IP cameras, badge readers, manufacturing PLCs, medical devices, and conference room hardware all need device identity if they are to reach internal services.

They cannot run FIDO2 and they cannot install an MDM agent. They can hold an X.509 certificate provisioned at manufacture or onboarded via 802.1X / EAP-TLS. The ZTNA architecture must accommodate them or it becomes an architecture that protects 80% of the assets and leaves the other 20% on the trusted VLAN it was supposed to eliminate.

Where Evertrust Fits

A ZTNA project that ignores certificates is a user-identity project sold as a network architecture. The user identity story is, in 2026, mostly solved — FIDO2, OIDC, IdPs, posture engines, identity-aware proxies are commodity components and the integration patterns are well understood.

The hard part — the part that determines whether the deployment delivers actual zero trust or just a more elegant VPN — is the certificate plane: the private CA, the enrollment substrate, the attestation policy, the renewal automation, the revocation reachability, the workload identity mesh, and the unified inventory across all four certificate layers.

This is the surface Evertrust’s platform is built for. The CA hierarchy is yours, hosted in your HSMs and integrated with your cloud KMS. Enrollment runs over SCEP and ACME with device attestation. Lifecycle is automated: 60-day device certs renew without human touch, 1-hour workload SVIDs rotate continuously, revocation publishes to OCSP and CRL distribution points the ZTNA broker can actually reach.

Inventory consolidates the device, broker, workload, and signing certificates into a single source of truth so the architecture diagram and the operational reality remain aligned 18 months after the VPN was decommissioned. To see how the certificate plane plugs into a ztna mtls deployment, explore Evertrust Certificate Lifecycle Management.