The EU Cyber Resilience Act Is Coming: What It Means, Who Needs to Prepare, and How I Can Help

What Is the Cyber Resilience Act, and Why Should You Care?

The Cyber Resilience Act (CRA) is the European Union's first horizontal regulation that sets mandatory cybersecurity requirements for products with digital elements. "Horizontal" means it applies across the board, not just to specific sectors like healthcare or finance. If your product connects to a device or network, directly or indirectly, it's almost certainly in scope.

Before the CRA, product cybersecurity in Europe was a patchwork. Some sectors had their own rules, but most products with digital elements had zero mandatory security requirements. A smart doorbell, a piece of accounting software, a web application's downloadable client: none of these had to meet any baseline security standard before being sold in the EU.

The CRA changes that completely. It introduces 21 mandatory cybersecurity requirements that cover the entire product lifecycle, from design through to end of life. And it puts the responsibility squarely on manufacturers, importers, and distributors, not on consumers.

The regulation was adopted in October 2024 and entered into force on 10 December 2024. It's being phased in over three years, with the full requirements applying from 11 December 2027.

The Timeline: When Does What Kick In?

This is where it gets real. The CRA uses a phased approach, and some deadlines are closer than you think.

10 December 2024 is when the CRA entered into force. The clock is ticking.

11 June 2026 is when conformity assessment bodies start operating under CRA rules. This matters if your product falls into the "important" or "critical" categories that need third party assessment.

11 September 2026 is the first big operational deadline. From this date, manufacturers must report actively exploited vulnerabilities and severe security incidents to ENISA (the EU Agency for Cybersecurity) within 24 hours. That's less than seven months away as I write this. If you don't have a vulnerability reporting process in place, you're already behind.

11 December 2027 is full enforcement day. Every product with digital elements sold in the EU must comply with all CRA requirements by this date. Non compliant products cannot be placed on the market.

What Does the CRA Actually Require?

Let me break down the core requirements in plain English, because the legal text is dense enough to put anyone to sleep.

Secure by design and by default. Your products must be designed with cybersecurity in mind from the start. That means minimal attack surfaces, encrypted or protected data, no unauthorised access, and secure default configurations. Your product should work securely out of the box, without requiring the user to be a security expert.

Software Bill of Materials (SBOM). This is a big one. You need to create and maintain a machine readable SBOM that documents at least the top level dependencies of your product. Think of it as an ingredients list for your software. If you're using Ruby on Rails with 200 gems, or a Solidus ecommerce platform with a dozen extensions, you need to document what's in there. The SBOM doesn't need to be public, but you must provide it to market surveillance authorities on request.

Vulnerability management. You need a documented process for handling vulnerabilities throughout your product's lifecycle. That includes identifying, documenting, and remediating vulnerabilities. You need to provide a way for users to report vulnerabilities. You need to distribute security updates promptly and for free. And you need to do this for a maximum support period of five years (or the product's expected lifespan, whichever is shorter).

Incident reporting. From September 2026, you must notify ENISA of any actively exploited vulnerability within 24 hours of becoming aware of it, followed by a more detailed report within 72 hours and a final report within 14 days. If you're a small or micro enterprise, you get a bit more flexibility on the 24 hour deadline, but the obligation still exists.

Conformity assessment. Around 90% of products fall into the "default" category and can use self assessment. But products classified as "important" (Class I or II) or "critical" require more rigorous assessment, potentially including third party certification. Annex III and IV of the CRA list these categories, and they include things like operating systems, firewalls, routers, smart meters, and industrial automation systems.

CE marking. Products that meet all CRA requirements receive the CE marking, which is required to place the product on the EU market.

Technical documentation. You need comprehensive documentation demonstrating how your product meets the CRA's requirements. This includes your risk assessment, your SBOM, your vulnerability handling process, and evidence of conformity.

Who Does This Apply To?

The short answer: almost everyone in the digital product supply chain.

Manufacturers bear the primary responsibility. If you design and build a product with digital elements and place it on the EU market, you're a manufacturer under the CRA. This includes software publishers. If you build a Ruby on Rails application that gets distributed to users (not pure SaaS, but anything with a downloadable component), you're in scope.

