Vulnerability scanning in 2026: from CVSS 4.0 to EPSS, CISA KEV, and exposure management

Scanning, penetration testing, and auditing answer different questions

Vulnerability scanning primarily answers this question: which known technical weaknesses can be detected within the agreed scope using specific tests and data sources? It provides broad, repeatable coverage and is well suited to recurring assessment, but its output still requires validation.

Penetration testing answers a different question: can a weakness actually be exploited in an agreed scenario, can several weaknesses be chained into an attack path, or can a control be bypassed? A penetration test may reveal business-logic flaws or authorization weaknesses that a typical infrastructure scanner will not detect. At the same time, a penetration test is a point-in-time assessment and does not replace continuous detection of newly disclosed vulnerabilities. NIST SP 800-115 describes these techniques as complementary security assessment methods.^[1]

An IT security audit, in turn, evaluates the environment against defined criteria: law, standards, contracts, policies, or an adopted methodology. It may assess whether the organization has a vulnerability management process, how it sets priorities, whether it meets defined remediation deadlines, how it handles exceptions, and whether it can demonstrate that actions were actually completed. A vulnerability scan may be one piece of evidence in such an audit, but it is not the same thing.

For that reason, scanning, penetration testing, and auditing should not be presented as three versions of the same service. It is equally wrong to assume that every organization subject to the Polish KSC Act, DORA, or GDPR must purchase all three on the same schedule. Obligations depend on the specific legal regime, risk, and architecture. In some cases the law explicitly requires testing or scanning; in others it requires an outcome that can be achieved through different controls.

Start with scope and inventory

A vulnerability management program starts before the first scan. You need to know what is being assessed.

The scope may include servers, workstations, network devices, internet-facing systems, cloud services, mobile devices, containers, machine images, applications, OT systems, and equipment operated by suppliers. From an effectiveness perspective, the percentage of the real environment that enters the program can be more important than the raw number of CVEs found.

A missing asset is especially dangerous because the scanner can work perfectly and still miss a system that is not in scope. This includes short-lived cloud instances, test systems that quietly became production systems, devices installed by contractors, and resources deployed outside the standard change process.

A mature program therefore combines information from asset inventories, cloud platforms, endpoint management systems, CMDBs, EDR, network monitoring, and service owners. The objective is not to create one perfect register. It is to detect inconsistencies between sources.

Authenticated and unauthenticated scanning

Unauthenticated scanning observes a system from the perspective of a remote client. It can identify open services, banners, versions, characteristic responses, configuration issues, and remotely reachable vulnerabilities. It is useful for assessing attack surface, especially from the internet, but it may not be able to determine patch status or host configuration accurately.

Authenticated scanning uses a technical account or another access mechanism on the target system. This allows the scanner to read actual package versions, update status, and settings that are not visible over the network. It usually improves data quality and reduces some false matches, but it introduces new requirements: secure credential storage, least privilege, logging of scanner-account use, and strict control over the reach of that account.

There is no universal rule that unauthenticated scanning is only for the internet and authenticated scanning only for internal networks. The correct mode depends on the objective. For a public-facing system, it can be useful to know both what an untrusted external client can see and whether the host actually has the expected patches installed.

Scanning should not be treated as destructive testing. Active tests can still affect old devices, real-time systems, OT equipment, printers, medical devices, or unstable services. Before a scan is launched, the rules of engagement, testing windows, stop conditions, and owner contact must be defined. NIST SP 800-115 explicitly treats authorization and rules of engagement as part of preparation for technical testing.^[1]

Validation: a scanner result is not yet a finding

One of the most expensive mistakes in vulnerability management is forwarding raw scan output without validation.

A scanner can misidentify a vulnerability based on a version exposed over the network. It may not account for a vendor backport. It may identify a vulnerable library that exists on disk but is not used in the vulnerable context. It may also miss a problem when a service is filtered or version identification is impossible.

Validation does not necessarily mean manually reviewing every line. It does mean having a method for resolving uncertain cases, considering vendor advisories, the local package state, configuration, exposure, and evidence from authenticated scanning.

A report should distinguish at least between confirmed vulnerabilities, probable observations requiring verification, non-applicable items, and findings that could not be resolved. This lets the system owner understand what the conclusion is based on and what should happen next.

