Appearance
Reporting and economic operators
The application framework asks whether one product is compliant. The organization framework asks whether the organization can keep products compliant: whether it knows which CRA roles it holds, runs the vulnerability-handling machinery as a repeatable operation, meets the Article 14 reporting clocks, and discharges the duties of whichever supply-chain capacities it occupies. OFF-26 carries this as 15 requirements, ORF-468–ORF-482.
Know your roles — ORF-468
For each product with digital elements and each legal entity concerned, the organization documents a dated, current determination of whether the CRA applies and every capacity in which the entity acts: manufacturer, authorized representative, importer, distributor, open-source software steward, or a person treated as a manufacturer under Article 21 or Article 22. One entity may hold several roles at once, but each determination is product-specific and must be updated when products, contracts, branding, or modifications change.
The four role requirements at the end of the framework (ORF-479–ORF-482) are conditional: they activate only for the capacities the organization actually holds, and a documented non-applicability justification is a completed outcome, not a gap.
The manufacturer's repeatable capabilities — ORF-469–ORF-475
Seven requirements turn the per-product duties of Annex I, Part II into portfolio operations:
| Requirement | The capability |
|---|---|
ORF-469 — Secure-product risk and compliance governance | A repeatable portfolio method for assessing and treating product cybersecurity risks, component due diligence, and keeping series production in conformity; where the full quality assurance route is used, the approved quality system and its surveillance |
ORF-470 — Portfolio support-period governance | Determining, documenting, and revisiting support periods across the portfolio; resourcing vulnerability handling for each period; governing extensions, end-of-support triggers, and handover to product-level disclosure |
ORF-471 — Component and SBOM governance | Component identification and SBOM generation per released version, including components obtained without a supplier contract; correlation with vulnerability intelligence; upstream reporting and fix sharing; the triggered authority routes |
ORF-472 — Security-update operations | Triage to affected products and versions, remediation without delay, fixes for all affected supported versions unless Article 13(10) is validly relied on, secure and where applicable automatic distribution, dissemination without delay and free of charge, retention of issued updates |
ORF-473 — Product security testing program | An effective and regular testing program with reports retained per tested version, coverage reconciliation, and testing triggered by changes, threats, vulnerabilities, or incidents beyond the planned cadence |
ORF-474 — Vulnerability disclosure and intake | A coordinated vulnerability disclosure policy, put in place and enforced; a contact address for reporting vulnerabilities; the single point of contact users can reach directly, choosing their means of communication; measures facilitating vulnerability information sharing |
ORF-475 — Security advisory and user communication | Informing impacted users (and, where appropriate, all users) of an actively exploited vulnerability or severe incident and the available mitigations, where appropriate in a structured, machine-readable format; sharing and publicly disclosing fixed vulnerabilities once an update is available |
Article 14 reporting — ORF-476
From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements, or of a severe incident having an impact on the security of a product with digital elements, notifies the CSIRT designated as coordinator and ENISA simultaneously, through the EU single reporting platform (Article 16, operated by ENISA). Each track runs its own three-stage ladder:
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Without undue delay, and in any event within 24 hours of becoming aware | Without undue delay, and in any event within 24 hours of becoming aware, including whether the incident is suspected to be caused by unlawful or malicious acts |
| Notification | Without undue delay, and in any event within 72 hours of becoming aware, unless already provided: general information on the product, the general nature of the exploit and vulnerability, measures taken, and measures users can take | Without undue delay, and in any event within 72 hours of becoming aware, unless already provided: the nature of the incident, an initial assessment, and measures taken and available |
| Final report | Unless already provided, no later than 14 days after a corrective or mitigating measure is available | Unless already provided, within one month after the submission of the 72-hour notification |
The two final-report clocks are anchored differently: the vulnerability clock runs from the availability of a corrective or mitigating measure, the incident clock from the submission of the 72-hour notification. The coordinator CSIRT may additionally request an intermediate report (Article 14(6)), and routing follows the Article 14(7) main-establishment test with its fallback sequence for manufacturers without a Union establishment.
Three transitional points matter:
- Article 14 applies from 11 September 2026 to all in-scope products, including products placed on the market before 11 December 2027, whether or not they have been substantially modified (Article 69(3), derogating from Article 69(2)).
- Reporting continues for products whose support period has ended.
- An Article 21/22 deemed manufacturer picks up the duties from 11 December 2027; an open-source software steward reports within the limits of Article 24(3): vulnerabilities only where it was involved in the product's development, incidents only where they affect network and information systems it provides for the product's development.
User-facing communication about the same events is the separate duty in ORF-475 (Article 14(8)). Under Article 17(2) the coordinator CSIRT may inform the public about a reported incident itself or require the manufacturer to do so; the manufacturer's own duty to inform the public arises only where required, and the duty to publicly disclose a fixed vulnerability once an update is available runs independently.
Corrective action, cooperation, and records — ORF-477, ORF-478
ORF-477 carries the post-market corrective-action duties: knowing or having reason to believe the product or its processes fail Annex I, the manufacturer immediately brings them into conformity, withdraws, or recalls; on a reasoned request it provides conformity information in a language the authority easily understands and cooperates on risk elimination; if it ceases operations in a way that stops compliance, it notifies authorities beforehand and, to the extent possible, users. Relevant economic operators grant the Article 53 access to design, development, production, and vulnerability data on a reasoned request and cooperate in Article 54 evaluations.
ORF-478 keeps each role's records current and producible for at least 10 years after placing on the market or the support period, whichever is longer: the manufacturer's technical documentation and EU declaration of conformity, the authorized representative's mandated copies, the importer's declaration copy, and every economic operator's ability to name, for 10 years after each supply, its supplier and, where available, whom it supplied.
The conditional roles — ORF-479–ORF-482
| Requirement | Role | The duties |
|---|---|---|
ORF-479 | Authorized representative | Holds a written mandate from the manufacturer allowing it at least to keep the declaration and technical documentation at authorities' disposal, provide conformity information on a reasoned request, and cooperate on risk elimination; provides a copy of the mandate on request |
ORF-480 | Importer | Places only conforming products on the market; verifies the conformity assessment, documentation, CE marking, declaration, and instructions; withholds a product where it considers or has reason to believe it non-conforming, until conformity is achieved; adds its name and contact details to the product; once placed, on knowledge or reason to believe non-conformity, immediately corrects, withdraws, or recalls as appropriate; reports vulnerabilities to the manufacturer without undue delay and significant cybersecurity risks to authorities immediately |
ORF-481 | Distributor | Acts with due care in making products available: verifies the CE marking and the manufacturer's and importer's duties, support-period end date included; where information in its possession indicates non-conformity, holds the product until conformity is achieved; afterwards, given reason to believe non-conformity, makes sure the necessary corrective, withdrawal, or recall measures are taken; informs the manufacturer of vulnerabilities without undue delay and authorities of significant cybersecurity risks immediately |
ORF-482 | Open-source software steward | Puts in place and verifiably documents a cybersecurity policy that supports secure product development and effective vulnerability handling by its developers, promotes vulnerability information sharing in the open-source community, and cooperates with market surveillance authorities on risk mitigation |
An importer or distributor that places a product on the market under its own name or trademark, or substantially modifies a product already placed, becomes a deemed manufacturer (Article 21) and owes the manufacturer duties; the same follows under Article 22(1) for a person outside those roles that both substantially modifies a product and makes it available on the market.
How this maps in Modulos
The Article 14 machinery is carried by two new controls that encode the ladders exactly: OCF-378 (actively exploited vulnerability reporting) and OCF-379 (severe-incident reporting). The capabilities reuse the incident-management, vulnerability-management, and communication controls shared with the NIS2 and DORA estates, alongside new portfolio controls: OCF-372 (support-period governance), OCF-373 (component and SBOM operations), OCF-374 (security-update operations), OCF-375 (testing program), OCF-376 (coordinated vulnerability disclosure governance), and OCF-377 (impacted-user notification).
Every requirement on this page carries CRA Role tags, so a project filters cleanly to the roles the organization actually holds: ORF-479 activates only for authorized representatives, ORF-480 for importers, ORF-481 for distributors, ORF-482 for open-source software stewards.
Where to go next
- Operationalizing the CRA in Modulos — the full MFF-26 / OFF-26 rollout with the mapping tables and control split.
- Vulnerability handling and the support period — the per-product duties these capabilities serve.
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.