CRA Art.12 User Notification: When Manufacturers Must Tell Users About Security Incidents and End-of-Life

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

Most coverage of the Cyber Resilience Act focuses on what manufacturers must report to ENISA — the 24-hour window for actively exploited vulnerabilities (Article 14), the 72-hour severity assessment, and the 14-day final report. That authority-facing reporting chain is important.

But there is a parallel obligation that receives far less attention: the user-facing notification duties that require manufacturers to directly inform the people using their products when security incidents occur and when support ends. These obligations are scattered across Article 13, Annex I, and intersect with GDPR Article 34 in ways that create significant compliance complexity — particularly for software products hosted in US jurisdictions where CLOUD Act compulsion can create gag order conflicts during active incidents.

This post dissects the complete user notification framework, the 14-month end-of-life advance notice requirement, and why hosting jurisdiction is a determinative factor in a manufacturer's ability to fulfill these obligations.

The Notification Cascade the CRA Creates

The CRA does not have a single "user notification article." Instead, it creates a cascade of obligations that together constitute the user notification framework:

Layer 1 — Authority Reporting (Art.14): Manufacturers report to ENISA. Active exploitation within 24 hours. Severity and impact within 72 hours. Final technical analysis within 14 days. This is the authority layer — it feeds into the European vulnerability database and CSIRT coordination.

Layer 2 — Market Surveillance (Art.47): National market surveillance authorities can require manufacturers to notify users if they determine a product poses a risk. This is the regulatory enforcement layer.

Layer 3 — Direct User Notification (Art.13 + Annex I): Manufacturers have ongoing, self-executing obligations to notify users about security updates, support period status, and end-of-life. This is the operational layer that runs independently of whether ENISA or market surveillance is involved.

Layer 4 — GDPR Art.34 Overlay: When a security incident constitutes a personal data breach with high risk to natural persons, the controller must also notify affected individuals directly under GDPR. For SaaS products, the manufacturer is often both the processor and controller, creating dual notification obligations under two separate legal frameworks.

The complexity is not in understanding any single layer — it is in coordinating all four simultaneously during an active incident, under time pressure, without the operational infrastructure becoming a compliance liability.

Art.13: The Security Update Notification Obligations

Article 13 of the CRA is titled "Obligations of manufacturers" and contains the core user-facing security notification requirements.

Security Updates Must Be Designated and Communicated

Article 13(3) requires that security updates be:

• Available without additional charge to users who received the product
• Clearly designated as security updates, distinguishable from functional updates
• Provided as separate updates when combined with functional changes (unless inseparable)
• Accompanied by sufficient information for users to understand what was fixed

The "clearly designated" requirement has significant operational implications. A changelog entry of "bug fixes and stability improvements" is not sufficient for CRA compliance. Security updates must be labeled as such, with enough information that a risk-aware user or system administrator can make an informed decision about deployment urgency.

For SaaS platforms, this creates a requirement to maintain a public security changelog — not merely an internal incident report.

The Support Period Transparency Requirement

Article 13(8) establishes what is arguably the most operationally significant user notification requirement in the CRA: manufacturers must inform users about the support period at the time of product purchase or acquisition, and must provide a minimum of 14 months advance notice before support ends.

The specific requirement is that when a product is placed on the market, the manufacturer must clearly communicate:

• The minimum support period (which must be at least 5 years for most products, unless the expected product lifetime is shorter)
• What "support" means — including whether it covers security updates, vulnerability disclosure, and coordinated incident response

The 14-month advance notice for end-of-life is measured from when the manufacturer decides to terminate support, not from some arbitrary date. If a manufacturer decides in January 2027 to end support for a product in March 2027 — without providing the required 14-month advance notice — that is a direct CRA violation, triggering Article 47 market surveillance procedures and potential Article 53 fine exposure.

For subscription SaaS products, this requirement effectively means that manufacturers cannot simply discontinue a product version without extensive advance notification. The 14-month window is intended to give enterprise users sufficient time to migrate or implement alternative security controls.

What "User" Means Under Art.13

The CRA definition of "user" in the context of Article 13 notification obligations is broader than it might appear. It covers:

• End users of consumer products
• Professional users deploying products in business contexts
• System integrators who incorporate the product into larger systems
• In the SaaS context: organizations subscribed to a platform where the manufacturer is the developer

This breadth means that B2B SaaS providers cannot argue that their notification obligations are satisfied by informing a single enterprise IT contact. The notification must reach the people who need to make security decisions based on it.

Annex I: The Inherent User Notification Obligations

Beyond Article 13, Annex I of the CRA establishes essential cybersecurity requirements that imply ongoing user notification obligations.

Annex I, Part I, Point 2(b): Vulnerability Remediation Information

Products must be designed so that vulnerability remediation information is communicated to users in a way that allows them to take appropriate action. This is not a reactive obligation triggered by an active incident — it is a design requirement. Products must have a built-in mechanism for delivering security-relevant information to users.

