Self-check · CRA / 2024/2847

HOW FAR ARE YOU FROM ANNEX I?

Work through the 22 requirements of Annex I to Regulation (EU) 2024/2847 — product properties and vulnerability handling. You get a score, gaps and a fix order.

This questionnaire builds on what is explained in the guide to the CRA

The questionnaire goes requirement by requirement through Annex I to Regulation (EU) 2024/2847: first the product properties from Part I, then the vulnerability handling processes from Part II. Each question comes with a short explanation of what is actually expected from the manufacturer. Your answers stay in your browser, nothing is sent anywhere and nobody asks for your email.

We do not copy out the wording of the regulation — the questions paraphrase it and each one names the point it comes from. The official text is in Annex I on EUR-Lex.

An indicative self-assessment, not an audit or a certification The output is an indicative self-assessment. It is not an audit, a certification or a conformity assessment under Article 32, and it does not evidence that the essential requirements are met — that is decided by the evidence in the technical documentation under Article 31 and Annex VII, not by answers in a form. The point of the questionnaire is different: to show where the biggest gaps are and in what order to close them before the product goes to market. What binds is the wording of Regulation (EU) 2024/2847. CypherOn is a cybersecurity consultancy, not a law firm.
1Properties 1/2
2Properties 2/2
3Vulnerability handling
4Result

Product properties — Annex I, Part I

Point 1 applies always and unconditionally. The requirements of point 2 apply, in the words of its opening sentence, “where applicable” on the basis of the cybersecurity risk assessment under Article 13(2) — which is why “not applicable” is an option for them. The justification then belongs in the technical documentation (Article 13(4)).

How to answer Yes = in place and you can evidence it. Partially = you do it, but not systematically or without evidence. No = not yet. Not applicable = the requirement does not apply to the product according to the risk assessment and you have a justification for that; this option is offered only by the requirements of Part I, point 2.
Do you have a documented cybersecurity risk assessment for the product? Annex I, Part I, point 1

Point 1 applies always: the product must be designed, developed and produced in such a way that it ensures an appropriate level of cybersecurity based on the risks. Article 13(2) and (3) give it operational shape — the assessment is made for the intended purpose and reasonably foreseeable use, it is documented, updated during the support period, and it must show which requirements of point 2 apply to the product and how they are met. Without it, the rest of this questionnaire has nothing to stand on.

Do you make the product available on the market without known exploitable vulnerabilities? Annex I, Part I, point 2(a)

Point (a) requires the product to contain no known exploitable vulnerabilities when it is made available on the market. In practice that means checking components against vulnerability databases before a release and having a decision for every finding: either it is fixed, or it is demonstrably not exploitable in this product.

Is the product shipped with a secure by default configuration and can it be reset to its original state? Annex I, Part I, point 2(b)

Point (b) requires a secure by default configuration, including the possibility of resetting the product to its original state. Anything else may be agreed only with a business user and only for a tailor-made product — for a consumer product, or for a customer not known in advance, that exception does not exist.

Can the product receive a security update, and automatically where that is possible? Annex I, Part I, point 2(c)

Point (c) requires that vulnerabilities can be addressed through security updates — where applicable automatic ones, installed within an appropriate timeframe as a default setting, with a clear and easy-to-use opt-out mechanism, with notification of available updates to the user and the option to postpone installation temporarily. It is the technical precondition for most of Part II: without a path for the fix to reach the user, the vulnerability does not get removed.

Does the product protect access to its functions and report possible unauthorised access? Annex I, Part I, point 2(d)

Point (d) requires protection from unauthorised access by appropriate control mechanisms, including authentication, identity or access management, and reporting on possible unauthorised access. This is not only about user login — it also covers service and diagnostic interfaces, APIs and update interfaces.

Does the product protect the confidentiality of stored and transmitted data? Annex I, Part I, point 2(e)

Point (e) requires protection of the confidentiality of stored, transmitted or otherwise processed data, personal or other — for example by encrypting them with state-of-the-art mechanisms. What decides the outcome is what is actually encrypted and with what: an outdated cipher or a key hard-coded in the firmware image does not meet the requirement.

Does the product protect the integrity of data, configuration and its own code? Annex I, Part I, point 2(f)

Point (f) requires protection of the integrity of stored, transmitted and processed data, commands, programs and configuration against manipulation or modification not authorised by the user, and reporting on corruptions. In practice that means verified boot and signed firmware, integrity checks on updates and detection of unauthorised changes to settings.

Product properties — second half

The remaining seven requirements of point 2: the data processed, availability, impact on surrounding networks, attack surfaces, mitigating the impact of an incident, security logging and data deletion.

