CRA Art.11: Vulnerability Handling — SBOM Tracking, Responsible Disclosure, and the Ban on Shipping Known Bugs (Developer Guide 2026)

Post #461 in the sota.io EU Cyber Compliance Series

The EU Cyber Resilience Act (Regulation (EU) 2024/2847, "CRA") imposes obligations at every stage of a product's life. Article 13 defines what you must build before you ship. Article 10 defines what you must maintain after you ship. Article 11 sits at the intersection: it defines how you must handle vulnerabilities — and it contains one obligation that most developers have not yet absorbed.

You cannot place a product with a known exploitable vulnerability on the EU market without a concurrent patch. That is not a best-practice recommendation. It is a legal prohibition that takes effect on 11 December 2027, backed by penalties up to €15 million or 2.5% of worldwide annual turnover.

Article 11 also mandates:

• An SBOM maintained throughout the product's supported lifetime (not only at release)
• A published Coordinated Vulnerability Disclosure (CVD) policy with a functional contact point
• Handling of disclosed vulnerabilities without undue delay
• Security updates made available at no additional charge to users
• User notification when a security update requires manual action

This guide walks through every Art.11 obligation with implementation guidance for software teams. It explains what SBOM-based vulnerability tracking means operationally, what "undue delay" looks like in practice, and how Art.11 relates to the 24-hour ENISA reporting obligation in Art.14.

The Core Prohibition: No Known Exploitable Vulnerabilities

Art.11(1) states that manufacturers shall not place on the market a product with digital elements that contains a known exploitable vulnerability, except where that vulnerability is remediated or mitigated at the time of placing on the market or is being disclosed pursuant to a coordinated vulnerability disclosure procedure.

Three things make this significant:

First, it is not limited to "critical" vulnerabilities. The prohibition applies to any known exploitable vulnerability. Whether a CVSS score is 9.8 or 5.1, if the vulnerability is known to the manufacturer and exploitable, placing the product on the market without a concurrent fix violates Art.11.

Second, "known" means known to the manufacturer, not publicly known. If your internal security scan, a third-party audit, or a researcher report has identified an exploitable vulnerability and you ship the product anyway pending a patch, you are in breach — even if the vulnerability has not yet been publicly disclosed.

Third, the exception for CVD disclosure is narrow. The carve-out applies when you are actively working through a coordinated disclosure process — the vulnerability has been reported, you are remediating, and you are disclosing in coordination with the national CSIRT or researcher. It is not a general exception for "we know about it but haven't fixed it yet."

What This Means for Release Pipelines

For teams with continuous deployment and short release cycles, Art.11 requires that vulnerability scanning become a gate condition, not a post-release activity.

Practically, this means:

