Appearance
Risk assessment and Annex I
The CRA's product-security duties are risk-based by construction. The cybersecurity risk assessment is not one requirement among many: it is the instrument that decides, for each of the thirteen Annex I, Part I security properties, whether and in what manner the property applies to this product. The Modulos framework models that structure directly: one requirement for the assessment (MRF-452), one for the overall security outcome (MRF-453), thirteen for the properties (MRF-454–MRF-466), and one for components and remote solutions (MRF-467).
The cybersecurity risk assessment — MRF-452
The manufacturer undertakes, documents, and keeps current a cybersecurity risk assessment for the product, and takes its outcome into account during planning, design, development, production, delivery, and maintenance. The assessment covers:
- the intended purpose and reasonably foreseeable use,
- the conditions of use, such as the operational environment and the assets to be protected,
- the length of time the product is expected to be in use (which also feeds the support-period determination).
Above all, the assessment states whether and in what manner each Annex I, Part I, point (2) property applies and how it is implemented, and gives a clear justification wherever an essential requirement is not applicable. For products referred to in Article 12 that are also subject to other Union legal acts, the cybersecurity risk assessment may form part of the risk assessment those acts require (Article 13(4)). For an AI-enabled product, that permits one merged assessment rather than two parallel ones.
The risk-based security outcome — MRF-453
Annex I, Part I opens with an outcome, not a checklist: the product is designed, developed, and produced so that it ensures an appropriate level of cybersecurity based on the risks, and it is made available on the market only where that outcome holds when the product is properly installed, maintained, and used for its intended purpose or under reasonably foreseeable conditions, with the necessary security updates installed where applicable. The lettered properties that follow are not an exhaustive statement of what an appropriate level of cybersecurity requires; MRF-453 scores the residual outcome across the whole life cycle.
The thirteen properties — MRF-454–MRF-466
Each property below applies where applicable on the basis of the documented cybersecurity risk assessment. Where a property does not apply, a clear, product-specific justification satisfies the requirement: in Modulos, a linked non-applicability justification is a completed outcome, not a gap.
| Requirement | Annex I, Part I | The property |
|---|---|---|
MRF-454 — No known exploitable vulnerabilities | (2)(a) | The product is made available without known exploitable vulnerabilities; the release decision rests on evidence about known vulnerabilities and their practical exploitability in this product |
MRF-455 — Secure defaults and reset | (2)(b) | Secure-by-default configuration, with the possibility to reset to the original state; the only statutory exception is an agreement with a business user for a tailor-made product |
MRF-456 — Secure and usable updates | (2)(c) | Vulnerabilities can be addressed through security updates; where automatic updates apply: on by default, clear opt-out, notification, and temporary postponement |
MRF-457 — Access control and access reporting | (2)(d) | Protection from unauthorized access (authentication, identity or access management) and reporting on possible unauthorized access — the reporting limb is a distinct capability, not satisfied by preventive controls alone |
MRF-458 — Data confidentiality protection | (2)(e) | Confidentiality of stored, transmitted, or otherwise processed data, personal or other, for example state-of-the-art encryption at rest and in transit |
MRF-459 — Data and software integrity | (2)(f) | Integrity of data, commands, programs, and configuration against unauthorized manipulation, with reporting on corruptions |
MRF-460 — Product data minimisation | (2)(g) | Processing only data adequate, relevant, and limited to what the product's intended purpose requires — non-personal data included |
MRF-461 — Essential-function availability and resilience | (2)(h) | Availability of essential and basic functions, including after an incident, with resilience and denial-of-service mitigation |
MRF-462 — Connected-service availability protection | (2)(i) | Minimizing the negative impact the product or connected devices have on the availability of services provided by other devices or networks |
MRF-463 — Attack-surface limitation | (2)(j) | Limiting attack surfaces, external interfaces included, with paths through remote data processing solutions in scope |
MRF-464 — Exploitation-impact mitigation | (2)(k) | Reducing the impact of an incident through appropriate exploitation mitigation mechanisms and techniques |
MRF-465 — Security activity logging and user control | (2)(l) | Recording and monitoring relevant internal activity, with an opt-out mechanism for the user — the opt-out is part of the essential requirement |
MRF-466 — Secure data removal and transfer | (2)(m) | Users can securely and permanently remove all data and settings; where data can be transferred to other products or systems, the transfer is secure |
For an AI-enabled product, the assessment decides how each property lands on the AI-specific parts: model artifacts and weights under integrity and confidentiality, training and telemetry data under minimization, model-serving endpoints under attack-surface limitation, inference availability under essential functions. The framework's scoring rule keeps this honest in shared controls: an AI-specific limb of a control is scored only where the risk assessment shows its cybersecurity relevance.
Components and remote solutions — MRF-467
The boundary work from MRF-450 becomes operational here:
- Remote data processing solutions are part of the product and must meet the essential requirements. Third-party remote solutions and external dependencies are risk-assessed and mitigated.
- Due diligence over integrated components, including free and open-source software not made available on the market in the course of a commercial activity.
- On identifying a vulnerability in an integrated component, the manufacturer reports it to the person or entity manufacturing or maintaining the component, and addresses and remediates it under Annex I, Part II. Where the manufacturer has developed a software or hardware modification, it shares the relevant code or documentation with that person or entity, where appropriate in a machine-readable format.
This is the CRA's upstream-citizenship rule: integrating open-source components carries a duty to report vulnerabilities upstream and, where the manufacturer has developed a modification, to share the relevant code or documentation with the maintainer, not just to patch downstream.
How this maps in Modulos
MRF-452 is backed by risk-assessment controls shared with the platform's other estates, so an organization already running structured cybersecurity risk work reuses it here. The thirteen property requirements draw on a mix: established information-security controls (access control, encryption, logging) reused from the ISO 27001, NIS2, and DORA estates, and new CRA product-security controls where the CRA demands something the estate did not yet carry, such as release-gating on known exploitable vulnerabilities (MCF-671), secure-by-default configuration and reset (MCF-672), the update capability (MCF-673), unauthorized-access reporting (MCF-674), integrity-corruption reporting (MCF-675), product data minimization (MCF-676), network-externality safeguards (MCF-677), blast-radius reduction (MCF-678), and secure erasure and transfer (MCF-679).
The full control split is on Operationalizing the CRA in Modulos.
Where to go next
- Vulnerability handling and the support period — Annex I, Part II: SBOM, testing, remediation, advisories, and the support period.
- Scope, classification, and conformity — the decisions that put the product here in the first place.
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.