The EU's Cyber Resilience Act (CRA) is reshaping how software vendors operate - and the clock is ticking. If you ship code into the EU market, whether you're based in Brussels or Boston, new security-by-default requirements are now a legal reality. For platform engineering teams, this isn't just a compliance burden: it's a strategic opportunity to embed security, transparency, and resilience directly into your internal developer platforms.

Main insights

• The CRA requires all software shipped into the EU to be secure by default, with mandatory Software Bills of Materials (SBOMs), vulnerability scanning, and 24-hour incident reporting starting September 11, 2026
• Platform teams can operationalize CRA compliance by embedding SBOM generation, CVE scanning, and cryptographic signing directly into CI/CD pipelines
• Open-source tools like Syft, Trivy, and OSV Scanner make it possible to meet CRA requirements without expensive enterprise solutions
• This regulation gives platform engineers concrete leverage to justify investment in secure-by-design platforms, observability, and automated vulnerability management

Nigel Douglas, Head of Developer Relations at Cloudsmith, recently walked through the practical steps platform engineering teams can take to meet CRA requirements without slowing down development velocity. Douglas specializes in artifact management, supply chain security, and helping DevOps communities navigate the intersection of compliance and engineering practice.

You can watch the full discussion here if you missed it.

What is the Cyber Resilience Act?

The CRA is the EU's first comprehensive regulation focused on the security of software products. Unlike GDPR, which protects user data, the CRA targets the code itself. Nigel summarized it plainly: "If you ship code - software, apps, firmware, APIs - into the EU market, it must be secure by default. And you're now responsible for fixing it when it breaks."

This is not a one-time certification. It's a continuous obligation. If a vulnerability is discovered after your software ships, you must have a reliable process to patch it. If something is actively exploited in the wild, you have 24 hours to file an early warning with ENISA (the European Union Agency for Cybersecurity), followed by a detailed report within 72 hours.

The stakes are significant. Penalties for non-compliance can reach €15 million or 2.5% of global annual turnover, whichever is higher. As Douglas noted, "Saying 'I didn't know this was a problem' is not legally considered a defensible comment."

The five requirements of CRA compliance

Douglas distilled the regulation into five practical obligations every platform team needs to understand:

1. No exploitable vulnerabilities: You cannot ship code with known, exploitable vulnerabilities. This means scanning dependencies against databases like the National Vulnerability Database (NVD), CISA's Known Exploited Vulnerabilities (KEV) catalog, and OSV (Open Source Vulnerabilities).
2. Secure by default: This includes avoiding plain-text passwords, disabling unused features, and following least-privilege principles. Tools like TruffleHog can scan for exposed credentials across code, models, and container images.
3. Software Bill of Materials (SBOM): You must generate an SBOM at build time listing all dependencies, their versions, licenses, and known vulnerabilities. The CRA accepts two formats: CycloneDX (maintained by OWASP) and SPDX (maintained by the Linux Foundation).
4. Continuous monitoring and patching: You must monitor for new vulnerabilities after release and maintain a process to patch them quickly - what the CRA refers to as a "24/7/365 patching mechanism."
5. Cryptographic verification: All releases, SBOMs, and artifacts must be cryptographically signed to prevent tampering and ensure authenticity.

Why SBOMs are the foundation

An SBOM is essentially a structured JSON or XML file that inventories every dependency in your software, including transitive dependencies - the dependencies of your dependencies. The scope can be surprising. Douglas demonstrated how a simple Python application with five direct dependencies can expand to over 600 packages once you account for the base container image, Go modules for Kubernetes, and all transitive dependencies.

"You end up with this kind of weird world of saying I pushed a Docker container, but now 677 known packages," Douglas explained. "Most of it - nearly all of this - you didn't write. Your code sits in that environment, but all the other stuff is written by other people, and you need to be accountable for all of that."

This is exactly why SBOM generation must be automated and embedded in your build process - manual tracking at this scale is not realistic.

How to operationalize CRA compliance in your platform

