The Rise of Product Cybersecurity Regulation in the EU
Everything from your fridge to your factory relies on software. That’s great for innovation—and also a jackpot for attackers. The EU has responded with its most ambitious cybersecurity regulation to date: the Cyber Resilience Act (CRA).
While previous regulations like GDPR focused on personal data and NIS2 targeted critical infrastructure, the CRA casts a much wider net. It’s the first EU law to impose cybersecurity requirements directly on the products themselves, from design to end-of-life.
Why the CRA Was Introduced
You might think that the European Commission just woke up one morning and decided to regulate toaster firmware, but actually the CRA was born from years of escalating threats and market failures in securing digital products:
- Many products ship with known vulnerabilities or insecure default settings.
- Security updates are often delayed—or never released.
- Consumers have no real way to assess product security before buying.
This created an uneven playing field where responsible manufacturers bore costs while careless ones cut corners.
The CRA entered into force in December 2024, with partial obligations kicking in by September 2026 and full compliance required by December 2027.
Where the CRA Fits in the Bigger EU Puzzle
The CRA is a core pillar of the EU’s Cybersecurity Strategy and Digital Decade goals. It complements:
- GDPR (data protection)
- NIS2 (network and critical infrastructure security)
- EU Cybersecurity Act (certification framework)
Together, they form a layered legal environment pushing Europe toward digital sovereignty.
Who’s Affected?
The CRA applies to almost everyone involved in making or selling digital products in the EU:
- Manufacturers (EU or abroad)
- Importers
- Distributors
Even open-source maintainers might be caught in the net—though the final text offers some relief (more on that in a later chapter).
Examples of covered products:
- Wi-Fi routers
- Smartwatches
- Home automation tools
- Software apps with online features
What’s Not Covered?
Certain sectors already have specific cybersecurity regulations, so they’re excluded from the CRA:
- Medical devices (covered under MDR)
- Automotive systems (regulated by UNECE WP.29)
- Aviation and defense technologies
Key Security Requirements for Products with Digital Elements
So, what does it really mean to make a product "cyber resilient"? The Cyber Resilience Act defines concrete requirements that must be embedded into the design, development, and post-market phases of every digital product sold in the EU.
“We’ll patch it later” isn’t a strategy anymore.
Secure by Design… For Real This Time
Gone are the days when security was an added feature. Under the CRA, security must be baked in from the start. That means:
- No known exploitable vulnerabilities at the time of release
- Secure default configurations (e.g. no more “admin/admin” logins)
- Strong authentication mechanisms, especially for remote access
- Access control enforcement across services and interfaces
- Protection of data in storage and in transit, typically via encryption
Example: If you're shipping a smart lock, it must use encrypted channels, require unique credentials, and protect against brute-force attacks—not just after a firmware update, but straight out of the box.
Security Throughout the Product Lifecycle
The CRA doesn’t stop once the product hits the shelf. Manufacturers are expected to maintain security throughout the entire lifecycle, including:
- Providing regular security updates, free of charge
- Informing users of known exploited vulnerabilities
- Ensuring secure update mechanisms (e.g. code signing, rollback prevention)
This means having a real post-market monitoring process—something that many companies currently lack.
Documentation & Evidence
If you're audited (and some products will require third-party assessments), you’ll need to show your work. That includes:
- Secure development policies and procedures
- Evidence of security testing and code review
- Records of updates and incident handling measures
Real-World Implications
Manufacturers now need to seriously invest in:
- Threat modeling and secure software development lifecycles (SSDLC)
- Hardening devices against physical and remote tampering
- Training dev teams in secure coding practices
The CRA puts product security on the same footing as safety and privacy. If you want to sell in the EU, you need to build with resilience in mind—not as a last-minute patch, but as a design principle.
Vulnerability Management and Incident Reporting Obligations
Shipping a secure product is just the beginning. Under the CRA manufacturers are also responsible for what happens after the product is out in the world. That means tracking vulnerabilities, responding to incidents, and notifying EU authorities within 24 hours when something goes wrong.
Let’s unpack what that actually involves.
No More “Patch and Pray”
The CRA requires every manufacturer to have a formal vulnerability handling process, which includes:
- Identifying, tracking, and fixing vulnerabilities in a timely manner
- Informing users about exploited vulnerabilities and available fixes
- Publishing updates free of charge throughout the product’s supported lifespan
- Maintaining a Software Bill of Materials (SBOM) to track third-party components
Example: If your app uses an outdated logging library and it gets exploited (looking at you, Log4j), you need to fix it quickly, notify affected users, and document how you addressed it.
The SBOM requirement is particularly notable. It means manufacturers must keep an up-to-date inventory of all software components—first-party, third-party, and open-source—used in their product. Think of it as an ingredient list for your firmware.
Incident Reporting: The 24-Hour Rule
If you discover your product is being actively exploited, the CRA gives you 24 hours to report it to the European Union Agency for Cybersecurity (ENISA) and your national Computer Security Incident Response Team (CSIRT).
The initial report must include:
- The nature of the vulnerability or exploit
- The products and users affected
- Immediate mitigation steps (if any)
Follow-ups are required, including:
- A more detailed report within 72 hours
- Final updates, corrective actions taken, and lessons learned within 14 days
Miss these deadlines, and you’re looking at potential fines of up to €15 million or 2.5% of global turnover.
Example: If a smart doorbell is found leaking customer video feeds due to a bug, the clock starts ticking the moment you confirm active exploitation.
Who Does This Apply To?
While the CRA places most of this burden on manufacturers, importers and distributors also have responsibilities. If you're in the supply chain and aware of an issue, you’re expected to act—or risk being complicit in non-compliance.
Compliance Pathways: Certification, CE Marking, and High-Risk Products
Getting compliant with the Cyber Resilience Act means building secure products and also proving they’re secure. The CRA lays out a structured system to assess whether your product meets its requirements. That includes conformity assessments, CE marking, and in some cases, mandatory third-party certification.
So, how do you know which path applies to you? Let’s break it down.
Conformity Assessment: Two Roads to Compliance
The CRA distinguishes between two major categories:
- Standard Products:
- Most digital products will fall into this category.
- Manufacturers can self-assess their compliance using internal documentation, security testing, and adherence to harmonised standards (once they’re published).
- This is similar to how low-risk products are CE marked today in other domains.
- Critical/High-Risk Products (Annex III):
- These include things like VPNs, firewalls, and intrusion detection systems
- These require a third-party conformity assessment—meaning an external, accredited auditor must certify your product’s security.
- In some cases, certification may be done via the EU Cybersecurity Certification Framework (EUCC).
Example: If you're shipping a VPN product in Europe, you'll need a notified body to validate your security claims—self-declaration won’t cut it.
The CE Mark—Now With Security Credentials
Once your product passes its conformity assessment, you can attach the CE mark, indicating compliance with the CRA. This mark has been around for decades (think toys, electronics, medical devices), but under the CRA, it now also signals cybersecurity assurance.
- The CE mark confirms your product meets essential CRA security requirements
- It must be visibly displayed and backed by technical documentation
- Authorities can demand this documentation at any time for review
That tiny logo just got a serious upgrade.
Keeping Up With Changing Risk Levels
If your product is updated, modified, or bundled in new ways, the risk classification might change—especially if it gains networking capabilities or handles more sensitive data. This can bump it from the “standard” category into the “critical” one, triggering stricter compliance steps.
Example: A basic IoT light bulb may be low risk, but once it connects to a cloud dashboard with access controls and camera feeds, it’s a different story.
Industry Challenges and What Businesses Should Do Now
The Cyber Resilience Act might sound like something only large enterprises need to worry about, but it hits startups, SMEs, and open-source maintainers just as hard. Compliance isn’t optional, and while the goals are clear, the path to readiness can feel like navigating a maze in the dark.
Here’s where the pain points lie—and how to tackle them.
The Biggest Challenges
1. Resource constraints
Many companies don’t have the internal expertise or budget to fully meet CRA obligations—especially when it comes to:
- Threat modeling and secure software development lifecycles (SSDLC)
- Keeping a detailed SBOM (Software Bill of Materials)
- Setting up vulnerability disclosure and response processes
2. Open-source exposure
While the final CRA text offers some relief for non-commercial open-source projects, commercial use or bundling of open-source code still brings compliance obligations. That means dev teams need to:
- Audit dependencies
- Monitor vulnerabilities in reused components
- Be ready to patch and report issues even if they didn’t write the original code
3. Conformity complexity
Many companies don’t yet know if their product falls under standard or critical categories. Misclassifying could lead to failing audits, product delays, or even legal trouble.
What You Should Do Right Now
The good news? You don’t need to do everything at once—but you do need a plan. Start with:
- Map your product portfolio: Classify each product’s CRA risk level
- Review your development processes: Add secure coding, regular code reviews, and security testing into your workflows
- Build an SBOM: Even a basic list of your third-party libraries is a strong starting point
- Prepare for incident reporting: Who in your team will report a breach? Do they know what 24 hours looks like under pressure?
- Check conformity needs: If you’re likely subject to third-party assessment, start discussions with notified bodies early
Pro tip: Our platform Brainframe GRC can simplify CRA compliance by tracking your conformity status, streamlining incident response, and enforcing secure software development lifecycle and vulnerability management through our Brainframe DEFEND offering.
