Confidential computing in C5:2026: defining the architecture and evidencing attestation

This page covers confidential computing as a focus topic of C5:2026. The OPS domain as a whole is covered on the page OPS domain, the cryptography policy and key management on the page CRY domain.

What is confidential computing about in C5:2026?

Confidential computing protects data while it is being processed. The catalogue adopts the definition of the Confidential Computing Consortium: computation takes place in a hardware-based, attested Trusted Execution Environment (TEE) (the German version 1.1.0 says “zertifiziert”, that is certified), an isolated part of the processor or chip in which only authorised code runs and whose data cannot be read or changed by code outside it (supplementary information on OPS-32). Attestation is used to check whether the TEE and the application running in it are trustworthy.

C5:2026 covers this in two new criteria. Both start with the same condition: “If the cloud service comprises capabilities for confidential computing” (OPS-32.01B, OPS-33.01B).

• OPS-32 Policies and procedures: The policy describes purpose and scope, the available technologies, which parts of the cloud stack are protected with which technology and where third-party access is possible, the suppliers involved and the use of TEEs or secure enclaves (OPS-32.01B). Customers receive this information according to PSS-01 (OPS-32.02B). One of the security requirements is that neither the provider nor any other unauthorised entity may access the customer data or the keys protecting it, and that the algorithms follow the cryptography policy (OPS-32.03B).
• OPS-33 Remote attestation: The provider offers remote attestation, rooted in trusted hardware and software, with an interface through which customers can verify the integrity of the attestation (OPS-33.01B to 03B).

The complementing additional criterion OPS-32.01AC requires a documented technical framework with eight points, among them documentation of all interfaces, remote attestation of TEE and code, monitoring, regular penetration tests under OPS-22 and updates of the Trusted Computing Base. OPS-33.01AC requires defining the available attestation levels and communicating them to customers.

Do OPS-32 and OPS-33 apply to my service?

If you offer confidential computing to your customers as a capability, for example confidential compute environments, both criteria apply. If you offer nothing of the kind, they are not applicable; you justify this in the system description. Under section 3.4.3 the justification can follow from the nature of the service or from your principles, procedures and measures; how you record exclusions in the scope is shown on the page C5 scope.

The case in between is open: you use the platform’s confidential virtual machines only internally, for example for a service that processes particularly sensitive data, and you promote this to customers. Whether the service then “comprises capabilities for confidential computing” is not expressly decided by the wording. Our recommendation: if you promise customers this protection as a property of the service, you should also be able to evidence it under OPS-32 and OPS-33. Clarify the classification with the auditor early on.

Starting point: an analytics platform with confidential compute environments

Fictitious example, not a client. A provider runs a platform on which research institutions and pharmaceutical companies jointly analyse pseudonymised health data without disclosing the raw data to each other. The analyses run in confidential virtual machines of a large cloud provider; the TEE technology comes from the processor manufacturer. The provider’s own key service releases the keys to the datasets only after the attestation of the compute environment has succeeded. Customers select a “confidential analysis” in the portal; confidential computing is therefore a capability of the service.

Before the project, the situation looks like this:

• The portal shows customers a green tick “Attestation successful”. Only the provider’s key service checks the evidence behind it.
• The operations documentation describes the confidential machines, but not which parts of the stack run outside the TEE: storage, network, key service, logging.
• The key service itself runs in an ordinary virtual machine; two administrators could change the release rules.
• Firmware and microcode updates of the platform go into operation without the provider assessing them first.

Who is responsible for what: provider, platform, customer?

The hardware comes from the processor manufacturer, the platform operates the confidential machines, the provider makes the promise to the customers. OPS-32 and OPS-33 are addressed to the provider; the catalogue lists no complementary customer criteria for them. Our classification for the example:

The suppliers under OPS-32.01B no. 4 overlap with the subservice organisations in your report; a shared subservice inventory avoids duplicate lists. Customers verifying evidence themselves is not a catalogue criterion for customers; if you assume it, it belongs in the system description as a complementary customer control (CUEC).

Which remote attestation scenarios does the catalogue distinguish?

In the supplementary information on OPS-33.01AC the catalogue rates four scenarios. The more the customer verifies itself in an environment it fully trusts, the stronger the attestation. If the provider retrieves the evidence, verifies it in a service it controls and returns only the result, the catalogue rates this as a weak attestation. The green tick in the example corresponds to this weak scenario. If the provider also passes on the evidence and the customer verifies it itself, the catalogue rates the scenario as very strong. The interface for customers is mandatory in every case (OPS-33.03B); defining and communicating the levels is complementing (OPS-33.01AC).

Example control description for OPS-32.03B and OPS-33

In the example, the promise to customers depends on one point: the key to a dataset may only reach an attested environment. Our example control (own wording, not catalogue text):

For the requirement from OPS-32.03B to hold against your own staff as well, the key service itself must be protected, for example in a TEE of its own or a hardware security module with release rules that nobody can change alone. That is our recommendation; the catalogue leaves open how the provider meets the requirement.

What evidence the auditor wants to see

With confidential computing the auditor has to trace two things: that the architecture delivers what the policy promises, and that attestation works in operation. Examples from the scenario:

How you map this evidence to the subcriteria and keep it available for the period is shown on the page Evidence and documentation.

Possible gaps: cause, effect, remedy

The following gaps follow from the wording of the criteria and the scenario. If a subcriterion is not met, the criterion counts as not met, and the auditor reports the deviation (sections 3.4.12 and 3.4.13).

Which gaps to close first is a question of prioritising measures.

Criteria relevant to confidential computing

Titles as in the English version 1.0.1, number of subcriteria counted per section 5 (B = basic, AS = sharpening, AC = complementing). The selection beyond OPS-32 and OPS-33 is our classification. The column “What it covers” is our own short description, not catalogue text; the wording of the criteria in the catalogue is binding.

OPS-32 and OPS-33 are new in C5:2026, with no predecessor.

Relationship to ISO/IEC 27001:2022 Annex A

The following mapping is our own, unofficial classification by topic. The BSI has not yet published a cross-reference for C5:2026. The catalogue refers to the BSI website for it (section 3.3). So far the table there covers C5:2020 only, and the BSI says the table for C5:2026 is “scheduled for publication in the near future” (as of 6 November 2026). According to the catalogue, even an official table only shows thematic proximity, not fulfilment of the criteria (section 3.3).