CVE-2021-44228 Log4Shell was publicly disclosed on the 9th of December 2021. Within two hours, active exploitation in the wild had been confirmed.
The patch was available. The advisory had been issued. But the vast majority of enterprise environments exposed to the vulnerability would not have it deployed for days in many cases, weeks. The attack surface remained open not because organisations lacked the patch, but because their governance processes were designed for maintenance cycles rather than emergency response.
Log4Shell was not a unique event. It was a demonstration of the new normal.
For most of the history of enterprise vulnerability management, the working assumption was that organisations had days sometimes weeks between the public disclosure of a vulnerability and its active exploitation in production attacks.
This assumption is no longer valid.
Research from multiple threat intelligence sources consistently shows that the median time from CVE publication to active exploitation has fallen from weeks to hours. Critical vulnerabilities affecting widely-deployed enterprise software the kind that affect your environment are targeted within hours of disclosure by threat actors who monitor CVE feeds, reverse-engineer patches to identify the underlying vulnerability, and deploy exploits against exposed targets.
For a CISO whose organisation operates a weekly patch approval committee, this shift is not merely inconvenient. It is a systematic security failure. The committee meets Tuesday morning. The critical CVE is published Monday afternoon. The organisation is exposed throughout Wednesday, Thursday, Friday, Saturday, Sunday, and into the following Monday a nine-day window during which every organisation running the affected software is a viable target.
Those nine days represent a structural gap between security intent and security reality that no amount of other security investment can close.
Complicating the patch prioritisation challenge is the almost universal reliance on CVSS (Common Vulnerability Scoring System) scores as the primary triage mechanism.
CVSS scores are a useful starting point. They are not a sufficient basis for enterprise patch prioritisation. Here is why.
CVSS scores measure theoretical severity: the maximum potential impact if the vulnerability were exploited in the worst-case configuration. They do not measure:
The result is that security teams managing large enterprise estates receive between 150 and 300 'critical' CVE alerts per week all labelled with the same severity designation and must make prioritisation decisions without the real-time threat intelligence that would allow them to distinguish 'critical and actively being exploited against organisations like yours' from 'critical in theory, no active exploitation observed.'
This is the problem that intelligence-driven patch prioritisation solves.
Intelligence-driven patch management integrates three data streams that CVSS scoring alone cannot provide:
Real-time exploitation intelligence from threat intelligence feeds indicating whether a CVE is being actively exploited, by which threat actor categories, against which sectors and software configurations, and at what escalating velocity.
Estate-specific relevance assessment crossing the CVE against your actual application inventory (via ALICE integration) to confirm which devices in your environment are genuinely vulnerable versus which are running different versions or configurations that are not affected.
Business context weighting that adjusts prioritisation based on the criticality of affected systems: a vulnerability affecting a core financial processing application carries a different response priority than the same vulnerability in an infrequently used reporting tool.
The output of this combined analysis is a dynamic, continuously updated priority queue that replaces hundreds of identically-labelled 'critical' alerts with a ranked, evidence-based action list that security operations teams can act on immediately.
For the CISO who needs to explain patch prioritisation decisions to the board, this approach also produces the audit trail and risk justification that defensible security governance requires.
Beyond the zero-day response challenge lies a deeper, structural vulnerability that affects nearly every enterprise estate: end-of-life software.
EOL software is the category of applications that have passed the vendor's support lifecycle and no longer receive security patches. Every day these applications remain operational, their vulnerability exposure grows. Known CVEs accumulate without remediation. Threat actors actively target EOL software precisely because they know no patch is coming.
In Camwood's estate assessments, EOL software consistently represents between 10% and 25% of discovered applications. In post-acquisition estates, the proportion is often higher. The majority of these applications have not been formally decommissioned they simply exist, unknown and unmanaged, in the application estate.
Beyond the direct security exposure, EOL software creates two additional liabilities that are increasingly board-relevant.
Cyber insurance is the first. A 2024 analysis of enterprise cyber insurance policy conditions found that 73% of major insurers now include active patch management requirements and EOL software elimination conditions in their enterprise cyber policies. An organisation that suffers a breach attributable to an EOL application may find their insurer declining the claim on the grounds of inadequate vulnerability management.
Regulatory compliance is the second. The NIS2 Directive, in force across EU member states from October 2024, imposes active vulnerability management obligations on organisations in critical infrastructure sectors. GDPR enforcement actions from the ICO have consistently cited failure to address known vulnerabilities as an aggravating factor in breach penalty decisions. The ICO's enforcement actions for preventable breaches from known vulnerabilities have averaged between £1.5M and £4.2M in recent cases.
EOL software is not a background IT housekeeping issue. It is a material security, compliance, and insurance liability.
Camwood's managed patch management programme delivers the security posture that modern threat timelines require.
For a financial services client managing 5,000 endpoints, the programme reduced their critical vulnerability response time from 8–12 days to under four hours. The mechanism is straightforward: when the intelligence-driven prioritisation engine identifies a CVE as actively exploited and present in the estate, it automatically elevates the patch to emergency status, initiates a phased pilot deployment for rapid validation, and proceeds to full production rollout without waiting for the weekly approval committee.
For standard-priority vulnerabilities, existing change control processes remain intact. The emergency bypass applies only to the small subset of vulnerabilities that genuinely require it: those that combine high CVSS severity with confirmed active exploitation and estate-specific presence.
The result: 99.5% patch compliance rates across the managed estate, compared to the 87% compliance achieved under the previous calendar-based approach. Zero missed critical response windows in the twelve months following implementation.
For CISOs preparing board-level security reporting, patch management metrics have become a primary indicator of organisational security posture.
Boards, regulators, and cyber insurers are increasingly asking not just 'do you have a patch management policy?' but 'what is your mean time to patch critical vulnerabilities, and how does it compare to known exploitation timelines?'
An organisation that can answer 'under four hours for critical CVEs with confirmed active exploitation' is demonstrating a security posture aligned to actual threat timelines. An organisation that answers 'we patch monthly, with exceptions requiring change control approval' is demonstrating a gap that sophisticated questioners including NIS2 competent authorities and cyber insurers will recognise immediately.
For CISOs who need to close that gap without requiring a complete overhaul of IT governance processes: Camwood's managed patch service delivers sub-four-hour critical response within existing enterprise frameworks, alongside the compliance evidence and board-ready reporting that modern security governance requires.
The zero-day problem is not going away. The exploitation timelines will continue to compress. Security-first patch management intelligence-driven, risk-prioritised, and automated for genuine emergencies is no longer a best practice aspiration. It is the minimum viable security posture for any enterprise operating in a modern threat environment.
The following reflects requirements that are now standard or near-standard across major UK and international enterprise cyber insurance policies (2024–2025 conditions). Organisations that cannot evidence these requirements face potential claim rejection following a breach.
|
Requirement |
Industry Standard |
Camwood Managed Patch Evidence |
|
Documented patch management policy |
Required — current and board-approved |
✓ Policy documentation provided as part of engagement |
|
Critical patch SLA |
Typically ≤72 hours for CVSS 9.0+ |
✓ Sub-4-hour response for actively exploited CVEs |
|
Third-party application coverage |
Required — not Windows-only |
✓ Full third-party coverage included as standard |
|
EOL software inventory and remediation plan |
Required — active plan mandatory |
✓ ALICE identifies all EOL software; remediation roadmap provided |
|
Patch compliance rate |
Typically ≥95% required |
✓ 99.5% compliance rate, continuously evidenced |
|
Compliance reporting for audit |
Required — evidence trail for claims |
✓ Continuous dashboard with exportable audit reports |
|
Vulnerability scanning frequency |
Typically weekly minimum |
✓ Continuous scanning integrated with Defender for Endpoint |
|
Incident response integration |
Patch management linked to IR procedures |
✓ Integrated with IR playbooks as part of managed service |
Key Risk: 73% of major cyber insurers now include patch management SLA clauses that allow claim rejection if a breach is attributable to an unpatched known vulnerability. Without documented SLA evidence, a preventable breach may not be covered.
The NIS2 Directive imposes active vulnerability management obligations on entities in critical sectors. The following summarises the key patch management requirements:
|
NIS2 Obligation |
Requirement |
Status Without Managed Patching |
|
Vulnerability handling policies |
Documented processes for identifying, assessing, and addressing vulnerabilities |
Manual processes may not meet documentation standard |
|
Incident reporting |
Security incidents reported to competent authority within 24 hours (initial) / 72 hours (detailed) |
Slow patch response increases incident likelihood and severity |
|
Supply chain security |
Vulnerability management extending to third-party software |
Third-party patching gap creates direct NIS2 exposure |
|
Risk management measures |
Proactive risk assessment and mitigation, not reactive |
Calendar-based patching is inherently reactive |
|
Board accountability |
Management bodies personally liable for NIS2 compliance |
Board members face personal liability for inadequate patch governance |
This article is part of Camwood's enterprise IT transformation blog series: