ENISA Vulnerability Disclosure + CRA Art.14: CVD Programme Guide for SaaS Teams

Post #4 in the sota.io EU ENISA Secure by Design 2026 Series

The Cyber Resilience Act's vulnerability handling obligations are among the most operationally challenging requirements for SaaS teams. CRA Article 14 doesn't just ask you to fix bugs — it mandates a documented, externally-facing Coordinated Vulnerability Disclosure (CVD) programme with specific timelines, notification channels, and reporting obligations to European cybersecurity authorities.

This post provides a complete implementation guide: what Art.14 actually requires, how ENISA's CVD guidelines map to those obligations, how to set up security.txt, when and how to report to the ENISA European Vulnerability Database (EUVD) and national CSIRTs, and a 60-day roadmap to get your programme operational before the September 2026 CRA deadline.

What CRA Art.14 Actually Requires

CRA Article 14 covers two distinct obligations that are often conflated: vulnerability handling (internal) and vulnerability reporting (external). Both are mandatory.

14(1) — The Internal Handling Obligation

Manufacturers must address vulnerabilities in products "without undue delay, and in any event within the timeframes specified in Annex I, Part II."

Annex I, Part II §8 gives the specific requirements:

• Identify and document vulnerabilities, including components in a Software Bill of Materials (SBOM)
• Remediate vulnerabilities promptly, including by providing security updates
• Apply effective and regular tests and reviews of the product's security
• Publicly disclose information about fixed vulnerabilities, including affected versions and remediation guidance

Practical translation for SaaS: You need a process that takes a vulnerability from discovery → triage → remediation → release → public disclosure, with documented timelines at each stage.

14(2) — The 24-Hour Reporting Obligation

This is the obligation that surprises most teams:

"Manufacturers shall notify ENISA and, where applicable, the relevant national CSIRTs, of any actively exploited vulnerability within 24 hours of becoming aware of it."

"Actively exploited" means evidence of exploitation in the wild — attacker infrastructure scanning for it, proof-of-concept public, or confirmed exploitation attempt against your systems. This is not every vulnerability — it's the subset being actively weaponised.

The 24-hour window runs from when you become aware, not when you confirm exploitation. If your monitoring flags suspicious activity consistent with a known CVE, the clock starts.

14(3) — The Coordinated Disclosure Obligation

For vulnerabilities you discover internally (or receive via third-party disclosure), you must handle them through a documented CVD process. Art.14(3) references ENISA's CVD guidelines as the standard to follow.

14(4) — The security.txt / Contact Channel Obligation

Manufacturers must "designate a point of contact for cybersecurity researchers and third parties to report vulnerabilities." This is the regulatory mandate for a public vulnerability reporting channel — security.txt is the standard mechanism.

14(5) — The SBOM Obligation (connected to disclosure)

When disclosing vulnerabilities, you must reference the affected components. This requires a maintained SBOM. Without it, you cannot fulfil the disclosure obligation because you don't know which of your customers' deployments are affected.

ENISA's CVD Guidelines: The Regulatory Framework

ENISA published updated Coordinated Vulnerability Disclosure guidelines specifically for the CRA context. The key principles:

Principle 1: Good Faith Safe Harbour Researchers who disclose vulnerabilities following your CVD policy should not face legal action. Your policy must explicitly state this. Teams that threaten researchers with legal action for responsible disclosure are in violation of Art.14 spirit and risk enforcement attention.

Principle 2: The 90-Day Disclosure Deadline ENISA recommends a 90-day disclosure timeline as the standard. If you cannot remediate within 90 days:

• Notify the disclosing researcher with an explanation and timeline
• Consider partial disclosure (mitigations available, full patch in progress)
• Coordinate with national CSIRT if the vulnerability affects critical infrastructure users

Principle 3: EUVD Synchronisation When you publish a security advisory, the content should be structured to enable EUVD (European Union Vulnerability Database) indexing. ENISA operates the EUVD as the EU's sovereign vulnerability database — it mirrors CVE data but adds EU-specific context.

