Legacy vulnerability management is an enumeration problem before it is a remediation problem. Arctic Wolf's guide puts the root cause as siloed inventories: the identity provider holds users, EDR holds only the endpoints where the agent actually installed, and the CMDB holds whatever someone remembered to register [8]. None of those produces a list of assets that exist but were never enrolled. That is where the 17% sits [4].
The arithmetic is worth stating in units of machines rather than percentages. Seventeen percent of a sample of more than 800,000 assets is roughly 136,000 assets that no scanner was ever pointed at [2][4][12]. On the breach side, 20% to 31% is an 11 point move, about 55% growth in one report cycle [13].
The buckets do not stack. The same post reports 18% outside enterprise patch or configuration management, 10% with no endpoint protection, and 19% at end of life [5][6][7], and it publishes no overlap between those groups, so adding them into a single number for the exposed share of an estate is not supported. The 19% is the category with no patch to apply at all [7]. Discovery there produces decommissioning tickets and compensating controls, not remediation work.
Two notes on provenance. The material circulated in UK and US editions of the same Arctic Wolf post [14], so this is one vendor's telemetry appearing twice, not two datasets. And the DBIR figure is relayed by that vendor rather than read from Verizon here [1]. Arctic Wolf also asserts that closing the visibility gap costs less than a manual asset audit or an annual red team [9], a claim it makes as the supplier of the continuous alternative and without publishing a figure on either side.
The acronym sorting in the market (ASM, EASM, CAASM, exposure management) does not change any of the above. Neither does the model itself, which is inventory, then find exposures, then verify remediation [11]. CIS Controls 1 and 2 have asked for inventory of enterprise assets and inventory of software assets for years, and are the two oldest controls in the set [10]. What the DBIR delta changes is the order of operations, because an unpatched VPN appliance is an attack vector whether or not it appears in the console [16].
Practically, this reframes what a patch compliance report means. A 98% figure computed over the enrolled estate says nothing about the unenrolled part, and the useful question to put to whoever owns the number is how the denominator was built and what reconciles against it. Diffing the identity provider, EDR, and CMDB lists against each other is the cheapest version of that work, and the resulting mismatches are the queue.
