EU Cyber Resilience Act Article 14 Starts September 11, 2026: Scope–Report–Prove for US Software SMBs

Published: September 3, 2026 · Last updated: September 3, 2026 · Author: Softix

If your US company makes or sells software Europeans can download or install—mobile apps, desktop clients, CLIs, SDKs, Docker images, firmware, or devices with software—EU Cyber Resilience Act Article 14 reporting becomes mandatory on 11 September 2026 (eight days from this post’s date).

This is not Softix’s EU AI Act Article 50 guide. Article 50 is AI transparency under Regulation (EU) 2024/1689. Article 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847) is about notifying actively exploited vulnerabilities and severe incidents affecting products with digital elements.

Softix’s frame: Scope–Report–Prove. Decide what is in scope, build a path that can hit 24- and 72-hour clocks, and prove it with people, logs, and evidence. Practical guidance for software teams—not legal advice. Confirm classifications with counsel.

What starts on 11 September 2026 (and what waits until 2027)

The European Commission CRA overview is explicit: the Act entered into force on 10 December 2024; reporting obligations apply from 11 September 2026; most other CRA product obligations apply from 11 December 2027.

The Commission dedicated CRA reporting obligations page restates the manufacturer duties:

• Notify actively exploited vulnerabilities and severe incidents that impact the security of the product with digital elements.
• Submit an early warning within 24 hours of becoming aware, and a full notification within 72 hours.
• Submit a final report no later than 14 days after a corrective measure is available for actively exploited vulnerabilities, or within a month for severe incidents.
• Report once through the CRA Single Reporting Platform (SRP) operated by ENISA; the notification reaches the CSIRT of main establishment (or of the authorised representative for non-EU manufacturers) and, unless exceptional circumstances apply, ENISA.

A Jones Day alert (July 2026) on the Commission 27 July 2026 CRA guidance flags points US teams miss: reporting covers products already on the market before 11 December 2027; “awareness” follows an initial assessment with reasonable certainty; there is no retroactive duty for exploitation you already knew about before 11 September 2026; and non-compliance can attract fines up to EUR 15 million or 2.5% of worldwide annual turnover (ceiling language—not your invoice).

cyberresilienceact.eu’s Article 14 page (reviewed 20 August 2026) aligns on the three-stage clock and notes Article 69(3) pulls reporting onto the installed base even where full product duties await December 2027. Softix treats that as secondary analysis of the Regulation—have counsel read Articles 14, 16, and 69 against your catalogue.

Scope — Are you a CRA manufacturer for an EU-facing product?

Scope is the first Softix gate. The CRA regulates products with digital elements made available on the Union market in the course of a commercial activity—not every cloud login.

Usually in scope for US SMBs that ship things users install

From the Regulation definitions and Commission/FAQ practice (see also Recital 12 and Article 3 in Regulation (EU) 2024/2847 on EUR-Lex):

• Standalone downloadable software (desktop apps, installers from your site).
• Mobile apps distributed via app stores into the EU.
• CLIs, SDKs, libraries, firmware, Docker/OCI images placed on the market as products.
• Hardware with software (IoT, appliances) and their manufacturer-controlled remote data processing that the product needs to perform a function.

If you place those under your name or brand on the EU market, you can be a manufacturer even with no EU subsidiary. Non-EU manufacturers typically need an authorised representative pathway for coordination (including which CSIRT is yours for SRP routing)—another counsel item, not a Softix determination.

Often out of scope — with a sharp edge

Standalone SaaS / pure cloud services that are not tied to a product with digital elements are generally outside the CRA and are addressed instead under regimes such as NIS2 (Directive (EU) 2022/2555) for qualifying cloud providers. Recital 12 of the CRA states that cloud solutions are remote data processing only if they meet the CRA definition; websites that do not support a product functionality, and cloud services designed outside a manufacturer responsibility for a product, do not fall under the CRA as products.

Softix rule of thumb (opinion, not a legal ruling):

• Pure browser SaaS with no installable client: often out of CRA product scope — still check NIS2, contracts, and customer security questionnaires.
• Mobile app plus an API backend you own that the app needs: the app is typically a product; the backend may be remote data processing tied to that product.
• Desktop client, CLI, SDK, or Docker image that EU customers pull: likely in for reporting once awareness hits.
• White-label app under your brand in EU stores: you may still be treated as manufacturer.

Do not assume “we only sell SaaS from Austin” ends the analysis if you also publish an Electron app, a mobile wrapper, or an SDK that EU customers consume commercially.

What you report (narrower than every CVE)

Per the Commission reporting page and Article 14 practice:

• Actively exploited vulnerabilities — reliable evidence a malicious actor exploited a vulnerability in your product without the owner permission.
• Severe incidents affecting the product ability to protect availability, authenticity, integrity, or confidentiality of data or functions.

A vulnerability you find and patch before exploitation stays in ordinary vulnerability handling—not this mandatory channel. Pair this mindset with Softix guides on AI agent containment and SaaS OAuth identity: detection and least privilege reduce how often active exploit becomes your problem.

Report — Hit the 24h / 72h / final clocks without heroics

Report is the operational gate. The clock starts when you become aware under the guidance “reasonable certainty after initial assessment” standard—not when a researcher first emails a vague tip, and not when you finally finish a perfect root-cause write-up.

The three stages (copy into the runbook)

