EU CRA Vulnerability Disclosure June 2026: The Deadline Every SaaS Developer Must Know

Post #1364 in the sota.io EU Regulatory Compliance Series — EU-CRA-2026-UPDATE #1/5

June 11, 2026 is not a theoretical future date. It is fourteen days away. On that date, Article 14 of the EU Cyber Resilience Act (CRA) — the mandatory vulnerability reporting obligation — becomes binding for manufacturers of products with digital elements operating in the EU market.

Most SaaS teams are unprepared. A 2025 BSI survey found that fewer than 30% of European software companies had established a structured vulnerability disclosure process aligned with CRA requirements. The other 70% are running out of time.

This is the first post in our five-part EU CRA 2026 Update series. We cover exactly what changes on June 11, who is legally in scope, how the 24-hour and 72-hour reporting windows work, how to build your disclosure program this week, and the connection to your existing NIS2 and GDPR obligations.

Part 1: What Actually Changes on June 11, 2026

The EU Cyber Resilience Act entered into force on October 10, 2024. But the full regulation applies in phases. June 11, 2026 triggers the vulnerability handling and reporting obligations under Articles 11, 13, and 14 — roughly 20 months before the full product-level obligations in September 2027.

The Three June 2026 Obligations

These are not reporting obligations for security incidents to your national authority (that is NIS2 Art.23). These are product vulnerability obligations: you must report to ENISA when you discover an actively exploited vulnerability in your product, and you must have a documented process for receiving, triaging, and remediating vulnerabilities reported to you.

What Is NOT Changing Yet

The full conformity assessment requirements (CE marking, technical documentation, notified body assessments for Class II products) do not apply until September 11, 2027. The September 2026 date only accelerates reporting obligations.

If your legal team told you "CRA doesn't apply until 2027" — they are half right. The core product-safety requirements wait until 2027. The vulnerability reporting obligations do not.

Part 2: Are You a CRA "Manufacturer"?

This is the question most SaaS teams get wrong. The CRA defines a manufacturer as any natural or legal person who develops or manufactures products with digital elements with a view to placing them on the market.

What Counts as a "Product With Digital Elements"

The CRA covers software that is placed on the market as a commercial product — but this explicitly includes software-as-a-service when the SaaS component includes a software element (library, SDK, plugin, client-side agent) that is distributed to and executed on the user's device or infrastructure.

Practical test: Does your product include anything the user downloads, installs, runs locally, or pulls into their build pipeline? If yes, you are almost certainly in scope as of June 11, 2026.

The European Commission's CRA FAQ published April 2026 confirms that a SaaS platform bundled with a browser extension, mobile app, or CI/CD plugin is in scope. Pure server-side SaaS with no distributed component is outside scope — but you should document this position explicitly.

The Importer and Distributor Obligations

Even if you are not the manufacturer, if you distribute products with digital elements (resell, white-label, bundle third-party components), you inherit due-diligence obligations. From June 2026, you must verify that the manufacturers of your embedded components have compliant vulnerability handling processes. Supplier security questionnaires are no longer a nice-to-have.

Part 3: The 24-Hour and 72-Hour Reporting Timeline

Article 14 establishes a two-step notification process to ENISA. This mirrors NIS2's incident reporting structure but is different in scope and destination.

Step 1: Early Warning — 24 Hours

Within 24 hours of becoming aware of an actively exploited vulnerability in your product, you must submit an early warning to ENISA via the EU Vulnerability Database (EUVDB).

"Actively exploited" means there is evidence of exploitation in the wild — not just a disclosed CVE. This is a narrower trigger than NIS2's significant incident threshold, but it moves faster.

The early warning requires:

• Product name and version(s) affected
• Vulnerability identifier (CVE if already assigned, internal ID if not)
• Nature of exploitation evidence
• Initial assessment of impact

You do not need a root cause analysis or remediation in 24 hours. You need confirmation that you are aware of the issue and ENISA is in the loop.

Step 2: Complete Notification — 72 Hours

Within 72 hours of initial awareness, you submit the complete notification:

• Full technical description of the vulnerability
• Impact assessment (confidentiality, integrity, availability)
• Affected versions and configurations
• Any available mitigations or workarounds
• Timeline for patch release (if known)
• Coordination status with CERT/CC, national CSIRT, or affected third parties

Step 3: Final Report — After Remediation

A final report summarising the vulnerability, root cause, remediation applied, and lessons learned must be submitted after the remediation is complete — no fixed deadline, but "without undue delay" from patch release.

ENISA EUVDB: The Reporting Destination