CVSS 4.0: severity, not a ready-made risk score

FIRST officially published CVSS 4.0 on 1 November 2023. The June 2023 presentation was a preview, not the official publication date.^[2]

CVSS 4.0 retains the 0-10 scale but changes the model. The Scope metric from version 3.1 was removed and impacts on the vulnerable system were separated from impacts on a subsequent system. A new Base metric, Attack Requirements, was introduced, and User Interaction became more granular. FIRST now distinguishes Base, Threat, Environmental, and Supplemental metric groups.^[2]

The Threat group includes Exploit Maturity, which captures the maturity of available exploitation methods. The Environmental group allows the consumer to reflect the importance of confidentiality, integrity, and availability in its own environment and to modify selected Base metrics. The Supplemental group carries additional information such as Safety, Automatable, Recovery, Vulnerability Response Effort, and Provider Urgency. Supplemental metrics do not change the calculated CVSS score.^[2]

FIRST's most important warning is explicit: the CVSS Base Score measures severity, not risk. A Base score does not tell you whether the system exists in your organization, whether it is exposed to the internet, whether it contains critical data, whether compensating controls are present, or whether attackers are actively exploiting the flaw.^[2]

A policy such as "patch everything with CVSS >= 7 within 30 days" should therefore not be treated as a universal risk model. Such a threshold can be one element of internal policy, but it is not a universal boundary between acceptable and unacceptable risk.

EPSS: exploitation forecast, not another severity scale

The Exploit Prediction Scoring System (EPSS) is a data-driven model maintained by the FIRST community. It estimates the probability that exploitation activity for a published CVE will be observed in the next 30 days. The score ranges from 0 to 1 and is updated daily.^[3] The foundations of an earlier generation of the model were also described in the peer-reviewed paper by Jacobs and co-authors.^[4]

EPSS does not tell you how serious the impact of successful exploitation will be. It also does not know your environment. A score of 0.10 means an estimated probability of roughly 10 percent that exploitation activity will be observed within the 30-day prediction window in the EPSS model. It does not mean "10 percent organizational risk".^[3]

FIRST does not define an official threshold above which every vulnerability becomes critical. Organizations can define thresholds for their own workflow, but those thresholds should be calibrated to team capacity, asset type, and risk tolerance. FIRST also publishes percentiles, which help show where a vulnerability ranks within the overall scored population.^[3]

CISA KEV: evidence of exploitation in the wild

The CISA Known Exploited Vulnerabilities Catalog contains vulnerabilities that meet criteria for confirmed exploitation in the wild. CISA itself describes KEV as an authoritative input organizations should use in vulnerability management prioritization.^[5]

For U.S. Federal Civilian Executive Branch agencies, remediation deadlines follow from Binding Operational Directive 22-01 and the due dates assigned to individual KEV entries. Those deadlines do not automatically apply to Polish companies or public bodies. In Poland, KEV is primarily a strong threat-intelligence signal: it tells you that the question "is anyone exploiting this?" has already been answered in the affirmative.

KEV is not a complete list of every vulnerability exploited anywhere in the world. Inclusion depends on CISA criteria and available evidence. A CVE that is absent from KEV is not therefore safe by definition. A mature program supplements KEV with vendor advisories, CSIRT/CERT notifications, ENISA reporting, internal SOC data, and other reliable threat intelligence.^[5][7][19]

Combining CVSS, EPSS, KEV, and asset context

The most effective prioritization does not collapse all these signals into one arbitrary number. It is often better to preserve what each of them actually means.

• CVSS answers the question of technical severity.
• EPSS answers the question of predicted exploitation likelihood over the next 30 days.
• KEV answers whether confirmed exploitation has been observed in real attacks.
• Organizational context answers whether the vulnerable asset is important, reachable, exposed, and what compromise would mean for the business.

Operational information also matters: whether a patch exists, how difficult it is to deploy, whether compensating controls are possible, what business dependencies exist, and which legal obligations apply.

For example, a moderate-CVSS vulnerability may deserve immediate attention if it is in KEV, affects an internet-facing edge device, and provides an entry point into the network. A high-CVSS vulnerability in a disabled component of an isolated lab can follow a different path. Those decisions should be documented and repeatable.