Principle 4: National CSIRT Involvement for High-Severity Issues For vulnerabilities with CVSS ≥ 9.0 affecting your product, proactively contact the relevant national CSIRT(s). This is both a regulatory best practice and a relationship investment — CSIRTs can help coordinate disclosure with affected organisations you may not be aware of.

Implementing security.txt

The security.txt standard (RFC 9116) is the primary mechanism for Art.14(4) compliance. It's a plain-text file at /.well-known/security.txt on your domain.

Minimum Required Fields (CRA Art.14 Compliant)

Contact: https://your-saas.example.com/security/report
Contact: mailto:security@your-saas.example.com
Expires: 2027-05-28T00:00:00.000Z
Encryption: https://your-saas.example.com/pgp-key.asc
Policy: https://your-saas.example.com/security/vulnerability-disclosure-policy
Preferred-Languages: en, de, fr
Acknowledgments: https://your-saas.example.com/security/hall-of-fame

Field explanations for Art.14 compliance:

Signing security.txt

RFC 9116 recommends signing security.txt with PGP to prevent tampering. For CRA purposes, a signed file is stronger evidence of your Art.14(4) compliance:

# Generate a security-specific PGP key (do NOT use your personal key)
gpg --full-generate-key
# Export public key for publication
gpg --armor --export security@your-saas.example.com > public/pgp-key.asc
# Sign security.txt
gpg --clearsign --armor security.txt > .well-known/security.txt

Store the private key in your secrets manager (HashiCorp Vault, AWS Secrets Manager), not in a developer's local keyring.

Next.js Implementation

In a Next.js app, serve security.txt as a static file:

public/.well-known/security.txt

Next.js automatically serves everything under public/ at the root path. The file will be accessible at https://your-saas.example.com/.well-known/security.txt.

Test with: curl https://your-saas.example.com/.well-known/security.txt

Writing a CRA Art.14-Compliant CVD Policy

Your CVD policy is the document that satisfies Art.14(3). It must cover:

Required Policy Sections

1. Scope Define what is in scope for vulnerability reports. For SaaS, this typically means:

• Your primary product domain and subdomains
• Public-facing APIs
• Mobile apps (if any)
• Out of scope: Third-party services you integrate with, social engineering, physical attacks

Be explicit about out-of-scope activities to protect both researchers and your team.

2. Good Faith Rules (Safe Harbour)

We will not pursue legal action against researchers who:
- Discover and report vulnerabilities following this policy
- Do not access, modify, or delete data beyond what is necessary to demonstrate the vulnerability
- Do not exploit the vulnerability beyond confirming it exists
- Do not violate the privacy of our users
- Do not perform DoS or DDoS attacks
- Report findings to us before public disclosure

3. Submission Process

• Primary: Web form at https://your-saas.example.com/security/report (track submissions with IDs)
• Secondary: Encrypted email to security@your-saas.example.com
• For critical findings: Direct contact to ciso@your-saas.example.com

4. Response Commitments (CRA Timeline Anchors)

5. What to Include in Reports Guide researchers to provide:

• Steps to reproduce
• Proof of concept (no destructive payloads)
• Affected component and version
• Suggested CVSS score (researchers often over-rate; be diplomatic if you disagree)
• Contact info for acknowledgment

6. Disclosure Coordination Explain your disclosure process: you will publish a security advisory at https://your-saas.example.com/security/advisories within 90 days of confirming the vulnerability, referencing the CVE if one is assigned.

Reporting to ENISA EUVD and National CSIRTs

The ENISA European Vulnerability Database (EUVD)

ENISA launched the EUVD as the EU's sovereign vulnerability database, providing an alternative to the US NVD (National Vulnerability Database). For CRA compliance:

When to report to EUVD:

• Any actively exploited vulnerability in your product (Art.14(2) — within 24 hours)
• Significant vulnerabilities in widely-used components (CVSS ≥ 7.0, broad customer impact)

How to report: ENISA provides a reporting form at https://euvd.enisa.europa.eu for manufacturers and security researchers. For Art.14(2) compliance, the 24-hour notification goes to ENISA via this channel, with your national CSIRT CC'd.

