Before a device can present TPM-attested certificate requests, its Attestation Key (AK) must be cryptographically bound to the Endorsement Key (EK) that the TPM manufacturer certified. This binding happens exactly once per device, using the TCG-standard Credential Activation protocol. After enrollment, every subsequent attestation trusts that the AK could only have been produced by this specific TPM.
Tpm Enrollment

​
What it is

Credential Activation proves that an AK physically co-resides with the manufacturer-certified EK in the same TPM. This is the foundation of hardware-rooted identity: without it, anyone could present an arbitrary AK and fake an attestation quote. After enrollment, TigerTrust stores the AK binding and every future attestation verifies the quote against that enrolled record.

​
When to use it

  • Register a new batch of IoT gateways before they are deployed to the field.
  • Re-enroll a device after a TPM clear or ownership change.
  • Bootstrap edge devices for attested certificate provisioning.

​
Set it up

1

Enable the TPM resource manager on the device

On Linux, load the tpm_rm driver so /dev/tpmrm0 exists. This is the device interface the TigerTrust agent uses.
2

Configure the agent's key provider

Set the agent configuration to use the TPM key provider and point it at the TPM device path and a local keystore directory. The agent needs read access to the TPM manufacturer EK certificate stored in the TPM’s NV memory.
3

Run enrollment

On the device, run:
tigertrust-agent enroll-tpm \
  --backend https://tigertrust.example.com \
  --device-id gw-042
The agent generates an AK inside the TPM, reads the EK certificate from NV memory, runs the Credential Activation challenge/response with TigerTrust, and stores the enrollment context locally.
4

Verify enrollment in TigerTrust

Go to IoT > Devices, open the device record, and check the Attestation history tab. A successful enrollment shows the AK name, EK manufacturer, and enrolled-at timestamp. From this point, tigertrust-agent renew-cert runs the full attest-and-provision flow automatically.

​
What you’ll see

After enrollment, the device record in IoT > Devices shows the enrolled AK identifier, the TPM manufacturer extracted from the EK certificate (for example, Intel, Infineon), and the enrollment timestamp. Subsequent attestation attempts appear in the Attestation history tab.

​
EK trust store

TigerTrust can optionally chain-verify the EK certificate against TPM manufacturer root certificates. Load manufacturer roots into your PKI Core configuration by downloading them from each manufacturer’s certificate distribution service. Without manufacturer roots, the Credential Activation challenge still runs but the EK chain is not verified against a trusted anchor.
ManufacturerCertificate source
Intel PTThttps://ekop.intel.com/ekcertservice
Infineon SLBhttps://pki.infineon.com/
STMicro ST33https://sw-center.st.com/STSAFE/
Nuvoton NPCThttps://www.nuvoton.com/security/NTC-TPM-EK-Cert/
AMD fTPMhttps://ftpm.amd.com/
In production, populate the EK trust store — otherwise you lose the “is this the TPM we think it is?” proof. An empty trust store means the Credential Activation challenge runs but manufacturer identity is not verified.

​
Re-enrollment

If a device’s AK needs to change (TPM cleared, ownership change), delete the enrollment record from IoT > Devices > Attestation and re-run tigertrust-agent enroll-tpm. The new AK goes through its own Credential Activation cycle.

TPM attestation

Per-issuance flow, the three cryptographic proofs, and failure reason codes.

TPM policies

Golden PCRs, EK allow-lists, and how issuance is gated.

IoT devices

Device inventory that TPM enrollment feeds into.