Infrastructure vulnerability scanning – authenticated vs unauthenticated, how often to scan and how to prioritise findings (CVSS, EPSS, KEV)

What is infrastructure vulnerability scanning? Infrastructure vulnerability scanning is an automated process in which a scanner identifies network services, operating systems and software on hosts, then compares them against databases of known vulnerabilities (CVEs) and misconfigurations. Every organisation operating servers, network devices or workstations needs it, and regulations such as PCI DSS, DORA and NIS2 require it explicitly or implicitly. Scanning is the first, cheapest and most frequently repeated element of a security testing programme – but only when it is correctly configured, run at the right frequency and connected to a remediation process.

Canonical definition: A vulnerability scan is an automated assessment of systems, networks or applications that detects known vulnerabilities and misconfigurations by comparing identified components against vulnerability databases, without actively exploiting them.

Infrastructure vulnerability scanning – key takeaways:

1. An authenticated scan (with credentials to the system) typically finds several times more vulnerabilities than an unauthenticated one, because it sees installed packages and configuration rather than only network service responses.
2. PCI DSS v4.0.1 requires internal scans at least every 3 months, authenticated from 31 March 2025 (requirement 11.3.1.2), plus quarterly external ASV scans (11.3.2).
3. DORA, through RTS 2024/1774 (Article 10), requires automated scanning of ICT assets supporting critical or important functions at least weekly.
4. A CVSS score alone is not enough to prioritise – combine it with EPSS (probability of exploitation) and the CISA KEV catalogue (actively exploited vulnerabilities) and with asset context.
5. According to Verizon DBIR 2025, exploitation of vulnerabilities was the initial access vector in around 20 % of breaches – a scan without a remediation process does not reduce that risk.
6. Patronusec delivers internal, external and ASV vulnerability scans, configuring authentication and scope so that results are acceptable to a QSA and to regulators.

---

---

What is a vulnerability scan, and how does it differ from a penetration test?

A vulnerability scan is automated detection of known flaws by comparing components against CVE databases, whereas a penetration test is a manual attempt to exploit vulnerabilities and chain them into an attack path. A scan answers “what is vulnerable”; a pentest answers “what can be done with it”. A scan takes hours and repeats weekly or quarterly; a pentest takes weeks and runs once or twice a year.

Criterion	Vulnerability scan	Penetration test
Method	automated, signature- and version-based	manual, tool-assisted, attacker logic
Detects	known CVEs, missing patches, weak configurations, default credentials	logic flaws, vulnerability chains, privilege escalation, segmentation weaknesses
False positives	frequent (reported version ≠ backported fix)	rare – every finding is confirmed
Duration	hours	1-4 weeks
Frequency	weekly to quarterly	annual or after significant change
Indicative cost	GBP 0-6,000 per year (licence or service) [REQUIRES VERIFICATION]	GBP 5,000-40,000 per project [REQUIRES VERIFICATION]
Output	vulnerability list with CVSS scores	report with attack narrative and business risk

A vulnerability scan identifies known flaws without exploiting them, whereas a penetration test verifies whether the identified flaws can actually be exploited and chained into an attack path.

The two are complementary and sit side by side in compliance programmes: PCI DSS requires both scans (requirement 11.3) and penetration tests (11.4); DORA lists both in Article 25 as elements of the testing programme; ISO 27001:2022 control A.8.8 requires obtaining information about technical vulnerabilities and taking appropriate measures, without prescribing a method. For an overview of all methods, see IT security testing methods.

In practice: a scan will report that a server runs an OpenSSH version with a CVE rated 9.8; a pentest checks whether that version is actually exploitable in your configuration, whether it provides entry, and where it leads next.

What types of infrastructure vulnerability scan exist?

Infrastructure scans divide along four axes: perspective (external from the internet or internal from the LAN), authentication (with or without credentials), collection method (host agent or network scan) and regulatory purpose (ASV scans for PCI DSS by an approved vendor). A complete programme combines at least an unauthenticated external scan and an authenticated internal scan.

Type	Perspective	What it shows	Typical use
External unauthenticated	from the internet, no credentials	the attack surface visible to anyone: open ports, service versions, certificates, public service misconfigurations	weekly perimeter monitoring; PCI DSS 11.3.2 (as an ASV scan)
Internal unauthenticated	from the LAN, no credentials	what an attacker sees after gaining a foothold: internal services, legacy protocols, network shares	lateral-movement assessment, segmentation verification
Internal authenticated	from the LAN, with a system account	missing patches, package versions, configuration, local accounts, policies	PCI DSS 11.3.1.2, DORA RTS Art. 10, the basis of vulnerability management
Agent-based	agent installed on the host	as authenticated, but continuous and covering mobile and remote devices	laptops, cloud, dynamic environments
ASV (Approved Scanning Vendor)	external, by a PCI SSC-approved vendor	compliance of the external attack surface with PCI DSS 11.3.2	quarterly “passing scan” for all in-scope public IPs
Configuration (compliance) scan	authenticated, against a benchmark (CIS, DISA STIG)	deviations from hardening standards, not only CVEs	PCI DSS 2.2, ISO 27001 A.8.9

