--- title: "EU Cyber Resilience Act: Test Evidence for Hardware" description: "What the EU Cyber Resilience Act asks of hardware makers: key dates, conformity assessment classes, technical documentation, and the test evidence to keep." url: https://galoislabs.ai/blog/cyber-resilience-act-test-evidence author: Alex Hernandez author_url: https://galoislabs.ai/blog/authors/alex-hernandez published: "2026-08-14" topic: Test evidence publisher: Galois Labs --- # EU Cyber Resilience Act testing: the evidence embedded teams need ![A small four-drawer card cabinet in isometric, one drawer pulled out and one card raised above the others.](https://galoislabs.ai/blog/figures/evidence-3.light.webp) *FIG. 1 — RECORD DRAWER, ONE CARD RAISED* The EU Cyber Resilience Act, Regulation (EU) 2024/2847, requires manufacturers of hardware and software products with digital elements to meet essential cybersecurity requirements and to prove it in technical documentation that includes a risk assessment and reports of the tests that verify conformity. Reporting duties have applied since September 11, 2026; the remaining obligations apply from December 11, 2027. For an embedded team, that makes cybersecurity a test program with a paper trail: tests mapped to requirements, run against named firmware versions, repeated through a support period that is normally at least five years, and kept for at least ten. > **Not legal advice** > > This summary is drawn from the regulation's text on [EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847) and from European Commission pages, read October 5, 2026. Scope, product class and conformity assessment route are questions for your counsel and, where one is involved, your notified body. Evidence supports a conformity assessment; it does not replace one. ## What is the EU Cyber Resilience Act? The [Cyber Resilience Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847) (CRA) is an EU regulation adopted on October 23, 2024, binding in its entirety and directly applicable in every member state. It covers "products with digital elements", which Article 3 defines as software or hardware products and their remote data processing solutions, including components placed on the market separately. Article 2(1) brings in products whose intended purpose or reasonably foreseeable use "includes a direct or indirect logical or physical data connection to a device or network." The wording names physical connections and devices, not only networks, so read the Commission's guidance before deciding that a product without a radio is out of scope. Article 2 excludes products covered by sector rules: medical and in vitro diagnostic devices (Regulations (EU) 2017/745 and 2017/746), motor vehicle type approval under Regulation (EU) 2019/2144, aviation products certified under Regulation (EU) 2018/1139, and marine equipment under Directive 2014/90/EU. Products built exclusively for national security or defense are out too. Medical hardware has its own route, covered in [medical device design verification](https://galoislabs.ai/blog/medical-device-design-verification). On July 27, 2026, the Commission published [non-binding guidance](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation) on scope, remote data processing, open-source software, support periods, substantial modification, reporting and risk assessment. The Commission's [implementation page](https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation) tracks implementing acts and standards as they land. ## When do Cyber Resilience Act obligations apply? Article 71 staggers the dates: | Date | What applies | Article | | ------------------ | ------------------------------------------------------------------------------------------------- | ------- | | December 10, 2024 | Entry into force | 71(1) | | June 11, 2026 | Chapter IV, notification of conformity assessment bodies | 71(2) | | September 11, 2026 | Article 14, reporting of actively exploited vulnerabilities and severe incidents | 71(2) | | December 11, 2027 | Everything else: Annex I requirements, technical documentation, conformity assessment, CE marking | 71(2) | Products placed on the market before December 11, 2027 come under the regulation only if substantially modified from that date (Article 69(2)): changed in a way that affects compliance with Part I of Annex I, or that alters the intended purpose the product was assessed for. Whether a given firmware release crosses that line is one of the topics in the Commission's guidance. Reporting is the exception. Article 69(3) applies Article 14 to in-scope products placed on the market before December 11, 2027, so manufacturers with in-scope products on the EU market already carry these duties: | Trigger | Early warning | Notification | Final report | | ------------------------------------------------ | --------------------------------- | --------------- | ------------------------------------------------------------- | | Actively exploited vulnerability | Within 24 hours of becoming aware | Within 72 hours | 14 days after a corrective or mitigating measure is available | | Severe incident affecting the product's security | Within 24 hours of becoming aware | Within 72 hours | One month after the incident notification | Notifications go through ENISA's single reporting platform (Article 16), simultaneously to ENISA and to the CSIRT designated as coordinator in the member state of main establishment; Article 14(7) sets fallbacks for manufacturers established outside the EU. A 72-hour vulnerability notification has to give general information about the affected product and the measures users can take. That is only fast if the records already say which firmware versions are in the field, what each contains, and what was tested on each. ## What does the CRA require of manufacturers? Article 13 sets the obligations. The ones that shape a test program: - **Design to Annex I, Part I** (Article 13(1)). - **A documented risk assessment**, updated during the support period and filed in the technical documentation. It states whether and how each requirement in Part I, point (2) applies, with a clear justification for any that does not (Article 13(2) to (4)). - **Component due diligence**, including open-source components (Article 13(5)). - **A support period** reflecting expected use, at least five years unless expected use is shorter, with its end date stated at purchase (Article 13(8) and (19)). - **Retention** of the technical documentation and EU declaration of conformity for at least 10 years after placing on the market, or the support period if longer (Article 13(13)). - **Series production** that stays in conformity, and a type, batch or serial number on every product (Article 13(14) and (15)). Annex I, Part I, point (2) lists thirteen product properties, from shipping "without known exploitable vulnerabilities" with a secure-by-default configuration, to access control, integrity, availability, a limited attack surface and secure data removal. Part II lists eight vulnerability handling requirements, including a software bill of materials (SBOM) "in a commonly used and machine-readable format covering at the very least the top-level dependencies," a coordinated vulnerability disclosure policy, secure update distribution, and point (3): "apply effective and regular tests and reviews of the security of the product with digital elements." Security testing is ongoing, not a pre-launch event. Article 64(2) caps fines for breaching Annex I or Articles 13 and 14 at EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. Supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities in reply to a request can draw up to EUR 5 million or 1% (Article 64(4)), so evidence quality is a compliance question in its own right. ## Which conformity assessment applies to my product? Article 32 ties the procedure to the product's category, using internal control (module A), EU-type examination plus conformity to type (modules B and C), or full quality assurance (module H). | Category | Examples from Annexes III and IV | Procedures (Article 32) | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Default (not listed) | Most products with digital elements | Module A, B plus C, H, or an applicable European cybersecurity certification scheme | | Important, class I | Boot managers; operating systems; physical and virtual network interfaces; routers, internet modems and switches; microcontrollers, microprocessors, ASICs and FPGAs with security-related functionalities | Module A only where harmonized standards, common specifications or a certification scheme at assurance level at least "substantial" are applied in full; otherwise B plus C, or H | | Important, class II | Hypervisors and container runtimes; firewalls and intrusion detection or prevention systems; tamper-resistant microcontrollers and microprocessors | B plus C, H, or a certification scheme at assurance level at least "substantial" | | Critical | Hardware devices with security boxes; smart meter gateways; smartcards and secure elements | A European cybersecurity certificate where a delegated act requires one; otherwise the class II procedures | Two details matter for embedded teams. Article 7(1) says integrating a component that is itself an important product does not, by itself, put the host product under the class I or class II procedures: a board built around a security microcontroller does not need them for that reason alone. And [Implementing Regulation (EU) 2025/2392](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32025R2392) describes each category; it covers microcontrollers whose security functions aim to secure products, networks or services beyond the microcontroller itself, and ties tamper-resistant ones to Common Criteria AVA_VAN level 2 or 3. Under module A, the manufacturer declares conformity on its sole responsibility. Under module B, a notified body examines the technical documentation, supporting evidence and specimens, and carries out or commissions its own tests. Annex VIII says that supporting evidence includes, where necessary, "the results of tests carried out by the appropriate laboratory of the manufacturer, or by another testing laboratory on its behalf and under its responsibility." Your bench results may be read by an outside reviewer. ## What goes in CRA technical documentation? Article 31 requires the technical documentation before the product is placed on the market, "continuously updated, where appropriate, at least during the support period." Annex VII sets the minimum: 1. General description: intended purpose, software versions affecting compliance, photographs or illustrations of a hardware product's external features, marking and internal layout, and Annex II user information. 2. Design and processes: architecture, SBOM, disclosure policy, update distribution, and production and monitoring processes with their validation. 3. The cybersecurity risk assessment. 4. The information used to set the support period. 5. Standards or specifications applied, or descriptions of the solutions adopted. 6. Reports of the tests carried out to verify conformity. 7. The EU declaration of conformity. 8. The SBOM, on a market surveillance authority's reasoned request. Bench data lands in items 1, 2 and 6: the software versions that affect compliance, the validation of production processes, and the test reports themselves. One way to lay the file out: ```text title="techfile/ (one per product, kept 10+ years)" techfile/ 01-general/ intended purpose, Annex II user information, photos of external features, marking and internal layout 02-design/ architecture, schematics, software integration 02-vulnerability/ SBOM per release, CVD policy, contact address, update design 02-production/ production and monitoring processes, their validation 03-risk-assessment/ risk assessment with per-requirement applicability 04-support-period/ inputs used to set the support period 05-standards/ standards applied, or descriptions of solutions adopted 06-test-reports/ fw-2.4.0/ one folder per firmware version affecting compliance fw-2.4.1/ 07-declaration/ signed EU declaration of conformity manifest.json SHA-256 of every file above ``` ## What does CRA test evidence look like for an embedded product? The regulation names outcomes, not test methods. The mapping below is an engineering choice your risk assessment has to justify, not a list from the regulation. | Annex I, Part I, point (2) | Example bench test | What the record holds | | ------------------------------------------- | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | | (b) Secure by default, with reset | Factory-reset a unit; compare configuration, services and credentials with the documented default | Firmware build, unit serial, diff against the default | | (c) Fixable through security updates | Cut power at points across an update's write window; confirm a verified image boots each time | Image hashes, cut times, console log per attempt | | (d) Protection from unauthorized access | Attempt access on every interface without credentials | Response per interface | | (f) Integrity of programs and configuration | Offer an image with a bad signature; corrupt stored configuration | Rejection message, running version afterward | | (j) Limited attack surface | Confirm JTAG or SWD is locked and only documented ports listen | Per-unit lock state, port scan | | (m) Secure data removal | Run the user wipe, then read storage back on a test unit | Readback result | Five properties make a report hold up: - **Traced** to the Annex I requirement and the risk assessment entry behind it. [Hardware test traceability](https://galoislabs.ai/blog/hardware-test-traceability) covers keeping that chain intact. - **Versioned:** firmware build and hash, bootloader, hardware revision, unit serial. - **Observed, not ticked:** the console output showing the rejected image, not a checkbox. - **Complete:** every run, including failures and reruns. - **Repeatable:** the same sequence revision runs again on the next security update. Some tests need instruments. Cutting power mid-update checks that a failed update leaves a valid, verified image, and a programmable supply makes the cut repeatable. The console strings are placeholders for your firmware's own messages: ```python title="update_power_cut.py" """Cut DUT power partway through a firmware update, then check it boots a verified image.""" import json import time import pyvisa import serial # pyserial UPDATE_CMD = b"fw update /images/candidate.bin\r\n" # placeholder: your update command WRITING = b"writing slot B" # placeholder: printed once flashing starts BOOT_OK = b"boot: image verified" # placeholder: printed by the bootloader CUT_DELAY_S = 0.5 # sweep this across the write window def wait_for(console: serial.Serial, marker: bytes, timeout_s: float) -> bytes: deadline = time.monotonic() + timeout_s seen = b"" while time.monotonic() < deadline: seen += console.read(256) # returns early on the port's read timeout if marker in seen: return seen raise TimeoutError(f"{marker!r} not seen within {timeout_s} s") rm = pyvisa.ResourceManager() psu = rm.open_resource("TCPIP0::192.168.1.60::inst0::INSTR", read_termination="\n", write_termination="\n") console = serial.Serial("/dev/ttyUSB0", 115200, timeout=0.2) console.write(UPDATE_CMD) wait_for(console, WRITING, timeout_s=30) time.sleep(CUT_DELAY_S) psu.write("OUTP OFF") # cut power mid-write time.sleep(2.0) console.reset_input_buffer() psu.write("OUTP ON") boot_log = wait_for(console, BOOT_OK, timeout_s=20) print(json.dumps({ "supply": psu.query("*IDN?"), "cut_delay_s": CUT_DELAY_S, "result": "booted verified image after power cut", "console_tail": boot_log[-400:].decode(errors="replace"), })) ``` One cut proves little: sweep the cut time across the write window and record each attempt as its own result. In [SCPI-99](https://www.ivifoundation.org/downloads/SCPI/scpi-99.pdf), `OUTPut[:STATe]` controls whether the output terminals are open or closed, but multi-channel supplies usually need a channel selected or a channel list, so check the programming guide. The [power rail validation plan](https://galoislabs.ai/blog/power-rail-validation-plan) scripts the same supplies. Production needs evidence too. Article 13(14) asks for procedures that keep series production in conformity, and 13(15) for a type, batch or serial number or other identifying element on each product. An end-of-line step that confirms debug access is locked and secure boot is enabled, logged per serial number, supports both. [EVT, DVT and PVT testing](https://galoislabs.ai/blog/evt-dvt-pvt-testing) covers where that step belongs. ## How do you keep CRA evidence current through the support period? In practice, each security update means rerunning the security sequence against the new build, filing a new folder of reports, updating the SBOM and, where applicable, the risk assessment (Article 13(7)). Running those sequences on every release candidate keeps the cost flat; [hardware tests in CI](https://galoislabs.ai/blog/hardware-tests-in-ci) covers wiring a bench into a pipeline. On a reasoned request, market surveillance authorities can ask for everything needed to demonstrate conformity (Article 13(22)), and the file must exist for at least ten years. Store reports as JSON, CSV or PDF, and hash every file so anyone can check later that nothing changed: ```python title="evidence_manifest.py" import hashlib import json import sys from datetime import datetime, timezone from pathlib import Path def sha256(path: Path) -> str: digest = hashlib.sha256() with path.open("rb") as f: for chunk in iter(lambda: f.read(1 << 20), b""): digest.update(chunk) return digest.hexdigest() def build_manifest(techfile: Path, firmware: str, hardware_rev: str) -> dict: files = sorted(p for p in techfile.rglob("*") if p.is_file() and p != techfile / "manifest.json") return { "firmware": firmware, "hardware_revision": hardware_rev, "generated_at": datetime.now(timezone.utc).isoformat(), "files": [ {"path": p.relative_to(techfile).as_posix(), "bytes": p.stat().st_size, "sha256": sha256(p)} for p in files ], } if __name__ == "__main__": root = Path(sys.argv[1]) manifest = build_manifest(root, firmware=sys.argv[2], hardware_rev=sys.argv[3]) (root / "manifest.json").write_text(json.dumps(manifest, indent=2) + "\n") ``` Run it as `python evidence_manifest.py techfile 2.4.1 C`, then commit or sign the manifest so the hashes cannot be quietly rewritten. ## How does Galois record test evidence? Galois is agent-driven test engineering for hardware teams: agents generate tests and instrument drivers, run them on real benches through the open-source galois-edge daemon, and turn the results into reports and a shared engineering record. For instrument-driven steps, such as the supply commands in the power-cut sweep, the platform writes the record as the test runs: - **Versioned sequences** in YAML, with explicit limits, version history and locking for production versions. - **Approval gates.** A draft sequence cannot run until an engineer approves it, and an edit after approval requires approval again. Sequences drafted by Évariste, the agent in the Galois platform, pass the same gate; [reviewing an agent-drafted test plan](https://galoislabs.ai/blog/review-ai-generated-test-plan) covers what to check. - **A per-step record:** measured value, limits, raw command and response, instrument ID, operator, DUT serial and timestamp. - **Reports drafted from the record**, so a number in a report traces to a command and a response. - **An audit log** of actions with actor, timestamp and resource ([security](https://galoislabs.ai/security)). For the power-cut sweep, an engineer opens Évariste beside the project, asks it to "List connected instruments" to confirm the supply from the script is on the team's edge, and states the supply side of one attempt: after the cut delay (0.5 s for the first attempt), switch the output off, hold it off for 2 s, then switch it back on. Évariste drafts the sequence; the engineer checks the channel, delay and hold time, approves the draft, and starts a run through galois-edge when the console shows the write has begun. Sending the update command and reading the console for the write-start and verified-boot messages stay with the engineer. Each step's timestamps let you set every attempt's actual cut time against its console log, and each move of the delay across the write window is an edit kept in the sequence's version history. Évariste can then compare a run on the new build with the one on the previous build and generate a test report from the run to file under 06-test-reports. The team no longer maintains the supply calls, their error handling and logging, or a report script; wiring the bench, choosing the delays and judging each boot stay with the engineers. Evidence can stay in storage you control: a dedicated single-tenant cloud with your own bucket, or a fully on-prem, air-gapped install ([deployment options](https://galoislabs.ai/deployment)). Packaged sign-off deliverables compiled from the same record are in build ([product](https://galoislabs.ai/product)). None of this decides conformity; the manufacturer's conformity assessment does, with a notified body where the class requires one. ## When is a document-based process enough? Automation is not a CRA requirement. A default-category product under module A, with a few firmware releases a year, a short security test list and one bench, can carry its file with a folder like the one above, signed PDF reports and a hash manifest. What matters is that the record is complete, tied to versions and retrievable for ten years. The balance shifts with frequent releases, long support periods, several hardware revisions in the field, or a notified body reading your evidence. A [DVT test report template](https://galoislabs.ai/blog/dvt-test-report-template) shows the fields reviewers expect either way. Then test the file the way an authority would: pick one shipped firmware version and see whether the file alone shows what was tested on it, on which unit, with what result. ## Frequently asked questions ### When does the EU Cyber Resilience Act apply? Regulation (EU) 2024/2847 entered into force on December 10, 2024. The rules on notifying conformity assessment bodies apply from June 11, 2026, the Article 14 reporting obligations from September 11, 2026, and the rest of the regulation, including the essential cybersecurity requirements, technical documentation and conformity assessment, from December 11, 2027. ### Does the Cyber Resilience Act apply to products already on the market? Products placed on the EU market before December 11, 2027 fall under the regulation only if they are substantially modified from that date (Article 69(2)). Reporting is the exception: the Article 14 duties to report actively exploited vulnerabilities and severe incidents also cover in-scope products placed on the market before that date (Article 69(3)). ### Do I need a notified body for CRA conformity assessment? It depends on the product's category. Products not listed in Annexes III or IV, the default category that covers most products with digital elements, can use internal control (module A) without a notified body. Important class I products can use module A only when harmonized standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial are applied in full; otherwise a notified body is involved. Class II always involves a third party, and critical products may need a European cybersecurity certificate. Confirm your product's category and assessment route with counsel. ### What test reports does the CRA technical documentation need? Annex VII, point 6 requires reports of the tests carried out to verify that the product and the vulnerability handling processes conform with the applicable essential cybersecurity requirements in Annex I, Parts I and II. The regulation names outcomes, not test methods; harmonized standards, once their references are published in the Official Journal, give a presumption of conformity for the requirements they cover. ### How long must CRA technical documentation be kept? At least 10 years after the product is placed on the market, or for the support period if that is longer (Article 13(13)). The support period must be at least five years unless the product is expected to be in use for less, and the technical documentation must be updated, where appropriate, at least during the support period (Article 31(2)).