CRA Article 14: The 24-Hour Active Exploitation Rule — What SaaS Developers Must Report to ENISA

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

The EU Cyber Resilience Act (CRA, Regulation 2024/2847) imposes a reporting obligation that many development teams have not yet absorbed: under Article 14, the moment you become aware that a vulnerability in your product is being actively exploited, the clock starts. You have 24 hours to file an early warning with ENISA.

This is not a patch-first, report-later framework. You must notify regardless of whether you have a fix. You must notify before you have completed your internal investigation. The 24-hour window is measured from the moment awareness begins — not from the moment you confirm the scope, and not from the moment you have a remediation plan.

For SaaS developers who build and ship software products used by EU customers, this is a mandatory obligation from 11 September 2026. Missing the window is not a procedural infraction — it is a conformity failure that can trigger fines of up to €15 million or 2.5% of global annual turnover under CRA Article 36.

This guide covers exactly what Article 14 requires, how the three-stage reporting timeline works, what "actively exploited" means in practice, and how to build the detection and notification pipeline before the deadline.

The Three-Stage CRA Article 14 Timeline

Article 14 creates three sequential obligations, each with its own deadline and content requirement.

Each stage builds on the previous. The 24-hour early warning is a mandatory minimum — it does not replace the 72-hour notification. Missing any stage is an independent violation of Art.14.

Critical rule: The clock starts when you become aware of active exploitation, not when a CVE is published, not when a researcher submits a report, and not when your legal team is informed. Internal escalation delays do not extend the window. If your tier-1 support team receives an exploitation report at 09:00 on Monday, and that report reaches your security team at 14:00 on Monday, the 24-hour clock started at 09:00.

What Counts as "Actively Exploited"

Article 14 is triggered by active exploitation — a term the CRA does not fully define in the text but which ENISA and CSIRT guidance have clarified through parallel frameworks.

Active exploitation means a vulnerability is being used by an attacker in the wild against real systems. It is distinct from:

• Proof-of-concept code published without observed attacks: not necessarily active exploitation
• Theoretical vulnerability described in a research paper: not active exploitation
• Vulnerability in a test environment with no network exposure: not active exploitation

The following indicators are generally treated as active exploitation under CRA Art.14 and NIS2:

The CISA KEV catalog deserves special mention. For EU manufacturers, a KEV listing creates a rebuttable presumption of active exploitation that is difficult to dispute. If a vulnerability in a library your product ships is added to the KEV catalog and you do not file an early warning within 24 hours, you face a strong compliance exposure.

How CRA Art.14 Relates to NIS2 Incident Reporting

Developers who build software products AND operate services in NIS2-covered sectors face two parallel reporting frameworks. They share the 24-hour early warning concept but differ in scope and trigger:

The overlap case: If your SaaS product has a vulnerability being actively exploited AND this exploitation causes a significant disruption to your service, both obligations are triggered simultaneously. You must file a CRA Art.14 early warning with ENISA AND a NIS2 Art.23 early warning with your national CSIRT — both within 24 hours. The content differs; the deadline does not.

For NIS2, "significant incident" is defined in Art.23(3) as one causing or capable of causing "severe operational disruption," "financial loss," or having "significant impact on other natural or legal persons." Active exploitation of a critical vulnerability frequently meets this threshold.

The ENISA EUVD Reporting Portal

ENISA operates the European Vulnerability Database (EUVD) as the centralised reporting platform for CRA Art.14 notifications. As of May 2026, the portal is at euvd.enisa.europa.eu with a dedicated manufacturer notification interface.

To use the portal, your organisation must:

1. Register as a manufacturer with your EUVD account — recommended to do this before September 2026, not during an active incident
2. Identify your products in the EUVD catalog — products are indexed by CPE identifiers or ENISA internal product IDs
3. File the early warning using the structured notification form — you can pre-draft template text for your product families
4. Track the notification thread — ENISA and the relevant national CSIRT(s) may request additional information within the 72-hour window

