Skip to content

CRA Compliance

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is the first EU-wide law setting mandatory cybersecurity requirements for products with digital elements — hardware and software — across their entire lifecycle. If your product connects to a network or another device and reaches the EU market, it is very likely in scope.

This section is written for engineers and product security teams, not lawyers. It explains what the CRA actually requires at a technical level, and how LAAVAT's PKI, code-signing, and device-identity capabilities map to those requirements.

Not legal advice

This section explains the CRA's technical requirements as we understand them and how LAAVAT's platform supports them. It is not a substitute for your own legal or compliance review. Consult qualified counsel to confirm your obligations and conformity assessment route.

Key dates

Date What happens
10 December 2024 CRA entered into force
11 June 2026 Notified body / conformity assessment provisions (Chapter IV) apply
11 September 2026 Article 14 reporting obligations apply — see Article 14 reporting
11 December 2027 Full application — essential requirements (Annex I), CE marking, market surveillance

Article 14 reporting applies to products already on the EU market, not just new launches — if you ship a connected device today, the September 2026 deadline concerns you even before the 2027 essential-requirements deadline.

What the CRA actually requires

The CRA splits its essential cybersecurity requirements (Annex I) into two parts:

  • Part I — product properties. What the product itself must be like when it ships: secure by default, no known exploitable vulnerabilities, protected against unauthorized access, resilient attack surface, and — critically for LAAVAT customers — built so that vulnerabilities can be addressed through security updates.
  • Part II — vulnerability handling. What the manufacturer must do, on an ongoing basis, for the entire support period: maintain a software bill of materials (SBOM), remediate vulnerabilities without delay, test regularly, run a coordinated disclosure process, and distribute security updates.

See the full breakdown in Annex I: what it means for embedded manufacturers.

Where LAAVAT fits

An update mechanism only delivers real security if the device can tell a genuine update from anything else. That's the practical core of what the CRA is asking for, and it's why secure boot and signed updates have become the default expectation for CRA-ready devices — not a checkbox someone added, but the mechanism that makes "vulnerabilities can be fixed" actually true rather than theoretical.

LAAVAT provides the cryptographic infrastructure underneath that update path:

  • HSM-backed firmware and update signing — so a security update can be cryptographically verified as genuinely from you before a device installs it.
  • Secure boot signing across a broad range of embedded silicon, bootloaders and update formats — so only authentically-signed firmware runs. See Secure boot and CRA for what that covers and how to check whether your platform is supported.
  • Device identity (IDevID/LDevID) — so devices can be individually authenticated, which supports both the "protection against unauthorized access" property in Part I and the auditability expected in vulnerability-handling processes in Part II.
  • PKI and CA hierarchy management — the certificate infrastructure underlying all of the above, with keys generated in and never leaving AWS CloudHSM.

In this section