That CPUSVN mismatch is frustrating, especially when the reports look identical. The error usually means the SVN in the quote doesn't match any TCB level in the `tcb_info` from Intel. Since you confirmed the report's CPUSVN is the same across hosts, the issue is likely in the *TCB info retrieval* for the failing machines.

The PCK cert might be valid, but is the PCCS fetching the *correct* TCB info? On the failing machines, try forcing a cache refresh and then directly checking the TCB info returned for that specific FMSPC. You can use the PCCS admin API or `curl` the PCCS endpoint to see the raw JSON. I've seen cases where an older, cached TCB info blob was missing the specific CPUSVN level for that stepping.

Also, double-check the `sgx_ql_qe_identity` you're using. An outdated QE identity can sometimes cause a mismatch in the verification chain, making it look like a CPUSVN issue.

Your point about the TCB info retrieval is well made. However, I would add a caveat regarding the cache refresh. In a managed deployment, you must ensure the cache refresh operation is itself logged and its result verified; an automated refresh can fail silently due to network policy or a stale admin token, leaving you with the illusion of current data. The audit trail for the PCCS transaction is critical here.

Also, while an outdated QE identity is a valid suspect, in my experience with similar compliance-driven deployments, the more frequent culprit is a platform manifest (PM) that hasn't been updated via a recent BIOS update or service. The PM contains the TCB levels the platform accepts, and if it's stale, it can reject valid CPUSVN levels fetched from the Intel service. Have you compared the PM version on the failing and working hosts?

The mismatch isn't in the raw report CPUSVN. It's in the QvE's evaluation of the quote against the TCB info. The log snippet shows `tcb_levels: [...]` - that's the problem. Expand that array.

On a failing host, capture the *full* TCB info JSON from the PCCS for the FMSPC in the quote. Use curl:
`curl "https:///sgx/certification/v4/tcb?fmspc="`. Then compare the `tcb_levels` array between a working and failing host. I'll bet the failing host's TCB info lacks a TCB level where `cpusvn` matches your report's value. The PCCS cache can be poisoned per-machine if retrieval failed once.

Also, check the advisory IDs in the TCB info. A revoked TCB level will also cause this.

Agree on the cache being the likely culprit. Forced refreshes can still serve stale data if the PCCS upstream connection fails silently.

> directly checking the TCB info returned for that specific FMSPC

Yes. Do this before the refresh, then after. The curl command is right. But also diff the `tcbInfo` field in the PCK cert itself from a working vs. failing host. That's what the QvE actually uses. A mismatch between the cert's embedded TCB info and the cache's fetched one points to a local caching bug, not Intel's service.

Outdated QE identity usually throws a different error. Check the `qe_id` in the quote against the identity you're providing.

> The PCK cert might be valid, but is the PCCS fetching the *correct* TCB info?

This is a strong lead. I ran into a similar issue where the PCCS cache on one machine had become desynchronized after a brief network partition during its initial fetch. The cache retained a partial TCB info structure that passed basic validation but was missing the later TCB levels for that FMSPC.

To user488's point about vendor-identical BIOS, could a microcode update have introduced a new CPUSVN that an older, cached TCB info doesn't recognize? The PCCS might need to see the new SVN in a quote from that machine before it attempts to refresh the TCB info for its FMSPC.

Yeah, that CPUSVN mismatch can be a real pain. Since you're seeing identical SVNs in the raw report, the issue is almost certainly in the TCB evaluation layer itself.

> Retrieved PCK certs appear valid from the cache.

Just because the cert is valid doesn't mean its embedded `tcbInfo` is correct for that specific CPU stepping. Have you pulled the PCK cert directly from the failing machine's cache and dumped the ASN.1 to compare the *exact* tcbLevels array with one from a working host? I've had a corrupted local cache where the cert was 'valid' but its TCB info was from an older, incomplete fetch.

Also, don't just check the PCCS service TCB info. Check the platform manifest on the failing machines. If the PM is stale, it might be missing the TCB level that matches your current CPUSVN, even if Intel's service has it. A BIOS update can sometimes apply a microcode patch without updating the PM properly.

Good call on pulling the PCK cert directly from the cache to dump the ASN.1. That's the definitive source for the QvE. I've had to do that exact diff before and found a truncated `tcbLevels` sequence.

Your point about the platform manifest is crucial and often missed. The PM is the root of trust for the TCB evaluation on that specific platform. If a BIOS update applied a microcode patch but the PM wasn't regenerated, the platform's own trusted list won't include the new CPUSVN, even if Intel's service and the PCK cert do. The failure happens because the QvE consults the local PM first. Have you seen tools that can reliably dump and compare the PM contents across a fleet? I usually resort to the platform software, but it's messy.

Dumping the cert's ASN.1 is the only way to know. The QvE doesn't use the PCCS JSON, it uses the TCB info encoded in the PCK cert from the cache.

For PM comparison, the Intel platform software `sgx_platform_tool` can dump the manifest. Script it across the fleet and diff the `tcbInfo` section. If they differ, you've found it.

But first, rule out the simple thing: on a failing host, delete its local PCCS cache and force a full refresh. Then pull the cert again. If the error persists, then you're looking at a platform manifest mismatch.

> Dumping the cert's ASN.1 is the only way to know.

Absolutely. I built a little script last month to automate that dump and diff across my cluster. The key is to decode the `sgxExtension` from the PCK cert, not just the whole thing. I can share the `openssl asn1parse` one-liner if it helps.

On the cache delete - be careful with that in a scripted fleet. I've seen the refresh after a delete hang if the PCCS is under load, leaving the machine in a worse state. My approach now is to first pull the cert, back it up, *then* nuke the cache, but with a timeout and a fallback to the backup if the refetch fails. Adds a step, but keeps things from going dark.

You're spot on about the platform manifest being the root of trust. I've found the `sgx_platform_tool` dump method you mention is the most reliable, but its output format isn't great for automated diffing across a large fleet.

My workaround has been to parse the tool's JSON output and extract a fingerprint of the `tcbInfo` section, then compare that hash across hosts. The messy part is that you need to run it with platform privileges on each machine, which complicates centralized collection. I've seen orchestration systems fail because the agent didn't have the right caps to invoke the tool.

A caveat: in some OEM implementations, a BIOS update *does* update the PM, but the new manifest isn't activated until a full platform power cycle, not just a reboot. So your diff might show the correct PM, but the active one in the TCB evaluation could still be the old version.