CRA Compliance for Your Digital Products
Bring your digital products, software and firmware alike, into compliance with the Cyber Resilience Act: obligation scoping, SBOM in CI/CD, CVE auditing, continuous monitoring, and reporting procedures.
CRA Compliance — Cyber Resilience Act
The first Cyber Resilience Act obligations land on 11 September 2026. Are your products ready?
Why now
Regulation (EU) 2024/2847, the CRA, sets cybersecurity requirements for any product that carries digital elements. Application software and embedded firmware both count. Miss the mark and you lose your CE marking, and with it the European market.
The timeline is already running:
- 11 September 2026: vulnerability handling and reporting. If a flaw is being actively exploited, you have 24 hours to warn ENISA.
- 11 December 2027: everything else applies. A usable SBOM, secure design, and security updates for the whole support period you advertise.
Embedded firmware, application software, connected product: we work on all three. Embedded engineering, continuous integration and software quality are our daily craft, and they are the levers a CRA compliance effort calls on.
Start with the self-assessment
Before we commit to anything together, you can size up your product in a few minutes: scope, role, class, and the obligations that apply to you.
➡️ Run the CRA self-assessment. It’s free and the result is immediate.
The offering, in five modules
Take one module on its own, or run them in sequence from regulatory scoping all the way to day-to-day monitoring. Your call.
1. Pre-audit and scoping
First, figure out where you stand. Does your product fall under the CRA, and with which exclusions? Are you a manufacturer, an importer, or a distributor? Which class: default, important I-II, critical? From there we draw up the obligations that apply and the route to compliance.
Deliverable: a scoping note, with scope and effort quantified.
2. SBOM generation in CI/CD
The goal is an inventory that stays current on every build, with no one keeping it by hand. We generate the SBOM (CycloneDX or SPDX) automatically and wire it into your pipeline as it stands. Coverage runs from application software to the vendored components of bare-metal and RTOS builds, where no package manager is there to help.
Deliverable: a pipeline that produces a usable SBOM, plus a template you reuse on your other products.
3. CVE auditing in CI
Plain aim: no critical vulnerability ships to production unseen. We scan inside the pipeline with OSV-Scanner and Grype, and fail the build past the severity threshold you set. False positives are handled cleanly, through VEX statements.
Deliverable: the CI scan stage and the blocking rules, documented.
4. Continuous monitoring with OWASP Dependency-Track
A CVE can land on a Friday evening, on a component you haven’t touched in months. The question that night is how many products are affected, and which ones. We deploy Dependency-Track, feed it the SBOMs from your whole fleet, and let the CVE matching run continuously. You go from “we’ll check next week” to “twelve products affected, identified, patches ship Monday”.
Deliverable: a running instance and your fleet connected to it.
5. Internal procedures for exploited vulnerabilities
Then there’s the organisation. Who watches for actively exploited vulnerabilities, meaning CISA’s KEV list and ENISA advisories? Who decides, who notifies, and by when? We set up the PSIRT process and connect it to the CRA reporting chain (Article 14: early warning at 24 hours, notification at 72, final report at 14 days), in step with your disclosure policy.
Deliverable: written PSIRT procedures and a notification runbook.
Who it’s for
Software vendors and makers of connected equipment (industry, IoT) selling on the European market. Integrators placing products with digital elements on that market. Product, software and firmware teams that would rather get ahead than chase the 2026 and 2027 deadlines.
📧 info@adnt.io. Put “CRA Compliance” in your message.