the whole job

Cyber Resilience Act: the whole job, in order

The Cyber Resilience Act puts duties on products, and it reaches the people who make, import and sell them. Here is the job as a plan: five phases, in the order that holds up, with who carries each step, what it produces and the proof it leaves.

last checked 2 November 2026

how to read this plan

Each step has an owner, a kind of work and two outputs. The kinds of work are different jobs: choices that someone with authority signs, things the product team builds, and checks that someone keeps running. Two dates matter. The reporting duty for exploited vulnerabilities and severe incidents has applied since 11 September 2026, including to products already on the market. The product requirements, the technical file and the conformity assessment apply from 11 December 2027. So the reporting routine comes first in practice, even though building security in comes first in the product. Under each step a small note names the legal basis, or says practice where no text sets it.

  • decide and documentchoices, policies and records that someone with authority signs
  • build and configuresystems, settings and procedures that make the choice real
  • prove and operatechecks, logs and records that show it keeps working
01

know your role and your product

Find out which of your products are covered, what role you play for each and which band each falls in.

  1. list the products that are in scope

    List every hardware or software product whose intended purpose or reasonably foreseeable use includes a connection to a device or a network, direct or indirect. Include products you sell free of charge and products already on the market, because the reporting duty reaches those too.

    • owner legal or DPO
    • decide and document
    what it produces
    a product register with the reason each product is in or out of scope
    the proof it leaves
    the register, dated and approved by management

    the work page

    basis CRA Art. 2(1); CRA Art. 69(3)

  2. decide your role for each product

    Mark each product as made by you, imported by you or distributed by you. An importer or distributor counts as a manufacturer when it sells a product under its own name or trademark, or substantially modifies one already on the market.

    • owner legal or DPO
    • decide and document
    what it produces
    a role entry per product, with the reasoning
    the proof it leaves
    the register entries, reviewed when a product or a contract changes

    basis CRA Art. 3(13), 3(16), 3(17); CRA Art. 21

  3. place each product in a band

    Check the core function of each product against the lists of important products (class I and class II) and critical products. Most products fall in the default band. The band decides how strict your conformity assessment must be.

    • owner head of IT
    • decide and document
    what it produces
    a band entry per product with the annex category checked
    the proof it leaves
    the register entries and the notes behind them

    basis CRA Art. 7(1), 8(1); CRA Annex III

  4. name an owner and note the dates

    Name one accountable owner per product line and one person who runs reporting. Write the dates beside each product: reporting since 11 September 2026, the rest from 11 December 2027, and for products placed on the market earlier, the requirements only after a substantial modification. Find your national market surveillance authority and its penalty rules.

    • owner board
    • decide and document
    what it produces
    an owner per product line and a date sheet
    the proof it leaves
    a board decision naming the owners, and the date sheet with its sources

    basis CRA Art. 71(2); CRA Art. 69(2)

you are done with this phase when you can show a product register with a role, a band and an owner for every product.
02

build security into the product

