CRA Art.7: Vulnerability Handling Requirements 2026 — Building Security Into Your SDLC Before September

Post #6 in the sota.io EU Cyber Resilience Act (CRA) 2026 Compliance Series

With September 11, 2026 approaching, EU software manufacturers and cloud service providers face a layered compliance challenge under the Cyber Resilience Act. Most attention has focused on the runtime obligations — Art.10's active vulnerability management, Art.11's 24-hour ENISA notification, Art.14's CVD coordination window. But Art.7 sits upstream of all of these: it governs how vulnerability handling must be built into your development process long before any vulnerability is discovered or exploited.

This distinction matters enormously for teams running their development infrastructure on US-hosted platforms.

What CRA Article 7 Actually Requires

Art.7 (Vulnerability Handling Requirements for Products with Digital Elements) establishes mandatory obligations for manufacturers — not operators or end users. The key requirements:

1. Vulnerability Disclosure Policy (VDP)

Manufacturers must publish and maintain a coordinated vulnerability disclosure policy that specifies:

• How security researchers and third parties can report vulnerabilities
• Expected response timelines
• Whether a bug bounty program exists
• How the manufacturer will acknowledge and communicate findings

This isn't optional guidance — it's a hard legal requirement for every product covered by the CRA.

2. Contact Point for Security Reporting

You must designate and publicize a dedicated contact for receiving vulnerability reports. A generic info@ address doesn't satisfy this. The contact must be monitored, responsive, and capable of triaging security reports.

3. Vulnerability Tracking and Patching Process

Art.7 requires documented processes for:

• Identifying and cataloguing vulnerabilities (including in third-party components and open-source dependencies)
• Prioritizing remediation based on severity and exploitability
• Deploying patches within defined timelines
• Notifying affected users when critical patches are available

4. CVE Assignment and Tracking

Manufacturers must cooperate with CVE (Common Vulnerabilities and Exposures) authorities. For software distributed in the EU market, this increasingly means engaging with ENISA's European Vulnerability Database (EUVDB) and ensuring discovered vulnerabilities are assigned CVE identifiers.

5. Security Testing Integration

Art.7 implies — and the CRA's Annex I makes explicit — that security testing (penetration testing, static analysis, dependency scanning, fuzzing) must be part of the regular development lifecycle. Ad-hoc security checks at release time are insufficient.

Art.7 vs Art.10 vs Art.11 vs Art.14: The Four-Layer Framework

The CRA's vulnerability provisions form a progression from build-time to runtime:

Art.7 is the foundation. Without it, you cannot meaningfully comply with Art.10, 11, or 14 — because you lack the processes, contacts, and tracking infrastructure those articles assume you have.

The CLOUD Act Dimension: Where Art.7 Meets US Jurisdiction

Here is where teams using US-hosted development platforms face a specific risk that most compliance frameworks miss.

Your Development Infrastructure Holds Sensitive Vulnerability Data

When your team is working on Art.7 compliance — tracking vulnerabilities in your issue tracker, discussing patches in your code review tool, running security scans in your CI/CD pipeline — that data exists somewhere. If that somewhere is a US-based platform, it is subject to the CLOUD Act.

The CLOUD Act (18 U.S.C. § 2713) requires US-based providers to comply with valid US legal process for data stored anywhere in the world, including EU data centers. This creates three specific exposure vectors during Art.7-mandated vulnerability handling work:

Exposure Vector 1: Issue Tracker — Vulnerability Details Before Patch

When your security team files an issue tracking a newly discovered vulnerability — before a fix exists — that issue contains:

• Vulnerability description and reproduction steps
• Affected versions and component analysis
• CVE assignment discussions
• Internal severity assessment

If this lives in GitHub Issues, Jira Cloud (Atlassian Delaware C-Corp), or Linear (Delaware) — a US law enforcement agency could, via NSL or court order, compel the US provider to produce this data while the vulnerability is unpatched and undisclosed. This is precisely the window when exposure causes maximum damage.

