Intro
The "Wild West" era of European software development–where you could ship code with known vulnerabilities and "fix it in post" (or never)–is officially over.
If you’ve been hanging around the water cooler lately, you’ve likely heard two acronyms thrown around like threats: NIS2 and the CRA. While they might sound like boring bureaucratic alphabet soup, they represent a tectonic shift in how we build, deploy, and maintain software in the EU.
Here is the reality: You cannot achieve NIS2 compliance if your software products ignore the Cyber Resilience Act. Let’s break down why this connection is the most important thing on your roadmap for 2026.
1. The CRA: Security is No Longer a "Feature"
The Cyber Resilience Act (CRA) is the EU’s way of saying that software is now a "product" just like a toaster or a car. If it has digital elements and is sold in the EU, it must meet a baseline of security requirements.
The CRA mandates:
Security by Design: No more hardcoded passwords or open-by-default ports.
Mandatory Security Updates: You are legally required to provide security patches for the "expected lifetime" of the product.
Vulnerability Reporting: Critical exploited vulnerabilities must be reported to ENISA within 24 hours.
Essentially, the CRA places the "Duty of Care" directly on the shoulders of the manufacturer (that’s us, the devs).
2. The NIS2 Connection: The Customer is Watching
While the CRA focuses on the product, the NIS2 Directive focuses on the entity. NIS2 mandates that "Essential and Important Entities" (banks, energy grids, healthcare, and even large-scale manufacturing) must secure their supply chains.
This is where the connection becomes a pincer movement:
If you sell software to a company that falls under NIS2, they are now legally required to audit their supply chain. If your software isn't CRA-compliant, you are a "weak link."
Your B2B customers won't just ask if you're secure; they will demand CRA compliance documentation (like an SBOM and CE marking) to satisfy their own NIS2 auditors. If you can't provide it, they can't buy from you. Period.
3. Bridging the Gap: Practical Integration
How do we actually align these two? It comes down to moving from "vibe coding" to evidence-based engineering.
Step 1: The SBOM is Your Passport
A Software Bill of Materials (SBOM) is the bridge between the CRA and NIS2. The CRA requires you to maintain one; the NIS2 entity needs it to perform risk assessments.
- Action: Automate your SBOM generation in your CI/CD pipeline using tools like CycloneDX or SPDX.
Step 2: Defining the "Lifetime" of Code
Under the CRA, you must define how long you will support a product. This directly feeds into a NIS2 entity’s "Business Continuity Plan."
- Action: Explicitly state your security support lifecycle in your documentation. No more "best effort" patching.
Step 3: Closing the 24-Hour Loop
The CRA's reporting window is brutal. If an exploit is found, the clock starts.
- Action: You need a formalized Incident Response (IR) plan that connects your dev team directly to your legal/compliance officers.
4. Why This is Your Competitive Advantage
Right now, most teams are terrified of the CRA. They see it as a hurdle. But if you embrace the connection to NIS2 early, you turn compliance into a marketing superpower.
When you can tell a lead architect at a major European bank, "Our product is CRA-certified and we provide automated SBOMs for your NIS2 audits," you've just removed 90% of their friction in the procurement process.
Conclusion: The New Standard Library
Security is no longer a "nice-to-have" or a toggle in your settings. In the EU, it is a license to operate. The CRA and NIS2 are the new boundaries of our sandbox.
The devs who thrive in 2026 will be those who realize that Product Security (CRA) is the foundation upon which Infrastructure Security (NIS2) is built.
Top comments (0)