ENISA-to-CSIRT coordination: When you file a CRA Art.14 notification, ENISA coordinates with the CSIRTs of the affected member states. This means your notification automatically triggers outreach to national authorities in countries where your customers are located. You cannot limit the notification to only the country where you are incorporated.

Pre-registration is mandatory in practice: Filing your first-ever EUVD notification during a live incident, when the 24-hour clock is running, is an operational risk that will test your team under pressure. Registration, product entry, and template preparation should be completed before September 2026. The ENISA portal supports draft notifications that can be submitted with minimal edits during an actual incident.

What Must the 24-Hour Early Warning Contain

The 24-hour early warning is deliberately minimal. The CRA requires sufficient information to enable ENISA to initiate coordination — not a full technical analysis. Under Art.14(1), the early warning must include:

• Product identification: Name, version range, and unique product identifier (CPE or EUVD product ID)
• Nature of the report: Confirmation that this is an actively exploited vulnerability notification
• Preliminary characterisation: High-level description — what type of vulnerability (e.g., remote code execution, authentication bypass), what attack surface
• Whether cross-border impact is likely: For multi-country SaaS products, typically "yes"
• Whether the vulnerability is publicly known: Is there a CVE, a public PoC, or security advisory already circulating?

What you do NOT need to include in the 24-hour warning:

• A patch or mitigation
• A complete CVE entry with CVSS score
• Root cause analysis
• Confirmation of exactly which customer environments are affected
• An estimate of financial impact

The 24-hour window exists precisely because these details take time to gather. The regulation separates awareness from investigation.

Sample early warning draft:

ENISA EUVD Early Warning — CRA Art.14
Product: ExampleSaaS API Gateway v2.x (EUVD ID: EXAMPLE-2026-001)
Notification type: Actively exploited vulnerability
Preliminary description: An authentication bypass vulnerability in the REST API
  endpoint handler (exact path under investigation) is being exploited in the
  wild. First exploitation evidence observed at 09:15 UTC 2026-05-06 via
  customer telemetry and confirmed by independent threat intelligence at 09:45
  UTC 2026-05-06.
CVE status: CVE pending assignment
Cross-border impact: Yes — service operates across all EU member states
Mitigation available: Under development; temporary WAF rules deployed
Public knowledge: Not yet publicly disclosed
Contact: security@example.com | +49 30 XXXXXXXX

The 72-Hour Vulnerability Notification

Within 72 hours of initial awareness, the full vulnerability notification must be filed. This replaces (or supplements) the 24-hour early warning in the EUVD system and requires:

User notification is a parallel obligation: Art.14(2) requires that manufacturers notify users who can take protective measures without undue delay. This is a separate obligation from the ENISA notification. If you have deployed a patch but customers must update manually, you must notify customers within the 72-hour window (or as soon as the mitigation is available). "Without undue delay" is interpreted as equivalent to the NIS2 standard — within hours of mitigation availability, not days.

The 14-Day Final Report

The final report must be filed without undue delay and no later than 14 days after a patch or complete mitigation is available. If a vulnerability remains unpatched beyond 14 days (for example, because a complex architectural fix is required), the final report must still be filed — documenting the ongoing exposure and the expected timeline for remediation.

The final report is the most detailed of the three stages:

• Root cause analysis: what code or design decision introduced the vulnerability
• Full exploitation timeline: first observed exploitation date/time, attack vector used, observable indicators
• Affected population: how many installations or users were potentially affected
• Mitigation applied: exact patch version, configuration change, or architectural fix
• Disclosure decision: whether and when public disclosure will occur (coordinated with ENISA under Art.15)
• Lessons learned: process or design changes to prevent recurrence

The 14-day final report becomes the basis for ENISA's public EUVD entry. If you do not file it, ENISA may publish based on the available information — without your framing or context.

DevSecOps Integration: Detecting Active Exploitation Automatically

The 24-hour window makes manual detection processes inadequate. If your security team only learns about active exploitation through customer complaints or weekly threat intel reviews, you will routinely miss the deadline. Active exploitation detection must be automated and integrated into your alerting stack.

Layer 1: Internal Telemetry Alerting

