Trust managed devices
Device trust adds a cryptographic device check to Firezone access. At connection time, the Client presents an X.509 certificate issued by your MDM or enterprise PKI and proves that it holds the corresponding private key. Firezone validates the identity before allowing access through a Policy that requires attestation.
Availability: Device trust is available on all Firezone plans.
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.
The private key stays in the platform's native key store or configured PKCS#11 token, backed by a TPM or other secure hardware where supported. A serial number by itself can be copied; Firezone requires the Client to prove that it holds the private key issued to that device.
Device trust proves that the current Client holds an identity issued by a CA you trust. It does not evaluate posture such as OS version, disk encryption, malware protection, or MDM compliance state.
How it works
- Your MDM or PKI issues each managed device a Client certificate and private key. Typically, this is done via SCEP or ACME.
- The certificate contains a device identifier in its Subject Alternative Name (SAN).
- When the Client finds a valid certificate and can use its private key, it connects to the Firezone portal using mutual TLS (mTLS). It presents the certificate and proves possession of the private key during the TLS handshake.
- Firezone validates the certificate chain, lifetime, intended usage, and device identifier against the trust anchors configured for your account.
- A Policy with Require attestation grants access only while that Client connection remains attested.
The mTLS connection cryptographically ties the device's Firezone session to the certificate. Copying the certificate or its device identifier is not enough to establish that session: the Client must also be able to sign with the private key. The private key stays in the platform's key store, which performs the signing operation on the Client's behalf.
Device trust supplements the user's existing sign-in. Resource traffic continues to use Firezone's WireGuard tunnels; mTLS secures the Client's connection to the portal.
Platform behavior
Each platform supplies the certificate and private-key operations differently. Your provisioning system deploys the identity and grants Firezone access to it.
| Platform | How Firezone uses the device identity |
|---|---|
| Windows | The Client finds the certificate in the local computer personal store (LocalMachine\My). The tunnel service runs as LocalSystem and signs through Windows CNG. The key can be protected by a TPM. |
| macOS | The Client uses the Keychain identity referenced by the managed VPN configuration. The certificate and VPN payloads must be linked. The network extension needs access to the private key without an interactive Keychain prompt. |
| iOS and iPadOS | The Client uses the managed identity referenced by the VPN configuration. The certificate payload supplies the identity, and the VPN payload selects it for Firezone. |
| Android | The Client uses an identity in Android KeyChain, selected by a managed keychain alias for corporate-owned devices or selected by the user for personally owned devices. The MDM grants Firezone access to the private key. The certificate and app must be installed in the same Android profile. |
| Linux | The Client uses a configured PKCS#11 identity. The certificate and signing key can be held by a TPM, smart card, hardware security module, or software token. Signing is delegated to the PKCS#11 provider. |
Use a non-exportable, hardware-backed key where the platform and enrollment method support it. The setup guides cover the provider-specific profiles and permissions.
Certificate requirements
Apply these requirements to the certificate profile or CA template:
| Field | Requirement |
|---|---|
| Subject | Set the common name to CN=dev.firezone.device-trust. |
| Extended Key Usage | Include TLS Web Client Authentication (clientAuth, OID 1.3.6.1.5.5.7.3.2). |
| Key Usage | Omit Key Usage or include digitalSignature. |
| Key algorithm | Use RSA or ECDSA with the P-256, P-384, or P-521 curve. |
| Private key | Make it non-exportable and hardware-backed where supported. |
| Validity | Choose a lifetime and renewal window appropriate for your organization. |
| Subject Alternative Name | Include at least one supported device identifier as a URI SAN. |
Firezone does not use the certificate subject as the device identifier. The subject's fixed common name lets Clients select the correct identity; the SAN contains the per-device claim.
Device attributes
Use a typed URI SAN in this form:
firezone://<type>/<value>
Choose the most specific stable ID your MDM can place in the certificate. An MDM inventory ID is preferable to a hardware serial because it is scoped to and controlled by the management provider.
| Claim | URI SAN example |
|---|---|
| Serial number | firezone://serial/C02ABC123XYZ |
| UDID | firezone://udid/00008110-001234560E91801E |
| SMBIOS UUID | firezone://smbios-uuid/01234567-89ab-cdef-0123-456789abcdef |
| Microsoft Intune device ID | firezone://intune-id/<device-id> |
| Workspace ONE UUID | firezone://ws1-uuid/<device-id> |
| Jamf Pro device ID | firezone://jamf-id/<device-id> |
| Iru/Kandji device ID | firezone://kandji-id/<device-id> |
A certificate may contain multiple typed URI SANs, for example both an MDM ID and a serial number. Do not use an empty, placeholder, or shared value.
Set up Device Trust
Follow Set up Device Trust to configure trust anchors and Policies, then choose a provider guide or the universal setup. Device Trust works independently of how you provision certificates, including on Linux through PKCS#11 with a TPM.
Certificate renewal and revocation
Renew a certificate before it expires and preserve its device identifier. When
selecting among
multiple usable certificates, Firezone picks the one with the most recent
validity start date (NotBefore). On platforms where the MDM or user selects
the identity, keep that selection pointed at the renewed certificate.
The Firezone portal supports both Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). It discovers the revocation endpoints advertised in certificates when devices connect:
- CRLs publish the certificate serial numbers revoked by an issuing CA.
- OCSP responders report the status of individual certificates.
Firezone checks for revocation in the background. Once it detects a revoked certificate, it disconnects Clients using that certificate and blocks them from reconnecting with it. Revocation takes effect after the CA publishes the updated status and Firezone retrieves it.
Need help? See all support options.