Set up Device Trust

Device Trust works with any X.509 certificate provisioning method. You can use an MDM, SCEP, ACME, or your own PKI tooling, as long as the certificate meets Firezone's certificate requirements and the Client can use its private key. The Firezone-side setup is the same for every provider, including Linux deployments using PKCS#11 with a TPM.

1. Choose or create a certificate authority

Every device identity is issued by a CA that you control and that Firezone trusts. Start here, because the next step needs that CA's public certificates.

If you already have a PKI, export the public certificates for its root and every intermediate in the chain, and confirm its certificate template can issue the values under certificate requirements.

Otherwise, see Set up PKI for what Firezone requires of a certificate authority, and for guides covering specific PKI providers. Return here once you have the CA's public certificates.

2. Add your trust anchors

1. Sign in to the Firezone admin portal and go to Settings → Trust Anchors.
2. Select Add Trust Anchor.
3. Enter a descriptive name and paste or upload the CA certificate.
4. Repeat for every intermediate and root CA needed to validate the Client certificate.

Firezone accepts PEM and DER certificates. The Client presents its leaf certificate, so add every CA certificate Firezone needs to build the chain.

3. Deploy and test the device identity

Deploy the certificate and private key to a test device using the guide for your provider, or the universal setup if your provisioning system is not listed.

Choose your provider and platform

Universal setup

Use this approach for Linux or any certificate provisioning system not listed above. A supported MDM integration is not required.

1. Issue a unique certificate for each device that meets the certificate requirements, including the CN=dev.firezone.device-trust subject and a supported device identifier URI SAN. Include firezone://serial/<serial-number> alongside the inventory ID, except on personally owned Android work profiles where hardware serials are restricted.
2. Provision the certificate and private key so the Client can use them through the platform's native key store or a PKCS#11 provider. Use a non-exportable, hardware-backed key where supported.

On Linux, configure the Client to use the PKCS#11 provider and identity holding the device certificate and private key. A TPM-backed PKCS#11 provider lets the TPM hold the key and perform signing operations without exporting it. Other PKCS#11 tokens work too; certificate issuance and renewal can use whichever provisioning system your organization already operates.

Confirm the identity on a test device

Connect the test device and open Settings → Device Trust in the Client. Confirm that it shows the selected certificate, a valid chain, and access to the private key.

Do not enforce device trust broadly until renewal has also been tested. An expired or inaccessible private key causes the Client to connect without attestation.

If any of those checks fail, see Troubleshoot Device Trust.

4. Require attestation in a Policy

1. Open the Policy that grants access to the protected Resource.
2. Add the Require attestation condition.
3. Save the Policy and test access from both an attested and unattested Client.

The condition checks the current connection. A Client that reconnects without its certificate does not retain an earlier attested state. Because overlapping Policies are additive, confirm that another Policy does not grant the same Group access to the Resource without the condition. See Policies for details.

Need help? See all support options.