Sovereign Data Centre Physical Security and Hardware Trust for EU Organisations

Sovereign data centre physical security and hardware trust refer collectively to the set of physical access controls, supply-chain integrity mechanisms and jurisdictional protections that together determine whether a hosting facility can genuinely be regarded as outside the reach of foreign governments, malicious insiders and tampered hardware. For compliance officers and CISOs in European regulated sectors, these three dimensions must be evaluated together, not in isolation, because a weakness in any one of them can undermine the others.

What Certification Frameworks Actually Require for Physical Security

ISO/IEC 27001:2022 Annex A.7 and the EU Cloud Sovereignty Framework SEAL levels each impose specific, auditable physical security obligations that go well beyond locked doors.

ISO/IEC 27001:2022 Annex A.7 organises physical and environmental security into fourteen controls covering secure areas, physical entry controls, protection against environmental threats, equipment maintenance and secure disposal. Annex A.7.2 requires that access to secure areas be controlled using appropriate entry controls and that a log of all access be maintained and reviewed. Annex A.7.3 requires that physical security of offices, rooms and facilities be designed and applied. These are not aspirational guidelines; a certified organisation must demonstrate conformance through documented evidence reviewable by an accredited auditor.

SOC 2 Type II, issued under the AICPA Trust Services Criteria, requires that physical access controls form part of the Common Criteria CC6 cluster. Unlike ISO/IEC 27001, SOC 2 Type II attests that controls were operating effectively over a defined period (typically twelve months), which makes it particularly relevant for demonstrating continuous compliance rather than point-in-time conformance.

The EU Cloud Sovereignty Framework introduces SEAL levels that layer sovereignty obligations on top of standard security certification. SEAL-3 requires that all data remain subject to EU legal jurisdiction and that personnel with privileged access are EU persons, with documented contractual safeguards for any non-EU support relationships. SEAL-4 demands full operational and ownership independence from non-EU entities, meaning that a US-owned provider with EU data centres cannot qualify regardless of contractual arrangements. Swiss-based providers with no non-EU parent company can meet the structural ownership criterion of SEAL-4 while simultaneously offering the jurisdictional advantages described below.

Hardware Supply-Chain Risks and the Controls That Address Them

Even a perfectly secured data centre building can host hardware that has been compromised before it arrived. Supply-chain attacks targeting firmware and embedded components represent one of the most difficult threat vectors to detect.

Malicious firmware implanted in server UEFI, network interface cards or storage controllers can survive operating system reinstallation and evade traditional endpoint detection tools. The Bloomberg reporting on implanted components in server motherboards (2018) illustrated the plausibility of such attacks, even if the specific claims remain contested; what is not contested is that UEFI vulnerabilities are real and actively exploited. ENISA’s Threat Landscape 2023 documented that supply-chain attacks on ICT products were among the fastest-growing threat categories in the EU.

Three technical controls form the hardware root of trust:

Trusted Platform Module (TPM) 2.0 is a dedicated cryptographic chip that stores measurements of the boot process and holds cryptographic keys in hardware-isolated storage. It enables attestation: a remote party can verify that a server booted only authorised firmware and operating system code, and that no measured component has been tampered with since manufacture. TPM 2.0 is mandatory under the Microsoft Windows 11 baseline and is increasingly required by regulated-sector procurement standards in the EU.

UEFI Secure Boot verifies that each component of the boot chain, from firmware to bootloader to kernel, carries a valid cryptographic signature before execution. When combined with TPM 2.0 measured boot, it becomes possible to detect and reject unauthorised code at the earliest stage of system initialisation.

Measured boot and remote attestation extend Secure Boot by recording cryptographic hashes of every boot component into TPM Platform Configuration Registers. A sovereign hosting provider should be able to provide attestation reports to customers on request, demonstrating that production servers match approved configuration baselines.

Trusted Execution Environments: Value and Limits

Intel TDX and AMD SEV-SNP provide hardware-enforced memory isolation for virtual machines and containers, protecting data in use from a potentially compromised hypervisor or cloud operator. This matters for multi-tenant environments where the infrastructure operator cannot be fully trusted.

Intel Trust Domain Extensions (TDX) create hardware-isolated trust domains at the virtual machine level, encrypting VM memory with keys managed inside the CPU and inaccessible to the hypervisor. AMD Secure Encrypted Virtualisation with Secure Nested Paging (SEV-SNP) achieves similar isolation and adds integrity protection against memory remapping attacks. Both technologies support remote attestation: a workload can cryptographically prove to a relying party that it is running inside a genuine, unmodified TEE on attested hardware.

However, the Confidential Computing Consortium has explicitly noted that TEE technology does not address jurisdictional exposure. A US-owned cloud operator subject to the CLOUD Act can be compelled to disclose access logs, metadata and encryption keys that exist outside the TEE boundary. The TEE protects data in use from the operator’s own privileged software access, not from a government order directed at the operator as a legal entity. For organisations whose primary concern is foreign-government compelled disclosure, TEE technology is a useful defence-in-depth layer, not a substitute for physical and jurisdictional sovereignty.

Conducting and Documenting Physical Access Audits for NIS-2

NIS-2 Directive Article 21(2)(e) requires essential and important entities to implement measures addressing the physical security of network and information systems. For organisations using colocation or managed hosting, this obligation extends to verifying the provider’s physical controls.