An ASV scan is an external, unauthenticated vulnerability scan performed by a vendor approved by the PCI SSC, required by PCI DSS requirement 11.3.2 at least every three months for all publicly accessible IP addresses in the cardholder data environment.

Two distinctions cause the most confusion. First, an ASV scan does not replace the internal authenticated scan – they are separate PCI DSS requirements. Second, a configuration scan against a CIS benchmark is a different product from a CVE scan: the first tells you SMBv1 is enabled, the second that a system lacks the patch for a specific flaw. A mature programme needs both.

In practice, an organisation processing card payments needs at least three scan streams: quarterly ASV (external), quarterly or more frequent internal authenticated, and a scan after every significant change.

Why does an authenticated scan find more, and what does it require?

An authenticated scan finds more because it logs into the system and reads installed packages, patch levels, registry or configuration, instead of inferring versions from network service banners. An unauthenticated scan cannot see vulnerabilities in software without open ports (browsers, office suites, libraries) and produces more false positives. It does, however, require a dedicated account, secure credential storage and system owners’ consent.

What you need to run an authenticated scan:

1. A scanning account – dedicated, with read access to configuration (Linux: an account with sudo to selected commands or none; Windows: an account with administrative read access to the registry and WMI, ideally a gMSA or managed account).
2. Secure credential storage – in the scanner’s vault or integrated with a PAM system; rotated passwords, logged access.
3. Network exceptions – firewall and EDR rules allowing the scanner SSH/WinRM/SMB to hosts; without them an authenticated scan silently degrades to unauthenticated.
4. Verification of authentication success – scanners report which hosts failed login; that report must be read after every scan.
5. Consent and time windows – authenticated scans load hosts; for production systems agree windows and concurrency limits.

An authenticated vulnerability scan is one performed with credentials that allow the scanner to log into the target system and read installed software and configuration – PCI DSS v4.0.1 requires it for internal scans under requirement 11.3.1.2 from 31 Mar 2025.

Requirement 11.3.1.2 of PCI DSS v4.0.1 specifies: internal scans are performed with authentication, credentials are sufficient for a full scan, and for systems that cannot accept credentials the exception must be documented. Scanning accounts with interactive login rights fall under requirement 8.2.2 (management of shared and system accounts).

In practice, the most common cause of a “clean” internal scan report is not a secure environment but failed authentication on 40 % of hosts that nobody checked.

How often should you scan infrastructure under PCI DSS, DORA, NIS2 and good practice?

Scan frequency follows regulation and asset classification: PCI DSS requires scans at least every 3 months and after every significant change, DORA (RTS 2024/1774) at least weekly for assets supporting critical or important functions, and CIS Controls v8 at least quarterly. Good practice is weekly external scanning, internal scanning every 2-4 weeks, and continuous (agent-based) scanning for endpoints.

Requirement source	Scope	Minimum frequency	Additional conditions
PCI DSS v4.0.1 requirement 11.3.1	internal scans in the CDE	every 3 months	high and critical vulnerabilities resolved, rescan confirms; authenticated from 31 Mar 2025 (11.3.1.2)
PCI DSS v4.0.1 requirement 11.3.1.3	internal scans	after every significant change	e.g. new systems, topology changes, product upgrades
PCI DSS v4.0.1 requirement 11.3.2	external ASV scans	every 3 months	“passing” result (no CVSS ≥ 4.0), rescans until passing
PCI DSS v4.0.1 requirement 11.3.2.1	external scans	after every significant change	may be run internally, ASV not required
DORA – RTS (EU) 2024/1774 Art. 10(2)(b)	all ICT assets, proportionate to classification	at least weekly for assets supporting critical or important functions	record every vulnerability and monitor remediation; verify that ICT providers report critical vulnerabilities
NIS2 Art. 21(2)(e)	essential and important entities	not quantified	“security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”
ISO/IEC 27001:2022 A.8.8	ISMS scope	not quantified	obtain vulnerability information, evaluate exposure, take appropriate measures
CIS Controls v8 7.5 and 7.6	internal and external assets	at least quarterly	authenticated internal scans (7.5), external scans (7.6)
SOC 2 CC7.1	system scope	not quantified	procedures to detect vulnerabilities and configuration changes
Cyber Essentials (UK)	in-scope devices	not a scan requirement	critical and high patches applied within 14 days of release

