Security by Design Under CRA Annex I: The Eleven Product Requirements, Translated

Most CRA articles answer what the regulation requires. Annex I Part I answers how good the product has to be. It lists eleven essential cybersecurity requirements that every product with digital elements must meet before it can be placed on the EU market. Unlike reporting deadlines or documentation rules, these requirements are about the product's engineering itself — the decisions your team made months or years before the DoC is ever signed.

This article walks through each of the eleven requirements, translates the regulatory language into engineering terms, and identifies the design choices that decide whether a product meets the requirement or merely looks like it does.

How Annex I Applies to Your Product

Annex I is structured as a list of requirements that apply "where applicable" to each product. A manufacturer must first determine which requirements are relevant — a task driven by the Article 13(3) risk assessment — and then show how the product meets each applicable requirement.

"Where applicable" is not a loophole. A smart lightbulb might not need the same audit-logging capability as a smart lock, but if an auditor asks why audit logging is omitted, the risk assessment must have made that call explicitly. An omission without a documented rationale is a gap, not a design choice.

Requirement 1: Delivered Without Known Exploitable Vulnerabilities

"Products with digital elements shall be placed on the market without known exploitable vulnerabilities."

The bar here is the moment of market placement. Known vulnerabilities in dependencies of the build at that moment are your responsibility.

In engineering terms:

• Run SBOM + vulnerability scanning on every release candidate.
• A release with a known CVE rated Critical or High in any component fails the gate. A release with a Medium CVE goes through a documented exception review.
• "Known" means known to the public — CISA KEV, NVD, GitHub advisories. Vulnerabilities known only privately to the manufacturer do not count as "known" for this test, but they do for the Article 13(2) vulnerability-handling clock.

Requirement 2: Secure-by-Default Configuration

"Delivered with a secure-by-default configuration, including the possibility to reset the product to its original state."

Default settings must be safe. A reset path must exist.

In engineering terms:

• First-boot flow requires setting credentials. Shipping with a universal default password fails this requirement.
• Remote-management features, cloud services, and network discovery protocols are off by default and opt-in.
• A documented hardware or software reset returns the product to the factory state including firmware integrity.

Requirement 3: Vulnerabilities Addressable via Security Updates

"Designed to ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism."

Every vulnerability in a shipped product must be fixable through an update mechanism that exists and works.

In engineering terms:

• A signed-firmware update path is part of the product, not a post-hoc bolt-on.
• Automatic updates are the default for consumer products. Opt-out is documented. Enterprise products may default to opt-in but must be capable of automatic updates.
• Update mechanisms survive the support period — build pipelines, signing keys, and update servers are maintained for as long as the product is supported.

Requirement 4: Confidentiality, Integrity, and Availability Protection

"Ensure confidentiality by means such as encryption … integrity, including by means such as cryptographic mechanisms … availability, including by resilience and mitigation measures."

The CIA triad, explicitly.

In engineering terms:

• Data at rest and in transit uses contemporary encryption (TLS 1.3 for transport, AES-256 or ChaCha20-Poly1305 for storage).
• Integrity of stored configuration and firmware is verified on boot (signed images, measured boot, or equivalent).
• The product survives predictable denial-of-service conditions — high traffic, malformed inputs, network partitions — without losing its security posture.

Requirement 5: Data Minimisation

"Process only data that is adequate, relevant, and limited to what is necessary in relation to the intended use of the product with digital elements ('minimisation of data')."

The product should not collect or transmit data that its function does not require.

In engineering terms:

• A privacy-by-design pass on telemetry: every metric the product reports home is justified by a feature that requires it.
• Default privacy settings err toward less data collection, not more.
• Data retention inside the product is bounded — logs rotate, caches expire, user state is forgotten when the user asks.

Requirement 6: Data Integrity Protection

"Protect the integrity of stored, transmitted, or otherwise processed data, personal or other, and ensure confidentiality of such data, including against unauthorised modification or erasure."

The explicit obligation to prevent tampering, not just disclosure.

In engineering terms:

