An attestation policy is the rulebook TigerTrust consults on every certificate issuance for a TPM-equipped device. It specifies which PCR values must match, which PCRs must be present in the quote, which TPM manufacturers are allowed, and whether the CSR key must be provably TPM-bound.

​
What it is

Each policy applies to a device type. When a device of that type requests a certificate, TigerTrust finds the matching policy and uses it to gate the cryptographic checks. Without a policy, the cryptographic checks still run but no PCR expectations or manufacturer filtering are enforced — suitable only for bootstrap. Production devices should always have a policy.

​
When to use it

  • Define golden PCR values for a specific firmware image and enforce them on every certificate renewal.
  • Restrict certificate issuance to devices with TPMs from specific manufacturers (for example, Intel and Infineon only).
  • Require Secure Boot to be measured (PCR7 non-zero) as a condition of certificate issuance.
  • Create a permissive default policy for development devices and a strict policy for production fleet.

​
Set it up

1

Capture golden PCR values from a reference device

On a known-good device built from the verified firmware image, run:
tpm2_pcrread sha256
Copy the hex values (without the 0x prefix) for the PCRs you want to gate on.
2

Open the policy editor

Go to IoT > Attestation > Policies and click New policy.
3

Set the device type

Enter the device type this policy applies to (for example, edge-gateway). Leave blank to create a default policy that applies to any device without a more specific policy.
4

Enter expected PCR values

Paste the golden PCR hex values into the Expected PCRs table under the SHA256 bank. Only entries you fill in are enforced — leave others blank to ignore them.
5

Set required PCRs

Enter the PCR indices that must be present in the device’s quote. Missing a required PCR fails attestation even if the PCR value would otherwise match.
6

Configure manufacturer and security options

Enter allowed EK manufacturers (for example, Intel, Infineon). Enable Require bound CSR key (on by default) and Require Secure Boot as needed.
7

Save and enable

Click Save. The policy is active immediately and applies to the next attestation attempt from any device of the configured type.

​
What you’ll see

IoT > Attestation > Policies lists all policies with their device type, enabled status, and the count of recent attestations that used each policy. IoT > Attestation > History shows the last N attestations across all devices with pass/fail reasons — critical for debugging a fleet-wide failure after a firmware rollout.

​
PCR reference

TCG recommendations for a typical UEFI + Secure Boot Linux device:
PCRWhat it measures
0UEFI firmware code
1UEFI firmware configuration
2Option ROM code
3Option ROM configuration
4Boot loader
5Boot loader configuration
7Secure Boot policy and signature databases
8–9Bootloader / kernel measurements
10IMA measurements (Linux kernel integrity)
For most fleets, gating on PCRs 0, 1, 2, 3, 4, and 7 gives you firmware and Secure Boot integrity without pinning the exact kernel image.
PCR values change on every firmware upgrade, kernel bump, bootloader change, or Secure Boot database update. Plan a policy update workflow: canary devices receive the new firmware first, you capture their new PCR values, update the policy, then roll out fleet-wide. Skipping this step means every device fails attestation after an OTA update.

TPM enrollment

Devices need an enrolled Attestation Key before policies fire.

TPM attestation

The full verifier flow that policies gate.

IoT devices

Device types, groups, and attestation history.