Monitoring
Continuous vulnerability monitoring for shipped products
Continuous vulnerability monitoring means re-checking the components of every product you still support against vulnerability data as that data changes, not only when your code changes. A scan that was clean at release goes stale as new advisories appear, so monitoring is what turns a one-off scan into the ongoing vulnerability handling the Cyber Resilience Act expects.
Free plan, no card required.
Why does a clean scan go stale?
A vulnerability scan answers one question at one moment: which known vulnerabilities affect these component versions, according to today's advisory data. New CVE records are published every day, and existing records are revised as affected versions, fixes and evidence of exploitation become known. Your product does not have to change for its risk to change: a firmware image with no known issues in March can carry an actively exploited flaw by June, with the same bytes on every device in the field.
That is why the CRA frames vulnerability handling as a process rather than an event. Annex I Part II asks manufacturers to identify and document vulnerabilities and components, to remediate without delay and to apply effective and regular tests and reviews. Those duties run for the whole support period, which Article 13(8) sets at a minimum of five years unless the product is expected to be in use for less time.
Rescanning shipped releases versus the main branch
Scanning the main branch on every change is useful, but it tells you about the code you will ship next, not the code your customers run. Devices in the field run releases: version 2.3 on some, 2.4 on others, and a long tail of units that never updated. Each supported release needs its own component list, re-checked against current advisory data, because the question “are our customers exposed?” is answered by the release, not by the branch.
Keep one software bill of materials (SBOM) per released version, tied to the version string users see. When a new advisory matches, you can then say which releases are affected and which fixed release to point customers to. For software, CRA Article 13(10) lets you remediate in the latest substantially modified version only, if users of earlier versions can move to it free of charge and without extra costs to adjust their environment.
SBOM-based re-matching: monitoring without rebuilding
Instead of rebuilding and rescanning the product, you keep the SBOM produced at release and regularly compare its component names and versions with advisory databases such as OSV.dev, the NVD and ENISA's EU Vulnerability Database (EUVD). Because the SBOM describes what shipped, a match is a match against real releases. The result is only as good as the SBOM: components without versions or package identifiers cannot be matched reliably, and vendored or statically linked code that the SBOM does not list stays invisible.
Re-matching complements a periodic full rescan rather than replacing it. A full scan picks up better component detection, new analysis rules and issues that are not component vulnerabilities at all, such as committed secrets or misconfigurations, so run one at each release and whenever the build changes.
How do KEV and EPSS help prioritise new vulnerabilities?
Monitoring produces a stream of matches; prioritisation decides which ones get attention first. Two public signals help. CISA's Known Exploited Vulnerabilities (KEV) catalogue lists vulnerabilities that have a CVE ID, reliable evidence of exploitation in the wild and clear remediation guidance. FIRST's Exploit Prediction Scoring System (EPSS) publishes, every day for every CVE, an estimated probability that it will be exploited in the wild in the next 30 days. CVSS describes how bad exploitation could be; KEV and EPSS indicate whether it has happened or how likely it is.
Combine them with your own context. A KEV-listed vulnerability in a component you ship should be triaged the same day: is the vulnerable code present and reachable in your build, and which releases carry it? Record the reasoning either way; a documented “not affected” decision is as useful to an auditor as a fix.
How does monitoring feed CRA Article 14 reporting?
Since 11 September 2026, CRA Article 14 has required manufacturers to notify actively exploited vulnerabilities contained in their products to the CSIRT designated as coordinator and to ENISA, through ENISA's single reporting platform. The early warning is due within 24 hours of the manufacturer becoming aware, the vulnerability notification within 72 hours, and the final report no later than 14 days after a corrective or mitigating measure is available. Under Article 69(3), Article 14 also covers in-scope products placed on the market before 11 December 2027.
The clock starts at awareness, which makes monitoring the front end of your reporting process. A new KEV entry that matches a component in a released product is a signal a person must assess quickly: is this an actively exploited vulnerability contained in your product, meaning there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission? Whatever the answer, Article 13(7) expects you to document the vulnerabilities you become aware of and to update the risk assessment where applicable.
How to set a monitoring cadence and owners
Monitoring fails quietly when nobody owns the output. Put the cadence and the owners in writing, as part of the vulnerability handling policy you need for the CRA anyway, and test the path once before you rely on it. A baseline to adapt to your products:
- An owner per product, with a deputy, who reviews new matches every working day and KEV matches the same day.
- A register of supported releases, each with its SBOM and end-of-support date.
- Re-matching of every supported release at least daily, and a full rescan at each release or build change.
- A triage order: known exploited first, then high EPSS, then CVSS severity, adjusted for exposure.
- A person who can approve an Article 14 notification within 24 hours, weekends included.
- A decision record for every match (affected, not affected, fixed in a named version) with its evidence.
Available in KROMSE today
On paid plans, KROMSE re-checks each product's latest SBOM against current advisory data and shows new matches inside the product.
- Every 6 hours, the latest SBOM of each product is re-checked against OSV.dev, for up to 5 products per workspace per cycle, in rotation.
- New matches appear as in-app notices, and a “Run monitoring now” button starts a check on demand.
- Findings with CVE IDs are enriched with CISA KEV, FIRST EPSS, the NVD and ENISA's EU Vulnerability Database (EUVD).
- Every scan produces CycloneDX and SPDX SBOMs, and you can upload the SBOMs you already have.
- On paid plans, internal CRA Article 14 report drafts for the 24-hour, 72-hour and final stages, as PDF, for a person to approve; KROMSE never submits them.
- Limits today: you cannot set your own schedule, monitoring sends no emails and it does not start rescans automatically.
Coming next
On the roadmap, not available yet. Dates are targets, not promises; this page changes the day a capability is live.
- Coming · Q4 2026 (December)Monitoring on your schedule, with AI agents. Rescans will run on a schedule you set, with AI agents that watch for new advisories, triage what applies, propose fixes and draft the report for your review.
- Coming · Q4 2026 (November)AI fix proposals, approved by a person. KROMSE will propose fixes for findings, written with AI and applied only after a person on your team approves them.
- Coming · Q1 2027Submission to ENISA's single reporting platform. After a person approves an Article 14 report, KROMSE will send it to ENISA's single reporting platform.
Frequently asked questions
What is the difference between vulnerability scanning and continuous vulnerability monitoring?
A scan inspects a product once and lists the known vulnerabilities in its components at that moment. Continuous monitoring repeats the comparison as advisory data changes, usually by re-matching each release's SBOM, so you learn about new vulnerabilities in shipped products without waiting for the next code change.
How often should shipped products be re-checked for new vulnerabilities?
No EU law sets a fixed interval. The CRA requires regular tests and reviews and remediation without delay, and its reporting clock runs from awareness of an actively exploited vulnerability, so the interval should let you notice one within hours, not weeks. Daily or more frequent SBOM re-matching, plus a full rescan at each release, is a reasonable starting point.
Does a KEV listing mean I must report under CRA Article 14?
Not automatically. Article 14 covers actively exploited vulnerabilities contained in your product: there must be reliable evidence that a malicious actor has exploited the vulnerability in a system without the owner's permission. A KEV entry is strong evidence of exploitation, but a person still has to establish whether the vulnerable code is in your product. Once you are aware that it is, the 24-hour deadline runs.
Does monitoring matter for products placed on the market before the CRA applies?
Yes, for reporting. Article 69(3) makes Article 14 apply to in-scope products placed on the market before 11 December 2027, and Article 14 has applied since 11 September 2026. The Commission's CRA FAQ explains that for these products manufacturers must report but are not required to meet other obligations, such as vulnerability handling. To notice an exploited vulnerability in them, you still need to know what they contain.
Does KROMSE email me when a new vulnerability matches my product?
Not today. On paid plans, KROMSE re-checks the latest SBOM of each product against OSV.dev every 6 hours, for up to 5 products per workspace per cycle in rotation, and shows new matches as in-app notices. Monitoring on a schedule you set, with AI agents, is on the roadmap.
Related guides
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
- European Commission: Cyber Resilience Act implementation FAQ
- ENISA: Single Reporting Platform
- ENISA: EU Vulnerability Database (EUVD)
- CISA: Known Exploited Vulnerabilities catalog
- FIRST: Exploit Prediction Scoring System (EPSS)
- OSV: open source vulnerability database