For SaaS platforms, this typically means:

• A public security advisory page (often at /security or trust.example.com)
• An opt-in security notification mailing list or webhook
• Integration with CVE databases and CSIRT notification systems

Manufacturers who satisfy this requirement through a private customer portal accessible only after login — preventing affected non-customers or lapsed-subscription users from receiving notifications — are likely non-compliant with the spirit of this requirement.

Annex I, Part I, Point 2(c): Availability During Exploitation

Products must "protect the availability of essential functions including as regards resilience and mitigation measures" when vulnerabilities are being actively exploited. This creates an implicit user communication obligation: if essential functions are degraded during an active exploitation event, users must be informed — they cannot be kept in the dark about degraded security posture while they make business decisions that depend on the product.

The GDPR Art.34 Overlap: When Security Incidents Become Data Breach Notifications

When a security incident affecting a CRA-covered product also constitutes a personal data breach, the notification obligations multiply.

GDPR Article 34 requires controllers to communicate to affected data subjects "without undue delay" when a personal data breach is likely to result in high risk to natural persons. The notification must:

• Describe the nature of the breach in plain language
• Identify a contact for further information
• Describe likely consequences
• Describe measures taken or proposed to address the breach

The critical interaction: GDPR Art.34 notification to users may be required before the CRA Art.14 reporting process to ENISA is complete. The GDPR "without undue delay" standard has been interpreted by supervisory authorities as requiring notification within 72 hours of when the controller becomes aware — the same window as the CRA's severity report to ENISA.

This means a manufacturer facing an active incident involving personal data must simultaneously:

1. Submit an initial CRA notification to ENISA within 24 hours (if actively exploited)
2. File a GDPR Article 33 notification to the lead supervisory authority within 72 hours
3. Prepare an Article 34 user notification if high risk is determined — potentially within the same 72-hour window
4. Provide a CRA final report to ENISA within 14 days
5. Issue security advisories meeting Annex I requirements

Managing this cascade requires pre-built incident response infrastructure. It cannot be improvised during an active incident.

The CLOUD Act Problem: When Gag Orders Conflict With User Notification

This is where hosting jurisdiction becomes a determinative compliance factor.

The Legal Framework Collision

When a US-hosted manufacturer (or a manufacturer using US-hosted infrastructure) receives a law enforcement request under the Stored Communications Act (18 U.S.C. § 2703) or a National Security Letter under FISA, that request often includes a non-disclosure order — a legally binding prohibition on informing anyone that the request was received, including users whose data was accessed.

National Security Letters under 18 U.S.C. § 2709 carry a default non-disclosure requirement. FISA Title I court orders are classified. The manufacturer cannot tell users, cannot tell the data protection authority, cannot coordinate with CSIRT.

Now consider the CRA Art.12/13 scenario: a manufacturer's US-hosted infrastructure is accessed by a law enforcement agency under a classified FISA order. The access constitutes an unauthorized disclosure of user data. Under GDPR Article 34, the manufacturer has an obligation to notify affected users. Under CRA Annex I, they have an obligation to communicate vulnerability remediation information. But the FISA non-disclosure order prohibits notification.

The manufacturer is simultaneously required by EU law to notify users and prohibited by US law from notifying users.

This Is Not Theoretical

The CLOUD Act framework (2018) explicitly preserved the ability of US agencies to access data held by US-service providers regardless of where that data is physically stored. The EU-US Data Privacy Framework (2023) provides some procedural safeguards for commercial data transfers, but does not address national security access orders. FISA and NSL non-disclosure orders remain fully operative for US-incorporated companies and their subsidiaries.

German BSI guidance on cloud security (C5 certification) identifies this conflict explicitly. The French CNIL's January 2022 ruling on Google Analytics found that US transfer risks were unacceptable precisely because of this notification-blocking scenario. The problem is not hypothetical — it has been identified by data protection authorities as a structural barrier to GDPR compliance.

The CRA Amplifies the Conflict

GDPR Art.34 notification conflicts with FISA gag orders have existed since 2018. The CRA adds a new dimension: the Art.13(3) obligation to clearly designate security updates means that manufacturers must affirmatively communicate when they issue patches or mitigations. If the incident being addressed originated from a classified law enforcement access event, the manufacturer cannot explain the root cause of the security update — which means the "clearly designated" requirement becomes impossible to fulfill in a meaningful way.

A security update released with the explanation "addressing internal security improvements" — because FISA prevents disclosure of the actual cause — fails the CRA's transparency requirements.

The 14-Month EoL Notice: An Underappreciated Compliance Cliff

The 14-month advance notice requirement for end-of-life deserves particular attention for SaaS and cloud-hosted products, because the compliance cliff is higher than it appears.

What Must Be Communicated

At minimum, 14 months before terminating support, manufacturers must inform users of:

• The specific date on which support will end
• What security update availability ends (including bug fixes for discovered vulnerabilities)
• What coordinated vulnerability disclosure will cover after EoL
• What migration options are available
• Whether a successor product maintains compliance coverage