1. <= 24 hours — Early warning. Alert that an actively exploited vulnerability or severe incident exists; for incidents, whether unlawful/malicious acts are suspected. Fields are deliberately light (type, manufacturer, product, title)—do not wait for a full forensic novel.
2. <= 72 hours — Notification. General nature of the vulnerability/exploit, initial assessment, corrective or mitigating measures taken, and measures users can take.
3. Final report. For vulnerabilities: within 14 days after a corrective or mitigating measure is available. For severe incidents: within one month of the 72-hour notification. Full description, severity, impact, remediation.

You file through ENISA Single Reporting Platform. The Commission states the SRP is intended to be operational by 11 September 2026, with functional and security testing underway. As of late August 2026 secondary sources, the public URL was still to be announced on ENISA SRP hub—plan for a human submitting a browser form (ENISA has indicated no API at this stage in published guidance summarized by practitioners).

Non-EU manufacturer routing (high level)

Reports go to ENISA and the CSIRT designated as coordinator for your main establishment—or, if you are not established in the EU, for your authorised representative. Record your reasoning now and confirm when ENISA publishes the coordinator list.

Users must hear from you too

Jones Day and the Regulation logic both emphasize informing impacted users (and where appropriate all users) about severe incidents and practicable mitigations. SRP filing without customer communication is incomplete.

Prove — Evidence that the machine works before the clock starts

Prove is the readiness gate—show a process, not a homepage slogan.

Before 11 September 2026 — Softix minimum evidence pack

1. Product inventory with CRA tags for every EU-reachable artefact (apps, installers, SDKs, containers, devices)—likely in / out / needs counsel.
2. Named reporters + backups with EU Login accounts created in advance; assume no API and weekend coverage.
3. Awareness definition in writing—who decides “reasonable certainty,” and log that timestamp (your 24-hour clock).
4. Internal early-warning template matching mandatory SRP fields.
5. SBOM + exploit monitoring—you cannot report a component you did not ship. See also Softix MCP servers security and vibe-coding governance.
6. User notification drafts (status page, email, in-app).
7. One tabletop: Friday-evening exploit in an EU Android build; measure time to awareness and draft early warning.

What good looks like after go-live

Ticket timelines show awareness → early warning → 72h → final report inside the windows; SRP confirmation IDs sit with the incident record; customers get mitigations they can apply; and you note if Scope tags were wrong (for example a “SaaS-only” product that also shipped a helper binary).

Scope–Report–Prove at a glance

Gate	Question	US SMB action
Scope	Is this a product with digital elements made available in the EU under our brand?	Inventory apps/SDKs/clients/devices; treat pure SaaS as often out, downloadables as often in; confirm with counsel
Report	Can we hit 24h / 72h / final via the SRP and tell users?	EU Login + dual reporters, templates, on-call path, user-notice drafts
Prove	Can we show inventory, SBOM, awareness logs, and a tabletop?	Evidence pack before Sep 11; keep artefacts with each incident

A 14-day readiness checklist (3–17 September 2026)

Use this as a product/ops sprint, not a legal memorandum.

1. Freeze product inventory; mark EU distribution channels.
2. Counsel call on manufacturer vs pure service for top products (especially SaaS + desktop helper bundles).
3. Appoint primary/backup reporters; create EU Login accounts.
4. Draft early-warning and 72-hour forms where backups can open them.
5. Refresh SBOM for in-scope artefacts.
6. Write awareness criteria: active exploit vs severe incident vs ordinary bug.
7. Prepare user-notification and status-page templates.
8. Tabletop a Friday-evening exploit; fix gaps.
9. Watch ENISA SRP announcements; bookmark Commission CRA pages.
10. Exec brief: Scope / Report / Prove. No fake “CRA certified” badges.

After 11 September, reporting is a live duty. Full CRA product conformity still ramps toward 11 December 2027—do not confuse “reporting live” with “CE marking done.”

FAQ

Is this the same as EU AI Act Article 50?
No. Article 50 is AI transparency/labeling. CRA Article 14 is vulnerability and severe-incident reporting for products with digital elements. Softix covers Article 50 separately here.

We only sell multi-tenant SaaS. Are we done?
Often CRA product rules do not treat standalone SaaS as a product with digital elements, but confirm whether you also distribute installable clients, SDKs, or manufacturer backends that qualify as remote data processing for a product. NIS2 and customer contracts may still apply.

Do we report every CVE?
No. Mandatory Article 14 notifications target actively exploited vulnerabilities and severe security incidents—not every scanner finding.

Does reporting apply to versions we sold in 2025?
Reporting duties can apply to in-scope products already on the market before December 2027 when you become aware on or after 11 September 2026. That is a major practical difference from waiting for full 2027 product conformity.

Can Softix file SRP reports for us?
Softix can help engineer detection, SBOM pipelines, secure updates, and notice UX via custom software development. We do not replace EU counsel or act as your authorised representative.

Limits and when to update this page

Prefer ENISA and Commission pages over vendor blogs—the SRP URL and CSIRT coordinator lists may still move. Commission CRA guidance (27 July 2026) is non-binding but authorities are expected to look to it. Update this article when the SRP goes live publicly or timelines change.

Build security-minded products—then wire the report path

If EU customers install your software, Scope–Report–Prove is a product requirement, not a December 2027 surprise. Softix helps US SMBs design update mechanisms, audit-friendly logging, and containment boundaries in custom software so vulnerability handling is operable when Article 14 clocks run. We will not invent compliance certificates or guarantee enforcement outcomes.

Contact Softix with: (1) which artefacts EU users download or install, (2) whether you already have an EU authorised representative discussion, and (3) how fast you can decide “active exploit” today.