CRA Article 14: the upstream component notification obligation

The duty most tooling ignores

Alongside reporting your own actively exploited vulnerabilities, Article 14 requires you to notify the manufacturer or maintainer of a third-party component when you discover a vulnerability in that component. If a dependency you ship turns out to be vulnerable, telling its maintainer is part of the obligation — not a courtesy.

This leg of Article 14 is small, unglamorous, and structurally unoccupied: most CRA workflows stop at your own ENISA submission and never touch the third-party notification at all.

What it asks, concretely

• Discover a vulnerability in a component you depend on (via your own analysis, a disclosure, or an exploitation signal).
• Resolve the maintainer contact — from registry metadata (npm, PyPI, NuGet, Maven, Go) and the repository's SECURITY.md or security-policy file where present.
• Send a notification to that maintainer describing the issue.
• Record the notification and its timestamp. This record is itself evidence that you met the duty, which is the point.

Why the record matters

Article 14 is, in practice, a series of timestamped facts: when you became aware, when you notified ENISA, and — here — when you notified the upstream maintainer. A defensible log of those timestamps is what you show counsel and, if it comes to it, a regulator. The notification is easy to draft once; the discipline is capturing that it happened, and when.

The readiness report includes an upstream-notification line in its checklist so you can see whether this process exists before you need it. Generating the maintainer draft from a signal, and logging it, is exactly the kind of small, real gap the Article 14 module is built to close.