Modern enterprise ZTNA backed by cryptographic device trust

Traditional VPNs authenticate users once and then implicitly trust the device they are using, the network path they connect through, and the session itself until logout or timeout. That trust model creates clear attack opportunities, including lateral movement after initial access, token replay, session hijacking, unmanaged devices reaching sensitive networks, and excessive exposure of internal systems far beyond what the user actually needs.

Smallstep ZTNA eliminates the concept of a trusted network and replaces it with identity-based, application-level access. Access is enforced through hardware-attested device identity, short-lived certificates, and continuous authentication using mTLS, with per-application routing over MASQUE and HTTP/3 tunnels. Only authenticated users on attested devices can reach protected applications, and no broad network access is ever granted.

Most ZTNA products rely on software-only agents, browser-based proxies, device posture checks without hardware proof, and IP reputation or token-based validation. These signals are weak by design and can be spoofed, replayed, or bypassed once an attacker gains a foothold on the device or inside the session.

Smallstep ZTNA is built on hardware-rooted identity rather than software assertions. It uses TPM, Secure Enclave, or vTPM attestation, non-exportable private keys, and mTLS-bound sessions with short-lived certificates. Access enforcement is based on real cryptographic guarantees, making ZTNA identity as strong as the device’s hardware security instead of easily faked software claims.

Smallstep uses MASQUE (Multiplexed Application Substrate over QUIC Encryption) as the transport layer for private application access. MASQUE runs over QUIC, providing low-latency, TLS-protected tunnels that work reliably even through restrictive networks, firewalls, and proxies, while supporting seamless roaming as devices move between networks.

Combined with mTLS-based identity, MASQUE enables multiple application connections to be securely multiplexed through a single tunnel with strong confidentiality and performance. The result is a ZTNA access channel that is fast, resilient, mobile-friendly, and enforced by cryptographic identity rather than network trust.

Smallstep supports two access modes depending on assurance requirements. The recommended model is full device identity with an agent, which uses hardware attestation through TPM or Secure Enclave and enforces mTLS device identity across the operating system, browser, and CLI. This mode is required for high-assurance access where device integrity and strong cryptographic guarantees matter.

For lower-risk scenarios, Smallstep also supports agentless browser access using browser-based mTLS only. This is suitable for contractors, BYOD users, and external partners, but provides lower assurance than full device attestation. Most organizations deploy a mix of both models, aligning access strength with user type and risk.

In a Smallstep ZTNA flow, a user attempts to access a specific internal service such as a web app, SSH endpoint, or API. The device presents a hardware-backed mTLS certificate, which the ZTNA relay validates along with device attestation, posture, and access policy before allowing any connection to proceed.

Once validated, a MASQUE tunnel is established between the device and the relay, and the user’s cryptographic identity is forwarded to the protected application using mTLS or SSH. Access is granted only to the requested application, not to the surrounding network, eliminating implicit trust and lateral movement.

For a device to gain access, it must pass hardware attestation, exist in inventory, maintain posture compliance, present a short-lived certificate, and successfully renew its identity. These checks are continuous, not one-time gates, and they determine whether access is allowed at any moment.

If any requirement fails, access is immediately denied. Unmanaged or compromised devices cannot spoof hardware attestation or generate valid client certificates, which prevents them from impersonating trusted endpoints or silently persisting inside protected environments.

Smallstep ZTNA can front-end virtually any TCP or HTTP(S) service, including internal web applications, Okta or Entra admin consoles, Grafana, Jenkins, ArgoCD, Kubernetes API servers, SSH hosts using SSH certificates, databases such as Postgres, MySQL, and Redis, internal APIs and microservices, and developer or operations tooling.

If a service listens on a port, Smallstep ZTNA can place identity-driven access controls in front of it, ensuring that only authenticated users on verified devices can reach the application without exposing the underlying network.

Smallstep enforces identity across a wide range of access methods, including CLI tools such as curl, Git, Terraform, and kubectl using mTLS certificates, SSH connections using short-lived SSH certificates, database clients authenticated with mTLS client certificates, and custom applications using PKCS#11 or filesystem-based certificates.

This closes a fundamental ZTNA gap. Smallstep protects everything that relies on network access, not just browser-based web applications, by extending strong identity enforcement to infrastructure, automation, and developer workflows.

Smallstep integrates directly with identity providers such as Okta, Entra, and Google for user authentication, with MDM and EDR platforms to enforce device posture and compliance, with Smallstep Device Identity to provide hardware-backed attestation, and with SIEM and SOAR systems to deliver audit logs and identity-based security events. It also integrates with Kubernetes and cloud platforms to extend identity enforcement to workloads.

Access is granted only when user identity, device identity, posture signals, and policy all agree. No single signal is trusted in isolation, and no access is permitted without full alignment across the identity stack.

Yes, policies can enforce controls based on user group membership, device class such as managed versus BYOD, hardware attestation status, operating system or patch level, and EDR health. They can also account for application sensitivity, environment distinctions like production versus development, and contextual constraints such as time of day or geographic location.

Each application can have its own Zero Trust policy, allowing organizations to apply strict controls where risk is highest and lighter controls where appropriate, without granting blanket network access.

Traditional VPNs provide network-wide access, rely on weak device trust, and authenticate users with long-lived passwords or pre-shared keys. This model carries a high risk of lateral movement, often delivers poor performance, and provides limited support for browsers, SSH, and API-driven workflows.

Smallstep ZTNA narrows access to the application level, enforces hardware-attested device trust, and uses short-lived certificates instead of static credentials. With QUIC and MASQUE–optimized performance, first-class browser support, and full support for SSH and APIs, Smallstep ZTNA effectively replaces most traditional VPN use cases, particularly for internal web applications, administrative systems, and developer infrastructure.

Traffic is secured end to end using mTLS between the device and the relay, QUIC TLS inside MASQUE tunnels, and mTLS or SSH for application-level connections downstream, with policy-based segmentation enforced on a per-application basis. Encryption and identity are applied at every layer, not just at the network edge.

Every request is bound to a verified user, a verified and attested device, a short-lived certificate, and an encrypted transport channel. This delivers true Zero Trust enforcement from the client to the application, without relying on implicit network trust.

Smallstep automatically blocks access through multiple independent controls. Hardware-bound private keys cannot be exported, certificates are short-lived, and removing a device from inventory immediately prevents identity renewal. If MDM or EDR posture checks fail, new certificates are denied, and any reset of the TPM or Secure Enclave breaks hardware attestation.

User suspension also disables certificate issuance, cutting off access at the identity layer. As a result, a stolen device cannot establish ZTNA tunnels or authenticate to protected applications, even if it still has network connectivity.

Yes. With Step CA Pro and Run Anywhere, organizations can deploy ZTNA relays on-premises alongside private certificate authorities and attestation services, operate in offline or highly restricted networks, and use customer-managed HSM keys. This model supports air-gapped environments and deployments in sovereign cloud regions such as GovCloud or Azure Government.

In all cases, identity issuance, policy enforcement, and cryptographic trust remain fully under the customer’s control. There is no dependency on a public cloud control plane to authenticate devices or authorize access.