Structuring your report for EUVD:

Product: <your product name and version>
Vulnerability type: <CWE classification>
Severity: <CVSS v3.1 score and vector>
CVE ID: <if assigned, or "CVE pending">
Exploitation status: <active exploitation / PoC public / no known exploitation>
Affected users: <estimated scale>
Mitigation available: <yes/no, link if yes>
Timeline: <when discovered, when ENISA notified>

National CSIRT Coordination

For EU-based SaaS companies, you need to know your primary national CSIRT. For cross-border products with significant user bases in multiple member states, you may need to notify multiple CSIRTs.

Key national CSIRTs for SaaS companies:

When to contact national CSIRTs:

1. Mandatory (Art.14(2)): Actively exploited vulnerability — contact ENISA + your national CSIRT within 24 hours
2. Recommended: CVSS ≥ 9.0 vulnerabilities — proactive coordination even before patch is ready
3. Optional but good practice: CVSS 7.0–8.9 with broad impact — courtesy notification after patch release

The CSIRT coordination call: Keep it factual and brief. CSIRTs are not legal entities — they are coordination hubs. A typical notification:

"We are notifying you of a vulnerability in [Product Name] v[X.Y]. CVE-[YYYY-NNNNN]. CVSS v3.1: [score]. [N] customers in [your country] may be affected. A patch is [available at URL / expected by DATE]. We are coordinating public disclosure for [DATE]. We will notify affected customers directly. Please contact [security@your-saas.com] if you need additional information."

Vulnerability Triage Process

Between receiving a report and notifying ENISA, you need a rapid triage process. Here is a practical triage protocol for SaaS teams:

Severity Classification (CRA-aligned)

The 4-Question Triage

When a report arrives, answer these four questions in sequence:

1. Is it real? Can you reproduce it? Does it affect your production systems? (Some reports are theoretical or already patched)

2. Is it actively exploited? Check threat intelligence feeds (AlienVault OTX, Cisco Talos, VirusTotal), shodan/censys for scanning patterns, your WAF/IDS logs. If yes → 24-hour ENISA notification clock starts.

3. What is the blast radius? Which features/endpoints are affected? What data could be accessed? Are specific customer tiers more exposed?

4. Can you mitigate immediately? Can you add a WAF rule, kill a feature flag, or rate-limit the affected endpoint while the patch is developed? Immediate mitigation is expected by ENISA and is evidence of good-faith Art.14(1) compliance.

SBOM Integration with CVD

One of the underrated Art.14 challenges: to disclose a vulnerability properly, you need to know which component is affected and which customer deployments use that component version.

Why SBOM matters for CVD:

When a dependency vulnerability is disclosed (e.g., a critical CVE in a library you use), you need to:

1. Identify which of your product versions use the affected library version (SBOM lookup)
2. Determine which customer deployments are on affected product versions
3. Prioritise patching by customer impact
4. Communicate specifically to affected customers

Without an SBOM, you're sending blanket "upgrade now" notifications to all customers, which creates unnecessary noise and undermines customer trust.

Tooling for SBOM-assisted CVD:

# Generate CycloneDX SBOM for your Node.js project
npm install -g @cyclonedx/cyclonedx-npm
cyclonedx-npm --output-file sbom.json --output-format JSON

# Scan SBOM for known vulnerabilities
npm install -g @cyclonedx/cdxgen
# Or use OWASP Dependency-Check for broader language support
dependency-check --project "your-product" --scan . --format JSON --out dependency-report.json

# GitHub Dependabot (if using GitHub) automatically cross-references your SBOM with GitHub Advisory Database

SBOM update cadence for Art.14: Update your SBOM at every release (automated in CI) and keep a point-in-time archive per release version. The 10-year documentation requirement in Art.13(4) applies here — you may need to demonstrate which dependencies were in a 2026 release version in 2034.

60-Day CVD Implementation Roadmap

Here is a concrete roadmap to get your CVD programme operational before September 2026:

Week 1–2: Foundation

