← CRA Glossary
Technical Security

Vulnerability Scanning

Vulnerability scanning is the automated process of probing systems, networks, or applications to identify known security weaknesses by comparing observed configurations and software versions against databases of known vulnerabilities. It provides continuous visibility into a product's security posture and supports the CRA's requirement that manufacturers monitor and address vulnerabilities throughout a product's lifecycle.

Vulnerability scanning is the automated process of probing systems, networks, or applications to identify known security weaknesses by comparing observed configurations and software versions against databases of known vulnerabilities. It provides continuous visibility into a product's security posture and supports the CRA's requirement that manufacturers monitor and address vulnerabilities throughout a product's lifecycle.

Technical Security

What Is Vulnerability Scanning?

Vulnerability scanning uses automated tools to probe a target - a network range, a host, an application, or a container image - and identify security weaknesses by comparing what is found against a database of known vulnerabilities (CVEs) and misconfiguration signatures. Unlike penetration testing, vulnerability scanning is non-exploitative: it identifies potential weaknesses without actively exploiting them. Scans can be unauthenticated (external view, as an attacker would see the system) or authenticated (internal view, using credentials to inspect installed software versions and configuration details). Vulnerability scanning is a continuous activity, not a one-time exercise, because new CVEs are published daily.

CRA reference:Article 13(3)(5), Annex I Part I(2)(f)

Vulnerability Scanning Under the CRA

The CRA requires manufacturers to monitor for vulnerabilities in their products and components and to address them without undue delay. Vulnerability scanning is the operational mechanism that makes continuous monitoring achievable at scale. Manufacturers who scan their products and infrastructure regularly can detect when a newly published CVE affects a component they ship, triggering the remediation process required by Annex I Part I(2)(f). Without automated scanning, manufacturers must rely on passive vulnerability intelligence feeds alone, which may not alert them to configuration-level weaknesses or locally hosted services with outdated software that scanning would immediately detect.

CRA reference:Article 13(3), Annex I Part I(2)(f)

How Manufacturers Implement Vulnerability Scanning

Manufacturers should implement vulnerability scanning across three distinct targets: (1) product software - scanning container images, firmware builds, and application packages for known CVEs using SCA and image scanning in CI/CD pipelines; (2) production infrastructure - scanning the servers, cloud infrastructure, and APIs that support the product's backend services; and (3) product-as-deployed - where possible, scanning deployed product instances to verify update take-up and identify configuration drift. Scan results should feed into a vulnerability management workflow with defined SLAs for remediation based on CVSS severity. Scan reports and remediation records form part of the evidence base for CRA technical documentation.

CRA reference:Article 13(3)(5), Annex I Part I

Common Mistakes

A common error is running vulnerability scans at fixed intervals - monthly or quarterly - and treating the results as current. The CVE disclosure rate means a scan that is two weeks old may miss critical vulnerabilities discovered after the scan date. Continuous or at minimum weekly scanning of internet-facing systems is the appropriate cadence for CRA-regulated products. Manufacturers also frequently scan only the production environment and miss development and staging environments that may contain vulnerabilities mirroring the production attack surface. Additionally, generating scan reports without a defined remediation process renders the scanning activity compliance theatre rather than meaningful security activity.

CRA reference:Annex I Part I(2)(f)

CVD Portal makes Vulnerability Scanning compliance straightforward.

Public CVD submission portal, acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Receiving and tracking reports is free for all manufacturers placing products with digital elements on the EU market. Article 14 filing with the SRP-ready package is on Pro.

Start your free portal

Frequently asked

Is vulnerability scanning the same as a security audit?+

No. Vulnerability scanning is an automated, tool-driven process that identifies known weaknesses based on software versions, configurations, and signatures. A security audit is a broader, more comprehensive assessment - typically including manual review of policies, processes, code, and architecture - conducted by security professionals. Both are valuable. The CRA's requirements are best met by a combination: continuous automated scanning for known vulnerabilities, supplemented by periodic manual security audits and penetration tests.

