C5:2026: Germany’s BSI standardizes confidential computing and remote attestation

What’s in the new catalogue

For a technology long considered a niche topic, that’s a clear signal. With C5:2026, confidential computing has arrived in the mainstream of cloud security. C5:2026 dedicates two criteria to confidential computing: OPS-32 for policies and procedures, and, interestingly, OPS-33 for remote attestation. Both apply once a cloud offers "confidential computing" features.

OPS-32 defines the term Trusted Execution Environment (TEE), which is central to confidential computing. It also lays down the basic mechanisms and minimum requirements. Among other things, it states explicitly that neither the cloud provider nor any unauthorized third party shall be able to access customer data or the keys used to protect that data.

OPS-33 raises remote attestation to its own level. If a cloud service offers confidential computing, it must also provide remote attestation. The attestation must be rooted in trusted hardware and software and made available to the customer for verification.

This requirement is fundamental. Without remote attestation, the customer has to trust the provider’s word that an application is actually running inside a TEE and that it’s the expected code. Attestation is what makes this technically verifiable. The BSI making this connection explicit, and tying remote attestation to confidential computing, is the right call.

The four attestation types

Within OPS-33, as shown in the screenshot above, the catalogue distinguishes four scenarios, depending on who collects the attestation evidence and who verifies it. The BSI’s assessment is unambiguous:

• Type 1 – very strong attestation. The customer collects the evidence directly from the TEE and verifies it on their own systems.
• Type 3 – strong attestation. The customer collects the evidence from the TEE but sends it to an external verification service they trust.
• Type 4 – weak attestation. The cloud provider collects the evidence from the TEE, sends it to a verification service under their own control, and returns only the result to the customer.

Type 2 is also defined, but in our reading it’s essentially identical to Type 1.

What this means in practice

Confidential computing offerings from hyperscalers and others typically operate as Type 4: the provider runs the verification service and hands the customer a result. Direct customer-side verification is not possible.

That’s a problem. The security claim ends up resting on trust in the provider, which is exactly what confidential computing is supposed to remove.

How we do it

At Edgeless Systems, we’ve built confidential computing products for years on a model that fully relies on customer-side verification. In the language of C5:2026, that’s Type 1.

Contrast, our open-source framework for confidential computing on Kubernetes, gives customers the tools to perform attestation themselves. The customer collects the evidence from the TEE, verifies it against a manifest they control, and decides on that basis whether a workload is trustworthy. That matches exactly the scenario C5:2026 calls Type 1.

Privatemode AI, our Confidential AI service, is built on Contrast and applies the same principle to AI inference. A client-side proxy handles attestation and encryption transparently for the user. The evidence is collected by the client and verified in an environment the user controls. Neither Edgeless Systems nor the underlying infrastructure provider can see prompts or responses.

This means Privatemode already delivers “very strong remote attestation” in the sense of C5:2026 and, on that basis, an effective and verifiable exclusion of the operator.

Outlook

C5:2026 will not change the market overnight. The catalogue becomes binding only on June 1, 2027, and providers will need time to align their confidential computing offerings with the new criteria. But the direction is set.

For organizations evaluating confidential computing solutions today, two questions are worth a hard look. Which attestation type is on offer? And who ultimately controls the trust decision: the cloud provider or the customer? The answers determine whether an offering meets the technical bar confidential computing sets, or whether trust in the provider quietly carries the security claim after all.