Annex I: The Product Properties and the Processes Behind Them

Annex I does not read like a checklist, and treating it as one produces both over-engineering and gaps.

Part I opens with a governing sentence: products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks. Article 13(2) then requires the manufacturer to undertake a cybersecurity risk assessment and feed its findings through planning, design, development, production, delivery and maintenance. Article 13(3) requires that assessment to be documented and kept updated during the support period.

So the thirteen properties in Part I apply to the extent the risk assessment says they are relevant, and to the depth it justifies. An air-gapped industrial controller and a consumer doorbell reach different answers on encryption in transit, and both can be compliant.

One point does not bend. Point (a) requires the product to be made available without known exploitable vulnerabilities, full stop.

Part I lists points (a) to (m). They group naturally.

Ship clean and controllable: no known exploitable vulnerabilities (a), a secure by default configuration with the ability to reset to the original state (b), and the capacity to address vulnerabilities through security updates (c).

Guard access and data: protection against unauthorised access with reporting of attempts (d), confidentiality of data at rest and in transit using state-of-the-art mechanisms such as encryption (e), integrity of data, commands, programs and configuration against unauthorised modification, with reporting of corruption (f), and data minimisation, processing only what is adequate, relevant and limited to the intended purpose (g).

Survive and observe: availability of essential functions including resilience against denial-of-service (h), not degrading other devices or networks (i), limited attack surface including external interfaces (j), exploitation mitigation techniques (k), security logging and monitoring of relevant internal activity with a user opt-out (l), and secure permanent deletion of data and settings (m).

Point (b) has two halves, and the second is the one that changes designs.

A secure by default configuration means the state the product arrives in is the safe state. No shared default credentials, no diagnostic port open, no permissive setting waiting for a hardening guide nobody reads. Where a product must ship with a default password, the design has to force a change before use.

The second half requires the possibility to reset the product to its original state. That is not the same as a factory reset that restores whatever was configured at the factory floor. It means a user can get back to the delivered secure baseline after a misconfiguration, a compromise, or a change of owner.

Combined with point (m) on secure permanent deletion, this shapes the resale and decommissioning path: reset must return the product to a safe configuration while removing the previous user's data, not merely clear settings.

Point (c) requires that vulnerabilities can be addressed through security updates. Where applicable, that includes automatic security updates installed within an automatic time frame, a clear and easy-to-use opt-out, notification to users that updates are available, and the option to postpone them temporarily.

The design consequence is that automatic installation is the expected default for consumer products, and the user's choice is to leave it, not to join it.

Part II point 2 adds a constraint that reaches into release engineering: where technically feasible, new security updates shall be provided separately from functionality updates. A customer must be able to take a fix without taking a redesign.

This is the requirement most likely to collide with existing practice. A team that ships one monolithic release train, where the only way to get a patched TLS library is to accept a new interface, has to build a separate security channel with its own branch, its own testing, and its own release cadence.

Part II is not about the product. It is about what the manufacturer must keep doing, throughout the support period.

One, identify and document vulnerabilities and components, including a software bill of materials. Two, address and remediate vulnerabilities without delay, with security updates separated from functionality updates where technically feasible. Three, apply effective and regular security tests and reviews.

Four, once an update is available, publicly disclose information about the fixed vulnerability: description, affected product identification, impact and severity, and how to remediate. Publication may be delayed in duly justified cases where the security risk of disclosure outweighs the benefit, until users have had the chance to patch.

Five, put in place and enforce a coordinated vulnerability disclosure policy. Six, facilitate reporting of potential vulnerabilities in the product and in its third-party components, including a contact address. Seven, provide secure update distribution mechanisms. Eight, disseminate available patches without delay and free of charge, with advisory messages.

Read together, the eight points describe a loop rather than eight separate tasks, and the loop has to run for years after the last engineer who wrote the code has moved on.

Inbound discovery has three mouths: your own regular testing under point 3, external reports arriving through the contact address and disclosure policy under points 5 and 6, and upstream advisories against components you catalogued in your bill of materials under point 1.

Everything converges on triage against the risk assessment, then remediation without delay, then secure distribution, then disclosure.

The arrow back from disclosure to the bill of materials is the part teams forget. Every fix changes component versions, so the inventory that made the next upstream advisory actionable has to be regenerated, not written once at launch.

Note also where Article 14 attaches. If triage finds the vulnerability is being actively exploited, a separate reporting clock starts immediately, in parallel with the fix.

Part II point 1 is quoted constantly and usually stretched. The text requires manufacturers to identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format, covering at the very least the top-level dependencies of the product.

Three things it says. The format must be machine-readable and commonly used, which points at established formats without naming one. The floor is top-level dependencies, not the full transitive graph. And it is an obligation to draw one up, which means it must exist and be current.

Three things it does not say. It does not mandate a specific format. It does not require publication: Annex II point 9 covers the case where a manufacturer chooses to make it available to users, framing that as optional. And it does not stop at launch.

Annex VII requires the bill of materials to be provided to market surveillance authorities on request.

Article 13(8) sets the obligation that most changes commercial planning.

The manufacturer determines the support period, and it shall be at least five years. Where the product is expected to be in use for less than five years, the support period corresponds to that expected use time. The determination must reflect reasonable user expectations, the nature and intended purpose of the product, comparable products on the market, the availability of the operating environment, and the support periods of third-party components. The information used to reach the figure goes into the technical documentation.

Article 13(9) adds a separate duty that outlasts the support period. Each security update made available to users must remain available after it has been issued for a minimum of ten years, or for the remainder of the support period, whichever is longer.

So a five-year support period does not free the download server in year six. It has to serve the year-one patch until year eleven.

Requirements that stay inside the company do not satisfy Annex II. It lists the information and instructions that must accompany the product.

Manufacturer identity and postal, email and web contact. A single point of contact for reporting and receiving vulnerability information, plus where to find the coordinated disclosure policy. Product identification. Intended purpose, essential functionality, the security environment the manufacturer assumes, and the product's security properties. Known or foreseeable circumstances, including reasonably foreseeable misuse, that may create significant cybersecurity risk.

Where applicable, the address at which the EU declaration of conformity can be accessed. The type of technical security support offered and the end-date of the support period.

Then detailed instructions, or a link to them, covering commissioning, how changes affect data security, installing updates, secure decommissioning including data removal, how to turn off automatic security updates, and what an integrator needs if the product is designed to be built into another.

Article 13 requires the support end-date, including month and year, to be specified clearly at the time of purchase.

The two parts fail differently, are evidenced differently, and are fixed differently.

The asymmetry matters for planning. Part I is a project: it has an end, and a conformity assessment closes it. Part II is an operating commitment with a five-year floor and a ten-year tail on update availability.

Organisations under-resource Part II because it has no launch date. It is also the part a market surveillance authority can test at any moment, simply by sending a report to the contact address and waiting.

A twelve-person company sells a wifi soil sensor with a companion app and a cloud backend the app needs to show history. Default category, in scope, backend included as a remote data processing solution.

The risk assessment scopes the work. Data is not personal, so point (g) is easy, but the device joins a home network, so points (i) and (j) carry weight: the sensor must not become a pivot.

Concrete changes. Per-device provisioning credentials instead of one factory key, satisfying (b). A signed firmware channel that can ship a library patch without shipping app features, satisfying (c) and Part II point 2. A published security.txt-style contact and a written disclosure policy, satisfying Part II points 5 and 6. A generated dependency manifest for firmware, app and backend, refreshed each release.

And a decision the founders must make and publish: the support end-date, at least five years out, on the box.