The EU Cyber Resilience Act stopped being a "we'll deal with it later" problem roughly twelve months ago. The regulation enters full application in December 2027, but the vulnerability-reporting obligations start biting in September 2026, and every procurement conversation with a European customer now includes a CRA questionnaire. If your product contains digital elements and you sell into the EU, you need a plan, not an opinion.
I have walked three product organizations through CRA scoping over the past year. What follows is the checklist I wish I had on day one — concrete artifacts, concrete controls, and the places teams consistently underestimate the work.
What Does the CRA Actually Require?
The CRA requires manufacturers of products with digital elements to ship products that are secure by default, provide a Software Bill of Materials, handle vulnerabilities throughout the support period, and report actively exploited vulnerabilities and severe incidents to ENISA within strict timelines. "Products with digital elements" is broad — it covers software, firmware, and any hardware whose intended function depends on software. SaaS is partially excluded, but remote data-processing components that ship with a product are in scope.
The obligations split across three pillars: essential cybersecurity requirements (Annex I, Part I), vulnerability-handling requirements (Annex I, Part II), and conformity assessment. Miss any of the three and the product cannot carry the CE mark for cybersecurity.
Who Is On the Hook?
The manufacturer placing the product on the EU market is primarily on the hook, with distinct obligations cascading to importers and distributors. If you are a US-based SaaS vendor selling a self-hosted appliance in Germany, you are the manufacturer. If you white-label another vendor's agent and ship it in your product, you inherit manufacturer obligations for the integrated whole. Open-source stewards have a lighter regime, but only when genuinely non-commercial — donation buttons and support contracts change the calculus.
Step-by-Step Implementation
Step 1: Build a Product Inventory and Scope Map
Start with an inventory of every product SKU you sell into the EU, including firmware variants, OEM builds, and appliances. For each, record the intended use, whether it processes personal data, whether it is "important" or "critical" under Annex III and IV, and the declared support period. Anything classified as important (class I or II) or critical needs third-party conformity assessment; everything else can self-assess today, but the Commission is expected to expand the important list.
Step 2: Establish a Secure Development Baseline
Map your SDLC against Annex I, Part I. At minimum you need threat modeling at design time, secure defaults (no default passwords, minimized attack surface, secure boot where applicable), encryption in transit and at rest for personal and sensitive data, authentication and access control, logging with integrity protection, and resilience against denial-of-service. Write this up as a one-page Secure Development Policy and map each control to the engineering practice that implements it.
Step 3: Generate SBOMs for Every Release
Generate an SPDX or CycloneDX SBOM for every release artifact and publish it alongside the binary. The CRA text does not mandate a specific format, but ENISA's technical guidance leans CycloneDX. Here is a minimal GitHub Actions step that covers most container-based products:
name: sbom
on:
push:
tags: ['v*']
jobs:
generate-sbom:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build image
run: docker build -t ghcr.io/acme/widget:${{ github.ref_name }} .
- name: Generate CycloneDX SBOM
uses: anchore/syft-action@v0.18.0
with:
image: ghcr.io/acme/widget:${{ github.ref_name }}
format: cyclonedx-json
output-file: sbom.cdx.json
- name: Attest SBOM
uses: actions/attest-sbom@v2
with:
subject-path: sbom.cdx.json
sbom-path: sbom.cdx.json
- uses: actions/upload-artifact@v4
with:
name: sbom
path: sbom.cdx.json
Retain every SBOM for the full support period. Auditors will ask.
Step 4: Stand Up a Coordinated Vulnerability Disclosure Program
Publish a security.txt at a well-known URL with a contact address, a PGP key, and a published disclosure policy. Annex I, Part II requires a policy on coordinated vulnerability disclosure and a mechanism to receive reports. A bare security email and a promise are not enough — you need SLAs for triage, assignment, and remediation, and you need to document them.
Step 5: Wire Up 24/72-Hour Incident Reporting
ENISA's single reporting platform requires three notifications for actively exploited vulnerabilities and severe incidents: an early warning within 24 hours of awareness, an incident notification within 72 hours, and a final report within 14 days. Build the reporting into your incident response runbook as three explicit checkpoints, each with a named owner. Practice it in a tabletop exercise before you need it for real.
Step 6: Prepare the Technical Documentation File
The CRA requires a technical documentation file per Annex V, retained for 10 years or the support period (whichever is longer). This includes a product description, a risk assessment, evidence of essential requirement compliance, SBOMs, test records, and the EU Declaration of Conformity. Start the file during development rather than at release — backfilling is painful and increases the risk of gaps an auditor will find.
Step 7: Prepare for Conformity Assessment
If any SKU falls into the "important" or "critical" category, engage a notified body early. Lead times for CRA-capable notified bodies are already lengthening. For self-assessed products, draft the EU Declaration of Conformity template now and dry-run signing it — the declaration requires specific references to the Annex I essential requirements and any harmonized standards applied.
How Long Is the Support Period?
The support period is at least five years, or the expected period of use if shorter, counted from placement on the market. During this period you must provide security updates without charge and within a timeframe appropriate to the severity of the vulnerability. Publishing a support-period policy per product line is the simplest way to make this unambiguous for customers, procurement teams, and your own engineering backlog.
What Counts As an "Actively Exploited" Vulnerability?
Actively exploited means there is reliable evidence that malicious actors have used the vulnerability against a system without the owner's authorization — not merely that a proof-of-concept exists. The distinction matters because the 24-hour early-warning clock starts when you become aware of exploitation, not when a CVE is published. In practice this means your triage process needs a named "exploitation determination" step with clear criteria, not ad-hoc judgment during a crisis.
How Do You Handle Third-Party and Open-Source Components?
You remain responsible for the security of every component you ship, regardless of origin. That means you need the SBOM to match reality, a process to track vulnerabilities in every listed component, and a policy for handling abandoned or unmaintained dependencies. "We pulled it from npm" is not a defense. For critical components, consider supporting maintainers directly or bringing the maintenance in-house.
Where Do Teams Consistently Underestimate the Work?
Teams consistently underestimate three areas: the scope of the technical documentation file, the coordination cost of ENISA reporting across legal, security, and engineering, and the ongoing burden of SBOM hygiene across every supported release line. A product shipping four concurrent major versions needs four parallel vulnerability-handling streams, and each has its own 24-hour clock when something breaks.
How Safeguard.sh Helps
Safeguard.sh was built for exactly this workload. Our platform ingests your SBOMs and enriches them with 100-level depth reachability analysis, so you know which CVEs in a transitive dependency are actually exploitable in your build — cutting down the vulnerability-handling burden to what really matters under Annex I, Part II. Griffin AI drafts ENISA-ready incident notifications from your internal ticket and telemetry data, keeping the 24- and 72-hour clocks honest. Our TPRM module tracks your suppliers' own CRA posture so you are not blindsided by an upstream issue, and the container self-healing runtime closes the window between CVE disclosure and patched artifact for every supported release line.