NEW: CRA vulnerability reporting begins 11 September 2026 — is your product ready? Check now →

The CRA Compliance Guide

Seven steps from 'we ship a digital product' to a signed Declaration of Conformity and CE-marked product. Pragmatic, prioritised, and based on the regulation text plus ENISA guidance.

01

Classify your product

Default / Class I / Class II — your category determines the conformity assessment route.

Start by checking Annex III, which lists Class I (Important) and Class II (Critical) categories. If your product is on neither list, it is a default product.

Default products self-assess. Class I needs a notified body unless fully harmonised standards are applied. Class II always requires a notified body.

Document the classification decision and the reasoning. Market-surveillance authorities will ask.

02

Run a gap analysis against the 21 essential requirements

Map your current security controls to Annex I, Part I. The gaps become your remediation backlog.

Build a simple matrix: requirement on one axis, your evidence on the other. For each cell, capture the control, the test that proves it, and any gap.

Common gaps for software: missing SBOM, no documented vulnerability disclosure policy, weak update mechanisms, no security-by-default flags.

Common gaps for hardware: factory-reset paths, secure-boot enforcement, signed firmware updates, attack-surface minimisation.

03

Generate and maintain an SBOM

A Software Bill of Materials is a hard requirement. Use CycloneDX or SPDX.

Generate the SBOM in your CI pipeline and treat it like an artefact: stored, versioned, signed, and reproducible.

Tools: Syft for containers, cyclonedx-bom for Python, cyclonedx-npm for Node, cyclonedx-gradle-plugin for JVM. The output format does not need to be exposed publicly — it must be available to authorities on request.

Keep the SBOM linked to the build that produced it. When a vulnerability is reported in a dependency, you need to find every shipped version that contained it within hours.

04

Implement coordinated vulnerability disclosure & management

A documented intake channel, an SLA for response, and an update mechanism.

Publish a /.well-known/security.txt file pointing at a triage email or form, plus a public PGP key if you want encrypted reports.

Define internal SLAs: time-to-acknowledge, time-to-triage, time-to-fix, time-to-disclose. Make them realistic — and stick to them.

Wire up your build/release pipeline so a security update can ship without a multi-week regression cycle. The CRA expects "without undue delay".

05

Draft your EU Declaration of Conformity

A simple, signed document referencing the regulation, your product, and your conformity route.

The DoC follows the template in Annex V. Required fields: product description, manufacturer details, statement of compliance with Regulation 2024/2847, conformity assessment procedure used, and any harmonised standards applied.

For default products, the DoC can be drafted internally. For Class II it must reference the notified body number.

Make the DoC machine-readable and link it from the product page. Many manufacturers publish it as a PDF inside a versioned /legal/cra-doc-vX.pdf URL.

06

Apply CE marking

Affix CE visibly to the product, packaging, or accompanying documents.

For physical products, CE marking goes on the product itself or its packaging.

For software, the CE marking and DoC reference must appear in the user-facing documentation, app-store listing, or the about screen.

Once CE is applied, you have legally declared conformity. Misrepresentation is one of the higher-tier fines.

07

Prepare for vulnerability and incident reporting

Detect, document, and report — within 24h, 72h, and 14 days from awareness.

Register your manufacturer profile on the ENISA Single Reporting Platform ahead of 11 September 2026. Don't wait for an incident.

Decide who is on the rotation, who has authority to submit, and what your internal cut-off line is for "actively exploited" — this is the trigger for the 24h clock.

Practice the workflow in a tabletop exercise. The first time you submit should not be in production.

CRA Compliance Checklist

A condensed, Annex-aligned list. Tick each item before you place the product on the EU market.

  • Identified every in-scope product on the EU market
  • Classified each product (Default / Class I / Class II)
  • Completed gap analysis against the 21 essential requirements
  • SBOM generated automatically on every build, in CycloneDX or SPDX
  • Vulnerability disclosure policy published at /.well-known/security.txt
  • Coordinated vulnerability disclosure SLAs documented internally
  • Secure-by-default configuration verified
  • Update mechanism tested end-to-end
  • EU Declaration of Conformity drafted and signed
  • CE marking applied to product or documentation
  • Technical documentation kept for 10 years
  • ENISA SRP manufacturer profile registered
  • 24h / 72h / 14d incident-reporting playbook in place
  • Authorised representative appointed (non-EU manufacturers only)

Is Your Product CRA Ready?

Get a free personalised CRA compliance briefing for your specific product type — delivered to your inbox. No spam, no sales calls.

  • Understand your exact product category (default, Class I, or Class II)
  • Get a checklist of your specific obligations and deadlines
  • Receive guidance on SBOM, vulnerability management, and reporting
  • Early access to our CRA Compliance Manager tool (launching 2026)
  • Weekly CRA news digest — ENISA updates, regulatory guidance

Get Your Free CRA Brief

Takes 60 seconds · Completely free

🔒 No spam. Unsubscribe anytime. Processed in accordance with GDPR.