How to answer Yes = in place and you can evidence it. Partially = you do it, but not systematically or without evidence. No = not yet. Not applicable = the requirement does not apply to the product according to the risk assessment and you have a justification for that; this option is offered only by the requirements of Part I, point 2.
Does the product process only the data it needs for its purpose? Annex I, Part I, point 2(g)

Point (g) is data minimisation: the product may process only data that are adequate, relevant and limited to what is necessary in relation to its intended purpose. What usually fails here is telemetry and diagnostics that collect more “just in case” than the product has any reason to.

Does the product keep its essential and basic functions available after an incident? Annex I, Part I, point 2(h)

Point (h) requires protection of the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks. Typically this is about request limits, behaviour under overload and whether the product returns to service on its own.

Does the product avoid harming other devices or networks? Annex I, Part I, point 2(i)

Point (i) requires minimising the negative impact of the product itself — and of connected devices — on the availability of services provided by other devices or networks. The aim is that the product does not become a source of traffic that brings down the customer's network, whether through a fault or after being compromised.

Is the attack surface limited to what the product really needs? Annex I, Part I, point 2(j)

Point (j) requires design, development and production that limit attack surfaces, including external interfaces. In practice that means unused services and ports switched off, no debug or service entry points in the production version, and the smallest possible number of components you have to maintain.

Does the product reduce the impact of an incident when one happens? Annex I, Part I, point 2(k)

Point (k) requires design, development and production that reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques — that is, whatever makes a flaw harder for an attacker to use, or limits how far they get. This covers compiler and runtime hardening, separation of processes and privileges, and isolation of components.

Does the product record security-relevant events? Annex I, Part I, point 2(l)

Point (l) requires the product to provide security related information by recording and monitoring relevant internal activity, including access to and modification of data, services or functions, with an opt-out mechanism for the user. Without those records you cannot find out what happened during an incident — and reporting under Article 14 then has nothing to build on.

Can the user securely and permanently delete data and settings? Annex I, Part I, point 2(m)

Point (m) requires the possibility to securely and easily remove all data and settings on a permanent basis and, where such data can be transferred to other products or systems, to do so in a secure manner. It is the function customers ask about when decommissioning a device or passing it on.

Vulnerability handling processes — Annex I, Part II

Eight requirements on the manufacturer's processes. Unlike point 2 of Part I they are not tied to the risk assessment and there is no “not applicable” option: under Article 6(b), processes that comply with Part II are a condition for making the product available on the market.

How to answer Yes = in place and you can evidence it. Partially = you do it, but not systematically or without evidence. No = not yet. Not applicable = the requirement does not apply to the product according to the risk assessment and you have a justification for that; this option is offered only by the requirements of Part I, point 2.
Do you know what the product is made of, and do you have a software bill of materials? Annex I, Part II, point 1

Point 1 requires identifying and documenting the vulnerabilities and components contained in the product, including by drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the top-level dependencies of the product. A hand-kept spreadsheet meets the requirement formally, once; the only sustainable bill of materials is one produced by the build.

Do you address and remediate vulnerabilities without delay? Annex I, Part II, point 2

Point 2 requires addressing and remediating vulnerabilities without delay in relation to the risks they pose to the product, including by providing security updates; where technically feasible, security updates are to be provided separately from functionality updates. Separately, so that the customer can take the fix without having to accept new functionality.

Do you test and review the security of the product regularly? Annex I, Part II, point 3

Point 3 requires effective and regular tests and reviews of the security of the product. It does not prescribe a method or a frequency — those follow from the risk assessment — but it does assume repeatability and a record. A one-off test before market launch does not meet the requirement.

Do you publicly disclose information about fixed vulnerabilities? Annex I, Part II, point 4

Point 4 requires the manufacturer, once a security update has been made available, to share and publicly disclose information about fixed vulnerabilities: a description, information allowing users to identify the product affected, the impact and severity, and clear information helping users to remediate the vulnerability. In duly justified cases, disclosure may be delayed until users have had the possibility to apply the fix.

Do you have a coordinated vulnerability disclosure policy in place and enforced? Annex I, Part II, point 5

Point 5 requires putting in place and enforcing a policy on coordinated vulnerability disclosure. That means a written, public rule on how an external report is handled: who receives it, when you respond, how it is resolved and when the information is published. Evidence of the policy belongs in the technical documentation (Annex VII, point 2(b)).

Does anyone outside have somewhere to report a vulnerability in your product? Annex I, Part II, point 6

Point 6 requires measures to facilitate the sharing of information about potential vulnerabilities in the product and in the third-party components it contains, including by providing a contact address for reporting. Annex II points to the same contact — it belongs to the information supplied with the product, so it has to be findable without any knowledge of the company's internal structure.

Do you have a mechanism that gets updates to users securely? Annex I, Part II, point 7

