Can a small manufacturer really self-assess under the CRA without outside help?

Yes, for default-category products — internal control (Module A) requires no notified body. The work is producing and maintaining the evidence: SBOM, the Annex I checklist, vulnerability handling, technical documentation, and the signed declaration.

How long does self-assessment take?

It depends on how much of the Annex I checklist is already true of your product. Teams with an existing SBOM and update process mostly need to document; teams starting from nothing need to build the update/disclosure process first.

CRA guide

CRA self-assessment for a small IoT manufacturer, step by step

Most small connected-device makers land in the CRA's default category and can self-assess under internal control (Module A) — no notified body required. Here's the sequence, in the order the evidence actually gets built.

Step 1 — Confirm you're actually default category

Before assuming self-assessment applies, check your product against CRA Annex III. A handful of connected-device categories are explicitly “important” rather than default — including smart-home general-purpose virtual assistants; smart-home products with security functionality such as smart door locks, security cameras, baby monitors and alarm systems; internet-connected toys with social-interactive features (e.g. speaking or filming) or location tracking; and personal wearables with a health-monitoring purpose that aren't already covered by EU medical-device rules (Annex III, Class I).

If your device is on that list, it's on a stricter route than the one below — see “Do you need a notified body?”. If it isn't, you're default category: the roughly 90% majority, and the rest of this guide applies to you.

Step 2 — Generate an accurate SBOM

CRA Annex I, Part II, (1) expects a software bill of materials — a machine-readable inventory of your product's components, in a common format such as CycloneDX or SPDX. For firmware and embedded builds this means scanning the actual build artifact, not just a source manifest.

This is the first evidence artifact everything else builds on: you can't monitor for known vulnerabilities in components you haven't inventoried. Normproof's free OSS CLI and GitHub Action generate one from your build in CI.

Step 3 — Work through the Annex I, Part I checklist

Annex I, Part I sets out 13 product-level security properties. In practice this is the checklist a small team works through once per product, then keeps evidenced as it changes:

Made available without known exploitable vulnerabilities — Annex I, Part I, (2)(a)
Secure-by-default configuration, including the ability to reset to original state — (2)(b)
Vulnerabilities addressable through security updates — (2)(c)
Protection from unauthorised access (authentication / access management) — (2)(d)
Confidentiality of stored and transmitted data (encryption) — (2)(e)
Integrity of data, commands, programs and configuration — (2)(f)
Data minimisation — process only what's necessary — (2)(g)
Availability of essential functions, incl. resilience to denial-of-service — (2)(h)
Minimise negative impact on other devices or networks — (2)(i)
Limited attack surfaces, including external interfaces — (2)(j)
Exploitation-mitigation techniques to reduce incident impact — (2)(k)
Security-relevant logging and monitoring, with a user opt-out — (2)(l)
Secure deletion / portability of data and settings — (2)(m)

Step 4 — Set up vulnerability handling (Annex I, Part II)

Alongside the SBOM (Part II, (1) above), Part II expects an ongoing process, not a one-time check:

Address and remediate vulnerabilities without delay — (2)
Effective and regular security testing and review — (3)
Publicly disclose fixed vulnerabilities once a security update ships — (4)
A coordinated vulnerability disclosure (CVD) policy — (5)
A published contact address for vulnerability reports (e.g. security.txt) — (6)
Secure, authenticated distribution of updates — (7)
Security updates disseminated without delay and, ordinarily, free of charge — (8)

Step 5 — Compile the Annex VII technical documentation

Annex VII is the dossier that shows how you meet everything above: product description, design and vulnerability-handling processes, the risk assessment, standards applied, test reports, and a copy of your Declaration of Conformity. See the dedicated Annex VII checklist guide for the full breakdown.

Step 6 — Sign the Declaration of Conformity and affix CE

Once the evidence above exists, you sign the EU Declaration of Conformity (Annex V) under your sole responsibility and affix the CE marking. See the worked Declaration-of-Conformity example for what the signed document actually looks like.

Key points

Classify first — a handful of connected-device categories are “important”, not default (Annex III).
SBOM (CycloneDX/SPDX) is the foundational artifact — generate it before anything else.
13 product-level properties (Part I) + 7 vulnerability-handling practices (Part II) = the Annex I checklist.
Annex VII documentation and the Annex V declaration are the paperwork; the controls above are the actual work.

Frequently asked questions

Can a small manufacturer really self-assess under the CRA without outside help?: Yes, for default-category products — internal control (Module A) requires no notified body. The work is producing and maintaining the evidence: SBOM, the Annex I checklist, vulnerability handling, technical documentation, and the signed declaration.
How long does self-assessment take?: It depends on how much of the Annex I checklist is already true of your product. Teams with an existing SBOM and update process mostly need to document; teams starting from nothing need to build the update/disclosure process first.

General information about the EU Cyber Resilience Act — not legal advice. Normproof provides tooling and audit-ready evidence; the manufacturer self-declares conformity. For your specific product, run the free readiness check or consult a qualified advisor.