Continuous vulnerability evidence for CRA compliance

The CRA evaluates each product and version, not your security program. One company-wide scan history cannot show what a specific product version looked like.

Annex I requires products to land on the market without known exploitable vulnerabilities. That makes pre-release assessment a gating control with a timestamp, not a post-launch activity.

Vulnerability handling runs for at least five years per product. Evidence has to survive team changes, tooling changes, and product end-of-life planning.

Embedded, on-premises, and customer-deployed products sit outside the reach of external-only scanners, and that is where much of the in-scope attack surface lives.

Twenty-four hours is not enough time to map a newly exploited CVE to your components by hand. The answer has to come from evidence that already exists.

Scheduled scanning lets you set assessments to run on a cadence that matches the manufacturer’s release cycle and the CRA report period. You can show that the scan ran on a defined date, you recorded the finding, and the evidence timestamp exists.

Vulnerability monitoring and diff-based alerting fires when something new appears between scheduled scans. Your evidence record shows how you handled vulnerabilities across the entire support period, not just when you ran a scan.

The Pentest-Tools.com offensive research team builds dedicated scanners for high-impact and actively exploited CVEs and publishes them to the vulnerabilities and exploits database. Once a check exists, you answer "is our product actually affected?" from a scan result, instead of manually mapping the CVE to your components - the slow, error-prone work that eats at the Article 14 response window.Monitoring then alerts you the moment that specific check flags something across your in-scope products.

The VPN Agent operates inside embedded, on-prem, or private-network deployments - you don’t need a permanent on-premises appliance per product line.

The ML Classifier reduces false positives in scanners by 50%. This means security teams don’t waste time cutting noise or over-report detections that aren’t confirmed exploitable, and meet CRA notification requirements in the required timeframe.

Sniper Auto-Exploiter’s proprietary validation marks findings as Confirmed only when HTTP request/response data, PoC payload, or equivalent forensic artifact supports it.

Security teams can provide the technical level of evidence Annex I, Part I, point (2) demands: a validated, timestamped record proving the deployed product version was free of known exploitable vulnerabilities when scanned.

Authenticated and API scanning extends confirmation behind the login wall and across API surfaces, where the most exploitable behavior in deployed products lives. This closes the gap between "the public surface is clean" and Annex I coverage across the full product.

Retest workflows run a targeted test after remediation. Before-and-after comparisons confirm the fix is effective, completing the Annex I, Part II, point (3) evidence chain:

issue detected → validated → remediated → retested → closed.

Available in PDF, DOCX, or JSON formats, the final report is part of the retest workflow rather than a separate task. The output drops into the technical documentation required by Article 31 and Annex VII without manual reformatting.

Scheduled rescans let you retest fixes during the next scan cycle. You detect any regressions and provide evidence for the entire support period.

API-triggered scans feed existing release pipelines, meaning GitHub Actions block release on critical CVEs. For Annex I, Part I, point (2) release-gate obligation, this is the control applied at the point of release, not after.