Appearance
Vulnerability handling and the support period
Annex I, Part II of the Cyber Resilience Act turns product security from a launch property into a lifecycle duty: the manufacturer must know what is inside the product, test it, fix it without delay, ship the fixes securely and free of charge, and tell users what they need to know, for the whole support period. The Modulos application framework carries these duties as five requirements, MRF-468 through MRF-472; the organization-side capabilities that make them repeatable across a portfolio live in ORF-470–ORF-475 on the reporting and economic operators page.
The support period — MRF-468
The support period is the clock most other duties run on. The manufacturer determines it so that it reflects how long the product is expected to be in use, records the information taken into account in the technical documentation, and:
- sets it at no less than five years, unless the product is expected to be in use for less than five years;
- specifies the end date, including at least the month and the year, clearly and understandably at the time of purchase in an easily accessible manner and, where applicable, on the product, its packaging, or by digital means;
- notifies users when the support period has ended, where technically feasible.
There is no internal route for shortening a support period already owed. Portfolio-level governance of support periods, extensions, and end-of-support triggers is the organization requirement ORF-470.
The SBOM and vulnerability record — MRF-469
The manufacturer identifies and documents the vulnerabilities and components contained in the product, including by drawing up a software bill of materials (SBOM) in a commonly used and machine-readable format covering at the very least the top-level dependencies. The record is kept per product and version and included in the technical documentation.
The SBOM is not published by default. It is provided to a market surveillance authority only on one of three routes, each with its own trigger and conditions:
| Route | Trigger |
|---|---|
| Annex VII, point (8) | A reasoned request needed to check compliance with Annex I |
| Article 13(22) | A reasoned request for the information and documentation necessary to demonstrate conformity |
| Article 13(25) | An ADCO Union-wide dependency assessment |
The routes are independent: a request valid on one route is not refused because it fails another route's conditions. Users receive the SBOM only where the manufacturer elects to make it available. The mandated machine-readable formats and their technical elements are still to be specified by an implementing act under Article 13(24); the Modulos content carries a watch-marker for it.
Security testing — MRF-470
The manufacturer applies effective and regular tests and reviews of the product's security, before placing on the market and throughout the support period, and keeps the reports (Annex VII, point (6)) linked to the tested version. Frequency and content are supported by the product's risks; relevant changes, new threats, new vulnerabilities, or incidents may require additional or adapted testing. Neither a fixed cadence nor its absence is by itself a statutory pass or fail condition; what is scored is that the testing program is effective, regular, and risk-supported.
Remediation, update delivery, and advisories — MRF-471
During the support period, the manufacturer (or deemed manufacturer under Article 21 or 22) addresses and remediates vulnerabilities without delay, and:
- provides new security updates separately from functionality updates, where technically feasible;
- distributes updates securely and, where applicable for security updates, automatically;
- disseminates available security updates without delay and free of charge, with advisory messages on the action to take; the only variation is an agreement between the manufacturer and a business user for a tailor-made product, and it varies only the free-of-charge term, not the timing;
- once a security update has been made available, shares and publicly discloses information about the fixed vulnerability, delaying only in duly justified cases where the manufacturer considers the security risks of publication to outweigh the security benefits, and only until users can apply the patch;
- keeps each issued security update available for a minimum of 10 years or for the remainder of the support period, whichever is longer (Article 13(9)), and may satisfy Annex I, Part II, point (2) only for the software version last placed on the market where both Article 13(10) conditions hold, with users of earlier versions able to obtain the latest version free of charge and without additional adjustment costs.
The product-side capability (the product can receive, verify, and install updates) is the Annex I property covered by MRF-456; this requirement covers the manufacturer's conduct: actually building, shipping, and communicating the fixes.
Product identity, information, and instructions — MRF-472
The product carries an element allowing its identification, and the manufacturer's identity and contact details accompany it. The product ships with the Annex II information and instructions to the user, in paper or electronic form, in a language easily understood by users and market surveillance authorities: the product's security properties, the support period and its end date, how to install updates, where to find the coordinated vulnerability disclosure policy, and how to securely decommission the product.
The manufacturer designates a single point of contact that lets users communicate directly and rapidly, allows them to choose their preferred means of communication, and is not limited to automated tools. The instructions are kept available for at least 10 years after placing on the market or for the support period, whichever is longer.
How this maps in Modulos
| Requirement | CRA anchor | Backed by (new CRA controls) |
|---|---|---|
MRF-468 — Support-period determination and disclosure | Article 13(8), (19); Annex II point 7 | MCF-683 support-period determination and end-of-support management |
MRF-469 — SBOM and vulnerability record | Annex I Part II point (1); Article 13(22), (25); Annex VII point (8) | Reused component-inventory and SBOM controls; the organization-side counterpart is OCF-373 |
MRF-470 — Product security testing and review | Annex I Part II point (3); Annex VII point (6) | Reused testing controls; the organization-side counterpart is OCF-375 |
MRF-471 — Remediation, update delivery, and advisories | Annex I Part II points (2), (4), (7), (8); Article 13(9), (10) | MCF-673 update capability and delivery, MCF-680 fixed-vulnerability advisory and disclosure, plus reused update-delivery controls |
MRF-472 — Product identity, information, and instructions | Article 13(15)–(20); Annex II | MCF-681 vulnerability reporting contact and intake, plus the Annex II limbs of MCF-673, MCF-679, and MCF-683 |
Alongside the new controls, these requirements reuse the vulnerability-management, patching, and communication controls the platform's ISO 27001, NIS2, and DORA estates already carry — the operationalizing page has the full split.
Where to go next
- Reporting and economic operators — the organization-side capabilities behind these duties, and the Article 14 reporting ladders.
- Risk assessment and Annex I — the product-security properties these processes maintain.
Disclaimer
This page is for general informational purposes and does not constitute legal advice. Always verify against the current published text of Regulation (EU) 2024/2847 and consult qualified advisers.