Turn the product requirements into things the team designs, builds and tests.

  1. assess the cybersecurity risks of each product

    Analyse the risks from the intended purpose, the foreseeable use, the conditions of use and the time the product is expected to be in use. Say which product requirements apply and how you meet them, and justify any that do not apply. Keep the assessment up to date during the support period.

    • owner head of IT
    • decide and document
    what it produces
    a documented cybersecurity risk assessment per product
    the proof it leaves
    the assessment, dated, with its updates, filed in the technical documentation

    the control: risk-register

    basis CRA Art. 13(2), 13(3), 13(4)

  2. turn the product requirements into design rules

    Go through the list in the first part of the annex and make each item a testable rule for your team: no known exploitable vulnerabilities at release, secure defaults with a reset, access control, protection of stored and sent data, data minimisation, a limited attack surface, logging, and a way to remove user data securely. Where an item does not apply, the risk assessment says why.

    • owner head of IT
    • build and configure
    what it produces
    a requirement-by-requirement checklist per product, with owners
    the proof it leaves
    the checklist, signed off before each release

    the control: secure-development

    basis CRA Art. 13(1); CRA Annex I

  3. check third-party and open-source components

    Exercise due diligence before you integrate a component so that it does not weaken the product, open-source components included. When you find a vulnerability in a component, report it to whoever maintains it and share your fix where appropriate.

    • owner head of IT
    • build and configure
    what it produces
    a component intake rule and a list of components with their checks
    the proof it leaves
    intake records and the reports sent to component maintainers

    the control: sbom-supply-chain

    basis CRA Art. 13(5), 13(6)

  4. make security updates deliverable

    Build a secure way to distribute updates, with automatic updates on by default where that fits the product and a clear way to opt out. Where technically feasible, ship security updates apart from functionality updates, free of charge, with a message that tells users what to do.

    • owner head of IT
    • build and configure
    what it produces
    an update mechanism and an update policy
    the proof it leaves
    a test of the update route and the policy text

    basis CRA Annex I

  5. test the security of the product and keep testing

    Run effective security tests and reviews before each release and on a regular rhythm afterwards. Record what you found, what you fixed and what you accepted.

    • owner head of IT
    • prove and operate
    what it produces
    a test plan and test reports per product
    the proof it leaves
    the reports, dated, kept for the technical documentation

    the control: secure-development

    basis CRA Annex I

you are done with this phase when you can show, for each product, a risk assessment, a design that follows the requirements and test results.
03

handle vulnerabilities and report