ENISA's European Vulnerability Database (EUVDB) is the single reporting point. As of May 2026, the EUVDB API specification has been published and the system is live in early-access for registered manufacturers. Registration is free and takes approximately 2 hours.

Register now at: euvdb.enisa.europa.eu (requires EU VAT number or EORI registration to verify manufacturer identity).

Unlike NIS2, where you report to your national CSIRT, CRA vulnerability reports go to ENISA directly. ENISA then notifies the relevant national CSIRT and coordinates with the manufacturer. If you are already reporting NIS2 incidents to your national authority (e.g., BSI in Germany, ANSSI in France, NCSC-NL in the Netherlands), your CRA reports go somewhere different.

Part 4: Article 13 — Your Vulnerability Handling Program

Article 14 covers what you report externally. Article 13 covers what you must do internally. By June 11, you need a documented vulnerability handling policy that covers:

The Five Required Elements

1. Vulnerability Intake Channel A publicly accessible security.txt file at /.well-known/security.txt (RFC 9116 format) and a dedicated security report submission path. Minimum: security@yourdomain.com with a published response SLA.

2. Acknowledgement and Triage SLA Acknowledge receipt within 5 business days. Complete triage (severity classification, internal owner assigned) within 15 calendar days. Document this SLA publicly.

3. Coordinated Disclosure Process If a researcher reports a vulnerability to you, you must coordinate with them before public disclosure. The CRA does not mandate a specific embargo period, but 90 days is the industry standard (Google Project Zero, HackerOne). Document your coordinated disclosure window.

4. Patch and Remediation Tracking Every accepted vulnerability report must have a ticket in your issue tracker, an assigned remediation owner, and a target patch date. You must be able to demonstrate this process to your national market surveillance authority on request.

5. CVE Assignment Capability For vulnerabilities in your own software components, you must be able to request CVE identifiers. This requires becoming a CNA (CVE Numbering Authority) or working with an existing CNA. MITRE's CNA application process typically takes 2–4 weeks — start now if you have not.

The security.txt Template for CRA Compliance

Contact: mailto:security@yourdomain.com
Contact: https://yourdomain.com/security/report
Expires: 2027-06-11T23:59:59.000Z
Acknowledgments: https://yourdomain.com/security/hall-of-fame
Policy: https://yourdomain.com/security/disclosure-policy
Preferred-Languages: en, de, fr
Hiring: https://yourdomain.com/careers
CSAF: https://yourdomain.com/.well-known/csaf/provider-metadata.json

The CSAF field links to your CSAF (Common Security Advisory Framework) provider metadata — this is how automated systems and ENISA's EUVDB will discover and ingest your security advisories.

Part 5: CSAF — The Machine-Readable Advisory Format

The CRA mandates that security advisories for actively exploited vulnerabilities be published in CSAF 2.0 format (ISO/IEC 29147 equivalent). This is not a PDF on your blog. It is a structured JSON document that automated scanners, vulnerability databases, and procurement teams can ingest.

CSAF Minimum Viable Advisory

{
  "document": {
    "csaf_version": "2.0",
    "id": "YOUR-COMPANY-2026-001",
    "title": "Critical Authentication Bypass in YourProduct",
    "publisher": {
      "name": "Your Company GmbH",
      "namespace": "https://yourdomain.com",
      "category": "vendor",
      "contact_details": "security@yourdomain.com",
      "issuing_authority": "Your Company Security Team"
    },
    "tracking": {
      "id": "YOUR-COMPANY-2026-001",
      "status": "final",
      "version": "1.0.0",
      "initial_release_date": "2026-06-15T10:00:00Z",
      "current_release_date": "2026-06-15T10:00:00Z",
      "revision_history": []
    },
    "distribution": {"tlp": {"label": "WHITE"}},
    "notes": [
      {"category": "summary", "text": "..."},
      {"category": "details", "text": "..."}
    ]
  },
  "vulnerabilities": [
    {
      "cve": "CVE-2026-XXXXX",
      "scores": [{"cvss_v3": {"baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"}}],
      "remediations": [{"category": "vendor_fix", "details": "Upgrade to version 2.4.1"}]
    }
  ]
}

Hosting your CSAF advisories at /.well-known/csaf/ with a provider metadata file makes them discoverable by ENISA's automated ingestion pipeline — which is how EUVDB aggregates vulnerability data across all registered manufacturers.

Tools for CSAF authoring: secvisogram (BSSN-funded, open-source, German), CSAF 2.0 Python library (csaf-tool), or OpenVEX for minimal vendor exchange format.

