A category is only as good as its definition of what qualifies. Sovereign computing makes its claims testable: a cloud demonstrates conformance through a published, signed report, assessed item by item against a shared checklist.

How conformance works

The conformance checklist uses the keywords MUST, MUST NOT, SHOULD, and SHOULD NOT in the sense of RFC 2119: MUST items are required for conformance; SHOULD items are strongly recommended, and any deviation must be justified in the report.

A cloud's conformance report completes the checklist item by item - each marked pass, fail, or not applicable, with rationale - dated and signed by the operator, and published openly. A cloud that claims to be an open sovereign cloud without a current public conformance report does not meet the definition.

What the checklist covers

Cross-cutting requirements

Every inter-level handover is exposed via a documented, versioned API; those APIs accept any licensed adjacent-level provider without a separate partnership; the operator publishes a machine-readable registry of providers at each level; and nothing in the operator's terms prevents a customer sourcing a provider independently.

Per-level requirements (Levels 0 to 5)

Each support level has its own checks - from Level 0's public documentation, forum, and machine-readable Knowledge Brief feed, through the ticket and escalation APIs at Levels 1 to 3, to Level 4's public issue tracker, public source, signed reproducible builds, and CVE feed, and Level 5's public governance and migration guarantees.

Component conformance

Every component is listed in a Component Conformance Manifest with its Level 4 status, and marked either substitutable or load-bearing.

What EU law already requires

Two of the requirements in this checklist are not only good practice. They are becoming conditions that European law attaches to cloud and digital infrastructure, which means an organisation asked to demonstrate them will need the same evidence a sovereignty assessment asks for.

A software bill of materials

The Cyber Resilience Act, Regulation (EU) 2024/2847, defines a software bill of materials at Article 3, point (39). The Cloud and AI Development Act proposal, COM(2026) 502 final, then makes one a condition of assurance. Annex II requires that an audited provider demonstrates that

a complete and up-to-date software bill of materials (SBOM), as defined in Article 3, point (39), of Regulation (EU) 2024/2847, and a list of identified dependencies relevant to the provision of the service are documented and made available to the auditing organisation.

The Cyber Resilience Act supplies the definition; the Cloud and AI Development Act proposal makes producing one a thing you are audited on. An SBOM is therefore not an artefact you generate for a certificate and file away, but a document that has to be current and has to be handed over.

Components you cannot support are a stated risk

The same Annex II clause continues, addressing components from outside the Union. Where such components are used, a provider must implement and document controls to

block any remote features that could materially tamper with or disrupt a device, system, or software (including during updates) and to ensure that the security-relevant components from third-country software manufacturers [...] are subject to source code audits, and have a documented migration plan in the event that the vendor fails or a third country imposes restrictions.

Two things follow. Source code audits require the source, which is why supportability and openness are the same question in practice. And a migration plan for vendor failure is exactly the multi-vendor property the support model describes: if only one organisation can support a component, the migration plan has nowhere to migrate to.

A further clause addresses open-source software directly, requiring a provider that uses it to have implemented and documented controls preventing the use of remote features that could tamper with or disrupt a system. Using open source does not remove the obligation to know what it does and to be able to stop it.

Status of these instruments

Regulation (EU) 2024/2847, the Cyber Resilience Act, is adopted law. The Cloud and AI Development Act, COM(2026) 502 final, is a Commission proposal and its text may change before adoption. The direction is consistent with the checklist either way: know what your software is made of, and be able to keep it running without the original vendor.

Sources: Regulation (EU) 2024/2847 (Cyber Resilience Act); COM(2026) 502 final annexes, Annex II, assurance level criteria.

The Sovereignty Test

Behind the detail is one practical test. A cloud passes only if all of the following are true at the same time:

• For each of Level 1, Level 2, and Level 3, the customer could today source that level from at least two independently owned providers. At Level 4, at least two independent organisations offer commercial-grade maintenance of the component.
• A customer that switches its Level 2 provider next quarter keeps its historical tickets, its Knowledge Brief contributions, and the operational telemetry it generated.
• Every interface used in such a switch is one of the documented APIs published under the cross-cutting requirements.
• The conformance report is published openly, dated, and signed.

A cloud that fails any one of these is not an open sovereign cloud, however much else it satisfies. The principle is simple: a customer that cannot change its Level 2 provider next quarter is not on a sovereign cloud.

How conformance becomes a procurable rating is covered in the Mark. The support levels it tests are described in the support model.