Exposure Vector 2: Code Review — Patch Details Under Gag Order

During security patch development, your code review system contains:

• The exact code that eliminates the vulnerability (which inversely reveals the vulnerability)
• Reviewer discussion of security implications
• Links between vulnerability reports and fix commits

GitHub Pull Requests (Microsoft NASDAQ:MSFT), GitLab.com (GitLab Inc. Delaware), and Bitbucket (Atlassian Delaware) are all subject to CLOUD Act requests. A gag order accompanying such a request means your team cannot inform your CISO, legal counsel, or ENISA — even if Art.11's 24h notification clock is already running.

Exposure Vector 3: CI/CD Security Scans — SBOM and Vulnerability Reports

Your CI/CD pipeline running SAST (Static Application Security Testing), SCA (Software Composition Analysis), or dependency scanning produces detailed reports that enumerate every known vulnerability in your software. These reports, stored on GitHub Actions, CircleCI, Travis CI (Idera Texas), or Buildkite (US entity) servers, constitute an attacker's roadmap to your product.

A CLOUD Act request targeting these artifacts would give the requesting party a comprehensive vulnerability assessment of your product — before you've patched anything.

The September 2026 Compliance Deadline — What Art.7 Requires in Practice

Timeline

• March 2025: CRA entered into force
• September 11, 2026: Art.7 obligations apply to products placed on EU market
• December 2027: Full CRA applicability including certification requirements

For products already in the EU market, September 2026 is the operative date for Art.7 compliance.

What Auditors Will Check

When EU market surveillance authorities evaluate Art.7 compliance, they will examine:

1. Published VDP: Is there a public URL for your vulnerability disclosure policy? Does it specify timelines?
2. Contact accessibility: Can a security researcher find and use your designated security contact?
3. Internal process documentation: Can you demonstrate documented procedures for triage, patching, and disclosure?
4. CVE participation: Are your disclosed vulnerabilities appearing in NVD/EUVDB?
5. SBOM currency: Is your Software Bill of Materials current and does it reflect known-vulnerability status?
6. Security testing records: Can you show that security testing occurs in your CI/CD pipeline, not just ad-hoc at release?

The CRA Art.52 Penalty Framework Context

Non-compliance with Art.7 obligations falls under the CRA's administrative penalty structure. The maximum fine for essential requirements violations — which include Art.7 — is €15 million or 2.5% of global annual turnover, whichever is higher. For EU-registered SMEs, reduced penalties apply, but the legal exposure is real.

Building an Art.7-Compliant Development Stack on EU Infrastructure

The most complete solution to CLOUD Act exposure in your Art.7-mandated processes is migrating your development infrastructure to EU-jurisdictional platforms. Here's a concrete architecture:

Issue Tracking and Vulnerability Management

EU-native options:

• Gitea (MIT license, self-hosted, German community stewardship) — run on sota.io or your own EU server
• Forgejo (Gitea fork, strong EU community, Codeberg.org hosted in DE)
• GitLab CE (self-hosted, AGPL, can run on EU infrastructure with EU legal entity as provider)
• Plane (open source, self-hosted, European option for Jira-alternative)

The key requirement: your issue tracker for security findings must be hosted on infrastructure where no US legal entity has backend access — not even as a cloud provider.

Code Review

EU-native options:

• Forgejo/Gitea PRs — built-in, self-hosted
• GitLab CE self-hosted on EU infrastructure
• Gerrit (Google-originated but open source, self-hostable)

The CLOUD Act risk in code review is highest during active security patch development. Gitea/Forgejo hosted on sota.io means your security-sensitive code review happens under EU jurisdiction with no US-provider intermediary.

CI/CD Pipeline

EU-native options:

• Woodpecker CI (FOSS, German open-source project, excellent Gitea integration)
• Forgejo Actions (GitHub Actions-compatible, FOSS)
• self-hosted GitLab CI/CD
• Tekton (CNCF, cloud-neutral, run on EU Kubernetes cluster)