Your application logs should be monitored for anomalous patterns that match exploitation signatures:

# Example: Automated exploitation detection alert
import re
from datetime import datetime, timezone
import json

EXPLOIT_PATTERNS = [
    r"(?i)sql\s+injection",
    r"(?i)path\s*traversal",
    r"(?i)authentication\s+bypass",
    r"\.\./\.\./",
    r"<script[^>]*>",
    r"(?i)union\s+select",
    r"(?i)eval\s*\(",
    r"(?i)base64_decode",
]

def check_log_line(line: str) -> bool:
    return any(re.search(p, line) for p in EXPLOIT_PATTERNS)

def scan_logs_for_exploitation(log_stream, threshold: int = 5) -> dict | None:
    hits = []
    for line in log_stream:
        if check_log_line(line):
            hits.append({
                "timestamp": datetime.now(timezone.utc).isoformat(),
                "line": line[:500]
            })
    if len(hits) >= threshold:
        return {
            "alert_type": "potential_active_exploitation",
            "hit_count": len(hits),
            "samples": hits[:3],
            "cra_art14_clock_start": hits[0]["timestamp"]
        }
    return None

Layer 2: External Threat Intelligence Integration

Subscribe to feeds that flag active exploitation of public vulnerabilities. The CISA KEV catalog provides a daily-updated list that can be checked against your dependency manifest:

import httpx
import json
from pathlib import Path

async def check_kev_against_dependencies(sbom_path: str) -> list[dict]:
    """Cross-reference SBOM against CISA KEV catalog."""
    sbom = json.loads(Path(sbom_path).read_text())
    your_cves = {
        comp.get("cveId") or comp.get("id")
        for comp in sbom.get("components", [])
        if comp.get("cveId") or comp.get("id", "").startswith("CVE-")
    }
    
    async with httpx.AsyncClient() as client:
        resp = await client.get(
            "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json",
            timeout=30
        )
        kev = resp.json()
    
    matches = []
    for vuln in kev.get("vulnerabilities", []):
        cve_id = vuln.get("cveID")
        if cve_id in your_cves:
            matches.append({
                "cve_id": cve_id,
                "vendor": vuln.get("vendorProject"),
                "product": vuln.get("product"),
                "kev_date_added": vuln.get("dateAdded"),
                "description": vuln.get("shortDescription"),
                "required_action": vuln.get("requiredAction"),
                "due_date": vuln.get("dueDate"),
                "cra_art14_triggered": True,
                "notification_deadline_hours": 24
            })
    return matches

Layer 3: Dependency Monitoring with CVE Watchers

Tools like Dependabot, Renovate, or pip-audit / npm audit should be configured to trigger CRITICAL alerts — not just pull requests — when a dependency vulnerability is marked as actively exploited:

# GitHub Dependabot configuration with alert escalation
version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "daily"
    # Dependabot security alerts with CRITICAL severity
    # trigger your CRA Art.14 review pipeline

The key is that CRITICAL severity alerts (CVSS >= 9.0) or KEV-confirmed exploitations should bypass normal PR workflows and trigger an immediate CRA Art.14 review meeting.

Infrastructure Jurisdiction and Art.14 Response Capability

CRA Article 14 does not grant US law enforcement or intelligence agencies access to your incident data. However, your ability to detect active exploitation and your response time are directly affected by whether your infrastructure logs and monitoring data are accessible to you without third-party legal interference.

The CLOUD Act (18 U.S.C. § 2703) permits US authorities to compel US cloud providers to disclose data stored on their infrastructure, including security logs and application telemetry. This creates a secondary compliance risk: if your logging infrastructure runs on AWS, Azure, GCP, or Cloudflare Workers, a US government request could theoretically suppress or delay access to the very logs you need to detect active exploitation and trigger your CRA Art.14 24-hour clock.

This is not a hypothetical. Incident response engagements in 2024 and 2025 documented cases where US subpoenas created coordination delays in cross-border incident investigations involving EU-US hybrid cloud deployments.

Running your security telemetry, SIEM, and incident detection on EU-jurisdiction infrastructure means:

