EU Cyber Resilience Act — Guide for Hardware & PCB Design Engineer
What the CRA means for your role, your team, and your day-to-day responsibilities.
Hardware and PCB Design Engineers are responsible for the physical and electronic foundations of products with digital elements. The CRA's Annex I requirements extend into hardware: secure boot roots of trust, cryptographic key storage, tamper-resistance, and the ability to deliver firmware updates securely are all hardware design decisions that affect CRA conformity. This guide explains how hardware engineers translate Annex I requirements into board-level design choices and produce the hardware documentation required for the technical file.
Your CRA responsibilities:
- ›Design hardware security features including secure boot chains, hardware security modules (HSMs), and trusted execution environments
- ›Select components with documented security properties and maintained firmware supply chains
- ›Produce hardware-level SBOM data covering all ICs, modules, and firmware-bearing components
- ›Design for physical tamper resistance proportionate to the product's risk classification
- ›Support the Security Architect with hardware threat modelling and attack surface definition
- ›Maintain hardware design documentation for inclusion in the CRA technical file
- ›Coordinate with firmware developers to ensure the hardware security architecture supports secure update delivery
CRA Obligations for Hardware Design
Hardware engineers often assume the CRA is a software regulation. It is not. Annex I Part I imposes requirements that hardware design must satisfy as part of the overall product conformity assessment.
Hardware-relevant Annex I obligations include:
- Annex I §1: products must be free of exploitable vulnerabilities at market placement — hardware-level vulnerabilities (e.g., unauthenticated JTAG interfaces, exposed debug ports) are in scope
- Annex I §2: attack surface minimisation — physically accessible interfaces that serve no operational purpose must be disabled or removed
- Annex I §6: authentication — where the product requires device authentication, the hardware must provide a cryptographic identity anchor (e.g., device certificate stored in a tamper-resistant element)
- Annex I §9: physical protection proportionate to risk — the standard does not require all products to be tamper-proof, but the design decision must be documented and justified
- Annex I §12: security update capability — the hardware boot architecture must support secure, verified firmware update with rollback protection
Hardware design review reports addressing each of these requirements should be included in the technical file.
Hardware Security Features — Secure Boot, HSM, TrustZone
Annex I §12 requires products to be capable of receiving security updates via authenticated and integrity-verified mechanisms. For hardware engineers, this translates into a secure boot chain as a non-negotiable baseline for any connected product.
Secure boot design requirements:
- Hardware Root of Trust (HRoT): a physically unclonable function (PUF), one-time programmable (OTP) memory, or dedicated security element storing the initial verification key — this key must not be extractable in normal operation
- Boot chain verification: each stage of the boot process must verify the cryptographic signature of the next stage before loading it; a single failed verification must halt boot
- Rollback protection: version counters in OTP or monotonic counter in a secure element must prevent downgrade to a previously revoked firmware version
HSM and TrustZone integration:
- Use a dedicated hardware security module or Arm TrustZone to isolate cryptographic operations from the application processor — keys used for device identity and firmware verification must not be accessible to application code
- Provision unique device identities at manufacture: device certificates should be provisioned in a controlled manufacturing environment with a documented chain of custody
- Expose hardware security capabilities to firmware developers through a documented API — this ensures the security architecture is used consistently
Hardware SBOM and Component Tracking
Article 13(6) requires manufacturers to identify and document the components of their products. For hardware, this means maintaining a hardware SBOM — a structured inventory of every component that bears firmware, processes data, or provides a security function.
Hardware SBOM content requirements:
- All firmware-bearing components: microcontrollers, SoCs, wireless chipsets (Wi-Fi, Bluetooth, cellular), and sub-modules — including the manufacturer, model, and current firmware version
- Security-critical passive components: secure elements, TPMs, and cryptographic accelerators — with vendor, part number, and certification status (e.g., CC EAL4+)
- Sub-assembly modules: pre-certified RF modules, camera modules, and compute modules that integrate third-party firmware
- Component vulnerability tracking: map each firmware-bearing component to its vendor security advisory channel so that new CVE disclosures can be assessed against the deployed fleet
Hardware SBOM data should be maintained in a structured format (CycloneDX supports hardware components) and updated at every PCB revision. The hardware SBOM feeds into the overall product SBOM held in the technical file.
Physical Tamper Resistance Requirements
Annex I §9 requires manufacturers to implement physical protection measures proportionate to the cybersecurity risks associated with the intended use environment. This is a risk-based requirement — not all products require tamper-evident hardware, but the design decision and its justification must be documented.
Tamper resistance design considerations:
- Risk classification: a consumer IoT device deployed in a home environment has a different physical threat profile from an industrial sensor deployed in an accessible public location — document the assumed environment in the threat model
- Debug interface controls: JTAG, SWD, UART, and USB debug interfaces must be disabled in production firmware and, for higher-risk products, physically isolated or removed from the production PCB layout
- Physical tamper detection: for high-risk products (e.g., payment terminals, industrial control nodes), consider active tamper meshes, epoxy potting, or case-open detection with key zeroisation — document the protection level and the attack scenarios it addresses
- Enclosure design: enclosure selection should be coordinated with the PCB designer — screwless snap-fit enclosures with internal tamper-evident labels are a low-cost minimum for consumer devices
The tamper resistance design rationale should appear in the hardware security design document included in the technical file.
Getting Started Checklist
Practical first steps for Hardware Engineers building CRA compliance into their design process:
- Audit all physically accessible interfaces on current production boards — document which are active in production firmware and which should be disabled or removed in the next revision
- Verify secure boot chain is implemented and tested: confirm that a corrupted firmware image halts boot and that rollback to a revoked version is rejected
- Start the hardware SBOM: list every firmware-bearing IC and module with current firmware version and vendor security advisory channel
- Review component security certifications: identify which security-critical components have Common Criteria or FIPS 140-2 certifications — include these in the technical file as supporting evidence
- Document tamper resistance decisions: for each product, record the assumed deployment environment, the identified physical threats, and the design controls chosen or consciously omitted with rationale
- Engage the firmware developer to confirm that the hardware security features (secure boot, HSM API, rollback protection) are being used correctly in the firmware
- Run the CVD Portal CRA Readiness Score with hardware-specific inputs to identify Annex I gaps before the design is frozen
CVD Portal handles your CRA Article 13 obligations automatically.
Public CVD submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation — built for HW Engs and their teams.
Start your free portalFrequently asked by HW Engs
Does the CRA require a hardware security module in every connected product?+
No. The CRA is a risk-based regulation. Annex I §6 requires appropriate authentication mechanisms, and §12 requires secure update delivery, but neither provision specifies a hardware security module as the mandatory implementation. For low-risk products, a secure element integrated into the SoC may be sufficient. For higher-risk products — particularly those in Annex III Class I or Class II — a discrete HSM or certified secure element is strongly advisable as both a security control and as evidence of proportionate risk treatment for the technical file.
Are COTS modules (e.g., a Wi-Fi module with pre-certified firmware) covered by the CRA?+
Yes. When you integrate a COTS module into your product, you as the manufacturer are responsible for the security of the integrated system, including the module's firmware. The module's own CE marking under the Radio Equipment Directive does not satisfy CRA conformity for the integrated product. You must include the module in your SBOM, track its firmware version for CVE disclosures, and verify that its security properties are consistent with your product's Annex I risk treatment.
What happens to hardware conformity if we change a component mid-lifecycle — for example, substituting an EOL chip for an equivalent?+
Component substitutions during the product lifecycle must be assessed for their impact on CRA conformity. If the substituted component changes the security architecture — for example, replacing a secure element with a general-purpose microcontroller — a new conformity assessment is required. For like-for-like substitutions where the security properties are equivalent or better, the change should be documented in a design change record added to the technical file, with an updated SBOM and, for Class I/II products, reviewed with the notified body.
Key CRA articles for HW Engs
Need a CVD policy template your team can deploy today?
Free CRA-compliant templates for every stage — from first CVD policy to full PSIRT programme.