Trust managed devices

Available on: all plan levels

Signing in proves who someone is. Device trust proves which device they are using. It adds a second, cryptographic check to Firezone access: before a Client can reach a protected Resource, it must prove that it holds a device identity your organization issued.

When to use device trust

Use device trust when signing in as an authorized user should not be enough to reach a sensitive Resource. Common examples include:

  • Restricting production, finance, or administrative systems to organization-managed devices.
  • Preventing a copied credential or active browser session from granting access on an unmanaged device.
  • Requiring a hardware-backed, non-exportable device identity in addition to your existing identity provider and multi-factor authentication.
  • Removing access when an MDM removes or stops renewing a device certificate.

How it works

  1. Your MDM or PKI system causes each managed device to generate a private key and obtain a corresponding client certificate, typically using SCEP or ACME. The key is generated inside the platform's key store, backed by a TPM or other secure hardware where available, and the certificate carries a device identifier in its Subject Alternative Name.
  2. When the Client finds a usable certificate, it connects to the Firezone portal over mutual TLS. It sends the certificate, and the key store signs the handshake on its behalf. The key itself is never transmitted.
  3. Firezone validates the certificate chain against the trust anchors configured for your account, along with its lifetime, intended usage, and device identifier.
  4. A Policy carrying the Require attestation condition grants access only while that Client connection remains attested.

Device trust supplements the user's existing sign-in rather than replacing it. Resource traffic continues to flow through Firezone's WireGuard tunnels; mutual TLS secures the Client's connection to the portal.

Why the identifier alone is not enough

A serial number can be read off a chassis. A certificate can be copied off a disk. Neither is a secret, so neither is proof on its own.

Why a copied certificate is not enoughTwo devices on the left, one above the other, both connecting to the same Firezone portal on the right. The upper device is managed. It holds a certificate whose device identifier is firezone://serial/C02ABC123, and it holds the matching private key in secure hardware. The lower device is unmanaged. It holds a copy of the very same certificate, with the very same device identifier, but its key slot is empty: the private key could not be copied, because it never left the hardware of the managed device. Both devices attempt a mutual TLS connection to the portal, which holds one set of trust anchors and applies them to both. The managed device signs the handshake with its key. The portal marks the connection attested and grants access back down that same connection, and the device then opens a WireGuard tunnel of its own to the protected Resource. That tunnel does not pass through the portal: the portal decides who may connect, and does not carry the traffic itself. The unmanaged device gets as far as the handshake and stops there, because it has no key to sign with. The portal rejects the connection, no tunnel is built, and there is no access, even though the certificate it presented was valid and identical.managed devicecertificatefirezone://serial/C02ABC123private keyheld in secure hardwareunmanaged devicecertificatefirezone://serial/C02ABC123private keycould not be copiedFirezone portalconnection attestedtrust anchorsconnection rejectedsigns the handshakeaccess grantednothing to sign withWireGuard tunnelprotected Resourceno access
Both devices hold the same certificate. Only one can sign with the key that certificate was issued to.

What makes the check meaningful is the second half of step 2. The Client does not merely present a certificate; it signs the TLS handshake with the matching private key. That key stays in the platform's native key store or a configured PKCS#11 token, and the signing happens inside it. An attacker who copies the certificate file, or who knows the device identifier inside it, still cannot produce the signature, so the session never becomes attested.

This is why Firezone treats the hardware-backed, non-exportable key as the thing worth having. Where the platform and enrollment method support it, the key cannot be exported at all, and the device identity is bound to that piece of hardware rather than to a file.

What device trust does not check

Device trust answers one question: is this Client holding an identity issued by a certificate authority you trust? It says nothing about the state of the device beyond that.

It does not evaluate OS version, disk encryption, malware protection, screen lock, or MDM compliance state. A managed device that has fallen out of compliance still holds a valid certificate until your MDM revokes or stops renewing it. Use Device Posture to add those checks to your Policies alongside attestation.

Where the identity comes from

Firezone does not issue device certificates and does not integrate with any particular MDM or PKI product to get them. It validates whatever your provisioning system produces, as long as the certificate meets the certificate requirements and the Client can reach the private key. See Set up PKI for what that asks of a certificate authority.

Each platform supplies that key differently: Windows through CNG in the local computer store, Apple platforms through a Keychain identity linked to the managed VPN configuration, Android through the KeyChain, and Linux through a PKCS#11 provider, which may be a TPM, a smart card, or a hardware security module. See platform key storage for what each one expects.

Next steps

  • Set up PKI covers what Firezone requires of a certificate authority, with guides for specific PKI providers. Start here if you do not already have one.
  • Set up Device Trust walks through trust anchors, deployment, and the Policy condition.
  • Device Trust reference lists the certificate requirements, device identifier formats, and revocation behavior.
  • Troubleshoot Device Trust covers certificates that are missing, unusable, or attested without granting access.

Need help? See all support options.

Found a problem with this page? Open an issue
Last updated: October 02, 2026