Hardware supply chain sovereignty refers to an organisation’s verified ability to confirm the origin, integrity and legal status of every physical component, from server CPUs and network interface cards to hardware security modules, that processes or transmits sensitive data. For European regulated organisations, this is no longer an aspirational goal: it is a compulsory element of supply-chain risk management under NIS-2, DORA and, increasingly, the emerging Chips Act 2.0 framework proposed in June 2026.
What Chips Act 2.0 Changes for Sovereign Procurement
Chips Act 2.0, proposed in June 2026 as a successor to Regulation (EU) 2023/1781, introduces mandatory supply-chain traceability obligations for semiconductor manufacturers selling into the EU market. Where the original Chips Act focused on investment incentives and capacity targets, the 2.0 proposal shifts the regulatory weight toward documentation: manufacturers must maintain a bill-of-materials at the die and packaging level, disclose fabrication locations, and provide buyers with machine-readable attestations of firmware signing authority.
For data centre and endpoint procurement, this matters because it creates a statutory baseline for what “trustworthy hardware” documentation must contain. A compliance officer at a financial institution subject to DORA can now point to a Chips Act 2.0 attestation as part of their ICT third-party risk file, rather than relying on voluntary vendor disclosures. The traceability chain extends to subcontractors, which is significant given that a single server board may incorporate silicon from four or five distinct fabrication sites, some subject to US Export Administration Regulations and some not.
The EU currently relies on non-EU suppliers for more than 80 percent of key digital products, including semiconductors and network hardware (European Commission, European Chips Act Impact Assessment, 2022). Chips Act 2.0 does not eliminate that dependency overnight, but it does make the dependency auditable and legally documented, which is the precondition for managing it.
Evaluating Hardware Trust Across the Stack
Hardware trust is not a single property; it is a layered assessment that must cover CPU microcode, firmware, network interface card firmware, and any dedicated security silicon such as hardware security modules or trusted execution environments.
CPU Microcode and Firmware
CPU microcode updates are delivered by Intel, AMD and ARM through vendor-controlled channels. An organisation running a data centre on x86 silicon is dependent on those vendors not introducing malicious or coercible update pathways. The practical control available to buyers is to enforce a firmware pinning policy: document the approved microcode version, test updates before deployment, and use Trusted Platform Module 2.0 measured-boot logs to detect any unauthorised modification between audit cycles. This does not eliminate the dependency on the original vendor, but it makes any deviation detectable and attributable.
Network Interface Cards and HSMs
Network interface cards present a distinct risk: they operate with their own firmware and, in some architectures, with their own processing cores that can inspect and modify traffic before the host operating system sees it. Procurement teams should require NIC vendors to supply signed firmware images, publish SHA-256 hashes of every release, and provide audit logs of firmware signing key custody. For HSMs, the relevant certification baseline is FIPS 140-3 or Common Criteria EAL 4+, both of which require documented key management and physical tamper evidence. ENISA’s supply chain cybersecurity guidelines explicitly identify HSM firmware provenance as a critical verification point for critical infrastructure operators.
“Supply chain integrity has to be verified at the hardware layer before we can make any meaningful claims about the security of software running above it,” according to ENISA’s Good Practices for Supply Chain Cybersecurity (ENISA, 2021).
SEAL-3 and SEAL-4: What Supply-Chain Transparency Requires in Practice
SEAL-3 and SEAL-4 are assurance levels defined in the EU Cloud Sovereignty Framework, which applies to cloud providers and sovereign infrastructure offerings targeting regulated buyers. They are directly relevant to hardware procurement because they define the minimum documentation a provider must supply to claim a given sovereignty level.
| Assurance Level | Hardware Provenance Requirement | Audit Right | Jurisdictional Guarantee |
|---|---|---|---|
| SEAL-3 | Documented hardware origin and firmware provenance; signed bill of materials | Right to review documentation | Contractual statement of no foreign-jurisdiction override |
| SEAL-4 | All SEAL-3 requirements plus physical supply-chain audit rights and chain-of-custody records to component level | Right to conduct or commission on-site physical audit | Binding contractual and legal guarantee, enforced under EU or equivalent law, that no component is subject to a foreign access demand |
A procurement specification for a sovereign data centre node that needs to reach SEAL-4 must therefore require vendors to supply chain-of-custody records down to the component level, not simply a country-of-assembly declaration. Re-badged products, where a European integrator assembles a server from Taiwanese or Korean chipsets without disclosing the sub-component origin, will fail SEAL-4 scrutiny even if the final product carries a European brand name.
Export Controls: US EAR and EU Dual-Use Regulation 2021/821
Any regulated organisation procuring advanced server hardware must maintain a compliance file that maps each acquired component against two separate export-control regimes. The US Export Administration Regulations govern any item with US-origin technology, regardless of where final assembly occurred. The EU Dual-Use Regulation (2021/821) governs the export of controlled goods, including advanced cryptographic hardware and high-performance computing components, from EU member states to third countries.
For inbound procurement, the practical obligation is to obtain from each vendor a written classification statement confirming whether the item is controlled under EAR Category 4 (computers) or Category 5 Part 2 (information security), and whether any re-export restriction applies to the buyer’s use case. For HSMs specifically, the cryptographic strength of built-in key generation algorithms may trigger controls under both regimes simultaneously. Buyers must retain these records for at least five years and make them available to national competent authorities on request.
“Strategic autonomy in semiconductors is not a luxury; it is a precondition for Europe’s digital sovereignty and the resilience of every critical infrastructure sector that depends on trusted hardware,” former European Commission Executive Vice-President Margrethe Vestager stated at the launch of the original Chips Act initiative (European Commission, 2022).
TPM 2.0 Attestation, Root-of-Trust and NIS-2 / DORA Auditability
Trusted Platform Module 2.0 provides a hardware root-of-trust that is separate from the main CPU and operating system. During each boot cycle, the TPM measures and cryptographically records every stage of the boot sequence: UEFI firmware, bootloader, kernel and critical drivers. These measurements, called Platform Configuration Register values, can be compared against known-good baselines by a remote attestation server.
Under NIS-2 Article 21, essential and important entities must implement supply chain security measures and be able to demonstrate them to national supervisory authorities. Under DORA Article 28, financial entities must manage ICT third-party risk with documented evidence of resilience controls. TPM-based attestation logs satisfy both requirements by providing a timestamped, tamper-evident record showing that the hardware layer was not modified between audits. An auditor can verify that the firmware version running on a critical server node matches the version approved at procurement, without physically inspecting the machine.
The average cost of a data breach for organisations in regulated sectors reached USD 4.88 million in 2024 (IBM, Cost of a Data Breach Report 2024). Hardware-layer compromises, while less frequent than software attacks, are particularly costly because they often go undetected for extended periods and can survive full operating system reinstallations.
Planning a Phased Transition to EU-Origin Hardware
A full transition to EU-fabricated hardware for all critical infrastructure nodes is not achievable in a single procurement cycle, given current European production capacity. A realistic phased approach organises transition across three horizons.
In the near term (zero to eighteen months), organisations should focus on deploying TPM 2.0 measured boot across all existing critical nodes, establishing a hardware bill-of-materials registry aligned with Chips Act 2.0 documentation requirements, and conducting a jurisdiction mapping exercise to identify which existing hardware components carry US EAR re-export restrictions. This creates the evidence base that auditors under NIS-2 and DORA will examine.
In the medium term (eighteen to forty-eight months), organisations should incorporate SEAL-3 and SEAL-4 hardware provenance requirements into all new procurement tenders, prioritise EU-designed or EU-assembled HSMs for key management infrastructure (where supply exists), and negotiate contractual chain-of-custody obligations with existing non-EU vendors as an interim measure.
In the longer term (beyond four years), as Chips Act 2.0 incentives begin to expand European fabrication capacity, organisations can progressively substitute critical processing nodes with EU-origin silicon, starting with the components that carry the highest jurisdictional risk: BMC controllers, NIC firmware processors and the cryptographic co-processors inside HSMs.
Throughout all phases, a documented risk-acceptance register is the required compensating control. This register must describe each hardware component that does not yet meet the target sovereignty standard, the specific risk it represents (foreign access demand, firmware integrity, export restriction), and the mitigating measures in place. NIS-2 Article 21 and DORA Article 28 both require this kind of systematic, documented risk management: the register is what transforms a hardware gap into a managed, auditable position rather than an uncontrolled liability.
FAQ
Does Chips Act 2.0 directly require regulated organisations to replace existing non-EU hardware?
No. Chips Act 2.0 places obligations on semiconductor manufacturers and sets traceability standards for products sold into the EU. For regulated buyers, it creates a due-diligence framework and supply-chain documentation baseline, not a hard mandate to replace hardware immediately. However, NIS-2 and DORA do require demonstrable supply-chain risk management, which Chips Act 2.0 documentation helps satisfy.
What is the difference between SEAL-3 and SEAL-4 for hardware procurement?
SEAL-3 requires documented evidence of hardware origin and firmware provenance, while SEAL-4 adds physical audit rights over the supply chain and binding legal guarantees that no component is subject to a foreign jurisdiction that could compel data access. A sovereign data centre targeting SEAL-4 must obtain chain-of-custody records below chassis level, not simply a country-of-assembly declaration.
How does TPM 2.0 attestation help demonstrate hardware sovereignty to auditors?
A Trusted Platform Module 2.0 cryptographically signs measurements of the boot sequence, firmware and loaded software. During an audit under NIS-2 or DORA, an organisation can present remote attestation logs showing that no unauthorised firmware or bootloader modification occurred, which is direct evidence that the hardware layer has not been silently compromised through a supply-chain intervention.
What export-control documentation must a procurement team maintain when buying advanced server CPUs or HSMs?
Buyers must retain the supplier’s EU Dual-Use Regulation (2021/821) classification records confirming whether the component falls under a controlled category, and any applicable export licences if the hardware originated from a US supplier subject to the US Export Administration Regulations. Where US-origin technology is embedded, the EAR’s re-export provisions apply, and the organisation must document that no controlled technology was transferred to restricted end-users or destinations.
What interim compensating controls are acceptable while EU-origin hardware is not yet available?
Acceptable interim controls include deploying TPM 2.0 measured boot on existing hardware, enforcing firmware signing and pinning policies, isolating critical workloads from internet-facing systems, implementing FIPS 140-3 certified HSMs for key management, and maintaining a documented risk-acceptance register that describes each gap and the compensating measures. This register is the primary artefact that compliance officers and auditors will examine under NIS-2 Article 21 and DORA Article 28.