Continuous vulnerability evidence for CRA compliance
If you sell products on the EU market, you need a CRA (Cyber Resilience Act) evidence layer in place before the Article 14 reporting obligations take effect on 11 September 2026.
The CRA requires products to have no known exploitable vulnerabilities at release, effective vulnerability handling across the support period, and 24-hour reporting of actively exploited vulnerabilities to ENISA.
Pentest-Tools.com produces the validated technical evidence that those obligations depend on.
What does the CRA actually require?
The CRA applies to all manufacturers of hardware and software products that sell on the EU market. If you’re reading this, it probably applies to you.
Annex I, Part I, point (2): no known exploitable vulnerabilities at release
Manufacturers must place products on the market without any known exploitable vulnerabilities. This is the release-gate obligation, forcing a pre-release vulnerability assessment with evidence.
Annex I, Part II, point (7): regular security testing
Products require effective and regular tests and reviews of the security of the product. Auditors and notified bodies expect to see the testing cadence and example test results, not just a written policy.
Article 13(8): vulnerability handling across the support period
Manufacturers must handle vulnerabilities effectively for the entire support period - a minimum of five years for most products. Vulnerability handling is a lifecycle obligation, not a release-time check.
Article 14: 24-hour reporting of exploited vulnerabilities
Manufacturers must report any actively exploited vulnerability, as well as any severe incident affecting product security,through ENISA's Single Reporting Platform. Manufacturers must submit an early warning within 24 hours of discovery, a full notification within 72 hours, and a final report within 14 days of releasing a corrective measure.
Where the CRA compliance evidence gap lives
The manual evidence bottleneck
GRC tools hold evidence, but only if someone puts it there. These tools don’t actually generate evidence.
Raw scans aren't audit-proof
Having a vulnerability scanner does not equal producing a validated finding, a retest, or a report. Auditors distinguish between these three things.
Point-in-time tests fail continuous audits
Manual penetration tests produce a point-in-time snapshot. SOC 2 Type II observation periods run for months, meaning a single pentest is structurally insufficient.
False positives stall remediation
Noisy scanners with false positives delay remediation evidence. Every false positive that reaches a developer queue is time not spent on real findings.
The internal asset blind spot
Scanning internal and private cloud assets - where sensitive data lives - requires a deployment model that most cloud-only scanners do not support.
How Pentest-Tools.com closes the CRA evidence loop
Evidence a vulnerability existed
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.
Evidence it was validated
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.
Evidence it was remediated
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.
Evidence the fix held
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.
Integrations that turn Pentest-Tools.com into a CRA evidence workflow
Integrations are what turn findings into action and action into evidence.
Jira: remediation evidence as a workflow by-product
Validated findings push as issues with severity, CVE reference, and PoC attachments. The vulnerability handling becomes a workflow by-product, not a separate compliance task.
Vanta: sync evidence across parallel programmes
Evidence syncs to 32 Vanta tests and 2 controls daily (05:00 UTC) for manufacturers running parallel SOC 2 or ISO 27001 programmes. Available on all paid plans.
GitHub Actions, CI/CD: block at the point of release
Scan on every pull request or release; block on critical CVEs at the point of release.
Webhooks: route evidence to any endpoint
Custom triggers on CVE, asset, CVSS, or EPSS score push results as JSON or PDF to any endpoint - evidence repository, SIEM, or product security dashboard. Scales across product lines.
Slack, Teams, Discord: instant Article 14 alerts
Alert rules fire on critical findings or actively-exploited CVE detections, putting Article 14-relevant signals in front of the on-call rotation immediately.
Vulnerability validation built into the scan from the start
Pentest-Tools.com starts the verification work during the scan
As web and network scanning run, findings that can prove to be exploitable get a Confirmed label, backed by request/response data, payload traces, or a proof of concept you can examine. The rest stay unconfirmed, so you always know which is which.
When a finding needs more, validation continues in the same product
Deeper exploitation confirms real impact and also captures the evidence. Assessment and validation under the same roof means that the proof an auditor or a buyer asks for is already attached to the finding.
Built for the entire CRA product lifecycle
Unlike other security regulations that evaluate your organisation's security programme, the CRA evaluates each individual product. Market surveillance authorities want to know whether you’ve ensured each product version is free of KEVs, and whether you have kept them that way across the support period.
Evidence organized per product
Workspaces organize evidence by product or client environment, scheduled scans run on a cadence tied to your release cycle, and vulnerability monitoring runs between scans.
Coverage behind the login wall
Authenticated scanning extends coverage behind the login wall, where most exploitable behaviour lives.
No client-side infrastructure to rebuild
For MSPs and security teams, each client environment gets its own VPN Agent deployment. That means there’s no client-side infrastructure to rebuild between engagements.
See how the VPN Agent works in our SOC 2 webinar
Chasing vulnerabilities manually doesn't scale across a product's five-year support period. In this live demo, our team bypasses the theory and shows how to build an automated workflow that actually fits embedded and private cloud product environments. See exactly how to uncover internal assets, validate findings, and produce the technical evidence the CRA expects, leaving the manual grind behind.
Why Pentest-Tools.com’s European origin matters under CRA
EU processing
Pentest-Tools.com is ISO/IEC 27001:2023 certified and processes data in the EU. Although the CRA doesn’t require EU-resident tooling, that matters.
One less category of due diligence
When your organization becomes a vendor under these frameworks, EU-resident data processing removes a category of due diligence questions before authorities get a chance to ask.
Proof Pentest-Tools.com supports CRA compliance
Benchmark-proven accuracy
Our Network Scanner ranked #1 in a Network Scanners Benchmark for having the highest remote detection accuracy across 128 environments, against Qualys, Nessus, OpenVAS, and others.
Deep application scanning
The Website Vulnerability Scanner covers vulnerabilities like XSS, SQL injection, HTTP Prototype Pollution, Directory Traversal, and 75+ more vulnerabilities in running web applications.
Proven global scale
In 2025, Pentest-Tools.com ran over 6M scans across 2000+ security teams in 119 countries, and sent tens of thousands of reports and exports to clients, teammates, and stakeholders.
Immediate, customized response
Dedicated free scanners for actively exploited CVEs - including regreSSHion CVE-2024-6387 (OpenSSH RCE), LDAPNightmare CVE-2024-49113 (Windows LDAP), and SessionReaper CVE-2025-54236 (Magento 2 / Adobe Commerce) - are operational tools built by the in-house offensive research team, not repackaged public information.
Get the blueprint for compliance reporting
Find out how we map offensive security data directly to compliance controls.
What customers are saying
The scans run quickly and the dashboard is easy to use. I like the attack surface feature. Organizing your scans and data is very simple to follow. Being cloud-based, you can get to the tools from anywhere without lugging around a dedicated device. The ability to generate and customize reports is very helpful.
Dr. Patrick Johnson
Business Owner at True North Consulting Group
See the CRA evidence trail in action
Start collecting audit-ready evidence yourself, or get a personalized walkthrough for your team's complex environment.
CRA compliance FAQs
Does Pentest-Tools.com generate CRA's Annex I Part II point (1) SBOM?
No. Pentest-Tools.com is a vulnerability assessment and validation layer. It does not generate SBOMs in SPDX or CycloneDX format. Manufacturers typically pair an SBOM tool with a vulnerability assessment tool; Pentest-Tools.com is the latter.
Does Pentest-Tools.com provide the coordinated vulnerability disclosure (CVD) process the CRA requires?
No. Annex I, Part II, point (5) requires a CVD policy and an intake mechanism - typically a security.txt file and a vulnerability submission process. Pentest-Tools.com does not provide that infrastructure. It produces the validated detections that feed into a CVD process, not the process itself.
Does running scans make our product CRA-compliant?
No. The CRA requires manufacturers to demonstrate compliance with the essential requirements of Annex I, complete a conformity assessment, draw up a Declaration of Conformity, and affix the CE marking.
Pentest-Tools.com produces the technical vulnerability evidence layer that several of those obligations depend on, but it does not replace the conformity assessment process or a notified body.
How does Pentest-Tools.com support the Article 14 reporting window?
Two ways. First, our research team publishes dedicated scanners for high-impact and actively exploited CVEs, so once a check exists you get answers from scan evidence rather than manual triage. Second, monitoring and alerting (via Slack, Teams, and webhooks) surface a relevant detection the moment it appears, not on the next scheduled scan. Pentest-Tools.com does not submit Article 14 reports to ENISA on your behalf - the regulation requires the manufacturer to do that directly.
Can Pentest-Tools.com scan internal, embedded, or on-prem product environments?
Yes, via the VPN Agent, deployed inside the product environment (including via the AWS Marketplace). It gives the cloud scanner a local presence without requiring a permanent on-premises appliance.
What does a CRA evidence package from Pentest-Tools.com actually look like?
Detection, validation, remediation, and ongoing monitoring across the support period are all exportable as PDF, DOCX, or JSON with custom report templates formatted for Article 31 and Annex VII.
Does automated scanning alone satisfy Annex I Part II point (7)?
Not on its own. The regulation expects a layered testing programme:
Continuous automated scanning
Periodic manual penetration testing
Threat modelling at design time
Code-level analysis in development.
Pentest-Tools.com produces the continuous automated testing evidence stream; combined with periodic manual testing, this satisfies the breadth and cadence that "effective and regular" implies.