For security scanning, EU-native options include:

• Trivy (Aqua Security, open source SBOM/vulnerability scanner)
• OWASP Dependency-Check (self-hosted)
• Semgrep CE (open source SAST)

Vulnerability Database Integration

Regardless of where your development infrastructure runs, your CVE/EUVDB integration can be EU-routed:

• ENISA EUVDB: direct API (EU-operated)
• NVD: read-only access doesn't expose your data
• OSV.dev: open source, no US-provider data retention

Art.7 Compliance Checklist for September 2026

Must-Have (Legal Requirements)

• Published Vulnerability Disclosure Policy with timeline commitments
• Designated security contact at a monitored address (security@yourdomain.com)
• Internal documented process for vulnerability triage and patching
• CVE assignment process (either direct CNA status or working with an existing CNA)
• SBOM generation for each release
• Security testing in CI/CD (SAST, SCA, dependency scanning — automated)
• Process connecting Art.7 tracking to Art.10 active management and Art.11 notification

Strongly Recommended (Risk Reduction)

• Security-sensitive issue tracking on EU-jurisdictional infrastructure
• Code review for security patches on EU-hosted platforms
• SBOM stored in EU-controlled artifact registry
• Security scan results retained in EU-hosted storage

Optional (Competitive Differentiation)

• Bug bounty program with defined scope and rewards
• Public security hall of fame
• ENISA EUVDB reporter status
• ISO 29147 (vulnerability disclosure) and ISO 30111 (vulnerability handling) alignment

Why Hosting Jurisdiction Determines Your Art.7 Risk Profile

A common misconception: "our data is stored in an EU AWS/Azure/GCP region, so we're covered."

This misunderstands how the CLOUD Act works. Data residency ≠ legal jurisdiction. AWS (Amazon Delaware C-Corp), Azure (Microsoft Delaware), and GCP (Google Delaware) are all US legal entities. The CLOUD Act gives US courts jurisdiction over data held by US companies regardless of where that data physically resides. An AWS EU (Frankfurt) S3 bucket holding your vulnerability reports is fully subject to CLOUD Act requests targeting Amazon.

EU-native cloud providers — those incorporated under EU law with no US parent company — are not subject to the CLOUD Act. A Woodpecker CI pipeline running on sota.io, with scan results stored in EU-operated object storage and security issues tracked in self-hosted Forgejo, presents a fundamentally different (and smaller) CLOUD Act attack surface than the same pipeline on GitHub Actions with Jira Cloud.

For Art.7 compliance under the CRA, the question isn't just "do we have the processes?" but "can those processes be compromised by extra-EU legal proceedings?" Teams that migrate their security development infrastructure to EU-native platforms reduce this risk to near zero — and can document that reduction for market surveillance authorities.

The CRA Series: What Comes Next

This post completes the core CRA vulnerability-management framework for software manufacturers:

1. Art.10: Active Vulnerability Management — Runtime monitoring, patch deployment, ENISA reporting
2. Art.11: Actively Exploited Vulnerabilities — 24h/72h/14d notification cascade
3. Art.14: Coordinated Vulnerability Disclosure — 9-month CVD window for third-party reports
4. Art.13: Security by Design — Architecture-level requirements
5. Penalty Framework — €15M/2.5% enforcement structure
6. Art.7: Vulnerability Handling in the SDLC (this post) — Development-time requirements

Together, these articles form the complete CRA compliance picture for EU software manufacturers. The September 2026 deadline is 121 days away. Teams that have not started their compliance audit should do so now — and consider whether their development infrastructure's legal jurisdiction strengthens or undermines their Art.7 posture.

sota.io provides EU-native PaaS infrastructure for European developers and software manufacturers building CRA-compliant products. Our platform runs exclusively under EU jurisdiction with no US parent company — meaning your development workloads on sota.io are outside CLOUD Act reach.