How frequently must manufacturers scan their products under the CRA?+

The CRA does not specify a scanning frequency. The obligation is to monitor for vulnerabilities and address them without undue delay. Given that new CVEs are published daily and that the CISA KEV catalogue tracks actively exploited vulnerabilities in near real-time, manufacturers of internet-connected products should implement continuous monitoring, with at minimum daily checks against major vulnerability feeds for components in shipped products.

Should vulnerability scanning cover the product's cloud backend as well as the device itself?+

Yes. For any product with digital elements that involves a cloud backend - APIs, data storage, management consoles - the entire system falls within the product scope for CRA purposes. Vulnerabilities in the cloud backend that allow an attacker to compromise the product, access user data, or push malicious firmware updates are product vulnerabilities under the CRA, not separate IT security issues. Manufacturers must scan and secure all components of the product system, not only the physical device.

Related terms

Software Composition Analysis (SCA)Software Composition Analysis (SCA) is the automated process of identifying open-source and third-party components in a codebase and checking them against known vulnerability databases to detect security risks. SCA is the primary technical mechanism for meeting the CRA's requirement that manufacturers identify and manage vulnerabilities in their products' components.Penetration TestingPenetration testing is a structured, authorised security assessment in which testers simulate real-world attack techniques to identify exploitable vulnerabilities in a product, system, or network before malicious actors discover them. The EU Cyber Resilience Act implicitly requires manufacturers to test their products' security prior to market placement.Patch ManagementPatch management is the process of identifying, testing, approving, and deploying software updates that fix security vulnerabilities and bugs. The EU Cyber Resilience Act requires manufacturers to provide security patches for their products throughout the defined support period and to deliver them without undue delay.Common Vulnerability Scoring System (CVSS)CVSS is an open framework for communicating the characteristics and severity of software vulnerabilities, producing a numerical score from 0 to 10. Manufacturers use CVSS scores to prioritise remediation and to communicate risk in security advisories required under the CRA.DevSecOpsDevSecOps is the practice of integrating security tools, testing, and responsibilities throughout the software development and operations pipeline - making security a shared responsibility of development, security, and operations teams rather than a final-stage gate. DevSecOps operationalises the CRA's SDLC requirements in modern continuous delivery environments.Software Supply Chain SecuritySoftware supply chain security encompasses the practices and controls that ensure the integrity, authenticity, and security of all software components - open-source libraries, commercial off-the-shelf modules, and development toolchains - that are integrated into a product. The CRA places explicit obligations on manufacturers to manage supply chain security throughout the product lifecycle.

Sector checklists covering Vulnerability Scanning

Enterprise Networking EquipmentEnterprise networking equipment - switches, firewalls, load balancers, and network management systems - spans multiple Annex III classifications. Hardware firewalls are Class II Important products; network management software and monitoring tools are Class I Important products. Both require third-party conformity assessment.Industrial Controllers & PLCsIndustrial controllers, PLCs, and SCADA components are classified as Important Class II under Annex III of the CRA, requiring third-party conformity assessment. These products have long operational lifetimes (10–20+ years), network connectivity, and significant safety implications. CRA compliance must be planned well in advance of the September 2026 deadline.Consumer Routers & ModemsConsumer routers and modems are high-value targets for attackers and face specific CRA requirements around default credentials, remote management security, and firmware update integrity. Routers marketed for home use are Default class; those marketed for industrial or critical infrastructure use may be Annex III Class II.Smart Cameras & Video SurveillanceSmart cameras and IP video surveillance systems are frequently compromised via default credentials and unpatched firmware - they were among the first device classes targeted by Mirai and similar botnets. The CRA's prohibition on default passwords and requirement for secure update mechanisms directly target these failure modes. Manufacturers must also consider GDPR obligations around video data and the NIS2 implications for critical infrastructure deployments.

Browse the full CRA Compliance Checklist

See how Vulnerability Scanning fits into your complete CRA compliance programme.

View checklists →