Introduction
Flexible PCR Policy allows you to customize which Platform Configuration Registers (PCRs) EVE-OS (Edge Virtualization Engine) uses when sealing the vault encryption key into the Trusted Platform Module (TPM). This replaces a previously hardcoded, static list of Platform Configuration Register (PCR) indexes with a controller-managed policy that can be updated per edge node without requiring a software redeployment.
How It Works
EVE-OS uses the TPM to seal the vault encryption key (the key that protects user data at rest) against a set of PCR values. Sealing means the TPM will only release the key if the edge node boots into a state that produces the same PCR values that were recorded at sealing time. Previously, the PCR indexes used for this sealing operation were fixed in EVE-OS at compile time and could not be changed without a code update and redeployment.
With Flexible PCR Policy, the Edge Infrastructure Services controller manages the list of PCR indexes and sends it to the edge node alongside the vault key after every successful remote attestation. EVE-OS then re-seals the vault key using the PCR indexes received from the controller rather than a hardcoded list. This gives operators direct control over which boot measurements are part of the vault protection policy.
The PCR index list is transmitted inside an authenticated, attestation-protected message. Because the edge node must pass remote attestation before receiving the key and the updated policy, the controller can be confident that the device is in an approved state before any policy change takes effect.
The controller validates every policy submission before distributing it. Specifically, it rejects any policy that removes PCR 0 (the Core Root of Trust measurement) or PCR 5 (Boot Manager Configuration), contains duplicate indexes, or includes indexes outside the valid range for TPM 2.0 (0–15).
After the edge node re-seals the vault key under the new policy, it stores the updated PCR index list in either a TPM non-volatile index or on disk for use in subsequent unseal operations. If storing the list fails due to sudden power loss or a TPM error, vault security is not compromised, but the next unseal attempt will fail and the edge node will need to complete attestation again to retrieve the list.
Key Benefits
- Per-node policy control. Operators can tailor the PCR sealing policy to the specific hardware, firmware, and boot configuration of individual edge nodes, without modifying or redeploying EVE-OS.
- Reduced false lockouts. PCRs that change frequently due to legitimate hardware or firmware variation (for example, PCR 1, Host Platform Configuration) can be excluded from the policy on nodes where those changes are expected, reducing unnecessary vault lockouts.
- Policy versioning and audit trail. Each policy carries a unique policy ID that increments with every change, giving operators a traceable record of which PCR configuration was active when a vault key was sealed.
- Backward compatibility. Edge nodes that do not receive a custom policy continue to use the EVE-OS default PCR indexes. No migration steps are required for existing deployments.
- Safety guardrails in ZCLI. The ZCLI command-line interface enforces a multi-stage review workflow when operators modify a policy, including a security impact warning when PCRs are removed from the default set.
Next Steps
This is a series of articles, you will likely follow them in this order:
- Overview of the Trusted Platform Module in EVE-OS
- Factors Affecting PCR TPM Register
- Remote Attestation Overview
- Flexible Platform Configuration Registers (PCR) Policy Overview - You are here!
- Manage a PCR Policy Using ZCLI
- Manage PCR Templates
- Configure an attestation policy in your project.
- Use EVE-OS Local UI to analyze attestation issues.