Platform teams are uniquely positioned to make CRA compliance frictionless for developers. Here's how to build it into your platform:

• Embed SBOM generation in CI/CD: Use tools like Syft or Trivy to generate SBOMs automatically during the build process. A single pipeline step can produce a CycloneDX-formatted SBOM alongside every container image you build.
• Scan for vulnerabilities and malicious code: Integrate OSV Scanner or Trivy into your pipeline to check for known CVEs and compromised packages. Douglas demonstrated scanning a Python requirements.txt file and flagging a malicious version of the lightllm package that had been compromised by the TeamPCP threat actor - a real-world example of why automated scanning matters.
• Fail builds on critical findings: Configure your pipeline to block deployments when it detects critical or high-severity vulnerabilities, or packages known to be actively exploited. This enforces secure-by-default practices without relying on developer discipline alone.
• Cryptographically sign releases: Use tools like Sigstore or GPG to sign container images, SBOMs, and artifacts. This ensures integrity and provides a verifiable chain of custody for every artifact you ship.
• Centralize SBOM storage and monitoring: Use a tool like OWASP Dependency-Track to store SBOMs and continuously monitor them against updated vulnerability feeds. This enables rapid incident response when a new CVE is disclosed against a dependency you're already running in production.

NIgel was clear that none of this requires expensive enterprise tooling: "Nothing in CRA requires you to pay for software. All I'm saying is that you do need to have these things in place."

The platform engineering opportunity

The CRA also gives platform teams real leverage to justify investments they've wanted to make for a long time. As Douglas put it, "If you're building a platform and you feel like internally you're not getting buy-in from different organizations... regulatory compliance and the CRA - the fact that we all have to meet it and comply with it - is even more opportunity to get in to meet regulatory standards."

Use the regulation to make the case for:

• Standardizing secure-by-default pipelines across the organization
• Building observability and incident response capabilities into the platform
• Automating vulnerability management and patching workflows
• Demonstrating measurable risk reduction to leadership

Douglas also highlighted the role of Internal Developer Portals (IDPs) like Backstage in this context. Centralizing visibility over deployments, pipelines, and pull requests gives platform teams the control surface they need to enforce CRA requirements consistently - and to catch non-compliant code before it reaches the stack developers build on.

Key dates and reporting requirements

The CRA's reporting obligations take effect on September 11, 2026. From that date, you must report actively exploited vulnerabilities to ENISA within 24 hours and provide a detailed follow-up report within 72 hours. This applies to any software sold or provided to customers in the EU, regardless of where your company is headquartered.

Douglas framed the significance of this shift: "Unlike today, before CRA comes into force, there was no time-based requirement where you had to get onto an organization like ENISA about exploitation and software dependencies. It just wasn't a thing. Now it will be."

If your logging, alerting, and incident response workflows aren't already in place, September 2026 is closer than it looks.

​

If you enjoyed this, find here more great insights and events from our Platform Engineering Community.

If you want to dive deeper, explore our instructor-led Platform Engineering Certified Professional course and connect with peers from large-scale enterprises who are driving platform engineering initiatives.

​

Key takeaways

• Start generating SBOMs now: Integrate SBOM generation into your CI/CD pipelines using open-source tools like Syft or Trivy. This is the foundation of CRA compliance and gives you immediate visibility into your software supply chain - including the hundreds of transitive dependencies you didn't write but are legally accountable for.
• Automate vulnerability scanning at build time: Use OSV Scanner, Trivy, or similar tools to scan for CVEs and malicious packages before code reaches production. Failing builds on critical findings is the most reliable way to enforce secure-by-default practices at scale.
• Use CRA as a platform engineering mandate: The regulation gives you a concrete, externally-driven reason to standardize secure pipelines, invest in observability, and build incident response into the platform. This is your opportunity to turn compliance into capability.
• Prepare for September 2026: Mark September 11, 2026 on your calendar. That's when the 24-hour reporting requirement for actively exploited vulnerabilities takes effect. Make sure your logging, alerting, and incident response workflows are operational well before that date.