Skip to content

Cyber Resilience Act · Risk assessment · Technical documentation

Risk assessment your auditor can follow.

Atrekos computes the cybersecurity risk assessment the EU Cyber Resilience Act requires from manufacturers of products with digital elements. A guided questionnaire becomes damage scenarios, attack paths, attack potential and risk levels, then treatment decisions and the evidence trail behind each of them.

For the product-security lead who owns the assessment, the engineers who feed it, and the assessors and customers who review it.

The risk level is computed, not chosen. The treatment decision is yours. Neither is a promise of compliance.

Join the waitlist →Sign in to the pilot
One risk, end to endcomputed · not chosen

Answer

The debug port is reachable without authentication.

Damage scenario

Firmware is replaced; the device drives an unsafe output.

Attack path

Physical access → debug port → firmware write.

Risk

Required attack potential moderate. Risk level high.

= f(elapsed time, expertise, knowledge, window, equipment)

Treatment

Mitigate with an authenticated debug unlock. Residual risk low.

Traced

The challenge

The CRA does not ask for a checklist. It asks for a risk assessment you can defend.

An assessor, or your customer's product-security team, will ask the same first question of every risk: why this level, and which fact about the product produced it? Spreadsheets do not survive that question a year later, and consultants do not scale past the first invoice. Five things make the assessment harder than it sounds.

Art. 13(2) · Annex I Part I

It has to be a real risk assessment

Article 13(2) asks you to assess the cybersecurity risks and to take the outcome into account in how the product is designed, built and maintained. Working through the Annex I requirements is not that. You need threats, damage, likelihood and a defensible risk level for each.

Where Atrekos helps

Atrekos derives damage scenarios and attack paths from your answers and computes each risk from a required-attack-potential model. The level is calculated, not chosen.

Art. 13(3) · Annex VII

It has to be traceable

The assessment goes into the technical documentation, and a conformity assessment reads it line by line. A spreadsheet cannot answer that question a year later, and neither can a consultant who has moved on.

Where Atrekos helps

Every risk, countermeasure and residual decision links back to the answer that caused it, and the reports are generated from that chain.

Art. 13(3) · Art. 13(8)

It has to stay current, across the whole portfolio

The assessment is updated during a support period of at least five years. New variants, newly reported vulnerabilities and new standards all change it. For most teams the second product costs as much as the first.

Where Atrekos helps

The second product costs a re-run, not a project. Clone the assessment, change what changed, and read the diff. Same input, same numbers, every time.

Art. 27 · M/606

It has to speak the standards' language while they are still being written

No CRA harmonised standard has been cited in the Official Journal yet, so no presumption of conformity is available to anyone, and the drafting deadlines have already slipped once. Mapping an assessment to standards by hand is work you will redo.

Where Atrekos helps

Atrekos treats the mapping as versioned data: CRA Annex I and ISA/IEC 62443-4-2 today, the horizontal and vertical harmonised standards as they land.

Art. 13(5) · Annex II

It has to hold at your customer's site

Some measures are only true if the integrator, operator or end user does their part. Your customers will ask which, and their own assessment depends on the answer.

Where Atrekos helps

Every condition the assessment relies on is named, with who has to fulfil it.

ENISA's 2026 SME survey found threat modelling among the widest readiness gaps; the Linux Foundation's 2026 report found only a third of respondents name the December 2027 date correctly.

Assessment modules

One assessment. Three ways it gets used.

The same computed, traceable assessment serves the team that runs it, the outside party that reviews it, and the technical documentation it ends up in.

Self-assessment

Who
Your product, engineering and compliance team.
What
Answer the questionnaire, review the computed risks, decide how each one is treated and record why. Re-run it when the product changes.
Output
The risk assessment for your technical documentation, on the default conformity route.

Art. 32(1) · Annex VIII Module A

Third-party assessment

Who
A consultant, test house or notified body reviewing your product, or an assessor running the assessment on your behalf.
What
They work in your workspace with the role you give them, see the same evidence chain, and confirm which mitigations they accept. Tracing shows what changes when only confirmed evidence counts.
Output
A reviewed assessment, the confirmed-versus-claimed picture, and the package the reviewer takes away.

Art. 32(2)–(3) · Annex VIII Modules B+C, H

Compliance

Who
Whoever owns the technical documentation: product compliance, or the GRC function where it carries the CRA.
What
The assessment is projected onto the requirements: CRA Annex I Part I and Part II, Annex II user information and ISA/IEC 62443-4-2. Coverage and gaps per requirement, with the measures that implement it.
Output
A verdict per requirement with the evidence attached, as the reports and exports that go into the file.

Annex I · Annex II · Annex VII

Lifecycle

The CRA applies across a product's life, not once at CE marking.

