EU Cyber Resilience Act (CRA) compliance starts with your developers
The Cyber Resilience Act sets mandatory cybersecurity requirements for every product with digital elements sold in the EU. Tools can generate your software bill of materials and scan your builds. The secure-by-design work the regulation actually demands is done by the people writing the code.
Development teams shipping into the EU train with SecureFlag
- In force
December 10, 2024
Regulation (EU) 2024/2847
- Reporting obligations
In force since September 11, 2026
Article 14 · 24-hour early warning
- Full application
December 11, 2027
CE marking required
- Penalties
Up to €15M or 2.5%
of global turnover
What is the EU Cyber Resilience Act?
The Cyber Resilience Act (Regulation (EU) 2024/2847) is the first EU law to set mandatory cybersecurity requirements for hardware and software products. It entered into force on December 10, 2024. If your product connects to a device or a network, directly or indirectly, the CRA almost certainly applies to it.
The regulation covers the full product lifecycle. Products must be designed and built securely, shipped without known exploitable vulnerabilities, and supported with free security updates for their expected lifetime. Manufacturers must implement and document a cybersecurity risk assessment, operate a defined vulnerability handling process, and report actively exploited vulnerabilities to ENISA, the EU's cybersecurity agency, within 24 hours of becoming aware of them.
Enforcement runs through CE marking. From December 11, 2027, a product that fails the essential requirements in Annex I cannot carry the CE mark, which means it cannot be sold in the EU.
- Build
Secure across the lifecycle
Designed and built securely, shipped without known exploitable vulnerabilities, updated for free.
- Report
24 hours to ENISA
Actively exploited vulnerabilities, from the moment you become aware of them.
- Enforce
CE mark or no market
Annex I essential requirements apply from December 11, 2027.
Who must comply with the Cyber Resilience Act?
The CRA applies to anyone placing products with digital elements on the EU market: manufacturers first, and importers and distributors with their own duties. It applies to companies headquartered outside the EU. If your software sells in Europe, the location of your engineering team does not matter.
A few product types are exempt because other EU rules already cover them: medical devices, motor vehicles, civil aviation, and marine equipment. Products built exclusively for national security or defense are out of scope, and so is open source software developed outside a commercial activity.
Most products fall into the default category and can self-assess conformity. Important products (categories like identity management systems, password managers, and firewalls, defined in Implementing Regulation (EU) 2025/2392) and critical products face stricter conformity routes, including assessment by a notified body.
Cyber Resilience Act timeline
- Published
Published in the Official Journal
- In force
Entered into force
- Article 14
Reporting obligations apply (Article 14)
- Full application
Full application, CE marking required
September 11, 2026, was the first date with legal exposure. Since that day, actively exploited vulnerabilities and severe incidents must be reported to ENISA or your national CSIRT, your country's designated incident response team, with an early warning within 24 hours.
A 24-hour window only works if your engineers can quickly find, assess, and describe a vulnerability. That is an engineering capability, not a legal one.
CRA requirements, and what they mean for your development team
Most CRA guides stop at the legal text. This table maps each engineering-relevant obligation to the capability your team needs, and to the evidence that supports your technical documentation when an assessor asks how you meet it.
Products designed, developed, and produced secure by design and by default
Delivered without known exploitable vulnerabilities
Vulnerabilities handled and remediated without delay
Documented cybersecurity risk assessment
Due diligence on third-party components
Technical documentation for conformity assessment
The proof an auditor asks for is a download, not a scramble.
Where does your team stand?
Ten questions covering the engineering obligations above: design practices, vulnerability handling, remediation speed, and the evidence you could show an assessor today. You get a gap view by obligation, not a sales call.
Developers get hands-on secure coding training in the languages and frameworks they actually ship.
Security requirements, covering data protection, access control, attack surface, and logging, are defined before code is written.
You track how many vulnerabilities each team introduces, by language and vulnerability category.
Every release is checked for known exploitable vulnerabilities before it ships.
Customers and researchers can report vulnerabilities to you, and your handling process could support a 24-hour early warning to ENISA.
Engineers can find the root cause of a confirmed vulnerability and ship a security update to users without delay.
Each product has a documented cybersecurity risk assessment that is kept up to date.
Threat models are updated whenever the architecture changes.
You keep an up-to-date software bill of materials (SBOM), and developers know how to use third-party components securely.
You could export per-developer training records and progress reports for an assessor today.
Tools cover your artifacts. The CRA regulates how you build.
SBOM generators, scanners, and compliance platforms produce the documents the CRA asks for. None of them writes secure code. The first requirement in Annex I is that products are designed, developed, and produced with an appropriate level of cybersecurity. That is a statement about your engineers.
The pattern in customer programs is consistent: teams that train in real, running applications close vulnerabilities faster than teams trained on slides and quizzes. That difference is what an assessor reads in your remediation timelines.
92%
“An overwhelming 92% of C‑suite and senior IT leaders believe secure coding training has reduced the number of security bugs introduced in development. This near-consensus suggests that, despite challenges, leadership sees training as an effective measure for improving software security.”
Trusted by security and engineering teams
“SecureFlag empowers me to run a secure coding training program that is practical, scalable, and highly effective across the organization.”
Application Security Architect
Financial Services
Cyber Resilience Act FAQ
Who needs to comply with the Cyber Resilience Act?
Anyone placing products with digital elements on the EU market: manufacturers, importers, and distributors. This includes companies based outside the EU whose products sell in Europe.
What products are exempt from the CRA?
Products already covered by sector rules (medical devices, motor vehicles, civil aviation, marine equipment), products built exclusively for national security or defense, and open source software developed outside a commercial activity.
What are the penalties for non-compliance?
Fines up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, for breaching the essential requirements. Market surveillance authorities can also force a product off the EU market.
Do we need a third-party audit?
Most products can self-assess. Important and critical products, as categorized by Implementing Regulation (EU) 2025/2392, need stricter conformity routes, up to assessment by a notified body.
How is the CRA different from NIS2?
NIS2 regulates organizations in critical sectors and their security operations. The CRA regulates products. If you build software, NIS2 may apply to your company, while the CRA applies to what you ship.
Does the CRA require developer training?
Not by name. The CRA requires products built with an appropriate level of cybersecurity and a documented secure development process. In conformity assessment, the practical question becomes how you ensure that, and evidence of developer competence is the standard answer.
Keep reading
Start mapping your team's CRA readiness today
See how SecureFlag maps training paths to the CRA's engineering obligations, and what the audit evidence looks like for your languages and frameworks. Thirty minutes, with your stack.