Planned: setting up the process that turns a vulnerability in a component into a decision and, where the CRA requires it, an Article 14 report: an SBOM per release, monitoring, triage and VEX, a reporting playbook and an exercise against the clock. Optional ongoing support.
From a component advisory to a decision and, where required, a report
Since 11 September 2026 manufacturers must report actively exploited vulnerabilities in their products: an early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a corrective or mitigating measure becoming available. That only works if the steps before it are in place. The package sets up the whole chain, so that the 24 hours are spent deciding, not searching.
The chain the package sets up
01
Know what is in each release
An SBOM generated for every release, with the fields a vulnerability lookup needs, kept with the release records.
02
Monitor the components
A defined way to learn about new vulnerabilities in those components, including the ones public databases do not cover, such as embedded libraries.
03
Decide whether you are affected
Triage rules, named owners and stand-ins, and VEX statements that record why a product is or is not affected.
04
Report and inform
An Article 14 playbook with prepared templates for the three reports, the reporting route, informing users, and telling the component’s maintainer.
Set-up project
SBOM generation per release, in a format and quality that tools can work with.
Vulnerability intake: monitoring sources, a security contact and a coordinated disclosure policy.
Triage and VEX rules: who decides, how quickly, and how the decision is recorded.
Roles and stand-ins for the 24-hour window, including weekends and holidays.
An Article 14 reporting playbook with filled-in templates for the early warning, the notification and the final report.
Which CSIRT and reporting route apply to you, and what each report must contain.
Informing affected users and the maintainers of affected components (Article 13(6)).
A tabletop exercise: the team works through one realistic case against the clock.
Ongoing support (optional)
Regular SBOM monitoring and triage reviews with your team.
Keeping VEX statements and the playbook up to date.
Help drafting reports when a case comes up.
When does a component vulnerability become reportable?
Not every exploited vulnerability in a component triggers a report. The obligation concerns vulnerabilities actively exploited in your product. If the vulnerable function is not used, or not reachable, your product is not affected, and a VEX statement records why. Getting that decision right, quickly and with evidence, is the core of the package.
Start with the SBOM check
The free SBOM check shows which components in your SBOM have known vulnerabilities and which of those are actively exploited. It runs in your browser and is a quick way to see where you stand.
— It is not a 24-hour on-call reporting service. The reports remain your legal duty and go out under your name; the package prepares your team to meet the deadlines, and we help draft.
— It does not establish CRA conformity.
Get in touch
Interested before it launches?
Tell us about your products and how you handle vulnerabilities today. We will come back with how the package would fit and, if the timing works, start with you as an early customer.
Opens our scheduling page in a new tab — pick a slot that suits you.
Worth including in a first message
What you build, and how many product lines are in scope.
Which regulations, standards or customer requirements are in view.
What is driving the timeline — customer requirement, audit, or CRA deadline.
Which package or engagement you are interested in.
Please keep a first message free of confidential technical detail and trade secrets. Once we reply we can agree an encrypted channel for anything sensitive.