Cyber Resilience Act checklist work is no longer something a software team can defer to a compliance department that does not exist yet. The notification duties in Regulation (EU) 2024/2847 go live on 11 September 2026, the first harmonised standards are already circulating in draft, and the full regime — essential requirements, conformity assessment and CE marking — applies to every product placed on the EU market from 11 December 2027. If you write, build or ship software that reaches European customers, the clock is already running.
This guide is a working Cyber Resilience Act checklist for software developers: the engineers, tech leads and heads of engineering who will actually implement the controls, rather than the lawyers who will read the recitals. It walks the six workstreams in the order a development team should tackle them — scoping, secure development, SBOM, vulnerability handling, reporting readiness and documentation — with the dates, artefacts and common failure modes attached to each.
It also slots into a series. Our Cyber Resilience Act compliance guide for UK software companies covers the legal regime end to end, and our operational guide to Cyber Resilience Act reporting requirements goes deep on the 24-hour, 72-hour and 14-day clocks. This article is the engineering layer underneath both: what has to change in your codebase, your pipeline and your on-call rota.
Treat every item below as a ticket, not a paragraph. A Cyber Resilience Act checklist only reduces risk when each line has an owner, a deadline and evidence behind it — the same discipline you already apply to the DevOps practices running your delivery pipeline.
Table of contents
- Who Needs a Cyber Resilience Act Checklist
- Cyber Resilience Act Checklist Dates: What Applies When
- Step 1: Inventory and Classify Every Product You Ship
- Step 2: Meet the Secure Development Requirements
- Step 3: Produce and Maintain a Software Bill of Materials
- Step 4: Stand Up Vulnerability Handling That Would Survive an Audit
- Step 5: Wire the 24-Hour Reporting Muscle Before September
- Step 6: Assemble the Technical File, Declaration and CE Mark
- Your 16-Month Cyber Resilience Act Checklist Plan
- Cyber Resilience Act Checklist Mistakes Developers Make
- Cyber Resilience Act Checklist FAQs
- References
Who Needs a Cyber Resilience Act Checklist
Manufacturers, and why developers inherit the work
The regulation places its duties on the “manufacturer” — anyone who develops or has developed a product with digital elements and places it on the EU market under their own name or trademark, whether for payment or free of charge. In a software business that legal label lands on engineering. The essential requirements are cybersecurity practices baked into development, the vulnerability duties are operational practices, and the technical file is largely engineering documentation. A Cyber Resilience Act checklist is therefore a development artefact first and a legal one second.
UK and non-EU developers are squarely in scope
The test is market access, not establishment. A UK, US or Indian software company selling into Germany, Ireland or France owes the same duties as a vendor in Berlin. Brexit changed nothing here: if your installable product, firmware, SDK or on-premise server software is placed on the EU market, the regulation applies to you, and the parallel UK Cyber Security and Resilience Bill is moving the domestic regime in the same direction.
Products with digital elements, in plain terms
Scope covers software or hardware whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. That includes desktop applications, mobile apps, firmware, libraries and SDKs shipped commercially, IoT devices and the remote data processing your product needs to function. Pure SaaS with no product component generally sits under NIS2 instead — but an installable agent, a downloadable client or an embedded component pulls you back into CRA territory.
Open-source software gets a carve-out with edges
Open-source developed or supplied outside a commercial activity is out of scope, and non-profit “open-source stewards” get a light-touch regime. The edges cut quickly, though: monetising support, hosting a paid tier, or shipping a community edition under your trademark can all make you a manufacturer. Enumerate everything that carries your name, not just everything that carries an invoice.
What a Cyber Resilience Act checklist should exclude
Cars, medical devices, aviation and marine equipment follow their own sectoral rules, and pure services without a product component follow NIS2. If your entire estate is genuinely out of scope, document that conclusion and revisit it at every major release — scope creep in a product line is how out-of-scope businesses quietly become in-scope ones.
Cyber Resilience Act Checklist Dates: What Applies When
The four Cyber Resilience Act checklist dates that matter
The regulation entered into force on 10 December 2024 with staggered application. Conformity assessment body provisions applied from 11 June 2026. The reporting obligations in Article 14 apply from 11 September 2026. The full regime — Annex I essential requirements, conformity assessment, CE marking and the technical file — applies from 11 December 2027. Your Cyber Resilience Act checklist needs to treat these as three different projects with three different deadlines, not one distant compliance event.
| Date | What applies | Developer action |
|---|---|---|
| 11 June 2026 | Notified body provisions | None direct; assessment capacity starts building |
| 27 July 2026 | Commission practical guidance and FAQ published | Use it to settle scope and classification questions |
| 11 September 2026 | Article 14 reporting duties | 24-hour early warning capability must be live |
| 11 December 2027 | Full regime: Annex I, conformity, CE marking | Products placed on the market must be conformant |
Reporting arrives fifteen months before conformity
The strangest consequence of the timetable is that you can owe a regulator a 24-hour notification about a product that is not yet required to be conformant. From September 2026, an actively exploited vulnerability or a severe incident starts a legal clock regardless of how far your Annex I work has progressed. That is why reporting readiness sits in the middle of this Cyber Resilience Act checklist rather than at the end.
Standards and guidance are landing now
The European Commission published practical guidance on 27 July 2026 to help manufacturers apply the regulation, alongside a living FAQ. Seventeen draft standards prepared under the standardisation request are open for comment in August 2026, with the two horizontal standards — secure development and vulnerability handling — due first. Following a harmonised standard, once cited, gives a presumption of conformity, so track the drafts even before they are final.
Measured from entry into force in December 2024, the gaps between the milestones show how compressed the remaining runway is.
Step 1: Inventory and Classify Every Product You Ship
Build the Cyber Resilience Act checklist inventory first
Every Cyber Resilience Act checklist starts with a list. Enumerate everything placed on the EU market under your name: applications, agents, firmware images, SDKs, libraries sold or licensed commercially, free tiers and community editions. For each, record the intended purpose, the data connections it makes, the platforms it runs on and whether any remote processing is essential to its function. This inventory drives every later decision, and it is the first thing the Commission’s July 2026 guidance tells you to settle.
The default category covers most software
Roughly nine in ten products fall into the default category, where the manufacturer self-assesses conformity against Annex I. No notified body, no certification — but the same essential requirements, the same technical file and the same vulnerability duties as everyone else. Self-assessment is a lighter route, not a lighter standard.
Important and critical products carry heavier routes
Annex III lists “important” products in two classes — Class I includes categories such as browsers, password managers, VPNs and network management tools; Class II includes hypervisors, container runtimes, firewalls and tamper-resistant microprocessors. Class I products can follow harmonised standards fully or use third-party assessment; Class II requires a notified body. Annex IV’s “critical” products, such as smart meter gateways and secure elements, may need European certification. Classify early: the route determines both cost and lead time.
| Category | Examples | Conformity route |
|---|---|---|
| Default | Most business and consumer software | Manufacturer self-assessment |
| Important, Class I | Browsers, password managers, VPNs | Harmonised standards in full, or third-party assessment |
| Important, Class II | Hypervisors, firewalls, container runtimes | Notified body assessment |
| Critical | Smart meter gateways, secure elements | European cybersecurity certification where mandated |
Decide the support period per product
For each product, set and document a support period — at least five years unless the product is genuinely expected to be used for less. During it you must provide free security updates. The period appears on the product information users see, so it is a commercial commitment as well as a Cyber Resilience Act checklist entry.
Step 2: Meet the Secure Development Requirements
Design, develop and produce with security in mind
Annex I Part I is the core of any Cyber Resilience Act checklist: products must be made available with no known exploitable vulnerabilities and with a secure-by-default configuration. Practically, that means a release gate that checks your dependency scan results before shipping, hardening defaults so the out-of-box state is the safe state, and recording the risk assessment that justified each design decision. The risk assessment is not optional paperwork: it must be maintained and included in the technical documentation.
Shrink the attack surface deliberately
The essential requirements ask for products designed to limit attack surfaces, protect the confidentiality and integrity of data, minimise the data they process, and be resilient against denial-of-service. For a development team this converts into concrete tickets: close unused ports and services, encrypt stored and transmitted data by appropriate mechanisms, strip debug interfaces from production builds, and rate-limit anything exposed to a network.
Ship a secure update mechanism
Every in-scope product needs a way to receive security updates — separated from feature updates where technically feasible, delivered by default with user opt-out, and protected against tampering. If your product cannot update itself safely today, this is usually the single largest engineering item on the whole Cyber Resilience Act checklist, and the one with the longest lead time. Start it first.
Map the work onto frameworks you already use
None of this is exotic. NIST’s Secure Software Development Framework, the NCSC’s secure development collection and IEC 62443 already cover most of Annex I Part I. Map your existing controls onto the Annex, mark the gaps, and let the forthcoming horizontal standard on secure development become the spine of your Cyber Resilience Act checklist evidence once it is cited. Teams practising continuous delivery will find most gaps sit in documentation, not engineering.
Step 3: Produce and Maintain a Software Bill of Materials
What the regulation actually requires
The vulnerability handling requirements oblige you to identify and document components in your products, including a machine-readable software bill of materials covering at least the top-level dependencies. You do not have to publish it — you must be able to produce it for market surveillance authorities and keep it current. A stale SBOM fails the purpose of the duty, so on a Cyber Resilience Act checklist this item belongs in the build pipeline, not in a quarterly spreadsheet exercise.
Choose a format and automate it
CycloneDX and SPDX are the two machine-readable formats that matter; both have mature tooling that can emit an SBOM on every build. Pick whichever your ecosystem supports best and generate per release artefact, so each shipped version has a matching manifest.
| Factor | CycloneDX | SPDX |
|---|---|---|
| Origin | OWASP, security-focused | Linux Foundation, licensing heritage |
| Standardisation | ECMA-424 | ISO/IEC 5962 |
| Strengths | Vulnerability exchange, services, lightweight | Licence compliance, broad ecosystem adoption |
| Typical fit | Security and CRA workflows | Organisations with licence-audit tooling in place |
Turn the SBOM into a monitoring feed
An SBOM earns its keep when it is matched against vulnerability intelligence continuously. Wire dependency alerts into the same intake as your disclosure inbox, because a known exploited vulnerability in a component you ship can trigger the assessment duty — and possibly the reporting duty — the moment you become aware of it. This is where the cybersecurity value and the compliance value of the exercise converge on the same pipeline.
Handle third-party and open-source components with care
When you integrate a component, exercise due diligence: check its maintenance status, known vulnerabilities and update cadence. If you modify an open-source component and ship it, the modified component becomes your responsibility. Record component provenance in the SBOM so that, when a component-level advisory lands, you can answer “which of our products ship this?” in minutes rather than days.
Step 4: Stand Up Vulnerability Handling That Would Survive an Audit
Publish a coordinated vulnerability disclosure policy
Annex I Part II requires a published coordinated vulnerability disclosure policy with a contact address for reporting — the first vulnerability handling item on any Cyber Resilience Act checklist. Make the address a monitored, timestamped queue on a rota, not a personal inbox. Awareness under the regulation is organisational, so an unread report in a shared mailbox is still awareness, and the intake timestamp is the evidence that protects you.
Fix and distribute without delay, free of charge
Vulnerabilities must be addressed and remediated without delay, with security updates distributed free of charge and, where technically feasible, separately from functionality updates. Users must be informed through advisories describing the issue and the corrective action. Draft the advisory template now, in peacetime, and agree who signs it off — the review loop is what usually burns the clock.
Test regularly and document what you tested
The regulation expects effective and regular tests and reviews of product security. Fold your existing scanning, code review and penetration testing cadence into documented evidence with dates, scope and findings. An auditor’s question will not be “do you test?” but “show me the last three cycles” — a Cyber Resilience Act checklist answer needs artefacts, not assurances.
Keep updates available for the long tail
Once issued, security updates must remain available for at least ten years or the remainder of the support period, whichever is longer. That has infrastructure implications — signed archives, stable download endpoints, version metadata — which is why this Cyber Resilience Act checklist item belongs on the engineering plan this year rather than in a 2027 scramble.
Step 5: Wire the 24-Hour Reporting Muscle Before September
Two triggers, three clocks
From 11 September 2026 you must notify an actively exploited vulnerability in your product, or a severe incident affecting its security, through the single reporting platform: an early warning within 24 hours of awareness, a fuller notification within 72 hours, and a final report within 14 days for exploited vulnerabilities or one month for incidents. The full mechanics — the triggers, the platform, the CSIRT choice, who may file — are in our dedicated reporting guide linked above, and they deserve a rehearsal, not just a read.
The checklist items that make reporting survivable
Four items close most of the gap: register on the reporting platform and test the credentials; name two authorised submitters with out-of-hours access; timestamp your disclosure intake; and pre-draft the early-warning template so an engineer can complete it at 3 a.m. A Cyber Resilience Act checklist that stops at “be ready to report” without naming the people and credentials has not actually reduced the risk.
Users must be told as well
Alongside the regulator, impacted users must be informed without undue delay about the incident or vulnerability and any corrective measures. Fold user notification into the same incident runbook — one Cyber Resilience Act checklist entry, not three — so the advisory, the 72-hour notification and the customer email are drafted together rather than sequentially.
Step 6: Assemble the Technical File, Declaration and CE Mark
The technical documentation is an engineering deliverable
Annex VII’s technical file includes the product description, the risk assessment, the vulnerability handling process, the SBOM, test reports and the standards applied. Most of it should fall out of the Cyber Resilience Act checklist work you did in steps two to five. Keep it per product, versioned, and retained for at least ten years after placing the product on the market.
Declaration of conformity and the CE mark
Before placing a product on the market from 11 December 2027, you draw up an EU declaration of conformity and affix the CE marking. For default-category products this is self-assessment; for important and critical categories the assessment route from step one applies. Products already on the market before that date are not retrofitted — but any substantial modification afterwards makes the modified product a new placement, and the duties attach.
Use harmonised standards as your evidence spine
Once the horizontal and vertical harmonised standards are cited in the Official Journal, conforming to them gives a presumption of conformity. Adopt the drafts as internal targets now: aligning early is cheaper than re-papering evidence later, and the two horizontal standards land first precisely because every manufacturer needs them.
Your 16-Month Cyber Resilience Act Checklist Plan
Now to December 2026: reporting and inventory
Between now and the end of 2026, complete the product inventory, settle classification using the Commission guidance, stand up the disclosure intake and reporting capability, and get SBOM generation into the build. September’s deadline makes the reporting workstream immovable; the rest of this Cyber Resilience Act checklist has slack, but the inventory gates everything downstream.
First half of 2027: close the Annex I gaps
Run the Cyber Resilience Act checklist gap assessment against Annex I Part I, prioritise the secure update mechanism and secure-default work, and begin drafting the technical file per product. Products needing a notified body should book assessment slots early — capacity will tighten as December 2027 approaches, and Class II queues will be the longest.
Second half of 2027: evidence, declaration, mark
Finalise documentation, complete conformity assessment, sign declarations and affix CE markings for everything that will be placed on the market from 11 December 2027. Leave a full quarter for the paperwork pass: teams consistently underestimate how long evidence collation takes when it was not generated automatically along the way.
Cyber Resilience Act Checklist Mistakes Developers Make
Treating December 2027 as the first deadline
The reporting duties land fifteen months earlier. A team that parks the whole programme until 2027 will be non-compliant by October 2026 if a single actively exploited vulnerability surfaces. Sequence the Cyber Resilience Act checklist around September 2026 first.
Assuming SaaS means out of scope
Pure cloud services generally fall under NIS2 — but agents, clients, on-premise components and remote processing essential to a product’s function are in scope. Map the boundary product by product on the Cyber Resilience Act checklist instead of ruling the estate out in one line.
Building the SBOM once and letting it rot
A point-in-time SBOM satisfies nobody. The duty is to identify and document components for the products you ship, and the value is continuous matching against advisories. If the SBOM is not regenerated by the pipeline on every release, it will drift within a sprint.
Forgetting the free and community editions
Anything placed on the market under your trademark counts, paid or not. Community editions, free tiers and branded SDKs belong on the inventory, and their support periods need deciding too.
Ignoring the penalty asymmetry
Breaching the essential requirements or the reporting duties carries fines up to €15 million or 2.5% of worldwide turnover; other obligations reach €10 million or 2%; supplying misleading information to authorities reaches €5 million or 1%. The most severe band covers precisely the engineering duties on this list — which is the strongest argument for owning it in engineering.
| Breach | Maximum fine | Turnover alternative |
|---|---|---|
| Essential requirements, Articles 13 and 14 | €15 million | 2.5% worldwide annual turnover |
| Other obligations | €10 million | 2% worldwide annual turnover |
| Misleading information to authorities | €5 million | 1% worldwide annual turnover |
Cyber Resilience Act Checklist FAQs
Does the Cyber Resilience Act checklist apply to internal tools?
Software developed for your own use and never placed on the EU market is out of scope. The moment an internal tool is offered to customers — sold, licensed or bundled — it becomes a product with digital elements and joins the inventory.
We only ship a JavaScript library. Are we really in scope?
If the library is placed on the EU market in the course of a commercial activity — sold, dual-licensed, or supporting a paid product — then yes. A genuinely non-commercial open-source project is not, though contributing companies should check whether their involvement crosses the commercial line.
What is the single most urgent item this quarter?
Reporting readiness. Register on the single reporting platform when onboarding opens to you, name authorised submitters, timestamp your disclosure intake and rehearse the 24-hour early warning. Every other Cyber Resilience Act checklist item has runway; this one has a September date on it.
Do we need to publish our SBOM?
No. The SBOM must exist in machine-readable form, cover at least the top-level dependencies and be available to market surveillance authorities on request. Publishing is your choice; keeping the Cyber Resilience Act checklist item maintained is not.
How long must we support a product?
At least five years unless it is genuinely expected to be used for a shorter time, with free security updates during the period, and updates already issued kept available for at least ten years. State the period in the product information.
Can we keep selling a product we know will never be conformant?
Only until 11 December 2027 for new placements. After that, placing a non-conformant product on the EU market risks the top fine band and orders to withdraw or recall. The realistic options are remediation, replacement or a managed exit from the EU market for that product line.
Does ISO 27001 certification cover the Cyber Resilience Act checklist?
No. ISO 27001 evidences organisational security management and helps enormously with the process duties, but it does not deliver product-level conformity, an SBOM, a technical file or the reporting capability. Treat certifications as accelerants, not substitutes.
Where should a five-person team start?
The inventory, then the disclosure policy and reporting readiness, then SBOM automation. Those three cost days rather than months, close the September 2026 exposure, and generate most of the evidence the technical file needs later.
References
Regulation (EU) 2024/2847 — the Cyber Resilience Act
European Commission — Cyber Resilience Act
European Commission — Guidance to Support Timely Cyber Resilience Act Implementation
NIST — Secure Software Development Framework
NCSC — Secure Development and Deployment Guidance
CISA — Software Bill of Materials