1. Pre-release SBOM scan: Every release must include an SBOM scan against known CVE databases (NVD, ENISA's EUVDB once operational) before deployment.
2. Known-vuln policy: Any CVSS ≥ 4.0 (exploitable) finding must either be patched, have a documented mitigation, or be managed under an active CVD process before release.
3. Pipeline block: CI/CD pipelines should block deployment if the SBOM scan returns exploitable vulnerabilities without a documented exception.

This is a structural change for many teams. The alternative — patch after release as a normal workflow — is legally compliant under NIS2 but not under CRA Art.11.

SBOM-Based Vulnerability Tracking (Art.11(1)(b))

Art.11 requires manufacturers to identify and document vulnerabilities and components contained in their products throughout the product's support period, including through an SBOM in a machine-readable format.

This goes beyond the point-in-time SBOM many developers think of. The CRA requires an SBOM that evolves with the product:

• When you add a new dependency, the SBOM must reflect it
• When a component in your SBOM receives a CVE, you are expected to become aware of it through your monitoring process
• When a component is updated or removed, the SBOM must be updated

SBOM Formats

The CRA does not mandate a specific SBOM format, but the European Commission's guidance points to established machine-readable standards:

• SPDX (ISO/IEC 5962:2021): Widely supported, XML and JSON formats, strong licensing metadata
• CycloneDX: JSON/XML, strong vulnerability linking through VEX (Vulnerability Exploitability eXchange) documents
• SWID (ISO/IEC 19770-2): Software identification tags, used in enterprise procurement contexts

For most software teams, CycloneDX with VEX is the strongest choice for Art.11 compliance: VEX documents allow you to record not only what vulnerabilities your SBOM components have, but whether they are exploitable in your specific product context. This distinction matters under Art.11 — a vulnerability in a component you ship is not automatically a violation if the vulnerable code path is not reachable in your product configuration.

Automated SBOM Maintenance

Manual SBOM maintenance does not scale. A compliant approach for ongoing tracking:

# sbom_tracker.py — example continuous SBOM vulnerability monitor
import json
import requests
from pathlib import Path
from datetime import datetime, UTC


NVD_API = "https://services.nvd.nist.gov/rest/json/cves/2.0"
SBOM_PATH = Path("sbom.cdx.json")
REPORT_PATH = Path("vulnerability-report.json")


def load_sbom() -> list[dict]:
    with open(SBOM_PATH) as f:
        sbom = json.load(f)
    return sbom.get("components", [])


def query_nvd(cpe: str) -> list[dict]:
    resp = requests.get(
        NVD_API,
        params={"cpeName": cpe, "resultsPerPage": 20},
        headers={"Accept": "application/json"},
        timeout=15,
    )
    resp.raise_for_status()
    return resp.json().get("vulnerabilities", [])


def check_components(components: list[dict]) -> list[dict]:
    findings = []
    for comp in components:
        cpe = comp.get("cpe")
        if not cpe:
            continue
        vulns = query_nvd(cpe)
        for v in vulns:
            cve = v.get("cve", {})
            cvss_score = (
                cve.get("metrics", {})
                .get("cvssMetricV31", [{}])[0]
                .get("cvssData", {})
                .get("baseScore", 0)
            )
            if cvss_score >= 4.0:
                findings.append({
                    "component": comp.get("name"),
                    "version": comp.get("version"),
                    "cve_id": cve.get("id"),
                    "cvss": cvss_score,
                    "description": cve.get("descriptions", [{}])[0].get("value", ""),
                    "detected_at": datetime.now(UTC).isoformat(),
                })
    return findings


def write_report(findings: list[dict]) -> None:
    with open(REPORT_PATH, "w") as f:
        json.dump({"generated": datetime.now(UTC).isoformat(), "findings": findings}, f, indent=2)
    print(f"[sbom_tracker] {len(findings)} exploitable findings → {REPORT_PATH}")


if __name__ == "__main__":
    components = load_sbom()
    findings = check_components(components)
    write_report(findings)
    if findings:
        print("[sbom_tracker] ACTION REQUIRED — exploitable vulnerabilities found")
        raise SystemExit(1)

This script can be run in CI/CD as a gate. If it exits non-zero, the deployment should be blocked pending triage.

VEX Integration

For components with known CVEs that you have assessed as non-exploitable in your product, a VEX document records the justification:

{
  "vulnerabilities": [
    {
      "id": "CVE-2024-12345",
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "The vulnerable code path in libxyz requires HTTP multipart upload which this product does not use.",
        "response": ["will_not_fix"]
      },
      "affects": [
        {"ref": "pkg:npm/libxyz@2.3.1"}
      ]
    }
  ]
}

A VEX document with not_affected + code_not_reachable is the correct way to document why a CVE in your dependency does not constitute a violation of Art.11(1) — the vulnerability is known, but it is not exploitable in your product context.

CVD Policy and Contact Point (Art.11(1)(c) and (d))

Art.11 requires manufacturers to put in place and enforce a coordinated vulnerability disclosure policy and to designate a contact point for receiving vulnerability reports from users, security researchers, and national authorities.

What the CVD Policy Must Cover

The CRA does not prescribe a template, but a compliant CVD policy should address:

1. Scope: Which products and versions the policy covers
2. Contact: A dedicated security email (e.g., security@yourcompany.com) and optionally a PGP key
3. Acknowledgement SLA: How quickly you will confirm receipt (industry standard: 24-72 hours)
4. Triage SLA: How quickly you will determine severity and exploitability (industry standard: 5-10 business days)
5. Patch timeline: Your target for releasing fixes based on severity — e.g., CVSS ≥ 9: 7 days; CVSS 7-8.9: 30 days; CVSS 4-6.9: 90 days
6. Disclosure timeline: When and how you will publicly disclose after a fix is available
7. Safe harbour: A clear statement that researchers who follow the policy will not face legal action for good-faith security research

