Article 14: vulnerability handling & reporting
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and national CSIRTs. That is a report to authorities, not an obligation to email end customers.
Article 14 is the calendar urgency for most manufacturers. You cannot report what you cannot find in a product already on the market. Informing end users sits with vulnerability handling / coordinated disclosure toward full application in December 2027, a separate path from SRP filing.
alloy-it is not CE-marking software, not a notified body, and does not submit reports to ENISA. It helps you know what you shipped, decide what is affected, stamp awareness, and prepare a copy-JSON packet.
The 24h / 72h / 14-day timeline
All three clocks run from the same moment: when the manufacturer became aware. See what you need in place before 11 September 2026 →
- 24 hours
Early warning
ENISA + national CSIRT
From the moment you become aware that a vulnerability in a product you placed on the market is being actively exploited. It can be short: what you know, and that you are investigating.
In alloy-it: Awareness is stamped when you record the exploit, and the 24h payload is drafted from your product and release data.
- 72 hours
Vulnerability notification
ENISA + national CSIRT
The fuller picture: affected products and versions, severity and impact, and any corrective or mitigating measures available to users.
In alloy-it: Affected releases come from your inventory and triage decisions, so scoping is not a manual archaeology exercise.
- 14 days
Final report
ENISA + national CSIRT
After a corrective measure is available: the vulnerability's nature, the fix, and what you did about it.
In alloy-it: The evidence pack pulls the SBOM, findings, triage history, and awareness timeline for the affected release.
How alloy-it supports Article 14 readiness
Living product inventory
Products and releases with vendor and/or firmware-derived SBOMs, so you can answer "does CVE X appear in something we already shipped?"
KEV / EUVD overlay
Highlight findings that are actively exploited against components in your shipped releases.
Awareness timestamp
Stamp when the manufacturer became aware. That starts the Article 14 clock.
Copy-JSON SRP payload
Export fields for ENISA SRP / national CSIRT. Alloy does not submit. Filing stays with your PSIRT and legal owners.
Customer advisories (patch version, apply-by) are a separate notify path, opened after triage confirms impact and a fix or mitigation exists. They are not the September 2026 obligation. How advisories work → See the full checklist →
CRA compliance hub
CRA overview for embedded & firmware
What the Cyber Resilience Act requires, the deadlines, and how manufacturers of products with digital elements comply.
CRA SBOM requirements
Format, scope, and per-version rules for a CRA-compliant product Software Bill of Materials.
CRA for embedded & firmware
Why firmware needs vendor SBOM plus binary-derived inventory, and how HEX/encrypted images differ.
CRA compliance checklist
A practical checklist mapping each CRA obligation to what your team must do.
Build-environment SBOM
Toolchain and build-time dependencies for technical docs: useful depth, but not what Sep 2026 reporting requires.
This page provides general information about the EU Cyber Resilience Act and is not legal advice. The regulation and its harmonised standards are still evolving: consult the official EU, ENISA, and BSI sources and qualified counsel for your specific product. alloy-it helps with product inventory, SBOM monitoring, triage, Article 14 evidence, and the rebuild path; it is not CE-marking software, not a notified body, and does not submit reports to ENISA or national CSIRTs.
Be ready before 11 September 2026
Living inventory, KEV/EUVD overlay, awareness clock, and SRP-ready export, without confusing authority reporting with customer email.