The EU Cyber Resilience Act: Vulnerability Handling Rules Every Software Product Must Meet

What the Cyber Resilience Act Actually Is

For twenty years, shipping insecure software carried no direct legal consequence in most of the world. The CRA changes that for the European market. It is the first horizontal regulation that says: if you place a product with digital elements on the EU market, you are legally responsible for its cybersecurity, for the entire support period.

"Products with digital elements" is deliberately broad. It covers desktop and mobile applications, IoT devices, operating systems, browsers, password managers, and the software components inside them. Pure SaaS is mostly covered by NIS2 instead, but the line is thin: if your product includes a downloadable client, a CLI, a browser extension, a mobile app, or an on-premise component, the CRA applies to that part.

The penalties are not symbolic. Non-compliance with the essential requirements can draw fines of up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher. Products can also be pulled from the EU market entirely.

The Timeline You Are On

September 2026 is already here. If a vulnerability in your product is being actively exploited, you now have a 24-hour early-warning clock. That is not a deadline you can meet if you find out about your vulnerabilities from angry users on X.

The Vulnerability Handling Requirements, Concretely

Annex I of the regulation lists what a manufacturer must do. Translated out of legal language, the vulnerability handling essentials are:

1. Know what is in your product. Identify and document components and dependencies, including a software bill of materials (SBOM) in a machine-readable format covering at least the top-level dependencies.
2. Ship without known exploitable vulnerabilities. Products must be placed on the market without known exploitable vulnerabilities in them.
3. Fix and distribute. Address vulnerabilities without delay and deliver security updates, separately from feature updates where feasible, free of charge.
4. Test regularly. Apply effective and regular tests and reviews of the security of the product.
5. Disclose. Publish a coordinated vulnerability disclosure policy and a contact address for reporting.
6. Report. Notify actively exploited vulnerabilities to the authorities within the 24-hour early-warning window.

Notice that four of the six are things a scanner can verify or automate: dependency inventory, known-CVE checks, regular testing, and a published disclosure route.

Why AI-Generated Code Makes This Harder

The CRA arrives exactly as codebases are getting less auditable. Veracode's 2025 research on AI-generated code found that roughly 45 percent of AI-completed coding tasks introduced a security flaw from the OWASP Top 10. Apiiro reported that AI-assisted repositories ship secrets and sensitive API endpoints at a significantly higher rate than human-written ones. And dependency sprawl is worse: tools like Bolt, Lovable, and Cursor happily add packages to solve any problem, which means your SBOM grows faster than your understanding of it.

A typical AI-assisted repo drifts into exactly the state the CRA prohibits:

// ❌ BAD — package.json in a typical vibe-coded project
{
  "dependencies": {
    "express": "*",            // unpinned, whatever installs today
    "lodash": "latest",        // unpinned
    "left-pad-utils": "^1.0.0" // added by the AI, nobody knows why
  }
  // no lockfile committed, no SBOM, no audit in CI
}

Under the CRA, "we did not know that dependency had a known CVE" is not a defense. The regulation expects you to have a due-diligence process for exactly that.

How to Get Compliant Without a Security Team

The good news: for a small product, the vulnerability handling requirements map to a short, automatable checklist.

# ✅ GOOD — a minimal CRA-aligned pipeline
# 1. Pin everything and commit the lockfile
npm ci

# 2. Generate a machine-readable SBOM (CycloneDX)
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# 3. Scan dependencies for known CVEs on every build
trivy fs --scanners vuln --severity HIGH,CRITICAL .

# 4. Publish a disclosure route
# https://yourapp.com/.well-known/security.txt  (RFC 9116)

Then make the testing "regular" instead of one-off. Tools like VibeDoctor's Vibe Check (vibedoctor.io) automatically scan your codebase and live site for known CVEs in dependencies, leaked secrets, and missing security controls, and flag specific file paths and line numbers, which gives you the recurring evidence trail the CRA's "regular tests and reviews" requirement expects. Free to sign up.

Finally, write the two documents the regulation expects to exist: a one-page coordinated vulnerability disclosure policy, and an internal note describing how you triage and ship security fixes. Neither needs to be long. Both need to be real.

Open Source and the Steward Question

Pure open-source software developed outside a commercial activity is largely out of scope, and the CRA created a lighter "open-source steward" regime for foundations. But the moment you monetize, offer paid support, or integrate open-source components into a commercial product, the obligations attach to you as the manufacturer. You inherit responsibility for the vulnerabilities in every dependency you ship, which is another reason the SBOM requirement exists.

FAQ