The Contact Point as Legal Requirement

Art.11(1)(d) makes the contact point a legal obligation, not a courtesy. If a user or researcher reports a vulnerability and cannot reach you because no functional channel exists, that is a compliance failure independent of whether an actual vulnerability existed.

For software-as-a-service products, the contact point requirement extends to your deployed instances — not only to a downloadable product.

Minimum viable implementation:

# security.txt — place at /.well-known/security.txt per RFC 9116
Contact: mailto:security@yourcompany.com
Encryption: https://yourcompany.com/pgp-key.txt
Acknowledgments: https://yourcompany.com/security/hall-of-fame
Policy: https://yourcompany.com/security/vulnerability-disclosure-policy
Preferred-Languages: en, de
Expires: 2027-04-19T00:00:00.000Z

The Preferred-Languages field is worth noting: the CRA applies EU-wide, so including the language of your establishment country alongside English is good practice.

Handling Disclosed Vulnerabilities Without Undue Delay (Art.11(1)(e))

When a vulnerability is reported or discovered, Art.11 requires the manufacturer to handle it "without undue delay." The CRA does not define "undue delay" numerically — it is a context-sensitive standard that national market surveillance authorities (MSAs) will apply based on:

• Exploitability: How easily can the vulnerability be weaponised?
• Severity: What is the potential impact on users?
• Patch complexity: How difficult is a fix? A one-line input validation fix has no legitimate reason for a 90-day delay; a cryptographic architecture flaw may reasonably require longer.
• Industry practice: What do comparable manufacturers do for similar severity?

Practical Timeline Framework

While "undue delay" is not defined, aligning with established industry timelines provides a defensible baseline:

These thresholds reflect common CVD programme standards (Google Project Zero, CERT/CC). They are not legally mandated, but using them demonstrates that your vulnerability response is calibrated to accepted industry norms.

Documentation Requirements

For each disclosed vulnerability, maintain a record covering:

• Date of initial report or discovery
• Date of acknowledgement to reporter
• Date of severity assessment completion
• Date of fix development start
• Date of fix availability (patch release)
• Date of public disclosure
• CVSS score at time of assessment
• Any extensions and their justification

This documentation is what an MSA will request during an investigation. Absence of records is itself evidence of non-compliance — it suggests there was no structured vulnerability management process.

Security Updates: Free, Separable, and Easy to Apply (Art.11(1)(f))

Art.11 requires that security updates be:

1. Made available without undue delay after the fix is ready
2. Free of charge to users — manufacturers cannot charge for security updates
3. Separable from feature updates where possible — a user should not be required to accept new features to receive a security patch
4. Easy to apply — where an update requires user action, clear notification and installation guidance must be provided

The "separable from features" requirement has practical implications for software teams that bundle security fixes into major feature releases. Under CRA Art.11, if a security fix is available before the next feature release, it should be shipped independently. Holding a security fix until a feature release to maintain a "clean" changelog is not compliant.

Hotfix Branch Strategy

A compliant release process includes a hotfix branch strategy separate from the main development branch:

main (feature development)
 │
 ├─ release/1.4.x (current supported release)
 │    └─ hotfix/CVE-2026-XXXXX → security-only patch
 │
 └─ release/1.3.x (previous supported release, LTS)
      └─ backport hotfix/CVE-2026-XXXXX → backport if still in support window

When a CVSS ≥ 4.0 vulnerability is confirmed, the fix should be merged to all supported release branches and shipped via the hotfix path — independent of what is happening on the main branch.

Art.11 vs Art.14: Vulnerability Handling vs ENISA Reporting

Art.11 and Art.14 are often conflated. They are distinct obligations with different triggers:

In practice, an actively exploited vulnerability triggers both Art.11 (you must handle it and release a fix without undue delay) and Art.14 (you must notify ENISA within 24 hours). Most vulnerabilities will only trigger Art.11 — the requirement to handle, patch, and notify users — without reaching the Art.14 threshold of active exploitation.

CRA × NIS2 Overlap