Be able to receive a vulnerability report, fix the flaw and send the 24 hour, 72 hour and final reports in time.

  1. publish a disclosure policy and a contact point

    Publish a coordinated vulnerability disclosure policy and a contact address for reports, and name a single point of contact that users can find easily and can reach by the means they prefer, not only through automated tools. Put both in the user information.

    • owner head of IT
    • build and configure
    what it produces
    a published policy, a monitored contact address and a single point of contact
    the proof it leaves
    the live policy page and a test report received and logged

    the work pagethe control: vulnerability-disclosure

    basis CRA Art. 13(8), 13(17); CRA Annex I

  2. set up triage and fixing

    Record every vulnerability you learn about, together with information from third parties, in a way that fits the nature and the risks of the product. Address and remediate each one without delay and publish information about fixed vulnerabilities once the update is out.

    • owner head of IT
    • build and configure
    what it produces
    a triage routine, a vulnerability record and a fix policy
    the proof it leaves
    the record with dates from report to fix, and the published advisories

    the work pagethe control: vulnerability-management

    basis CRA Art. 13(7), 13(8); CRA Annex I

  3. agree what counts as reportable

    Write down, for your own products, what an actively exploited vulnerability is (reliable evidence that someone has exploited it without the owner's permission) and what a severe incident is. Decide who may judge this at any hour, because the clock starts when you become aware.

    • owner legal or DPO
    • decide and document
    what it produces
    a one-page reporting rule with named decision makers
    the proof it leaves
    the rule, approved by management

    basis CRA Art. 3(42), 14(5)

  4. prepare the three reports

    Each case needs an early warning within 24 hours of becoming aware, a notification within 72 hours and a final report. For a vulnerability the final report is due no later than 14 days after a fix or mitigation is available, and for an incident within one month of the 72 hour notification. Prepare a template for each, and decide who may send it.

    • owner legal or DPO
    • build and configure
    what it produces
    three templates for vulnerabilities, three for incidents, and a rule for who sends them
    the proof it leaves
    the templates and a dry run

    the work pagethe control: incident-management

    basis CRA Art. 14(2), 14(4)

  5. work out where your reports go

    Reports go through the single reporting platform that ENISA runs, to the CSIRT of the country of your main establishment in the EU, which is where decisions on the cybersecurity of your products are mostly taken. If you have no establishment in the EU, the text sets an order of fallbacks, starting with your authorised representative. Record the country and the route.

    • owner legal or DPO
    • decide and document
    what it produces
    a note naming the receiving CSIRT and the submission route
    the proof it leaves
    the note, with the date and the reasoning

    basis CRA Art. 14(7); CRA Art. 16(1)

  6. prepare to tell affected users

    After you become aware of an exploited vulnerability or a severe incident, inform the impacted users, and all users where appropriate, with the steps they can take. Where appropriate, use a structured, machine-readable format. If you do not tell them in time, the CSIRT may do it for you.

    • owner head of IT
    • build and configure
    what it produces
    a user notice template and a way to reach users of each product
    the proof it leaves
    the template and a test send

    basis CRA Art. 14(8)

  7. rehearse a report on a real product

    Run an exercise with an invented exploited vulnerability in one of your products. See whether the right people can decide, send an early warning inside 24 hours and tell users. Write down what broke and who fixes it.

    • owner everyone
    • prove and operate
    what it produces
    a rehearsal report with actions and owners
    the proof it leaves
    the report and the action list, closed or dated

    basis working practice. No legal text sets this.

you are done with this phase when you can show a disclosure policy, a named reporting lead, ready templates and a record of a rehearsal.
04

set the support period and build the technical file

Decide how long you support each product, keep the proof in a technical file and complete the conformity assessment for the product's band.

  1. decide the support period and write down why

    Set the support period to match how long the product is expected to be in use, taking account of reasonable user expectations and the nature of the product. It is at least five years, unless the product is expected to be used for less. Record what you considered, because it goes in the technical documentation.

    • owner board
    • decide and document
    what it produces
    a decision on the support period per product with its reasons
    the proof it leaves
    the decision, signed by management

    basis CRA Art. 13(8)

  2. state the end date at purchase

    State the end date of the support period, at least month and year, clearly where the customer buys. Where technically feasible, show users a notice when support ends. Keep each security update available for at least 10 years, or the rest of the support period if that is longer.

    • owner legal or DPO
    • build and configure
    what it produces
    an end date on the product page, packaging or contract, and an update retention rule
    the proof it leaves
    a screenshot or copy of the statement, and the retention rule

    basis CRA Art. 13(19); CRA Art. 13(9)

  3. produce and keep the software bill of materials

    Record the components of each product in a commonly used, machine-readable format that covers at least the top-level dependencies, and update it with the product. The authority can ask for it, and the Commission may specify the format later. Whether to give it to customers is your decision.

    • owner head of IT
    • build and configure
    what it produces
    a bill of materials per product release
    the proof it leaves
    the files, tied to release versions

    the control: sbom-supply-chain

    basis CRA Annex I; CRA Annex VII; CRA Art. 13(24)

  4. write the technical documentation

    Draw it up before the product goes on the market and update it during the support period. It holds a general description, the design and vulnerability handling processes, the risk assessment, the support period reasoning, the standards applied, the test reports and a copy of the declaration of conformity.

    • owner head of IT
    • build and configure
    what it produces
    a technical file per product
    the proof it leaves
    the file with a version history

    basis CRA Art. 31(1), 31(2); CRA Annex VII

  5. choose the conformity procedure for your band

    In the default band you can use internal control, among other routes. For class I important products you need a third-party route unless you applied standards or a certification scheme in full. For class II important products you need a third-party route or a certification scheme at least at the substantial level. For critical products the Commission may require a certification scheme.

    • owner legal or DPO
    • decide and document
    what it produces
    a recorded choice of procedure per product with the reasoning
    the proof it leaves
    the decision note

    basis CRA Art. 32(1), 32(2), 32(3), 32(4)

  6. complete the assessment, sign the declaration and mark the product

    Run the chosen procedure. When conformity is shown, draw up the declaration of conformity, which makes you responsible for compliance, and affix the marking. Ship a copy of the declaration, or a short version with the address of the full one, and keep the file and the declaration for at least 10 years or the support period if longer.

    • owner legal or DPO
    • prove and operate
    what it produces
    a signed declaration, the marking applied and a retention rule
    the proof it leaves
    the declaration, the assessment record and the retention rule

    basis CRA Art. 13(12), 13(13), 13(20); CRA Art. 28(4); CRA Art. 30(1)

  7. ship identification and user information with the product

    Give each product a type, batch or serial number, your name and contact details, and the user information from the second annex: single point of contact, intended purpose, end of support, and instructions for secure installation, updates and decommissioning. Keep it available for at least 10 years or the support period if longer.

    • owner head of IT
    • build and configure
    what it produces
    product labelling and a user information pack
    the proof it leaves
    the pack and a labelled sample

    basis CRA Art. 13(15), 13(16), 13(18); CRA Annex II

  8. keep each product in conformity over time

    Put procedures in place so that products from a series stay in conformity, including when standards or your own process change. If you learn that a product or your process does not conform, take corrective measures at once or withdraw or recall the product. Answer reasoned requests from the authority with the documents it needs.

    • owner head of IT
    • prove and operate
    what it produces
    a change and conformity check routine and a corrective action log
    the proof it leaves
    the log and the check records

    basis CRA Art. 13(14), 13(21), 13(22)

you are done with this phase when you can hand a market surveillance authority a technical file, a declaration of conformity and the support period for each product.
05

ask your suppliers and answer your buyers

Check what you receive from the chain, ask your own suppliers for what the law makes you need and be ready to answer your customers.

  1. if you import, check what the manufacturer gives you

    Before you place a product on the market, check that the manufacturer ran the conformity procedure, drew up the technical documentation, applied the marking and supplied the declaration and user information. If you think it does not conform, do not place it on the market. Show your name and contact on the product, and keep a copy of the declaration for at least 10 years or the support period if longer.

    • owner procurement
    • build and configure
    what it produces
    an import check list per product and a record of each check
    the proof it leaves
    completed checks and the stored declarations

    basis CRA Art. 19(2), 19(3), 19(4), 19(6)

  2. if you distribute, verify before you sell

    Act with due care. Check that the product carries the marking and that the manufacturer and importer have supplied the required documents. If you have reason to believe a product does not conform, hold it back, and tell the manufacturer about any vulnerability you learn of.

    • owner procurement
    • build and configure
    what it produces
    a distributor intake check
    the proof it leaves
    completed checks and the contact log with manufacturers

    basis CRA Art. 20(2), 20(3), 20(4)

  3. ask the suppliers of your components the right questions

    Ask each supplier whether it is a manufacturer under the Act and in which band, what its support period end date is, who to contact about vulnerabilities, how it tells you about exploited vulnerabilities, and whether it gives a bill of materials. If you integrate its product into yours, ask for the information you need to meet the requirements and the documentation duty.

    • owner procurement
    • build and configure
    what it produces
    a standard supplier question set and the answers received
    the proof it leaves
    the question set, the answers and the contract terms agreed

    the work pagethe control: supplier-management

    basis CRA Art. 13(5); CRA Annex II

  4. prepare answers for your buyers

    Public buyers have to take the product requirements and your ability to handle vulnerabilities into account when they procure, and buyers that fall under the NIS2 Directive look at their supply chain. Prepare one pack: your role and band, support end date, disclosure policy and contact, declaration of conformity, how you inform users and your position on sharing a bill of materials.

    • owner legal or DPO
    • build and configure
    what it produces
    a customer answer pack, versioned
    the proof it leaves
    the pack and a log of the questions customers asked

    basis CRA Art. 5(2); NIS2 Art. 21(2)(d)

  5. watch for standards, formats and guidance

    Check the Official Journal and the Commission's pages on a rhythm for harmonised standards, for the format of the bill of materials and for the format and procedure of reports. The Commission's guidance of 27 July 2026 is not binding. Update your procedures when something changes.

    • owner legal or DPO
    • prove and operate
    what it produces
    a watch list with an owner and a check rhythm
    the proof it leaves
    the watch list with dates of each check and what changed

    basis CRA Art. 13(24); CRA Art. 14(10)

you are done with this phase when you can show a supplier question set with answers, and an answer pack ready for a customer.

who carries what

The same steps, grouped by the person who has to act.

legal or DPO

head of IT

board

everyone

procurement

controls you will need

Each control has its own page: what it is, what to look for, where it goes wrong and the proof it leaves.

    check it yourself

    your next step

    List every product you make, import or sell, mark your role for each, and check that someone could send a 24 hour early warning today.

    see the dates