Duties start before development and run to the end of support. Each stage carries the article or annex that binds there, and what Atrekos does at that stage. Where the work happens outside it, the stage says so.

  1. Planpartly

    Art. 7–8 · Annex III–IV (class) · Art. 13(8) (support)

    Suggests a class from the product you describe. The decision stays yours.

  2. Assessyes

    Art. 13(2) · Annex I Part I

    Derives damage scenarios and attack paths from your answers and computes each risk level.

  3. Designpartly

    Annex I Part I

    Matches countermeasures and records each treatment decision and why. The architecture is your engineers'.

  4. Buildno

    Annex I Part I

    Code, builds and dependencies are outside the tool.

  5. Testpartly

    Annex I Part I

    Tracks which mitigations are confirmed, and shows what changes when only confirmed evidence counts.

  6. Releasepartly

    Annex VII · Annex II · Art. 32 (conformity) · Art. 30 (CE marking)

    Produces the risk assessment and its projections for the file, not the whole file.

  7. Maintainpartly

    Annex I Part II · Art. 14

    Re-runs the assessment and shows the diff when something changes. Monitoring and reporting happen outside it.

  8. Retireno

    Annex I Part I (2)(m)

    Decommissioning, key and credential revocation and end-of-life notices happen outside the tool.

Product lifecycle, with the return path from Maintain to AssessEight stages in order: Plan, Assess, Design, Build, Test, Release, Maintain, Retire. Maintain is the long stage: the support period, at least five years. In Maintain, an actively exploited vulnerability or a severe incident in the field forks two ways: out, to reporting under Article 14, which happens outside the tool; and back, into Assess, from where the change flows forward again through Design, Test and Release.

What re-opens an assessment

The product changes
a new interface, a change to the authentication model, new sensitive data, a change to the update mechanism, a major architecture change, a new variant.
The supply chain changes
a supplier or dependency change.
Something happens in the field
an incident, a newly disclosed vulnerability.
The standards move
a newly cited harmonised standard.

Guidance, not obligation. Eight of the ten triggers above are the playbook's. Following it does not establish conformity with the CRA.

ENISA, Secure by Design and Default Playbook v1.0, July 2026

Only an actively exploited vulnerability or a severe incident reaches reporting. Reporting starts, on the Article 14 clocks. Everything else re-enters the assessment and stops there.

A vulnerability found in a fielded product re-enters the risk assessment rather than terminating in a report.

What you get

Computed where it matters. Traceable everywhere. Yours to keep.

Questionnaire-based

Plain questions about the product stand in for threat modelling from a blank page. The engine derives damage scenarios and attack steps from the answers, and only asks what is relevant to what you have described.

Computed risk, not scored by hand

Each attack path gets a required attack potential from elapsed time, expertise, knowledge of the product, window of opportunity and equipment. Risk comes out of the matrix, before and after countermeasures. The same input always gives the same result.

Standardised, yet adaptable

Tailor the assessment for your organisation and add your own countermeasures and assumptions. Every assessment stays tied to the exact catalogue it was made with, so an auditor can reproduce it later.

Traceable by construction

Reports are generated, not written. Every risk, measure and residual decision links to the answer that caused it. Confirm which mitigations actually hold and see what changes. Quality checks point out what an auditor would question, before an auditor does.

Your data stays yours

Every report as PDF, and the whole assessment as JSON and XLSX, whenever you want it.

Planned

A self-contained archive that re-renders and recomputes without the platform.

Mapped to the regulation and the standards

Each requirement gets a verdict (addressed, partial, or not judgeable where nothing in the assessment is bound to it) with the measures and answers behind it.

Planned

The harmonised horizontal and vertical standards as they are published.

See it on one of your products.

Atrekos runs as a closed pilot with selected manufacturers. Join the waitlist and we will contact you when the next cohort opens.

Join the waitlist →Sign in to the pilot

Frameworks

The frameworks your assessments map to, as data, not rework.

The CRA's essential requirements are being translated into harmonised standards. Atrekos maps assessments to what is stable today and tracks the drafts as they move.

Status as of 2 October 2026

Full bar = in the product · Two-thirds = in pilot · One-third = planned · Dashed outline = tracking the draft

  • CRA

    Essential requirements, vulnerability handling and user information (Annex I and II)

    In the product

    In force; applies 11 Dec 2027

  • EN 40000 series

    Cybersecurity requirements for products with digital elements: vocabulary (-1-1), principles for cyber resilience (-1-2), vulnerability handling (-1-3), generic security requirements mapping to Annex I of the CRA (-1-4)

    Tracking the draft

    -1-1 and -1-2 approved (2 Oct 2026), publication pending; -1-3 in approval; -1-4 drafting, due 2027

  • ISA/IEC 62443 series

    Industrial automation and control system security; the product maps to part 4-2, component requirements, SL1–SL4

    In the product

    Published

  • IEC 63452

    Railway applications cybersecurity; succeeds CLC/TS 50701

    In pilot

    Final draft (FDIS); publication expected Q4 2026

  • EN 50770 series

    OT security profiles on IEC 62443 for the CRA product categories

    Tracking the draft

    New projects approved Oct 2025; 6 standards planned; drafting, CENELEC TC 65X

  • ETSI EN 303 645

    Cyber Security for Consumer Internet of Things: Baseline Requirements

    Planned

    Published

  • ETSI EN 304 xxx series

    17 vertical standards for the CRA's important product classes (Annex III): browsers, operating systems, routers, firewalls, VPNs and more

    Tracking the draft

    17 drafts in public enquiry; due 31 Dec 2026 (proposed)