Remediation deadlines should therefore come from organizational policy and risk analysis. NIST SP 800-40 Rev. 4 describes patch management as the process of identifying, prioritizing, acquiring, installing, and verifying patches, but it does not impose universal service-level targets such as "KEV in 14 days" or "CVSS 9.0 in 30 days" for every organization.^[12]

What 2025-2026 data shows

The Verizon 2026 DBIR identified vulnerability exploitation as the initial access vector in 31 percent of analyzed breaches and reported that it surpassed credential abuse as an entry point for the first time in the history of the report.^[6] This does not mean that 31 percent of all cyberattacks worldwide begin with a vulnerability. DBIR describes its own dataset and methodology.

ENISA Threat Landscape 2025, based on 4,875 incidents between 1 July 2024 and 30 June 2025, reported vulnerability exploitation as 21.3 percent of identified initial intrusion vectors, second to phishing.^[7] This is a different population from DBIR, so the percentages should not be directly compared.

Both sources nevertheless support the same operational conclusion: technical vulnerabilities remain an important route to initial access. Particular attention is warranted for edge systems and other internet-facing assets, where the window between disclosure and exploitation attempts can be short.

Common vulnerability management failures

1. Scanning only before an audit. An annual report can prove that an assessment happened on a particular date, but it says nothing about vulnerabilities disclosed afterward or configuration changes made after the scan. Frequency should reflect risk, environmental change, and applicable requirements. Some systems justify short cycles; others require more cautious testing in controlled windows.
2. Missing ownership. A CVE list is not a remediation plan. Every item that requires action should have an owner, priority, deadline, status, and closure evidence.
3. No exception process. Not every patch can be installed immediately. A vendor fix may not exist, a maintenance window may be unavailable, or an application may be incompatible. An exception should have a rationale, a risk owner, compensating controls, a reassessment date, and a long-term resolution plan.
4. Limiting scope to servers. Vulnerabilities also exist in workstations, network appliances, printers, cameras, hypervisors, cloud systems, containers, and OT devices.
5. Treating finding count as a security score. An increase in findings after improving scan coverage can mean that the program has become better, not worse. Useful metrics therefore include asset coverage, validation time, remediation time for high-priority items, overdue exceptions, and recurring root causes.
6. Automated remediation without impact control. A patch may remove a vulnerability and simultaneously stop a critical service. Mature vulnerability management is connected to change management, testing, backup, and rollback planning.

OT and systems that are difficult to patch

In OT environments, active scanning requires particular care. An old controller, real-time device, or unusual protocol may react to testing traffic very differently from a typical IT server. Before scanning, the permitted techniques should be agreed with the process owner and equipment vendor. In some segments, passive network observation and inventory may play a larger role.

The inability to patch immediately does not mean that no action is possible. Exposure can be reduced through segmentation, traffic filtering, restrictions on remote access, additional monitoring, application control, or temporary feature disablement. These are compensating controls that should be linked to a specific risk and to a long-term remediation plan.

Web application scanning

Infrastructure vulnerability scanning and dynamic web application testing are related but distinct areas. DAST tools send requests to an application and observe its responses. They can identify some classes of weakness, but they do not replace business-logic review, authorization testing, or source-code analysis.

OWASP Top 10 2025 is an awareness document describing important categories of web application security risk. It is not a scanning methodology. OWASP ASVS 5.0.0, by contrast, is a set of verifiable requirements and can be used as a much more precise basis for application security testing.^[17]

A statement such as "the DAST scanner found nothing" should therefore not be presented as proof that the entire application complies with OWASP Top 10 or ASVS.

Legal foundations in Poland and the EU

KSC. Following the amendment effective from 3 April 2026, Article 8 of the Polish Act on the National Cybersecurity System requires essential and important entities to perform systematic risk management, collect information about cyber threats and vulnerabilities, regularly update software with consideration of update criticality, and take action without undue delay after vulnerabilities are identified.^[8] The Act does not say that every such entity must buy a particular scanner.

For some providers covered by Article 8b KSC, Commission Implementing Regulation (EU) 2024/2690 applies directly. Section 6.10 requires obtaining information about vulnerabilities, evaluating exposure, and managing them, and, where appropriate, performing vulnerability scans at planned intervals and retaining evidence of the results. The same act requires a security testing policy and links vulnerability handling with patch management, change management, risk management, and incident management.^[10]