Importers must verify that the manufacturer has complied. If you're importing smart devices to sell on your Solidus ecommerce store, you need to ensure those products meet CRA requirements before listing them.

Distributors must check that products bear the CE marking and that manufacturers and importers have done their jobs. If you resell software or connected products, this is your obligation.

Open source software gets special treatment. If you're contributing to open source without commercial intent, you're not directly subject to CRA obligations. But and this is crucial, if you integrate open source components into a commercial product, you are responsible for ensuring those components comply. The CRA also introduces the concept of "open source stewards" for organisations that systematically support commercial open source projects.

The Important Exception: Pure SaaS

Here's a nuance that trips a lot of people up. Pure Software as a Service (SaaS) products, where there's no downloadable software distributed to users, are generally not covered by the CRA. They fall under the NIS2 Directive instead.

But here's the catch. If your SaaS product has any downloadable component, a desktop client, a mobile app, a browser extension, a plugin, then that component is a product with digital elements and falls under the CRA. And if your SaaS platform provides "remote data processing" that is essential for a physical product's functionality (like a smart home hub that relies on your cloud service), your remote processing solution is also in scope.

So if you're building a custom SaaS on Rails that includes a mobile app or a desktop sync client, you need CRA compliance for those distributed components. The web app itself might fall under NIS2, but anything you ship to the user falls under CRA.

What Are the Pitfalls?

Let me be straight about where businesses are likely to get tripped up.

Underestimating scope. The CRA is broader than most people think. It doesn't just apply to IoT devices and smart gadgets. It covers any software that connects to a network. If you sell a downloadable application, extension, or plugin in the EU, you're likely in scope.