• Your log data is not subject to CLOUD Act disclosure
• Your incident response team retains unimpeded access to all telemetry
• Your 24-hour Art.14 window is not at risk of being extended by legal coordination delays
• Your final report to ENISA can be filed without concerns about parallel US disclosure obligations

For manufacturers placing products on the EU market, the CRA Art.14 reporting obligation creates a concrete infrastructure jurisdiction requirement: your security monitoring must be accessible to you, without undue delay, at any hour. A cloud provider that could receive a US government order affecting your log access is an operational risk to your CRA compliance posture.

Penalties for Missing the Art.14 Window

CRA Article 36 establishes the penalty framework. Missing the Art.14 reporting obligation falls under the "non-compliance with any other obligation" category, which carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher.

Market surveillance authorities (MSAs) in each member state have enforcement powers from 11 September 2026. Enforcement priorities as communicated by ENISA and the CSIRT Network focus on:

1. Manufacturers who fail to file any Art.14 notification despite evidence of known exploitation
2. Repeated late notifications where a pattern of systemic non-compliance is evident
3. Manufacturers who notify users without filing the parallel ENISA notification (Art.14(2) user notification does not substitute for the Art.14(1) ENISA notification)

The 14-day final report carries additional exposure because it is the basis for ENISA's public EUVD record. A manufacturer whose final report contradicts a public CVE entry or independent research may face additional scrutiny of whether the 24-hour early warning was accurate.

Art.14 Compliance Checklist for September 2026

Use this checklist to verify your CRA Art.14 readiness before the September 11 deadline:

Pre-incident preparation:
☐ EUVD manufacturer account created and products registered
☐ Early warning template drafted for each product family
☐ On-call security contact designated and accessible 24/7
☐ CISA KEV feed integrated into dependency monitoring
☐ Internal telemetry alerting configured for exploitation patterns
☐ CRA Art.14 trigger criteria documented and reviewed with legal
☐ 24h / 72h / 14d content requirements understood by security lead

During incident response:
☐ Time of awareness documented immediately (timestamp, source)
☐ 24h early warning filed within deadline
☐ CVE submission to MITRE/CNA initiated
☐ Customer notification drafted (Art.14(2) parallel obligation)
☐ 72h full notification filed with CVE reference and CVSS
☐ ENISA coordination requests acknowledged and responded to
☐ Final report filed within 14 days of patch/mitigation

Post-incident:
☐ EUVD entry reviewed for accuracy after ENISA publication
☐ Lessons learned documented internally
☐ Detection process updated to prevent recurrence
☐ Insurance notified if cyber coverage applies to regulatory events

Key Deadlines Summary

For SaaS developers, the relevant date is September 11, 2026. Products that are software-as-a-service without a traditional "placing on the market" step still fall under the CRA if they include a software component that can be downloaded, updated, or deployed by customers.

What This Means for Your Product Strategy

CRA Article 14 makes exploit detection a compliance function, not just a security function. If your organisation does not currently have:

• A documented security contact with 24/7 availability
• Automated CVE monitoring against your SBOM
• A pre-drafted ENISA notification template
• Log retention sufficient to reconstruct the exploitation timeline for the final report

...then these are compliance gaps that must be addressed before September 2026.

The infrastructure dimension is equally important. Manufacturers who rely on US-cloud log aggregation, US-cloud SIEM (Splunk Cloud, Datadog, AWS Security Hub), or US-cloud WAF alerting should assess whether those services create CLOUD Act exposure in the incident timeline that could affect their Art.14 compliance posture.

EU-hosted security telemetry, stored on infrastructure with no US jurisdictional link, eliminates the CLOUD Act interference risk entirely — and it is the only architecture that guarantees your 24-hour window is fully under your control.

This post is part of the sota.io EU Cyber Compliance Series. For the complete CRA compliance picture, see our guides on CRA Art.11 (vulnerability handling process), CRA Art.13 (SBOM obligations), CRA Art.15 (coordinated vulnerability disclosure policy), and CRA Art.16 (ENISA coordinated disclosure mechanics).