NIS2. Article 21 of the Directive includes, among cybersecurity risk-management measures, security in the acquisition, development, and maintenance of network and information systems, including vulnerability handling and disclosure, and policies and procedures to assess control effectiveness.^[9] A Polish organization should nevertheless determine its concrete obligations primarily under the KSC Act and directly applicable EU acts.

KRI. The Polish National Interoperability Framework regulation of 21 May 2024, in force on 29 August 2026, requires public-sector entities to maintain an up-to-date inventory of hardware and software, keep software updated, reduce risks arising from published technical vulnerabilities, and act without delay when previously undisclosed vulnerabilities are identified.^[14] The regulation does not prescribe one scanning frequency. ELI indicates that it will cease to apply on 23 February 2027. In August 2026, the new KRI proposal RD313 remains a draft and should not be treated as current law.^[14]

DORA. Regulation (EU) 2022/2554 requires financial entities to continuously identify sources of ICT risk and assess relevant cyber threats and ICT vulnerabilities.^[11] Commission Delegated Regulation (EU) 2024/1774 goes further: it requires vulnerability management procedures and automated vulnerability scanning and assessment of ICT assets, with frequency and scope commensurate with asset classification and risk profile.^[13] It therefore does not impose one universal schedule for every system.

GDPR. Article 32(1)(d) requires, where appropriate to the risk, a process for regularly testing, assessing, and evaluating the effectiveness of technical and organizational security measures.^[15] It does not explicitly require "a vulnerability scan every X days". Vulnerability scanning can, however, be one form of evidence that security controls are being assessed in practice.

PCI DSS. For environments subject to payment-card standards, the current version is PCI DSS v4.0.1. Requirement 11 includes recurring vulnerability scans, and certain external scans must be performed by a PCI SSC Approved Scanning Vendor. PCI SSC explains that quarterly scans mean at least once every three months.^[16] This is an industry-standard requirement, not a general legal duty for every organization.

Cyber Resilience Act and SBOM

Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), changes responsibilities on the manufacturer side for products with digital elements. Its main obligations apply from 11 December 2027, while the reporting obligations in Article 14 start applying on 11 September 2026.^[18]

CRA requires vulnerability handling processes, and technical documentation must include a software bill of materials (SBOM). Annex I requires manufacturers to identify and document vulnerabilities and components and to draw up an SBOM in a commonly used, machine-readable format covering at least top-level dependencies.^[18]

For a user, an SBOM is not a scanner and does not automatically prove that a product is vulnerable. It does, however, make it faster to answer whether a particular component is present in a product. That can shorten triage after a vulnerability is disclosed in a widely used library.

From vulnerability scanning to exposure management

A mature program increasingly starts not with the CVE list but with a broader question: which attack paths lead to important assets, and which weaknesses actually increase the probability of compromise?

Vulnerability scanning remains an important sensor, but it should be combined with attack-surface data, identities, cloud configuration, application security, attacker activity, and real service dependencies. This does not mean that every organization must buy a product marketed as "exposure management". The point is to connect data into a decision process.

In practice, vulnerability scanning can be connected with an IT security audit, hardening, penetration testing, and a 24/7 SOC. Each of those functions answers a different question. At 4crypto, technical findings are treated as inputs to risk management rather than as a standalone "security certificate".

How to measure the program

The number of detected vulnerabilities is operationally useful but is a weak maturity metric. More useful measures include:

• coverage: what percentage of known assets and critical services are covered by an appropriate assessment method;
• freshness: how quickly a new asset enters the program;
• validation: how long it takes to confirm or reject a high-priority finding;
• remediation: the time from confirmation to effective remediation or risk reduction;
• backlog: how many items are overdue and why;
• exceptions: how many accepted exceptions lack a current reassessment;
• recurrence: how many weaknesses reappear because of the same root cause;
• verification: what percentage of remediations have been retested.

Metrics should be defined so that the start and end of each measurement are unambiguous. "Mean time to remediate" measured from CVE publication is not the same metric as "mean time to remediate" measured from the moment the vulnerability is detected in your environment.