• Draft CVD policy (use template above as starting point)
• Create security@your-saas.com inbox with ticket tracking
• Publish /.well-known/security.txt
• Generate PGP key pair for security inbox
• Create /security/vulnerability-disclosure-policy page on your website

Week 3–4: Process

• Implement web-based submission form (tracks report IDs, sends confirmation)
• Define triage process and assign triage rotation (min. 2 engineers)
• Set up severity classification matrix (align with CVSS thresholds above)
• Create security advisory template (Markdown format, CVE fields)
• Identify your national CSIRT and ENISA contact channels

Week 5–6: SBOM and Monitoring

• Integrate SBOM generation into CI pipeline
• Set up dependency vulnerability scanning (Dependabot / Snyk / OWASP Dependency-Check)
• Implement WAF + IDS alerting for known exploit patterns
• Subscribe to vendor security mailing lists for key dependencies
• Create internal playbook: "actively exploited vulnerability → 24-hour ENISA notification"

Week 7–8: Testing and Documentation

• Run tabletop exercise: simulate receiving a critical CVE report
• Test the 24-hour ENISA notification process end-to-end
• Document your CVD programme in your technical documentation file (Art.13(4))
• Publish public security advisories page
• Add CVD programme details to your CRA technical documentation package

Common CVD Programme Mistakes (and How CRA Enforcement Will Find Them)

Mistake 1: "We'll respond when we have time" Art.14(1) says "without undue delay." If a critical report sits for 30 days before triage, regulators will find it (researchers complain to national CSIRTs, CSIRTs check your policy response times). A 3-business-day acknowledgment is the minimum evidence of good faith.

Mistake 2: Threatening researchers with legal action If a researcher discloses a vulnerability to you in good faith and you respond with legal threats, they will escalate to their national CSIRT or CERT/CC. That CSIRT will contact your national CSIRT. You will receive a very formal visit. ENISA guidance is explicit: good-faith researchers are protected by the CVD framework.

Mistake 3: Silent patching Fixing a vulnerability without publishing an advisory violates Art.14(1) Annex I §8. "Publicly disclosing information about fixed vulnerabilities" is mandatory. Your customers need to know what you fixed and in which version, so they can make informed decisions about updating.

Mistake 4: Not maintaining security.txt security.txt must be updated before the Expires date or it becomes invalid. Set a recurring calendar reminder 30 days before expiry. Expired security.txt is a signal to regulators that your CVD programme is unmaintained.

Mistake 5: Treating Art.14(2) as optional The 24-hour actively-exploited vulnerability notification to ENISA is a hard legal obligation. "We didn't know" is not a defence if your monitoring should have detected exploitation. CRA enforcement will look at whether your monitoring capability was proportionate to your product's risk profile.

What "Secure by Design" Means for CVD

This series has built up from the ENISA Secure by Design playbook (post #1), through secure-by-default configuration (post #2) and secure SDLC (post #3). CVD is the final loop that closes the secure development cycle: you build securely, but you accept that vulnerabilities will still be found, and you handle them transparently.

A mature CVD programme is evidence that your organisation takes the "ongoing security" obligation in CRA seriously — not just at launch, but throughout the product lifecycle. ENISA treats CVD programme quality as a key indicator of a manufacturer's security culture.

Post #5 (series finale) will bring these together: an ENISA Secure by Design CRA Compliance Scorecard — a practical checklist covering all five obligations from this series that you can use to self-assess your CRA readiness before September 2026.

Key Resources

• ENISA CVD Guidelines: enisa.europa.eu/publications/coordinated-vulnerability-disclosure
• ENISA EUVD: euvd.enisa.europa.eu
• RFC 9116 (security.txt): rfc-editor.org/rfc/rfc9116
• ENISA Secure by Design Playbook v0.4: enisa.europa.eu/publications/secure-by-design
• CVSS v3.1 Calculator: first.org/cvss/calculator/3.1
• CycloneDX SBOM: cyclonedx.org
• OWASP Dependency-Check: owasp.org/www-project-dependency-check