EU CRA Technical Requirements — 32 Controls (Mandatory + Good Service)
An engineer-facing breakdown of EU CRA technical requirements: 13 Annex I Part I essential cybersecurity controls (mandatory), 7 Annex I Part II vulnerability-handling controls (mandatory), and 12 Good Service practices that materially reduce CRA risk and audit friction.
The CRA's essential requirements are written in functional, outcome-oriented language. Engineers need a more concrete control catalogue. This article translates Annex I (Parts I and II) into 20 mandatory technical controls and adds 12 Good Service controls that go beyond the legal floor — the same controls that mature notified bodies look for as evidence of a credible, durable secure-development programme.
Marking convention: MANDATORY = required by Annex I Parts I or II. GOOD SERVICE = not strictly required by the CRA but expected by notified bodies, customers, and Member State market-surveillance authorities as evidence of due care.
Part A — Annex I Part I: Essential Cybersecurity (T-01 → T-13, MANDATORY)
| ID | Technical control | Implementation | CRA ref | Status |
|---|---|---|---|---|
| T-01 | Risk-based design | Documented threat model + risk register per release; risks traced to design decisions. | Annex I §1(1) | MANDATORY |
| T-02 | Ship without known exploitable vulnerabilities | Pre-release SCA + SAST + DAST gate; no Critical/High open against shipping artefact. | Annex I §1(2)(a) | MANDATORY |
| T-03 | Secure-by-default configuration | Hardened defaults (no default passwords, deny-by-default network, signed packages). | Annex I §1(2)(b) | MANDATORY |
| T-04 | Verifiable security updates | Signed update artefacts; automatic delivery channel; rollback safety; user notification. | Annex I §1(2)(c) | MANDATORY |
| T-05 | Authentication & access control | MFA on admin paths; least-privilege; session management; account lockout. | Annex I §1(2)(d) | MANDATORY |
| T-06 | Data confidentiality | AES-256 at rest; TLS 1.3 in transit; per-tenant key separation; HSM-backed key storage. | Annex I §1(2)(e) | MANDATORY |
| T-07 | Data & command integrity | Digital signatures on commands; hash-verified config; tamper-evident logs. | Annex I §1(2)(f) | MANDATORY |
| T-08 | Data minimisation | Per-feature data-collection inventory; defaulted-off telemetry; user opt-out. | Annex I §1(2)(g) | MANDATORY |
| T-09 | Availability & resilience | Rate limiting, circuit breakers, DoS-resistant parsing, redundancy for essential functions. | Annex I §1(2)(h) | MANDATORY |
| T-10 | No collateral damage to other services | Egress allow-listing; bandwidth caps; documented network behaviour. | Annex I §1(2)(i) | MANDATORY |
| T-11 | Limited attack surface | Unused ports/services disabled; minimal external interfaces; documented surface inventory. | Annex I §1(2)(j) | MANDATORY |
| T-12 | Exploitation-mitigation hardening | ASLR / DEP / stack-canaries / sandboxing / seccomp / capability-based isolation. | Annex I §1(2)(k) | MANDATORY |
| T-13 | Security event logging | Authentication, privilege change, config change, and update events logged with secure timestamps. | Annex I §1(2)(l) | MANDATORY |
Part B — Annex I Part II: Vulnerability Handling (T-14 → T-20, MANDATORY)
| ID | Technical control | Implementation | CRA ref | Status |
|---|---|---|---|---|
| T-14 | SBOM (machine-readable) | CycloneDX or SPDX produced on every build; published with each release. | Annex I Part II §(1) | MANDATORY |
| T-15 | Timely vulnerability remediation | SLA: Critical 7d, High 30d, Medium 90d from confirmation; tracked to closure. | Annex I Part II §(2) | MANDATORY |
| T-16 | Continuous security testing | Pre-merge SAST/SCA/secrets, weekly DAST, annual penetration test, recurring fuzzing. | Annex I Part II §(3) | MANDATORY |
| T-17 | Public CVD policy | Published security.txt + reporting endpoint; acknowledged < 72h; safe-harbour language. | Annex I Part II §(5) | MANDATORY |
| T-18 | Secure update distribution | TUF / signed manifests; integrity verified before install; rollback on failure. | Annex I Part II §(7) | MANDATORY |
| T-19 | Free security updates for support period | Updates published without paywall for the declared support period (≥ 5 years or product lifetime). | Annex I Part II §(8), Art. 13(8) | MANDATORY |
| T-20 | Public security advisories | CSAF or HTML advisory per fix; description, impact, CVSS, affected versions, remediation. | Annex I Part II §(8) | MANDATORY |
Part C — Good Service & Beyond (T-21 → T-32, RECOMMENDED)
| ID | Technical control | Implementation | Why it matters | Status |
|---|---|---|---|---|
| T-21 | Build-pipeline integrity (SLSA L3+) | Hermetic, reproducible builds; provenance attestations; signed pipelines. | Demonstrates supply-chain integrity beyond Annex I §1(1). | GOOD SERVICE |
| T-22 | Hardware-backed key storage | TPM / HSM / Secure Enclave for signing and identity keys. | Materially exceeds the cryptographic baseline of T-06/T-07. | GOOD SERVICE |
| T-23 | Memory-safe languages for new code | Rust / Go / managed runtimes for new components; documented exceptions. | Reduces classes of CVE; aligns with CISA / EU memory-safety push. | GOOD SERVICE |
| T-24 | Continuous fuzzing | OSS-Fuzz or in-house fuzzers on critical parsers and protocol handlers. | Catches latent bugs before disclosure pressure forces 24h reports. | GOOD SERVICE |
| T-25 | Bug bounty programme | Public or private programme with documented rewards and scope. | Generates credible vulnerability inflow at lower cost than incidents. | GOOD SERVICE |
| T-26 | Confidential computing for sensitive workloads | TEEs (Intel TDX / AMD SEV-SNP / ARM CCA) for keys, models, or PII. | Defence-in-depth over T-06/T-12 for high-value data. | GOOD SERVICE |
| T-27 | Anti-tamper for firmware/devices | Secure boot, measured boot, rollback protection, anti-debug fuses. | Closes physical-access gaps not explicit in Annex I. | GOOD SERVICE |
| T-28 | Runtime application self-protection (RASP) | In-process detection of injection, deserialisation, and SSRF attempts. | Increases detection coverage beyond T-13 logging. | GOOD SERVICE |
| T-29 | Privacy-preserving telemetry | Differential privacy / aggregation / on-device processing of usage data. | Strengthens T-08 and aligns with GDPR / EU AI Act. | GOOD SERVICE |
| T-30 | Coordinated patch release windows | Disclosure aligned with downstream OS / runtime vendors to avoid 0-day windows. | Reduces exploitation gap; appreciated by CSIRTs and NBs. | GOOD SERVICE |
| T-31 | Customer-facing security portal | Single page with advisories, SBOM, support-period info, and CVD policy. | Replaces ad-hoc requests during procurement diligence. | GOOD SERVICE |
| T-32 | Transparent end-of-support transition | 12-month advance notice; migration guidance; final security update. | Reduces market-surveillance and reputational risk after EoS. | GOOD SERVICE |
Total: 32 technical controls (20 MANDATORY + 12 GOOD SERVICE). Implement all 20 mandatory controls before placing the product on the market; adopt the 12 Good Service controls to reduce notified-body friction and to differentiate against competitors operating only at the legal floor.