EU Cyber Resilience Act compliance checklist for small manufacturers (2026–2027)

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) applies to virtually every product with digital elements sold on the EU market — hardware with embedded software, connected machines, desktop and mobile applications, firmware and on-premise software. If that describes your product, two deadlines now define your roadmap: 11 September 2026 (vulnerability and incident reporting) and 11 December 2027 (full compliance, including CE marking).

This checklist walks through what a small manufacturer actually needs to have in place, in the order that makes sense to do it. It is written for teams of 2–50 people without a dedicated compliance department.

Not sure the CRA applies to you at all? Run the free 3-minute scope check first — it tells you your risk class and which of the items below apply.

Step 1 — Confirm scope and risk class

Before anything else, establish two facts: whether your product is in scope, and which class it falls into.

In scope: products with digital elements placed on the EU market for commercial purposes — regardless of where your company is based. This includes hardware with software inside, standalone software that customers install, and remote data processing that a physical product depends on.

Out of scope: pure cloud services (SaaS without a required local component), non-commercial open source, and products covered by sector rules (medical devices, motor vehicles, aviation, marine, defence).

Risk classes: roughly 90% of products are default class and can self-assess. Products with security functions (VPNs, password managers, smart locks, network monitoring, consumer routers and similar) are Important Class I; industrial firewalls, hypervisors and tamper-resistant processors are Class II; hardware security modules, smart meter gateways and smartcards are critical and need European certification. Class I and above require harmonised standards or a notified body.

Action: document your scope determination and class in writing — it becomes part of your technical documentation later.

Step 2 — Build your Software Bill of Materials (SBOM)

The CRA requires you to identify and document the components in your product, including open-source dependencies, in a machine-readable SBOM covering at least the top-level dependencies.

For a small team the practical route is:

1. If you have a build pipeline: generate an SBOM automatically from your lockfiles or container images (CycloneDX and SPDX are the accepted formats; open-source tools like Syft do this in minutes).
2. If you build firmware or embedded systems without a modern pipeline: start with a manual component inventory — every library, RTOS, SDK and third-party module, with versions — and convert it to CycloneDX.
3. Regenerate the SBOM on every release. A stale SBOM fails its purpose: it is the basis for knowing whether a newly published vulnerability affects you.

Step 3 — Set up continuous vulnerability monitoring

An SBOM is only useful if something watches it. You must have a process that flags known vulnerabilities (CVEs) in your components and assesses whether they affect your product. For most small manufacturers this means matching your SBOM against public vulnerability databases (such as OSV and the NVD) on a scheduled basis, and recording the outcome — including "not affected" decisions.

This process is also what feeds your reporting obligation, which is the next item — and the first deadline.

Step 4 — Be ready to report within 24 hours (by 11 September 2026)

From 11 September 2026, manufacturers must notify ENISA and their national CSIRT of any actively exploited vulnerability and any severe incident affecting the security of the product:

• Early warning within 24 hours of becoming aware
• Vulnerability/incident notification within 72 hours with known details
• Final report within 14 days (vulnerabilities) or one month (incidents)

Two details catch teams off guard. First, this applies to products already on the market today — not just new launches. Second, being "ready" means having the process rehearsed before an incident, not designed during one.

Minimum viable readiness:

• A named person (plus backup) responsible for reporting
• A one-page internal playbook: who assesses, who decides, who files, within which hours
• Draft notification templates with your product and company details pre-filled
• A monitored intake channel for vulnerability reports from third parties (a security@ address and a disclosure policy page)

Step 5 — Establish your vulnerability handling process

Beyond reporting, the CRA requires a documented vulnerability handling process for the product's support period (at least five years): how you receive reports, triage, fix, and distribute security updates — and updates must be available separately from feature updates, free of charge for the support period.

Write this down as a short policy (one to two pages is fine for a small team) and publish a coordinated vulnerability disclosure policy on your website.

Step 6 — Do the security risk assessment (security by design)

You must perform and document a cybersecurity risk assessment of the product, covering its intended use and reasonably foreseeable misuse, and design the product accordingly: no known exploitable vulnerabilities at release, secure default configuration, protection of data in transit and at rest where relevant, access control, and attack surface minimisation.

For an existing product, run this as a structured review: list interfaces and data flows, identify threats per interface, record mitigations or accepted risks. The output goes into your technical documentation.

Step 7 — Assemble the technical documentation

By 11 December 2027, every product needs a technical documentation file per Annex VII, including: product description and intended purpose, the risk assessment, the SBOM, the vulnerability handling process, test and verification evidence, and the EU Declaration of Conformity.

Note the language requirement: information and instructions for users must be provided in a language easily understood by users in the member states where you sell — for most manufacturers that means preparing user-facing documents in multiple EU languages.

Step 8 — CE marking and Declaration of Conformity

For default-class products, you self-assess: complete the documentation, sign the EU Declaration of Conformity, and affix the CE marking. Class I products must apply harmonised standards (once published) or involve a notified body; Class II always requires a notified body; critical products need European cybersecurity certification.

After 11 December 2027, a product with digital elements without CE marking under the CRA cannot legally be placed on the EU market. Fines reach €15 million or 2.5% of global turnover.

Step 9 — Keep it alive

CRA compliance is not a one-off project. Every release changes your SBOM; every new CVE may trigger assessment or reporting; documentation must reflect the current product. Plan for compliance as a recurring monthly activity, not an annual scramble.

Quick checklist summary

1. Scope + risk class determined and documented
2. SBOM per product, regenerated every release (CycloneDX/SPDX)
3. Continuous vulnerability monitoring against your SBOM
4. 24h/72h ENISA reporting playbook ready before 11 Sep 2026
5. Vulnerability handling + disclosure policy published
6. Security risk assessment documented
7. Technical documentation file (Annex VII) assembled
8. Declaration of Conformity + CE marking before 11 Dec 2027
9. Monthly compliance routine in place

Start with step 1: check your scope and risk class free in 3 minutes.