• Write paths to sensitive state go through integrity-protected mechanisms (MACs, signed envelopes, transactional integrity at the storage layer).
• User-visible logs include integrity markers so tampered logs are detectable.
• Audit trails cannot be silently erased by an attacker with local access.

Requirement 7: Only Necessary Functions

"Products with digital elements shall be designed, developed, and produced to reduce attack surfaces, including external interfaces."

Minimise what is exposed.

In engineering terms:

• Every network-listening service is justified by a feature that needs it. Unused ports are closed.
• Debug interfaces are disabled in production firmware.
• Physical interfaces (USB, serial) are either authenticated or default-off in shipped devices.

Requirement 8: Resilience to Denial-of-Service

"Designed, developed, and produced to minimise the impact of incidents by means such as exploitation mitigation mechanisms and techniques."

The product keeps its security posture under attack.

In engineering terms:

• Rate limiting on authentication endpoints.
• Memory-safe practices (bounds checking, safe language choices, ASLR, stack canaries).
• Isolation between components so a compromise in one does not cascade.
• Compartmentalisation of secrets — a single compromised subsystem does not hand over all credentials.

Requirement 9: Security Logging

"Provide security-related information by recording and/or monitoring relevant internal activity, including the access to or modification of data, services, or functions, with an opt-out mechanism for the user."

The product keeps a record of security-relevant events.

In engineering terms:

• Authentication attempts (successful and failed) are logged with timestamps.
• Configuration changes are logged.
• Firmware updates are logged.
• Logs are accessible to the user (directly or via a management interface).
• Users can opt out of non-essential logging.

Requirement 10: Secure Update Mechanism

"Ensure that vulnerabilities can be addressed through security updates in a timely manner, free of charge, or — exceptionally — at the cost of shipping a replacement component."

Updates must be possible, fast, and free. Paid security updates are not allowed.

In engineering terms:

• Updates are delivered cryptographically signed.
• Rollback protection prevents downgrading to vulnerable versions.
• Users are notified when an update is available.
• The update mechanism itself is resistant to manipulation (no HTTP-only update channels, no unauthenticated redirects).

Requirement 11: Clear Update Information

"Provide information and notifications about the availability of updates, as well as details on the content of security-related updates, including their severity and the vulnerabilities they address."

Users can tell what a security update does.

In engineering terms:

• Every security update ships with an advisory referencing the CVEs it fixes and the severity.
• The advisory is discoverable from the product (in-product notice, linked in release notes, accessible from the support page).
• Post-fix public disclosure is coordinated with affected third parties (Annex I Part II(4)).

The Two Traps

Treating "where applicable" as optional. Every requirement not applied must be explicitly dispositioned in the risk assessment with a rationale. "It doesn't apply to us" is the wrong answer; "it doesn't apply because X" is the right answer.

Treating "applicable" as "already done". Most engineering teams assume they meet Annex I because they care about security. The CRA test is not whether you care; it is whether the risk assessment, the test reports, and the technical file demonstrate each requirement with evidence. Good security practice in engineering culture is necessary but not sufficient.

Mapping to Your Technical File

The technical documentation file (Annex VII) must describe how the product meets each applicable Annex I requirement. A clean way to structure that is a table with one row per requirement: the requirement, whether it applies, how the product meets it, the controls and test reports that demonstrate it, and cross-references to the risk-register entries that informed the design.

Expect this table to be the most-cross-referenced artefact in the technical file. Auditors use it as an index into everything else.

How Seentrix Fits In

The product-conformity workflow in Seentrix includes a walkthrough of each Annex I requirement — mark applicable, describe the control, attach supporting evidence, set the status (pending / in progress / complete / not applicable). The resulting conformity-step table is the skeleton of the technical file's Annex-I compliance section, and the dashboard shows which requirements are open across your product portfolio so you can plan engineering work against deadlines.

The eleven requirements above are not particularly exotic for a team that already cares about security. What the CRA adds is the need to show each one was deliberately addressed, with evidence that survives a ten-year audit window. Annex I is where engineering practice becomes regulatory evidence.