For B2B SaaS, the communication must reach the security and compliance decision-makers within customer organizations, not just the primary account contact.

The Product Discontinuation Trap

Consider a common SaaS scenario: a startup CRA-covered product is acquired by a larger company. The acquirer decides to sunset the product in favor of a consolidated platform. If they provide less than 14 months notice, they are non-compliant — and the liability attaches to the acquiring company, not the original manufacturer.

In M&A due diligence for EU-market SaaS products, CRA EoL obligations are now a material consideration: acquired products may carry forward EoL notification obligations that constrain the acquirer's roadmap flexibility for up to 14 months post-acquisition.

The Support Period Display Requirement

Article 13(8) also requires that the support period be visible at the point of purchase or first product encounter — not buried in terms of service. For SaaS, this means the pricing page or product onboarding flow must clearly display when support expires, if a fixed term applies.

Free tiers with no defined support commitment present a specific compliance question: if a free tier user relies on security updates (for example, a self-hosted version offered alongside a paid SaaS), the manufacturer must either commit to a minimum support period or clearly communicate that no security update commitment exists.

Practical Compliance Architecture for User Notification

Given the multi-layer notification cascade, a CRA-compliant user notification architecture for SaaS products includes:

1. Public Security Advisory Infrastructure

• /security page with current and historical security advisories
• CVE assignment process (directly or through a CVE Numbering Authority)
• RSS feed or security notification webhook for enterprise users
• Machine-readable format (CSAF, VEX) for automated toolchain integration

2. Security Update Designation System

• Changelog entries tagged as SECURITY vs. FEATURE vs. BUG
• Email notification to opted-in users when security updates are released
• Severity rating (CVSS or equivalent) for each security update

3. EoL Notice System

• Product lifecycle page with current support period for each version/tier
• Automated 14-month-ahead alert system for all users on affected versions
• Defined migration path documentation published simultaneously with EoL notice

4. Incident Response Communication Plan

• Pre-drafted notification templates for different incident severity tiers
• Pre-identified data protection authority contacts for Art.33 notification
• Pre-approved communication channels (email, status page, in-product banner)
• Legal review protocol for any incident involving law enforcement access (especially US jurisdiction)

5. Jurisdictional Isolation for High-Risk Communications

• For manufacturers who want to eliminate the CLOUD Act conflict: user notification infrastructure hosted outside US jurisdiction
• EU-native email service providers (not Gmail/Outlook/AWS SES) for security notification delivery
• Status page hosted on EU-native infrastructure so it remains accessible and unaffected by US legal process

The EU-Native Advantage in User Notification Compliance

An EU-incorporated manufacturer using EU-native infrastructure for its product and notification systems faces a simpler compliance environment:

• No CLOUD Act compulsion applies to EU-incorporated entities without a US subsidiary or US-based infrastructure
• German, French, Dutch, or other EU member state law enforcement process does not include non-disclosure orders that conflict with GDPR Art.34 or CRA Art.13 obligations
• BSI, ANSSI, and NCSC-NL coordination processes are designed to work within the GDPR notification framework, not against it
• The security advisory, EoL notification, and incident communication infrastructure can be built without attorney review for every release (no need to assess whether disclosure triggers a classified order)

For SaaS platforms built on EU-native infrastructure like Hetzner (Germany), OVHcloud (France), or Scaleway (France), the notification cascade simplifies to its legal core: detect incident, assess risk, notify authorities and users within required windows, document everything.

For US-hosted platforms, every notification decision during an active incident requires a legal assessment of whether disclosure is permissible — which introduces delays, legal costs, and the genuine possibility of notification obligations being superseded by classified orders.

Summary: CRA User Notification at a Glance

What Happens in September 2026

The CRA becomes fully applicable on 11 September 2026. From that date:

• Products placed on the EU market must meet all Art.13 user notification obligations
• ENISA reporting (Art.14) activates for actively exploited vulnerabilities
• Market surveillance authorities (Art.47) can require user notifications for at-risk products
• The 14-month EoL notice clock starts running — meaning any EoL decision made today carries forward into post-September 2026 compliance territory

Manufacturers who are building their CRA compliance programs now need to treat user notification not as a communications function but as a compliance function. The technical infrastructure for delivering timely, legally-sufficient user notifications — designated security updates, EoL notices, incident communications, and GDPR overlap handling — needs to be in place before September 11, not after an incident triggers regulatory scrutiny.

The jurisdiction where that infrastructure runs is not a technical detail. It is a compliance design decision.

sota.io is an EU-native managed PaaS built on Hetzner infrastructure in Germany. Our platform's notification and security infrastructure operates entirely within EU jurisdiction, eliminating the CLOUD Act conflict described in this article. For teams evaluating hosting platforms for CRA-covered products, jurisdiction-aware infrastructure is a compliance requirement, not a preference.