Mapping an assessment to a standard is a projection of your assessment, not a certificate. No CRA harmonised standard has been cited in the Official Journal yet, so no tool can offer a presumption of conformity.

In force now

Reporting has been mandatory since 11 September 2026.

If you place a product with digital elements on the EU market, an actively exploited vulnerability or a severe incident is reportable from the moment you become aware of it. This applies to products already on the market. You report once, and it reaches the coordinating CSIRT and ENISA together.

An actively exploited vulnerability

Art. 14(2)

Early warning
24 hoursfrom becoming aware of it
Notification
72 hoursfrom becoming aware of it
Final report
14 daysfrom a corrective or mitigating measure becoming available

A severe incident affecting the product's security

Art. 14(4)

Early warning
24 hoursfrom becoming aware of it
Notification
72 hoursfrom becoming aware of it
Final report
one monthfrom the incident notification

Article 14(8) also requires you to inform the impacted users of the product, and where appropriate all users, about the vulnerability or incident.

Where it goes

One submission, through the Single Reporting Platform that ENISA operates under Article 16. Registration is per manufacturer and the coordinating CSIRT validates it, so it is worth doing before you need it.

ENISA's Single Reporting Platform page ↗

Atrekos does not file reports. A reported vulnerability changes your risk assessment; Atrekos re-runs it and shows you what moved.

The clock

The CRA calendar: what applies already, and what applies from 11 December 2027.

Some of these dates are in the regulation. Some are proposed and have already moved once. Some have passed. The page says which is which.

  1. 10 December 2024

    In the regulation

    Entry into force

    Regulation (EU) 2024/2847 enters into force.

  2. 11 June 2026

    In the regulation

    Notified bodies

    Chapter IV applies: conformity assessment bodies can be notified.

  3. 11 September 2026

    In the regulation

    Reporting duties in force

    Reportable since this date, for products already on the market. The deadlines are in the reporting section.

  4. Today

  5. 31 October 2026

    Proposed

    Horizontal core standards due

    The principles and risk-process standard and the vulnerability-handling standard, under the Commission's draft amendment to the standardisation request.

    Originally 30 August 2026

  6. 31 December 2026

    Proposed

    Vertical standards due

    Product-category standards for Annex III products.

    Originally 30 October 2026

  7. 2027

    Expected

    First citations in the Official Journal

    Presumption of conformity becomes available where a cited standard is applied in full.

  8. 30 October 2027

    In the regulation

    Remaining horizontal standards due

    Technical measures, including the generic security controls. Date from the standardisation request.

  9. 11 December 2027

    In the regulation

    Full application

    Annex I essential requirements, technical documentation, conformity assessment and CE marking apply in full.

  10. After full application

    Ongoing

    The support period

    At least five years, or the expected time in use if that is shorter. Vulnerabilities must be handled for all of it.

What matters now

  1. Decide which products are in scope, and in which class

    Default, important class I or II, or critical. The class decides the conformity route and who has to be involved.

    Atrekos: partly

    Atrekos suggests a class from the target of evaluation you describe. The decision stays yours.

  2. Do the risk assessment now, against the regulation text

    Do not wait for the harmonised standards. An assessment done against Annex I today is what the standards will be measured against.

    Atrekos: yes

    This is the product.

  3. Build the technical documentation around it

    Annex VII puts the risk assessment inside the file, next to the architecture, the vulnerability-handling procedures and the support-period reasoning.

    Atrekos: partly

    Atrekos produces the assessment and its projections, not the whole file.

  4. Stand up vulnerability handling and the reporting path

    Article 14 applies now. Annex I Part II binds from 11 December 2027, and the 24-hour clock starts when you become aware, not when you are ready.

    Atrekos: partly

    Atrekos tracks Annex I Part II status; reporting and SBOM are outside it.

  5. Plan the support period and how the assessment stays current

    Decide now how a change is re-assessed, and who does it.

    Atrekos: yes

    Re-run, diff, clone.

  6. If the product is class II or critical, talk to a notified body early

    Third-party conformity assessment takes time and the bodies are only being notified since June 2026.

    Atrekos: yes

    The third-party module is built for that conversation.

Get early access

Atrekos is running as a closed pilot with selected manufacturers. Join the waitlist with your work address and, if you like, your company, and we will contact you when the next cohort opens.

The operator named in the imprint collects your address to write to you when a place opens, and for nothing else. Withdraw at any time by replying to any mail from us.

ImprintHow we handle personal data

Atrekos uses only its own, technically necessary cookies to operate.

Cookie policyPrivacy policy