Ignoring the supply chain. If your product relies on third party components (and let's be honest, virtually every modern application does), you're responsible for the security of those components. That dodgy npm package or unmaintained Ruby gem in your dependency tree? Your problem now.

No vulnerability process. Many smaller software companies have no formal vulnerability handling process. No security contact, no way to receive reports, no process for triaging and fixing issues. The CRA makes this mandatory.

Missing SBOMs. Most companies have never generated an SBOM. If you don't know exactly what's in your software, you can't demonstrate compliance, and you can't respond quickly when a vulnerability like Log4Shell hits a dependency you didn't even know you were using.

Thinking "we're too small." The CRA applies regardless of company size. Micro enterprises get some flexibility on reporting deadlines, but the core obligations apply to everyone. If you sell a product with digital elements in the EU, you comply.

Confusing CRA with GDPR. They're different regulations with different requirements. CRA compliance doesn't automatically mean GDPR compliance and vice versa. You may need to satisfy both.

The Cybersecurity Angle: What Steps Must You Take?

CRA compliance isn't just about paperwork. It requires genuine security practices. Here's what that looks like in practical terms.

Threat modelling and risk assessment. Before you ship anything, you need to assess the cybersecurity risks. What are the attack vectors? What data does your product handle? What happens if it's compromised? This needs to be documented.

Secure development practices. Code reviews, static analysis, dependency scanning, secrets management, secure CI/CD pipelines. If you're not already doing these, start now. Tools like Brakeman for Rails, Bundler Audit for gem vulnerabilities, and OWASP ZAP for dynamic testing should be part of your development workflow.

Penetration testing. Regular pen testing is essential. Using tools like Kali Linux, you can simulate real world attacks against your applications. I use Kali regularly to test the security posture of systems I build and manage, running everything from network scanning with Nmap to web application testing with Burp Suite.

Dependency management. Lock your dependencies, audit them regularly, and have a process for updating when vulnerabilities are disclosed. For Ruby on Rails projects, tools like bundler-audit and services like GitHub's Dependabot automate much of this.

Automated SBOM generation. Tools like CycloneDX and Syft can generate SBOMs automatically from your project files. For Rails projects, the CycloneDX Ruby gem can generate an SBOM directly from your Gemfile.lock.

Continuous monitoring. Security isn't a one time thing. You need ongoing monitoring, log analysis, and intrusion detection. Set up automated alerts for abnormal behaviour in your production systems.

Incident response plan. When (not if) something happens, you need a documented plan. Who gets notified? How do you assess impact? How do you report to ENISA within 24 hours? How do you communicate with affected users? Write this plan now, before you need it.

How I Can Help: Growth Hacking, SaaS, Solidus, and Secure Systems

This is where my background becomes particularly relevant. I'm not just a Growth Hacker who optimises marketing campaigns. I build and secure the systems that those campaigns run on. Here's what that looks like in practice.

Secure SaaS development on Ruby on Rails. I build custom SaaS platforms on Rails with security baked in from day one. That means encrypted data at rest and in transit, secure authentication with multi factor support, role based access controls, input validation, protection against the OWASP Top 10, and automated security scanning in the CI/CD pipeline. Rails has excellent built in protections against common vulnerabilities like CSRF, XSS, and SQL injection, but they need to be properly configured and maintained.

Solidus ecommerce with CRA in mind. If you're running a Solidus store that sells connected products or distributes software, CRA compliance needs to be part of your platform strategy. I help Solidus merchants understand their obligations as distributors and importers, ensure their platforms handle product documentation and CE marking correctly, and build secure checkout and customer data flows that satisfy both CRA and GDPR.

SBOM generation and management. I set up automated SBOM generation pipelines for Rails and Solidus projects using CycloneDX. Every deployment automatically generates an up to date SBOM that can be provided to authorities on request. This isn't just compliance, it's good practice. Knowing exactly what's in your software means you can respond instantly when the next Log4Shell style vulnerability drops.

Vulnerability management workflows. I build and implement vulnerability handling processes that satisfy CRA requirements. That includes setting up security contact pages (security.txt), vulnerability reporting forms, triage workflows, patch management processes, and the notification pipelines needed for the 24 hour ENISA reporting requirement.

Penetration testing and security audits. Using Kali Linux and industry standard tools, I conduct security assessments of web applications, APIs, and infrastructure. This includes network reconnaissance, vulnerability scanning, web application testing, and social engineering assessment. Every finding gets documented with severity ratings and remediation guidance, which feeds directly into your CRA technical documentation.

Infrastructure hardening on Linux. All my production systems run on Linux (as discussed in my previous post on European digital sovereignty), and I harden them according to CIS benchmarks. That means proper firewall configuration, SSH hardening, regular patching, minimal attack surfaces, and ongoing monitoring. For Solidus and Rails deployments, that means Nginx or Caddy with proper TLS configuration, Docker containers with minimal base images, and automated security updates.

Growth hacking that doesn't compromise security. This is the bit that makes my approach different. Many growth hackers bolt on tracking scripts, third party widgets, and marketing tools without thinking about the security implications. I build growth systems that are secure by design: first party analytics, privacy respecting tracking, secure form handlers, and marketing automation that complies with both GDPR and CRA requirements.

What Should You Do Right Now?

If you've read this far, you're probably wondering where to start. Here's my recommended priority list.

First, determine your scope. Figure out whether your products fall under the CRA, NIS2, or both. If you distribute any software or connected hardware in the EU, assume you're in scope until proven otherwise.

Second, audit your software stack. Generate an SBOM for every product. Identify all dependencies, including transitive ones. Flag anything that's unmaintained, has known vulnerabilities, or lacks a clear security contact.

Third, establish a vulnerability handling process. Create a security policy, set up a security contact (like a security.txt file), define your triage and remediation workflow, and test it with a simulated incident.

Fourth, prepare for reporting. The September 2026 deadline is coming fast. You need processes and tooling in place to detect, assess, and report vulnerabilities to ENISA within 24 hours. That means monitoring, alerting, and a clear chain of command.

Fifth, document everything. Start building your technical documentation now. Risk assessments, security architecture, SBOM, vulnerability management procedures, update policies. You'll need all of this for conformity assessment.

Sixth, integrate security into your pipeline. If security is something you "do later" or "before release," you're going to struggle. Build automated security testing into your CI/CD pipeline. Make it impossible to ship code that hasn't been scanned.

The CRA is not going away. The deadlines are real. The fines are substantial. But the opportunity is equally real: businesses that embrace secure by design principles will build better products, earn more trust, and gain a genuine competitive edge in the European market.

If you need help getting there, especially with Ruby on Rails, Solidus, or custom SaaS platforms, that's literally what I do. Let's talk.