If you make software — or hardware with software in it — and any of it reaches the EU market, the Cyber Resilience Act (CRA) now applies to you. It's one of the broadest pieces of product-security regulation ever written, and the obligations are concrete. This is the plain-English version.
What the CRA actually is
The CRA sets baseline cybersecurity requirements for "products with digital elements" placed on the EU market. That phrase is deliberately wide: it covers commercial software, connected devices, libraries, and firmware. If it processes data and can connect to something, it's likely in scope.
The goal is simple to state and hard to fake: products should be secure by design, stay secure through their supported life, and be honest about the risks they carry.
The obligations that matter
- Security by design & default. Ship without known exploitable vulnerabilities, with a secure default configuration.
- A Software Bill of Materials (SBOM). You must know — and be able to show — what's inside your product, down to its dependencies.
- Vulnerability handling. Monitor components for new vulnerabilities, remediate them, and distribute updates for the support period.
- Documentation. Maintain technical documentation that demonstrates conformity, kept current as the product changes.
- Incident & vulnerability reporting. Actively exploited vulnerabilities and severe incidents must be reported to authorities within tight deadlines.
The part teams underestimate
The requirements aren't just "be secure" — they're "be able to prove you're secure, continuously." An SBOM from six months ago isn't evidence today. A vulnerability you patched but never recorded doesn't help you in an audit. The CRA rewards a living trail of evidence, not a one-time PDF.
Compliance here is less a document you write once, and more a signal you maintain — a current, defensible record of what you shipped and how you keep it safe.
A practical path to readiness
- Generate a real SBOM (CycloneDX or SPDX) as part of your build, not by hand.
- Wire in continuous vulnerability monitoring against that SBOM, with a way to record decisions (including "not affected" — a VEX statement).
- Keep an evidence log that's tamper-evident, so your trail holds up under scrutiny.
- Score your readiness against the CRA's essential requirements, and close the gaps deliberately.
- Prepare the dossier — the technical documentation — and keep it regenerating as the product moves.
Where this is headed
The CRA's obligations phase in over the next couple of years, but the work is cumulative: the teams that start the evidence habit early will breeze through, and the ones treating it as a last-minute paperwork exercise won't. Start the trail now.
This is exactly the problem Proofwright — one of our products — was built to solve: evidence-first CRA readiness, from SBOM to audit-ready dossier.