Under Article 10(2)(b) of Commission Delegated Regulation (EU) 2024/1774, financial entities subject to DORA perform automated vulnerability scanning of ICT assets supporting critical or important functions at least on a weekly basis.

The gap between “quarterly” (PCI DSS, CIS) and “weekly” (DORA) is not accidental: PCI DSS sets a minimum for compliance evidence, DORA an operational rhythm for a sector in which the window between exploit publication and mass use is measured in days. An organisation under both regimes adopts the weekly rhythm and treats the quarterly scan as a documentation checkpoint.

Patronusec Insight: In our project experience, a QSA most often challenges not the frequency itself but the continuity of evidence: four quarterly scans must cover every IP and every host in scope, and every high or critical vulnerability needs a rescan confirming remediation. A missing quarter, or one host skipped because authentication failed, is a non-compliance with requirement 11.3.1. Within our vulnerability scanning service, Patronusec configures schedule, scope and authentication so that a full 12 months of reports can be presented to the auditor without back-filling.

How do you prioritise scan results – CVSS, EPSS, KEV and asset context?

You prioritise scan results by combining four signals: technical severity (CVSS), the probability of exploitation in the next 30 days (EPSS), confirmed active exploitation (the CISA KEV catalogue) and asset context (internet exposure, critical function, sensitive data). CVSS alone produces too many “critical” items for any team to fix in a reasonable time.

Signal	Publisher	What it measures	How to use it
CVSS (v3.1, v4.0)	FIRST; scores assigned by NVD and vendors	technical severity on a 0-10 scale (attack vector, complexity, impact)	initial filter; PCI DSS treats ≥ 7.0 as “high”, ASV scans fail at ≥ 4.0
EPSS	FIRST (model updated daily)	probability of exploitation within 30 days (0-1)	treat EPSS > 0.1 as priority regardless of CVSS
KEV	CISA (Known Exploited Vulnerabilities)	confirmed exploitation in real attacks	any KEV entry on an exposed asset = emergency remediation
Asset context	your asset register (CMDB)	exposure, DORA/PCI classification, data, dependencies	multiplier: the same CVE on a payment server and on a printer are two different risks
Exploitability	scanner and pentest data	public exploit available, mitigations effective (EDR, segmentation)	raises or lowers priority

A practical four-step prioritisation model:

1. Immediate (24-72 h): vulnerability in KEV or EPSS > 0.5, on an internet-facing asset or one supporting a critical function.
2. Urgent (7-14 days): CVSS ≥ 7.0 and (EPSS > 0.1 or exposed asset); all “high” vulnerabilities in PCI DSS scope.
3. Scheduled (30-90 days): CVSS 4.0-6.9 on internal assets; remaining PCI DSS items per the targeted risk analysis (requirement 11.3.1.1).
4. Risk acceptance: vulnerabilities with no patch and no exploitability in the given configuration – documented, with a review date.

EPSS (Exploit Prediction Scoring System) is a model published by FIRST that estimates the probability of a given vulnerability being exploited within the next 30 days, complementing the CVSS severity rating with a likelihood dimension.

Requirement 11.3.1.1 of PCI DSS v4.0.1 requires vulnerabilities other than high and critical to be managed according to a targeted risk analysis (requirement 12.3.1) – a formal basis for context-driven rather than CVSS-only prioritisation.

In practice, a list of 400 “critical” vulnerabilities from a quarterly scan usually shrinks to 20-40 items requiring action this week once EPSS and KEV are applied – and those are what the team should work on.

How do you build a vulnerability management process around scanning?

The scan is a data supplier; vulnerability management is the process that consumes it: asset inventory, scanning, prioritisation, owner assignment, remediation within SLA, verification by rescan, and trend reporting. Without that cycle, scanning generates reports nobody reads and the count of open vulnerabilities grows every quarter.

Six process elements and typical metrics:

Element	What it covers	Metric
1. Inventory	asset register with owner, classification and exposure; discovery scans to find unknown hosts	share of hosts in scan vs CMDB (target > 95 %)
2. Scanning	schedule, scope, authentication, exceptions	share of hosts with successful authentication
3. Prioritisation	CVSS + EPSS + KEV + context; deduplication	number of “actionable” vulnerabilities after filtering
4. Assignment	technical owner per asset, ticket in the service desk	share of vulnerabilities with an assigned owner
5. Remediation	patch, configuration, mitigation or risk acceptance within SLA	median time to remediate (MTTR) per severity
6. Verification and reporting	rescan, ticket closure, board report	share remediated within SLA; trend of open items