If your organisation is also subject to NIS2 (as an essential or important entity), be aware that NIS2 Art.23 imposes incident notification obligations to national CSIRTs on a similar timeline (24h early warning, 72h full notification). The trigger in NIS2 is a security incident affecting the availability, integrity, or confidentiality of your services — different from CRA's vulnerability-in-product framing.

When a vulnerability is actively exploited against your product and your service is affected:

• CRA Art.14: You notify ENISA about the vulnerability in the product
• NIS2 Art.23: You notify the national CSIRT about the incident affecting your service

These may be two separate notifications about the same underlying event, addressed to different bodies.

Art.11 Compliance Checklist

Use this checklist to assess your organisation's current Art.11 readiness:

SBOM and Vulnerability Tracking

• SBOM generated at release in SPDX or CycloneDX format
• SBOM updated continuously as dependencies change
• Automated CVE monitoring against SBOM components (NVD, ENISA EUVDB)
• VEX documents maintained for known CVEs assessed as non-exploitable
• CI/CD gate blocks deployment when exploitable CVEs are found without documented mitigation

Pre-Release Prohibition Compliance

• Pre-release security scan integrated into deployment pipeline
• Release policy documented: no known CVSS ≥ 4.0 without patch or VEX exception
• Exception process defined for CVD-managed disclosures (concurrent disclosure)

CVD Policy and Contact Point

• CVD policy published at https://yourcompany.com/security/policy
• /.well-known/security.txt deployed per RFC 9116
• Security contact email monitored with ≤72h acknowledgement SLA
• Safe harbour language included in CVD policy

Vulnerability Response Process

• Severity classification criteria documented (CVSS thresholds)
• Patch timeline targets defined per severity tier
• Vulnerability tracking record maintained (discovery → patch → disclosure dates)
• Hotfix branch strategy in place for separable security releases

Security Update Distribution

• Security updates released independently from feature updates where possible
• Security updates free of charge to all users
• User notification process for updates requiring manual action

Art.11 vs Art.14 Readiness

• Process defined for escalating from Art.11 (vulnerability) to Art.14 (active exploitation trigger)
• 24-hour ENISA notification runbook in place for Art.14 activation
• NIS2 incident notification overlap mapped (if NIS2 also applies)

What Applies from September 2026 vs December 2027

Art.11 forms part of the December 2027 obligation set — the full CRA manufacturer obligations. However, two elements of the vulnerability management framework apply earlier:

• September 2026 (Art.14): Notification of actively exploited vulnerabilities to ENISA (24-hour early warning, 72-hour full notification). You need the internal monitoring and escalation process in place for Art.14 by September 2026 — and that infrastructure also underpins Art.11 compliance.
• December 2027 (Art.11): All remaining vulnerability handling obligations: the pre-release prohibition, SBOM maintenance, CVD policy, and update management.

The practical implication: start building the SBOM and CVD infrastructure for September 2026 (Art.14 readiness), and you are building the foundation that Art.11 requires anyway. Teams that wait until 2027 for "the full compliance sprint" will hit September 2026 without the monitoring and notification infrastructure Art.14 requires — and then face a compressed timeline to complete Art.11 at the same time.

CRA Series Index

This post is part of the sota.io CRA Developer Series:

• CRA Art.2: Scope — Does the CRA apply to your product?
• CRA Art.3: Definitions — Key terms explained
• CRA Art.6: Essential Requirements — What you must build in
• CRA Art.7: Presumption of Conformity — Using harmonised standards to demonstrate compliance
• CRA Art.8: OSS Stewards — Lighter obligations for open-source foundations
• CRA Art.9: Third-Party Due Diligence — SBOM obligations and supply chain due diligence
• CRA Art.10: Product Lifecycle — Ongoing post-market security obligations
• CRA Art.11: Vulnerability Handling ← You are here
• CRA Art.12: Authorised Representative — EU mandate requirements for non-EU manufacturers
• CRA Art.13: Manufacturer Obligations — SBOM, documentation, and conformity assessment
• CRA Art.14/16: ENISA Reporting — 24-hour notification and CVD

The September 2026 deadline for Art.14 ENISA reporting is under five months away. Art.11 builds on the same infrastructure. The time to start is now.