The EU Cyber Resilience Act (CRA), formally Regulation (EU) 2024/2847, is the first horizontal EU law that imposes cybersecurity requirements on almost all "products with digital elements" placed on the European market. It entered into force on 10 December 2024 and phases in over the following three years, with vulnerability-reporting duties arriving before the full essential requirements. Manufacturers must build security in by design, handle vulnerabilities across the product's support period, and document components — explicitly including a software bill of materials. This FAQ covers the questions vendors ask most, and notes Safeguard's own posture honestly: our platform is architected for FedRAMP HIGH and DoD Impact Level deployment, and our SOC 2 Type II audit is in progress.
Frequently Asked Questions
What is the EU Cyber Resilience Act? The CRA is a regulation that sets mandatory cybersecurity requirements for products with digital elements — hardware and software — throughout their lifecycle, from design through the end of the support period. It applies across sectors rather than to one industry, which is why it is described as a horizontal regulation. Because it is a regulation rather than a directive, it applies directly in all EU member states without needing national transposition.
What products does the CRA cover? It covers any product with digital elements whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network, when placed on the EU market. That sweeps in most commercial software, connected hardware, and their remote data-processing components. Certain products already governed by sector-specific EU law, such as medical devices and motor vehicles, are largely carved out to avoid duplication.
When does the CRA take effect? The regulation entered into force on 10 December 2024, but its obligations are phased. The vulnerability and incident reporting duties apply from 11 September 2026, and the main body of essential requirements applies from 11 December 2027. Manufacturers should treat 2026 as the reporting-readiness deadline and 2027 as the full-compliance deadline.
Does the CRA require an SBOM? Yes, in effect. Annex I requires manufacturers to identify and document components and vulnerabilities, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies." The SBOM does not have to be published, but it must exist and be available to authorities on request. Safeguard's SBOM Studio generates machine-readable CycloneDX and SPDX bills of materials automatically, so this obligation becomes a build artifact rather than a manual document.
What are the vulnerability reporting obligations? Once the reporting duties apply, manufacturers must notify the designated CSIRT and ENISA of any actively exploited vulnerability in their product, starting with an early warning within 24 hours of becoming aware, followed by a fuller notification and a final report once a fix is available. Severe incidents affecting product security carry parallel reporting timelines. Continuous vulnerability monitoring is the only practical way to meet a 24-hour clock; Safeguard's software composition analysis surfaces newly disclosed and exploited vulnerabilities in your components as they emerge.
What is the support and security-update period? Manufacturers must handle vulnerabilities and provide security updates for the product's support period, which must reflect the reasonably expected product lifetime. Where a shorter period is not justified, the expectation trends toward at least five years of support. Practically, you need a durable record of what shipped in each release so you can patch the right versions across that window.
How are product risk classes defined? The CRA sets a default class assessed by the manufacturer itself, plus "important" products (Annex III) split into classes I and II, and "critical" products (Annex IV) that face the strictest scrutiny. Higher classes require more rigorous conformity assessment, up to involvement of a notified body or application of harmonized standards. Most ordinary software falls in the default class and can self-assess, provided the essential requirements are genuinely met.
What is CE marking under the CRA? Products that meet the CRA's essential requirements carry the CE marking, the same conformity mark used across EU product legislation, signaling that the manufacturer has completed the required conformity assessment. For CRA purposes the CE marking asserts cybersecurity conformity, backed by technical documentation the manufacturer must keep. Selling a covered product into the EU without valid CE conformity after the deadlines is a violation.
How does the CRA treat open-source software? Non-commercial open-source software developed outside a commercial activity is largely outside the CRA's manufacturer obligations, and the regulation introduces a lighter-touch category of "open-source software steward." However, commercial products that incorporate open-source components remain the responsibility of the manufacturer that ships them. In other words, using open source does not transfer your CRA duties to the upstream project.
What are the penalties for non-compliance? Breaching the essential requirements can draw administrative fines of up to 15 million euro or 2.5 percent of total worldwide annual turnover, whichever is higher, with lower tiers for other violations. Supplying incorrect or incomplete information to authorities carries its own penalty tier. The scale of the fines is deliberately aligned with other major EU regulations to make non-compliance a board-level risk.
Does the CRA apply to non-EU vendors? Yes. The obligations attach to placing a product on the EU market, regardless of where the manufacturer is based, and non-EU manufacturers must designate an importer or authorized representative established in the EU. If your software reaches EU customers, you are in scope even without an EU entity. This mirrors the extraterritorial reach that made the GDPR a global compliance concern.
How does the CRA relate to NIS2 and other EU rules? The CRA governs the security of products, while NIS2 governs the cybersecurity practices of essential and important organizations operating in the EU. They are complementary: a covered entity under NIS2 may also be a manufacturer subject to the CRA for the products it sells. Vulnerability evidence and SBOMs generated for one regime generally support the other, which is why centralizing that evidence pays off.
How does Safeguard help with CRA readiness? Safeguard turns the CRA's documentation-heavy duties into automated artifacts: machine-readable SBOMs, continuous vulnerability evidence with timestamps for the reporting clock, and policy gates that block releases missing required security attestations. The Griffin AI detection engine scans every change so first-party code is held to the same standard as dependencies, and the compliance workspace organizes it all into an evidence pack aligned to the essential requirements.
To compare Safeguard against other supply-chain security tools, see the comparison page, and read the full product documentation at docs.safeguard.sh.