Appearance
Operationalizing the CRA in Modulos
Modulos ships the Cyber Resilience Act as a paired framework (templates 1.0.28): OFF-26 establishes the organization's CRA posture once (roles, repeatable product-security capabilities, Article 14 reporting readiness), and MFF-26 produces the per-product evidence that a given AI-enabled product with digital elements meets the essential cybersecurity requirements. Both carry the Regulation label and the cra.svg icon.
Project structure
| Template | Project type | Scope | Requirements | Distinct Controls |
|---|---|---|---|---|
OFF-26 — Cyber Resilience Act | Organization | The organization and its economic-operator roles | 15 (ORF-468–ORF-482) | 38 |
MFF-26 — Cyber Resilience Act | AI application | One AI-enabled product with digital elements | 26 (MRF-450–MRF-475) | 71 |
One MFF-26 project assesses one product; it does not model every non-AI product in scope. The two templates' control sets do not overlap, so together the 41 requirements map to 109 distinct Controls. There is no scoping questionnaire; applicability is handled inside the requirement text, with MRF-450 (product) and ORF-468 (roles) recording the perimeter decisions.
The application framework — MFF-26
| Requirement | CRA anchor |
|---|---|
MRF-450 — CRA applicability and product boundary | Articles 2, 3, 21, 22, 69(2) |
MRF-451 — Product category, modification, and conformity route | Articles 6–8, 12, 22, 32; Implementing Regulation (EU) 2025/2392 |
MRF-452 — Cybersecurity risk assessment | Article 13(2)–(4) |
MRF-453 — Risk-based cybersecurity outcome | Annex I, Part I, point (1); Article 6 |
MRF-454 — No known exploitable vulnerabilities | Annex I, Part I, point (2)(a) |
MRF-455 — Secure defaults and reset | Annex I, Part I, point (2)(b) |
MRF-456 — Secure and usable updates | Annex I, Part I, point (2)(c) |
MRF-457 — Access control and access reporting | Annex I, Part I, point (2)(d) |
MRF-458 — Data confidentiality protection | Annex I, Part I, point (2)(e) |
MRF-459 — Data and software integrity | Annex I, Part I, point (2)(f) |
MRF-460 — Product data minimisation | Annex I, Part I, point (2)(g) |
MRF-461 — Essential-function availability and resilience | Annex I, Part I, point (2)(h) |
MRF-462 — Connected-service availability protection | Annex I, Part I, point (2)(i) |
MRF-463 — Attack-surface limitation | Annex I, Part I, point (2)(j) |
MRF-464 — Exploitation-impact mitigation | Annex I, Part I, point (2)(k) |
MRF-465 — Security activity logging and user control | Annex I, Part I, point (2)(l) |
MRF-466 — Secure data removal and transfer | Annex I, Part I, point (2)(m) |
MRF-467 — Component and remote-solution assurance | Article 13(5), (6); Annex I, Part II |
MRF-468 — Support-period determination and disclosure | Article 13(8), (19); Annex II, point 7 |
MRF-469 — SBOM and vulnerability record | Annex I, Part II, point (1); Article 13(22), (25); Annex VII, point (8) |
MRF-470 — Product security testing and review | Annex I, Part II, point (3); Annex VII, point (6) |
MRF-471 — Remediation, update delivery, and advisories | Annex I, Part II, points (2), (4), (7), (8); Article 13(9), (10) |
MRF-472 — Product identity, information, and instructions | Article 13(15)–(20); Annex II |
MRF-473 — Technical documentation and lifecycle maintenance | Article 31; Annex VII |
MRF-474 — Conformity, declaration, and CE marking | Articles 28, 30; Annexes V, VI, VIII |
MRF-475 — Continuous conformity and corrective action | Article 13(14), (21) |
Two scoring rules keep the framework honest for AI-enabled products:
- For
MRF-454throughMRF-466, a linked Article 13(4) non-applicability justification is a completed outcome, not a gap — the thirteen properties apply where applicable on the basis of the documented cybersecurity risk assessment. - In a shared Control, only the limb evidencing the mapped CRA outcome is scored; an AI-specific limb is scored only where
MRF-452shows its cybersecurity relevance orMRF-451records the Article 12 branch.
The organization framework — OFF-26
| Requirement | CRA anchor |
|---|---|
ORF-468 — CRA actor role and applicability governance | Articles 2, 3, 18–24 |
ORF-469 — Secure-product risk and compliance governance | Article 13(1)–(7), (14) |
ORF-470 — Portfolio support-period governance | Article 13(8) |
ORF-471 — Component and SBOM governance | Annex I, Part II, point (1); Article 13(5), (6) |
ORF-472 — Security-update operations | Annex I, Part II, points (2), (7), (8); Article 13(10) |
ORF-473 — Product security testing program | Annex I, Part II, point (3); Annex VII, point (6) |
ORF-474 — Vulnerability disclosure and intake | Article 13(17); Annex I, Part II, points (5), (6) |
ORF-475 — Security advisory and user communication | Article 14(8); Annex I, Part II, point (4) |
ORF-476 — Mandatory vulnerability and incident reporting | Articles 14, 16, 69(3) |
ORF-477 — Post-market corrective action and authority cooperation | Articles 13(21)–(23), 53, 54, 58 |
ORF-478 — Compliance records and economic-operator traceability | Articles 13(13), 18(3), 19(6), 23 |
ORF-479 — Authorised representative mandate and duties | Article 18 |
ORF-480 — Importer placing-on-the-market and subsequent duties | Article 19 |
ORF-481 — Distributor due-care and making-available duties | Article 20 |
ORF-482 — Open-source software steward cybersecurity duties | Article 24 |
The four role requirements (ORF-479–ORF-482) are conditional: a documented non-applicability justification is a completed outcome for any role the organization does not hold.
The 22 new CRA Controls
| Control | Carries |
|---|---|
MCF-670 — CRA applicability, classification, and route record | The single dated record of scope, boundary, role, category, substantial modification, and conformity route |
MCF-671 — Release without known exploitable vulnerabilities | Release-gating on enumerated known vulnerabilities and their practical exploitability |
MCF-672 — Secure-by-default configuration and reset | Hardened defaults and reset to the original secure state |
MCF-673 — Product security-update capability and delivery | Receiving, verifying, and installing security updates; where automatic updates apply, on by default with opt-out |
MCF-674 — Unauthorized-access reporting capability | The product's own reporting on possible unauthorized access |
MCF-675 — Product data, command, software, and configuration integrity | Integrity protection with corruption reporting |
MCF-676 — Product data minimisation | Data processing limited to the product's intended purpose, non-personal data included |
MCF-677 — Resource-consumption and network-externality safeguards | Minimizing outward harm to other devices' and networks' services |
MCF-678 — Exploitation mitigation and blast-radius reduction | Impact-reduction mechanisms with a per-component blast-radius analysis |
MCF-679 — Secure user data and settings erasure and transfer | Permanent removal of all data and settings; secure transfer where transferable |
MCF-680 — Fixed-vulnerability advisory and public disclosure | Advisories once an update is available, with the duly-justified delay rule |
MCF-681 — Product vulnerability reporting contact and intake | The single point of contact, not limited to automated tools, feeding intake into handling |
MCF-682 — Third-party component vulnerability escalation and fix sharing | Upstream reporting to component maintainers and sharing of developed fixes |
MCF-683 — Support-period determination and end-of-support management | The determination record, purchase-time disclosure, and end-of-support notification |
OCF-372 — Portfolio support-period governance | One repeatable portfolio method for support periods, with the Article 13(8) determination inputs |
OCF-373 — Component and SBOM operations | The component inventory and SBOM per released version, with the three authority routes |
OCF-374 — Security-update operations | The standing update operation: triage, fixes for all affected supported branches, secure distribution, retention |
OCF-375 — Product-security testing program | Effective and regular tests and reviews with retained reports |
OCF-376 — Coordinated vulnerability disclosure governance | The CVD policy, contact, and information-sharing measures |
OCF-377 — Impacted-user cybersecurity notification | Informing impacted users of exploited vulnerabilities and severe incidents with mitigations |
OCF-378 — CRA actively exploited vulnerability reporting | The 24-hour / 72-hour / 14-day reporting ladder to the coordinator CSIRT and ENISA |
OCF-379 — CRA reporting of severe incidents having an impact on the security of a product with digital elements | The 24-hour / 72-hour / one-month reporting ladder to the coordinator CSIRT and ENISA |
Control reuse — shared coverage from day one
The other 87 of the 109 mapped Controls are reused from the platform's existing estate, and every one of them is shared with at least one other framework. The largest overlaps:
| Framework | Controls shared with MFF-26 | Controls shared with OFF-26 |
|---|---|---|
| ISO/IEC 27001 | 37 | 19 |
| NIS2 | 34 | 22 |
| DORA | 29 | 16 |
| ISO/IEC 42001 | — | 20 |
| EN 18286 | 14 | 13 |
An organization with existing ISO 27001, NIS2, or DORA work on the platform already operates shared Controls covering roughly a third of the CRA estate, and the Evidence attached to them counts here from day one: the vulnerability-management, access-control, encryption, logging, incident-management, and supplier controls carry over. A set of shared Controls was broadened so the same practices now serve both AI governance and product-security assessments, without change to their existing framework coverage. The 22 new Controls carry the genuinely new product-security ground. Reuse is a control-layer economy, not an assertion of clause-level equivalence between the CRA and any other framework.
The three CRA tag categories
Template version 1.0.28 adds three tag categories, attached directly to the CRA requirements:
- CRA Role — Manufacturer, Authorised Representative, Importer, Distributor, Open-Source Software Steward, Deemed Manufacturer (Art 21/22). Every requirement names the roles that owe it; the conditional role requirements carry exactly their own role.
- CRA Product Category — Outside Annexes III and IV, Important Class I, Important Class II, Critical. The category values mirror the Article 32 conformity-route tiers and the Implementing Regulation (EU) 2025/2392 technical descriptions.
- CRA Phase — Before placing on the market, At placing on the market, At making available on the market, During and after the support period. The phases follow the Regulation's own event vocabulary: placing on the market is the first making available (Article 3(21)); every later supply is a making available (Article 3(22)).
Filter a project by Role to see only the duties of the capacities you hold, by Product Category to match your conformity tier, and by Phase to sequence work against the market events.
Dates and transitional rules
Each requirement states its own operative date and the transitional rules for products already on the market:
- 11 September 2026 — Article 14 reporting (
ORF-476, backed byOCF-378/OCF-379) applies to all in-scope products, including products placed on the market before 11 December 2027 (Article 69(3)) and products whose support period has ended. - 11 December 2027 — the remaining duties apply. Products placed on the market before that date are caught only if substantially modified from then on (Article 69(2)).
Pending regulatory events
No harmonized standard for the CRA has been cited in the Official Journal; the requirements anchor directly to the Regulation and carry regulatory watch-markers that trigger an update when the pending events land:
- citation of CRA harmonized standards (the EN 40000 series) in the Official Journal,
- the Article 13(24) implementing act specifying SBOM formats and elements.
The Commission's Article 26 practical guidance (C(2026) 5252) was published on 27 July 2026 as non-binding guidance covering scope, substantial modification, support periods, and reporting.
Rollout sequence
- Determine roles and applicability (
ORF-468): which entities act in which capacities, for which products. - Stand up the organization capabilities (
ORF-469–ORF-475): support-period governance, component and SBOM operations, update operations, testing, coordinated disclosure, user communication. - Make Article 14 reporting operational before 11 September 2026 (
ORF-476): awareness triggers, the 24-hour and 72-hour drills, single-reporting-platform access, routing. - Scope each product (
MRF-450,MRF-451): boundary, category, Article 12 decision, conformity route. - Run the risk assessment and evidence the Annex I properties (
MRF-452–MRF-467), with justified non-applicability where the assessment supports it. - Close the lifecycle duties (
MRF-468–MRF-472): support period, SBOM, testing, remediation, user information. - Assemble conformity (
MRF-473–MRF-475): technical documentation, declaration, CE marking, series conformity.
Each requirement is evidenced through its linked Controls; the Requirement Owner reviews the completed Controls and marks the Requirement as Fulfilled. Framework versioning tracks the pending regulatory events, so projects are notified when the templates update.
Where to go next
CRA overview
What the Regulation covers, the key dates, and the framework structure
Scope, classification, and conformity
The decisions that drive everything else
Reporting and economic operators
The Article 14 ladders and the conditional roles
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.