Documentation

Other frameworks

CRA: Cyber Resilience Act for products with digital elements

The Cyber Resilience Act (Regulation (EU) 2024/2847) sets essential cybersecurity requirements for manufacturers of products with digital elements sold in the EU, covering secure-by-default design, a documented vulnerability-handling process (including a software bill of materials), coordinated disclosure, and mandatory incident/vulnerability reporting. It's the newest framework EuroCompliant supports, and its automated-evidence coverage is intentionally narrow: only one of its four tracked obligations is platform-managed today, and that one is explicitly a partial check.

Why this is required

Article 6 requires that products with digital elements meet the essential cybersecurity requirements in Annex I Part I only where properly installed, maintained and used as intended with necessary security updates, and that the manufacturer's own processes meet Annex I Part II.

Article 13 requires manufacturers to conduct and document a cybersecurity risk assessment, exercise due diligence on third-party and open-source components, and maintain a vulnerability-handling process including a software bill of materials for at least a 5-year support period.

Article 14 requires notifying any actively exploited vulnerability and any severe incident to the CSIRT designated as coordinator and ENISA within strict deadlines: 24-hour early warning, 72-hour notification, and a final report within 14 days (vulnerability) or one month (incident).

Article 31 requires technical documentation containing the elements set out in Annex VII, drawn up before the product is placed on the market and kept continuously updated during the support period.

What EuroCompliant does

Enabling CRA adds four obligations to your Obligations page. Article 6 (secure-by-default configuration) is platform-managed, evidenced by a clean CSPM scan of your cloud infrastructure — but that's a genuinely partial proxy: it covers cloud configuration only, not on-device or hardware security, or the full breadth of Annex I Part I. The other three (Articles 13, 14, 31) are tenant actions with specific, article-grounded guidance, not generic placeholders.

A CRA Technical File document type is available from the Documents section. It's generated on demand and pulls real per-company data: your software bill of materials from the Syft SBOM scan engine, and open/resolved vulnerability counts from Trivy scan findings. It's genuinely useful evidence to review and attach to your Article 31 documentation — but generating it doesn't automatically mark Article 31 complete, since the platform can't yet verify you actually reviewed and finalised it.

There's no automated check for Article 13's vulnerability-handling process or Article 14's reporting process today; both need a real, documented process on your side.

Walking through it

1

Enable CRA

Adds all four obligations, including the one platform-managed check.

Open /settings/frameworks →
2

Generate and review the CRA Technical File

Pulls your real SBOM (Syft) and vulnerability (Trivy) scan data into one document, structured against Annex VII.

Open /documents →
3

Document your vulnerability-handling and reporting process

Articles 13 and 14 need a real process on record: a support-period commitment, an SBOM, coordinated disclosure, and the 24h/72h/14-day reporting chain to your CSIRT and ENISA.

Open /obligations →

The law

Penalties for non-compliance

Non-compliance with the essential cybersecurity requirements in Annex I or with Articles 13 and 14 carries fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher (Article 64(2)). A separate, lower tier of up to €10 million or 2% covers a longer list of other articles, and supplying incorrect or misleading information to authorities carries up to €5 million or 1% (Article 64(3)-(4)).

Frequently asked

Are we in scope for CRA?

If you develop, manufacture, or have manufactured products with digital elements (hardware or software, including remote data-processing components) that you place on the EU market and that have a data connection to a device or network, generally yes. Notable carve-outs exist for medical devices, vehicles, aviation-certified products, maritime equipment, and products developed exclusively for national security or defence.

How is this different from the EU AI Act's cybersecurity requirement (Article 15)?

They can both apply at once. Article 15 of the AI Act is one requirement among many for high-risk AI systems specifically. CRA is a dedicated, much more detailed cybersecurity regime covering essentially any connected product with digital elements, AI or not, including SBOM, coordinated vulnerability disclosure, and its own incident-reporting timeline separate from the AI Act's.

Related guides

Try it on your own systems

Everything in this guide runs in the live product. Start a free trial and follow along with your own data.

Start free trial