Point 7 requires mechanisms for the secure distribution of updates so that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, automatically. Secure distribution means verified origin and integrity of the package and resistance to spoofing and to rollback to an older version. A description of the technical solution chosen belongs in the technical documentation (Annex VII, point 2(b)).

Do you disseminate security updates without delay, free of charge and with an advisory message? Annex I, Part II, point 8

Point 8 requires available security updates to be disseminated without delay and free of charge, accompanied by advisory messages telling users what happened and what to do. Anything else may be agreed only for a tailor-made product and only with a business user. Paid support may therefore exist, but it must not be a condition for obtaining a security fix.

The score is only a summary of the answers: “yes” counts in full, “partially” counts as half, “not applicable” is excluded from the calculation. It is not a measure of compliance with the regulation.

The dates that go with this

11 September 2026 Article 14 applies: actively exploited vulnerabilities and severe incidents having an impact on the security of the product are reported within 24 hours, 72 hours and by a final report. This also covers products placed on the market earlier (Article 69(3)).
11 December 2027 The Regulation applies as a whole (Article 71(2)): the essential requirements of Annex I, conformity assessment under Article 32, technical documentation, the EU declaration of conformity and the CE marking.
after 11 December 2027 Products placed on the market before that date are governed by the requirements of the regulation only if they undergo a substantial modification after it (Article 69(2)).

What to do next

  • Close the gaps in the order above and, for each one, note straight away what will evidence it — a test report, a process record or a link into the repository
  • File the outputs in the technical documentation under Article 31 and Annex VII as you go; it is created during development, not just before the conformity assessment
  • Go through the information and instructions to the user under Annex II — the contact point for reporting, the type of support and the end date of the support period, instructions for updates and for secure decommissioning
  • Check which conformity assessment route applies to your product category (Article 32); for important and critical products a notified body is involved
  • Prepare your reporting procedure under Article 14 — it applies from 11 September 2026 and also covers products already on the market today (Article 69(3))
  • Microenterprises and small enterprises may submit elements of the technical documentation in a simplified format under Article 33(5); the substance of the requirements does not change

The output is based solely on your answers and is indicative — it is not evidence of conformity or a conformity assessment under Article 32. The score is useful for comparing yourself against yourself over time, not for comparison with other manufacturers.

Open the CRA guide →

CypherOn provides cybersecurity consulting services and is not a law firm. For legal opinions, turn to an attorney registered with the Czech Bar Association.

How this is done in development

What SCA, SAST, DAST and image scanning actually find, how a software bill of materials and VEX are produced, what to block in CI/CD, and how KEV and EPSS feed the decision to report under Article 14.

Open DevSecOps

Does the CRA apply to your product?

Scope, your role in the supply chain and the product category under Annexes III and IV — and the conformity assessment route that follows from them under Article 32.

Open the calculator

Reporting under Article 14 step by step

When a vulnerability counts as actively exploited or an incident as severe, the 24 h / 72 h deadlines and the final report, the content of each report and preparing for the ENISA platform.

Open the procedure

Official sources

The questions and their explanations are based on the sources below, as they stood on 9 August 2026. What binds is the wording of the legislation, not our reading of it.

Regulation (EU) 2024/2847 — Annex I ↗ The official text of Annex I. Part I, point 1 and point 2, (a) to (m), are the template for the questions in the first two steps; Part II, points 1 to 8, for the third step. Regulation (EU) 2024/2847 — Articles 6 and 13 ↗ Article 6 provides that a product may be made available on the market only where it meets Part I of Annex I and the manufacturer's processes comply with Part II. Article 13(2) to (4) covers the cybersecurity risk assessment, its documentation and the justification for requirements that do not apply — which is what the “not applicable” answer rests on. Regulation (EU) 2024/2847 — Annex VII and Annex II ↗ Annex VII lists the content of the technical documentation (among others point 2(b) — the bill of materials, the disclosure policy, the contact address and the description of update distribution; point 3 — the risk assessment; point 6 — test reports). Annex II sets out the information and instructions supplied with the product. Regulation (EU) 2024/2847 — Articles 69 and 71 ↗ The dates in the result: the regulation applies from 11 December 2027, Article 14 from 11 September 2026 (Article 71(2)). Products placed on the market earlier come under the regulation only upon a substantial modification (Article 69(2)), but the reporting obligations under Article 14 do apply to them (Article 69(3)). Commission guidance on the application of the CRA (27 July 2026) ↗ Communication C(2026) 5252 — scope, remote data processing solutions, open source, substantial modification, the support period and reporting. Not binding, but the best available guidance on borderline cases.
Content valid as of 9 August 2026

When the questionnaire produces a longer list

The requirements of Annex I
are built into development,
not into documents.

Product threat modelling, secure development review, vulnerability management and the inputs for the technical documentation under Annex VII. Tell us which points came out as gaps and where you stand today.

Discuss a specific product →