Skip to content

Annex I: What It Means for Embedded Manufacturers

Draft — needs compliance review before external use

A technical mapping, not a conformity statement. Meeting the requirements below is your responsibility as manufacturer; LAAVAT provides infrastructure that supports specific requirements, not blanket CRA conformity. Verify against the official Annex I text.

Annex I is the heart of the CRA's technical demands. It has two parts: Part I describes properties the product must have, and Part II describes processes the manufacturer must run. This page walks through both, and points to where LAAVAT's platform supports each requirement.

Two things to keep in mind. First, LAAVAT is infrastructure — it supports specific requirements (mostly the ones about update integrity, access protection, and identity), not the whole of Annex I. Requirements about your own SDLC, your CVE monitoring, or your disclosure policy are yours to satisfy. Second, "supported by LAAVAT" means the cryptographic mechanism exists and is available to you; using it correctly in your product and process is still your work.

Part I — Product properties

Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity based on the risks. Concretely, Annex I Part I calls for products that:

Annex I (Part I) requirement What it means in practice LAAVAT support
Made available without known exploitable vulnerabilities You ship with no known-exploitable issues in the product or its dependencies Indirect — your SDLC and CVE process. LAAVAT's role is enabling the fix to be delivered securely (see Part II update requirement).
Secure by default configuration Default settings are the secure ones; hardening isn't opt-in Your product design. LAAVAT's device identity supports authenticated-by-default access models.
Vulnerabilities can be fixed via security updates, including automatic updates where appropriate There is a mechanism to deliver and install fixes, and it's trustworthy Core LAAVAT capability — HSM-backed signing of firmware/update artifacts (RAUC, MCUboot, FIT, and others) so a device can verify an update is genuinely yours before installing it.
Protection from unauthorized access, with appropriate authentication/identity mechanisms Only authorized parties can access the product and its data Supported — device identity (IDevID/LDevID) and the PKI to issue and manage it.
Protect confidentiality of stored/transmitted data (e.g. encryption at rest/in transit) Sensitive data is encrypted Supported for signing/encryption workflows (AES encryption); transport/storage encryption in your product is your design.
Protect integrity of code, configuration, and data Unauthorized modification is prevented or detected Core LAAVAT capability — secure boot signing means only integrity-verified, authentically-signed firmware runs. See Secure boot and CRA.
Data minimisation — process only what's necessary Don't collect/retain more than the function requires Your product design.
Protect availability, resilience against DoS Essential functions survive attack/overload Your product/system design.
Minimise attack surface, including external interfaces Reduce exposed interfaces and services Your product design.
Reduce impact of incidents (exploitation mitigation) Limit blast radius when something is exploited Your product design; secure boot contributes by preventing a compromised update from persisting.
Record and monitor security-relevant activity Log security-relevant internal activity Your product; device identity supports attributable/auditable actions.
Provide a way to securely remove/transfer data and reset the product Users can wipe/reset securely Your product design.

The pattern is clear: the requirements about update integrity, boot integrity, and identity are the ones LAAVAT directly underpins. The rest are properties of your product and process that LAAVAT doesn't replace.

Part II — Vulnerability handling

Part II is ongoing. It applies throughout the support period you declare for the product (which the CRA expects to reflect how long the product is reasonably in use — at least five years for many products unless the expected use is shorter). Manufacturers must:

Annex I (Part II) requirement What it means in practice LAAVAT support
Identify and document vulnerabilities and components, including an SBOM in a common machine-readable format Maintain a software bill of materials, at least for the top-level dependencies Your build/SDLC tooling. LAAVAT's own releases are published with provenance attestations, which is the same idea one level up.
Remediate vulnerabilities without delay, including via security updates Fix and ship fixes promptly This is where the signed update path pays off — see Part I update row. The remediation isn't real until it reaches devices and installs safely.
Apply effective and regular tests and reviews of security Test the product's security on an ongoing basis Your process.
Publicly disclose fixed vulnerabilities (info + remediation) once available Publish advisories with remediation guidance Your process.
Have a coordinated vulnerability disclosure policy A documented way for researchers to report issues to you Your process.
Facilitate the sharing of vulnerability information (e.g. a contact address) Provide a reporting channel Your process.
Distribute security updates securely, without delay and (where feasible) free of charge, with advisory messages Ship updates to devices in a trustworthy way Core LAAVAT capability — cryptographically signed updates are what makes "securely distribute" mean something. A device can reject anything not signed by you.

The through-line

Across both parts, one requirement threads through everything: a device must be able to trust an update before it installs it. Part I demands the product be updatable and integrity-protected; Part II demands updates actually be produced and securely distributed for years. Neither is satisfied by an update mechanism that can't distinguish a genuine fix from a malicious payload.

That verification step — device checks a cryptographic signature, made with a key you control in an HSM, before trusting firmware — is exactly what LAAVAT's signing platform provides. It doesn't make you CRA-compliant on its own, but it is the mechanism that makes the CRA's central update-and-integrity requirements technically real rather than aspirational.