Indicative SLAs used in practice (to be adapted to the organisation’s own risk analysis):

• KEV / actively exploited, exposed asset: 72 hours (CISA BOD 22-01 sets 2-3 week deadlines for US federal agencies; financial-sector practice is stricter),
• critical (CVSS ≥ 9.0): 7-14 days,
• high (7.0-8.9): 30 days,
• medium (4.0-6.9): 90 days,
• low: in the maintenance cycle or risk acceptance.

Vulnerability management is a continuous process comprising asset inventory, scanning, prioritisation, remediation within defined timeframes and verification by rescan – as distinct from a single scan, which is only one of its stages.

Article 10(2) of RTS 2024/1774 adds four process obligations for DORA entities: tracking third-party libraries (including open source) in services supporting critical functions, verifying that ICT providers report critical vulnerabilities, responsible disclosure procedures, and recording every detected vulnerability with monitoring of its resolution. Provider-side vulnerability handling is covered in third-party risk management.

In practice, the scanner must be integrated with the service desk and CMDB – otherwise stages 4-6 are done manually in a spreadsheet, which stops working after the second quarter at a few hundred hosts.

What do practitioners usually get wrong with infrastructure vulnerability scanning?

The most common mistakes concern scope, authentication, interpretation of results and failure to close the loop. Each makes the scan formally compliant without reducing risk.

❌ Scanning only known IP addresses without discovery scans – hosts missing from the CMDB never enter scope; PCI DSS 11.3.1 covers all in-scope components, including forgotten ones.

❌ Ignoring the failed-authentication report – an authenticated scan that logged into 60 % of hosts is 40 % unauthenticated; a “clean” result is then an artefact, not evidence.

❌ Treating CVSS as the only criterion – hundreds of “critical” items without EPSS and KEV paralyse the team; PCI DSS 11.3.1.1 explicitly provides for risk analysis of lower-rated vulnerabilities.

❌ Closing vulnerabilities without a rescan – a “patch deployed” ticket is not evidence; PCI DSS 11.3.1 requires a confirming rescan and DORA RTS Art. 10 requires monitoring and verification of remediation.

❌ Treating the ASV scan as the only external scan – quarterly ASV is the compliance minimum; between scans the perimeter goes unmonitored for 90 days.

❌ Permanently excluding “sensitive” systems – instead of exclusion: time windows, reduced concurrency, agent-based or passive scanning; a permanent exception requires documented risk acceptance and a review date.

Auditor’s checklist – what will a QSA or ISO 27001 auditor check on vulnerability scanning?

1. Is there a documented vulnerability management procedure with scan frequency, prioritisation criteria and remediation deadlines?
2. Does scan scope cover every asset in the audit scope (host list from the scan reconciled against the asset register and network diagram)?
3. Are internal scans authenticated, and is there an authentication success report for every scan?
4. Do the past 12 months contain four quarterly internal scans and four passing ASV reports (PCI DSS)?
5. Does every high or critical vulnerability have a rescan confirming remediation?
6. Are there scans after significant changes, and is “significant change” defined in the procedure?
7. Are vulnerabilities below high managed according to a documented risk analysis (PCI DSS 12.3.1)?
8. Are scanning accounts subject to privileged account management (password rotation, access logging)?
9. Do exceptions and risk acceptances have an owner, justification and review date?
10. Does management receive a trend report (open vulnerabilities, MTTR, share within SLA)?

---

FAQ – common questions about infrastructure vulnerability scanning

---

Recommended reading

1. IT security testing methods – how scans, penetration tests and red teaming form a complete testing programme.
2. Application vulnerability scanning – DAST, SAST, SCA, IaC and containers.
3. Vulnerability scanning and compliance requirements – mapping DORA, NIS2, CRA, PCI DSS, ISO 27001, SOC 2.
4. PCI DSS scope, CDE and segmentation – how CDE scope determines the host list to scan.
5. Cyber Resilience Act obligations and deadlines – how scan results feed manufacturers’ vulnerability handling obligations.

---

Infrastructure vulnerability scanning – consultation

Patronusec delivers internal, external and ASV scans, configuring scope and authentication so that reports meet PCI DSS and DORA assessment requirements. If you want to check whether your current scanning programme would pass an assessment, book a free call.

Vulnerability scanning | ASV scanning | Penetration testing

---