A defensible physical access audit programme for NIS-2 compliance should include the following documented steps. First, the organisation should obtain and review the provider’s ISO/IEC 27001:2022 Annex A.7 certification scope, confirming that the specific data centre facility (not just the corporate entity) is in scope. Second, the contract or service agreement should grant the customer the right to conduct or commission independent physical security audits at defined intervals, with results retained as evidence. Third, the organisation should request access logs covering at least the past twelve months, including records of all physical access events, failed access attempts and visitor management entries. Fourth, a structured walkthrough checklist covering mantrap operation, CCTV coverage, server cage access controls and environmental monitoring should be completed and signed by both parties. This documentation forms the evidentiary basis for demonstrating compliance when responding to a supervisory authority inquiry.

Hardware Disposal and Media Sanitisation in the Sovereign Contract

The IBM Cost of a Data Breach Report 2024 placed the global average breach cost at USD 4.88 million, with improper media handling at end of life identified as a recurring contributing factor in storage-related incidents.

NIST SP 800-88 Revision 1 defines three sanitisation categories applicable to regulated data: Clear (pattern overwrite, appropriate for reuse within a trusted environment), Purge (cryptographic erase or degaussing, appropriate for reuse outside the trusted environment), and Destroy (physical disintegration or incineration, required when media cannot be reliably sanitised by other means). The older DoD 5220.22-M standard specifying multiple-pass overwrite is no longer recommended by NIST for modern storage media, because flash-based storage does not guarantee that overwritten sectors are the only sectors containing data.

A sovereign hosting contract should specify: which sanitisation category applies to each storage media type in use; a requirement for a certificate of destruction or sanitisation signed by the provider; chain-of-custody documentation from decommission through to final disposal; and the right of the customer to witness or independently verify destruction for the highest-sensitivity media. The contract should also define what happens to hardware if the provider is acquired by a foreign entity before end-of-life disposal is complete.

Jurisdictional Location as an Auditable Risk Reduction

ENISA’s Threat Landscape 2023 found that ransomware and data-theft attacks against EU public administration and healthcare accounted for more than 40 percent of all significant reported incidents, underscoring that the adversary landscape extends well beyond state-level actors to criminal groups capable of exploiting legal vulnerabilities.

The legal exposure of EU-based data hosted at a US-owned provider does not require a direct attack. The US CLOUD Act (18 U.S.C. 2713) empowers US authorities to compel US-domiciled cloud providers to disclose data held anywhere in the world, regardless of the data’s physical location. FISA Section 702 permits collection from US-based electronic communication service providers without individual warrants. Neither mechanism is neutralised by contractual Standard Contractual Clauses, because those clauses bind the processor in private law but cannot override a statutory government order in public law.

Switzerland is not subject to these mechanisms. The revFADP, in force since September 2023, imposes GDPR-equivalent substantive data protection obligations on Swiss processors and requires Swiss judicial authorisation for any foreign-government access request. A hosting provider incorporated and operated entirely in Switzerland, with no US parent company and no US-operated infrastructure dependencies, removes the CLOUD Act exposure entirely rather than mitigating it contractually.

To present this risk reduction to a data protection authority or supervisory body in a credible, auditable form, the organisation should document: the provider’s Swiss incorporation and ownership structure (verified against the Swiss commercial register); the absence of any US-law nexus in the provider’s corporate structure; the provider’s published policy on handling foreign government access requests; and the legal opinion confirming that the revFADP framework applies to the processing relationship. This documentation constitutes a Transfer Impact Assessment equivalent for the jurisdictional risk dimension and directly supports the accountability principle under both GDPR Article 5(2) and the revFADP.

FAQ

Does ISO/IEC 27001:2022 certification of a data centre guarantee that physical security meets NIS-2 Article 21(2)(e) requirements?

ISO/IEC 27001:2022 Annex A.7 certification provides strong evidence of physical security controls and is widely accepted by supervisory authorities as a baseline, but NIS-2 imposes sector-specific obligations and proportionality requirements that go beyond the standard. Certification should be combined with documented physical access audits and risk assessments tailored to the organisation’s threat model.

Can Intel TDX or AMD SEV-SNP replace the need for a physically sovereign data centre?

No. Confidential computing technologies protect data in use by isolating workloads from the hypervisor and cloud operator, which is valuable in multi-tenant environments. They do not address jurisdictional exposure: a US-owned cloud operator subject to the CLOUD Act can still be compelled to produce metadata, access logs and encryption keys held outside the TEE. Physical sovereignty and TEE protection serve different threat models and are complementary, not interchangeable.

What does NIST SP 800-88 require when decommissioning storage media that held regulated personal data?

NIST SP 800-88 defines Clear, Purge and Destroy as the three sanitisation categories. For regulated personal data, Purge or Destroy is typically required. A sovereign hosting contract should specify which category applies to each media type, require a certificate of destruction, and define chain-of-custody documentation that can be presented to a data protection authority.

What is the practical difference between SEAL-3 and SEAL-4 in the EU Cloud Sovereignty Framework?

SEAL-3 requires that data remain under EU legal jurisdiction and that staff with privileged access are EU persons, but it permits some reliance on non-EU parent companies with contractual safeguards. SEAL-4 demands full operational and ownership independence from non-EU entities, making it the appropriate level for highly sensitive government and critical-infrastructure workloads where even indirect foreign control is unacceptable.

Why does Swiss jurisdiction under the revFADP reduce legal exposure compared with EU-based hosting at a US-owned provider?

Switzerland is not subject to the US CLOUD Act or FISA Section 702. The revFADP, in force since September 2023, imposes GDPR-equivalent data protection obligations but contains no mechanism compelling Swiss-domiciled processors to disclose data to foreign governments without Swiss judicial authorisation. For organisations whose threat model includes foreign-government compelled disclosure, a Swiss-domiciled provider with no US parent company removes a legal exposure that contractual clauses alone cannot eliminate.