Part 6: CRA vs NIS2 — Dual Obligation for Most SaaS Teams

If you are already NIS2-compliant (which you should be — the deadline was October 17, 2024), you have overlapping but non-identical obligations. Here is the reconciliation:

A single security event can trigger both reporting chains simultaneously. For example: if a zero-day in your SaaS platform's mobile app is actively exploited, causing a significant availability incident:

• NIS2: Report to your national CSIRT within 24h (incident affecting your service)
• CRA: Report to ENISA EUVDB within 24h (actively exploited vulnerability in your product)

These reports go to different destinations and must contain different information. Your incident response runbook should have two parallel tracks.

GDPR Adds a Third Track

If the vulnerability enables unauthorized access to personal data, GDPR Art.33 requires notification to your supervisory authority within 72 hours. That is a third simultaneous reporting chain — to your national DPA (e.g., BfDI in Germany, CNIL in France, DPC in Ireland).

Design your incident response process for all three tracks from day one. Trying to retrofit separate processes for each regulation wastes engineering time and creates coordination failures.

Part 7: Market Surveillance and Penalties

The CRA enforcement mechanism is market surveillance by national authorities (MSAs) — the same bodies that enforce product safety regulations (CE marking, medical devices, etc.). In Germany this is the BSI, in France the ANSSI, in the Netherlands the NCSC-NL.

What MSAs Can Do From June 2026

From the vulnerability reporting obligation date, MSAs can:

1. Request documentation of your vulnerability handling policy and evidence of past reports
2. Audit your CSAF publication — is your .well-known/csaf/ directory populated and accurate?
3. Investigate complaints from researchers who claim coordinated disclosure was mishandled
4. Issue corrective action notices requiring you to remediate specific process gaps within 30 days

Penalties for Non-Compliance

CRA Article 64 establishes a two-tier penalty structure:

These penalties are per violation — a pattern of unreported vulnerabilities is not a single €15M exposure; it is potentially multiple penalties. The regulation explicitly states that MSAs must take into account the intentional or negligent nature of the violation.

Part 8: June 2026 Implementation Checklist

This Week (Days 1–7)

• Scope determination: Document whether your product includes distributed software components. If yes, you are in scope.
• EUVDB registration: Register at euvdb.enisa.europa.eu. Requires EU VAT/EORI. Takes 1–2 hours.
• security.txt deployment: Deploy RFC 9116 compliant security.txt at /.well-known/security.txt with CSAF field.
• Security@ inbox: Ensure security@yourdomain.com is monitored with documented response SLA.
• CNA application: If you ship software components with CVE potential, start MITRE CNA application now.

Next Week (Days 8–14)

• Vulnerability handling policy: Draft and publish at /security/disclosure-policy — include intake, triage SLA, coordinated disclosure window, patch timeline commitment.
• CSAF provider metadata: Create .well-known/csaf/provider-metadata.json linking to your advisory directory.
• Incident response runbook update: Add parallel CRA (ENISA) track alongside NIS2 (national CSIRT) and GDPR (DPA) tracks.
• Engineering toolchain: Install secvisogram or csaf-tool in your security team's workflow.
• Bug bounty review: If you run a HackerOne/Intigriti/Bugcrowd program, update your policy to reflect CRA coordinated disclosure obligations.

Before September 2027 (Full CRA Application)

• Technical documentation package (per Annex V)
• Conformity assessment for Class I products (self-declaration)
• Notified body assessment for Class II products
• CE marking on distributed software
• Software Bill of Materials (SBOM) in SPDX or CycloneDX format

Summary

June 11, 2026 is not the full CRA deadline — that is September 2027. But the vulnerability reporting obligations that kick in on June 11 require non-trivial process and tooling changes that take weeks to implement, not days.

The three things you must have operational by June 11:

1. A public vulnerability disclosure channel with documented policy
2. An ENISA EUVDB account for direct reporting
3. An incident response process that handles CRA, NIS2, and GDPR simultaneously

The full CRA technical documentation and conformity assessment requirements follow in 2027, but the foundation you build now — CSAF tooling, CVE capacity, coordinated disclosure policy — directly accelerates your 2027 readiness.

In the next post in this series, we cover CRA Security Requirements under Article 13 in detail: secure-by-default configuration, Software Bill of Materials implementation, and the SBOM format war between SPDX and CycloneDX.

sota.io provides EU-sovereign hosting infrastructure for SaaS teams building CRA-compliant products. Start free — no US jurisdiction, GDPR-native, CRA-ready infrastructure.