Binding a KMS key policy to PCR8 instead of PCR0: is there a practical middle ground?

To start with the conclusion: there is room to argue that you might be mistaken regarding both Question 1 and Question 2.

Q2: You can define the PCR0 allowlist directly in the policy

kms:RecipientAttestation:PCR<PCR_ID> is a multivalued condition key (unlike ImageSha384, which is single-valued). Policies generated by Anjuna tools also use an array format.

Since multiple values ​​within the same key are evaluated with OR logic, and different keys are evaluated with AND logic, you can write the expression exactly as you intended:

"Condition": {
"StringEqualsIgnoreCase": {
"kms:RecipientAttestation:PCR8": "<Signing Certificate>",
"kms:RecipientAttestation:PCR3": "<Parent IAM Role>",
"kms:RecipientAttestation:PCR0": ["<Approved 1>", "<Approved 2>"]
}
}

However, this alone does not eliminate the need for edits with every release. The solution is described in the next section.

Q1: Please separate the Key Policy from the IAM Policy

This condition key can be used in both the Key Policy and the IAM Policy, and the conditions from both are combined using a logical AND.

	Condition	Change Frequency	Change Management
Key Policy	PCR8 + PCR3	Rarely changes	MFA / Multi-party approval
Role IAM Policy	PCR0 allowlist	Every release	CI auto-update / PR / CloudTrail

This addresses both sides of the trade-off. You avoid touching the most critical control (the Key Policy), while only the IAM side changes. Even if the IAM side is compromised, the "Signed by Us" barrier remains, ensuring that the worst-case scenario is equivalent to a configuration using only PCR8.

From an operational standpoint, you should incorporate practices such as rotating the allowlist across N generations to remove old PCR0 values ​​(effectively revoking them) and using the kms:RecipientAttestation:* values ​​recorded in CloudTrail to audit actual decryption events after the fact. Furthermore, an article on Nitro Enclaves + KMS published by Trail of Bots in August 2026 outlines a review framework that includes using PCR0 for authorization, PCR1–2 for defense-in-depth, PCR3 for parent role restrictions, and MFA for critical operations. The approach described above is a natural evolution of that framework.

Q3: It hinges on whether reproducible builds are actually verified.

If a third party actually performs a rebuild and matches the result against PCR0, that step becomes the linchpin of the chain of trust. If the process remains merely "intended" but no one actually reproduces the build, the published PCR0 is nothing more than a self-declaration, rendering all other elements meaningless. This is the single most critical point. While reviewers in the custody domain do perform actual verification, typical SOC2 auditors generally do not.

There is one technical loophole. A certificate endpoint with a nonce proves that an enclave with that PCR configuration exists, but it does not prove that the current TLS peer is indeed that enclave; a proxy on the parent instance could forward a certificate belonging to a different process.

To close this gap, terminate the TLS connection inside the enclave and bind its public key to the public_key field of the certificate. An end-to-end claim can only be substantiated once a reviewer confirms that these two keys match.

Additionally, since making the key policy immutable is likely impossible, disclosing the entities authorized to modify it—along with the associated approval requirements—will complete the trust model.