Times Are Changing: Why Patch Management Alone Will Not Save You

Singel-post cover image

The shifting threat landscape

The vulnerability landscape has shifted in ways that most security programs have not caught up with. The volume of disclosed CVEs continues to grow year over year, the gap between public disclosure and active exploitation keeps shrinking, and ransomware operators, state-aligned actors, and opportunistic criminals are all racing to weaponize new findings before defenders can respond. For many organizations, the playbook still assumes a slower, calmer world, which one that no longer exists.

If the security strategy of your organization was designed for that older world, it is already behind.

The patch management problem

Traditional patch management is built around monthly cycles, scheduled change windows, and the assumption that defenders have weeks to act. The data shows that the assumption is wrong.

For example, research compiled by the Zero Day Clock project tracks how the median time from CVE disclosure to first observed exploit has shortened over a single decade:

  • 2018: 771 days (defenders had over two years).
  • 2021: 84 days (around 9× shortened in three years).
  • 2023: ~6 days, with approximately 40% of exploited flaws being zero-days and over 44% exploited within 24 hours of disclosure.
  • 2024: ~4 hours.
  • 2025: zero-day: most exploited vulnerabilities are now weaponised before they are publicly disclosed at all.

Palo Alto Networks Unit 42 research shows that roughly 80% of public exploits now appear before the official advisory (around 23 days earlier than the official advisory is published). The system that was built to warn defenders is no longer working.

Average patch deployment across organizations, and most certainly median as well, has improved significantly. It is still mostly measured in weeks. The implication is uncomfortable: organizations are exposed to the vast majority of any given vulnerability’s lifecycle, and monthly patch cycles have become more theatre and compliance exercise than control.

A modern patch management program needs three things, and most organizations are insufficient in at least one:

  • Inventory that can be trusted: An organization cannot patch what it does not know exists. Real visibility covering also shadow IT, OT, cloud workloads, third-party SaaS, and forgotten legacy systems is the foundation. Everything else is built on top of an unknown attack surface.
  • Risk-based prioritization: Not every CVSS 9.8 is critical to your environment, and some medium-severity findings on internet-facing assets are critical threats. The prioritization needs to be tied to real exploitability, real exposure, and real business impact based on complex knowledge of the infrastructure, not just vendor severity scores.
  • Speed: Critical fixes on internet-exposed assets must be measured in hours and days in the worst case, not weeks. Anything slower means losing the race against attackers.

But here is the uncomfortable part: even a perfect patch management program is not enough on its own.

The time now runs against the defender.

Two themes from current research are worth taking seriously.

  • Verification asymmetry between offence and defence An attacker testing an exploit gets a binary, instant response: it worked, or it did not. A defender evaluating an alert or an event gets noise, ambiguity, and weeks of uncertainty. AI accelerates whichever side has the cheaper feedback loop, and right now that side is the offence.

  • AI-driven discovery, exploit writing, and attack execution have begun to outpace any human defensive cycle Single AI agents have been demonstrated to produce dozens of working exploits for one flaw at trivial cost, and AI systems have already discovered previously unknown high-severity vulnerabilities in widely deployed software. We do not speak only about top-level models like Anthropic Mythos, but even standard and open-source models can be utilized. Our own research in offensive and defensive techniques was accelerated by 15x-20x compared to standard human level research.

The point is not that AI changes the rules in some abstract future. The point is that the gap between attacker capability and defender posture is widening every quarter. Static, calendar-based security strategies and companies employing them do not survive that.

Threat-intelligence reporting from major vendors describes what AI is doing to attacker behavior in the field, and the picture is consistent. For example, CrowdStrike’s 2026 Global Threat Report, published in February 2026 and covering 2025 data, is one of the most concrete data points currently available:

  • AI-enabled adversary operations rose 89% year-on-year in 2025.
  • The average initial access to first lateral movement fell to 29 minutes, a 65% acceleration over 2024 (when the same metric stood at 48 minutes). The fastest breakout observed by CrowdStrike was 27 seconds.
  • In at least one tracked intrusion, data exfiltration began within four minutes of initial access.
  • Adversaries are not only using AI but attacking it: malicious prompt injections were observed against generative-AI tools at more than 90 organizations.
  • Named state-aligned actors are now deploying LLM-enabled malware (the FANCY BEAR group has been associated with the LAMEHUG family, used to automate reconnaissance and document collection), criminal actors are using AI-generated scripts to accelerate credential dumping and forensic-evidence destruction; DPRK operators are using AI personas to scale insider-style infiltration of Western organizations. In Central Europe we see a slower breakout time, usually up to 4 hours, but we also see usage of foundational models in attackers’ operators in lateral movement, exploitation and automatization of attacks.

Practically, this means three things for defenders:

  • Detection-and-response windows are now sub-hour, not multi-day. Any monitoring or response process measured in days is no longer a control; it is a delay, most possibly waste of time. Sub-30-minute compromise and lateral movement times do not leave room for ticket queues.

  • Phishing and identity-based attacks are more convincing than they have ever been. AI-generated fakes, voice clones, and live deep-fake video have collapsed the historical gap between “obvious phishing” and “authentic communication.” Anti-phishing strategies based primarily on user vigilance are no longer viable on their own. Phishing-resistant MFA, help-desk verification protocols, and out-of-band confirmation for sensitive actions are now baseline controls, not advanced ones.

  • Organizations AI deployments are themselves part of your attack surface. Prompt-injection attacks, data leakage through unmanaged generative-AI use, and AI supply-chain risks all need real technical controls (not just policies) before broad rollout.

The takeaway is straightforward: AI does not change whether attackers will reach your environment. It changes how fast they reach it, how convincingly they impersonate trusted parties once inside, and how cheaply they can repeat the attempt against you and everyone else.

Cloud adoption and the loss of data control

Migration to cloud (it can be IaaS, PaaS, and especially SaaS) has diminished the perimeter most security programs were originally built to defend. The data that used to live on file shares now lives in someone else’s datacenter (cloud is nothing more than somebody else’s computer), processed by someone else’s infrastructure, accessed through someone else’s identity provider, and protected by controls a customer can configure but not own and not control. Customers need to trust that Cloud providers deliver on their security controls, which is the single most undervalued state.

This is not an argument against the cloud. The argument is narrower and more refined: moving data/infrastructure/operations to the cloud changes who controls data/infrastructure/operations, who can see it, and under whose laws it is governed. Most organizations underestimate all three of those changes.

The concept that has become relevant is shared responsibility between the consumer and the cloud provider. And shared responsibility is where most breaches actually happen. Cloud providers are responsible for the security of the cloud (the physical infrastructure, the hypervisors, the underlying network, the platform services). Customers remain responsible for security in the cloud: identity, configuration, data protection, access control, and the application logic on top. Most cloud-related breaches in recent years have not been failures of provider infrastructure. These have been failures of customer-side configuration and identity management against a provider whose own platform was not compromised.

One example is the 2024 Snowflake customer breach campaign, attributed by Mandiant to threat actor UNC5537 (overlapping with the ShinyHunters extortion group). Approximately 165 Snowflake customer organizations were targeted, with confirmed victims including Ticketmaster/Live Nation (over 560 million records), AT&T (call and text records of nearly all wireless customers), and Santander Bank (around 30 million customers across Chile, Spain, and Uruguay). The modus operandi was consistent across victims.

  • Snowflake’s own infrastructure was not compromised.
  • Customer credentials had been harvested by infostealer malware (Lumma, MetaStealer, Raccoon, RedLine, RisePro, Vidar). In some cases, the credentials were years old, with the oldest valid credentials dating to 2020.
  • Affected accounts had no multi-factor authentication.
  • Affected accounts never rotated their credentials, despite the original credentials being stolen, and being four or more years old in some cases.
  • Several initial infostealer infections occurred on contractor-owned, non-Snowflake-monitored devices used for personal activities.

The lesson is not that Snowflake is unsafe. The lesson is that in the cloud, your data is exactly as protected as the weakest authentication path that reaches it, and that path frequently runs through identities, devices, and contractor relationships your security team does not directly control. A platform that is compliant with every certification on the market still leaks data when a username and password are circulating on a Telegram channel.

With regard to cloud, there is one more relevant point: data residency is not data sovereignty. Storing data in a Frankfurt or Dublin datacenter owned by a US-headquartered provider does not place that data under European jurisdiction. The US Clarifying Lawful Overseas Use of Data (CLOUD) Act from 2018 requires US-based providers to provide data anywhere in the world upon valid US legal demand, regardless of where it is physically stored. The US authority’s jurisdiction follows provider control, not data location.

This creates a structural conflict with EU law that no contract can resolve:

  • GDPR Article 48 prohibits transfers of personal data to non-EU authorities outside an applicable international agreement.
  • The EU Data Act (Regulation (EU) 2023/2854), which entered into force in January 2024 and began being applied in September 2025, requires cloud providers operating in the EU under Chapter VII to implement technical, legal, and organizational measures preventing unlawful third-country government access to non-personal data, and to challenge access requests that conflict with EU law.
  • The EU-US Data Privacy Framework (DPF) adopted in July 2023 provides a legal basis for personal data transfers to certified US organizations but does not override CLOUD Act demands and rests on a US Executive Order (14086) that is revocable by a sitting US administration. Following changes to the US Privacy and Civil Liberties Oversight Board in early 2025, the framework’s long-term viability is openly questioned in the EU regulatory community.
  • The Court of Justice of the EU’s Schrems II judgment confirmed that contractual measures alone are insufficient where local law gives authorities surveillance access; technical supplementary measures, which consist of primarily customer-managed encryption with keys held outside the provider’s jurisdiction, are required to make GDPR-compliant transfers durable.

For industries which fall under one or more regulations like banking and financial services under DORA, critical infrastructure operators under NIS2, healthcare, public sector, defense, this concern is not an academic debate. The practical implication is that for sensitive workloads, whoever holds the encryption keys is the entity that legally controls the data. If that entity is a US-headquartered SaaS provider, the data is subject to US jurisdiction in addition to EU law, and the provider (not the customer) can control who can read it.

Challenges of detection in the cloud

Jurisdiction aside, the reality of multi-cloud and multi-SaaS environments is that data is harder to see, audit, and protect than it was on-prem.

According to IBM’s Cost of a Data Breach Report 2025:

  • Breaches involving data distributed across multiple environments (public cloud + private cloud + on-prem) cost an average of USD 5.05 million.
  • Cross-environment security incidents took 276 days to detect and contain, which is 59 days longer than breaches confined to on-premises systems.
  • Private cloud breaches averaged 247 days while public cloud breaches averaged 251 days. On-premises breaches were much faster to detect and contain, at a lower average cost.

Each new SaaS application adds another identity surface, another set of audit logs in another format, another set of security controls (if any), another administrative console with its own permissions model, another integration with its own API tokens, and another data flow that the organization SOC may or may not see. Multi-cloud and multi-SaaS programs that are not connected to deliberate visibility investment routinely end up with significant blind spots in identity, data flow, security controls and configuration.

Two infamous specific blind spots are worth mentioning explicitly:

  • Shadow SaaS and shadow AI Employees start to use SaaS tools and AI assistants much faster than IT can check them and integrate them into security flows. IBM’s data shows that shadow AI alone was a factor in 20% of breaches, exposing customer PII in 65% of those incidents versus 53% baseline. Most organizations do not know how many SaaS applications their employees are signed into, let alone what data has been uploaded to them.
  • Third-party / supply-chain Organizations data does not stop at their SaaS provider, but it flows to their sub-processors, their support contractors, and their integrations and so on. Each link in that chain is a potential breach path that does not appear in your own logs at all.

What would “control” of cloud data actually look like

Practical control over cloud data requires investments most organizations do not make:

  • Customer-managed encryption keys (CMEK / BYOK), held in jurisdiction-controlled hardware security modules (HSMs), so that even if the provider is legally compelled to produce the data, the data is unreadable without keys the provider does not hold.
  • Strong, phishing-resistant MFA on every cloud and SaaS identity, including service accounts and contractor access. Sad fact is that the single change would have prevented most of the Snowflake-like customer compromises.
  • Conditional access and trusted-location policies that prevent valid credentials from being reused outside expected geographies and devices.
  • Credential rotation is essential, especially for service-to-service authentication and contractor access. Long-lived static credentials are an unmanaged liability.
  • SaaS Security Posture Management (SSPM) and Cloud Security Posture Management (CSPM) to detect misconfiguration drift across the SaaS and IaaS estate.
  • Cloud and SaaS logs forwarded to a SIEM not controlled by the cloud vendor must be retained long enough to support DFIR activities.
  • Data classification before cloud migration (not after) because once sensitive data is in a SaaS workspace, controlling what happens to it is almost impossible.
  • A documented exit and portability strategy, supported by the EU Data Act’s switching provisions, so that “we can’t change provider” is not a constraint on security or compliance decisions.

The cloud is not (only) the threat. The threats are loss of visibility, the jurisdictional shift, the configuration sprawl, and the assumption that the provider’s compliance certifications equate to your data being safe. They are addressable, but only when the organization treats cloud-resident data as something it has delegated the operation of, not something it has outsourced the responsibility.

Defense in depth is no longer optional

If patching alone were sufficient, organizations with mature vulnerability programs would not be compromised. They are regularly, and at every size, sector and geography.

Attackers do not need an unpatched CVE to succeed. Incorrect architecture, phishing, credential reuse, misconfigurations, supply chain compromise, insider misuse, and zero-days all bypass patch windows entirely. A program built around “patch faster” expects the only door is the one you locked. The reality is that there are many doors, and several do not have locks at all. Unfortunately, most are big holes and can be used by any attacker.

There is also a structural reason a single layer cannot be relied on. Most modern intrusions need only one control to fail: one user approves a phishing prompt, one exposes admin interface, one exposes unsegmented network path, one weakens service account to begin a full compromise chain. And from our experience in incident response, controls fail far more often than most organizations acknowledge.

Picus Security’s Blue Report 2025, based on more than 160 million attack simulations executed against live customer environments between January and June 2025, found:

  • Average prevention effectiveness across organizations of just 62%, down from 69% in 2024. Even well-tuned, well-equipped environments do not approach 100%, and the trend is currently going down.
  • Only 14% of attacks generated an alert at all. That is six in seven malicious actions going unnoticed in real time, even though logging coverage is 54%.
  • Data exfiltration prevention is just 3%, which is troublesome when double-extortion ransomware has made exfiltration the central business model of modern attackers.
  • 46% of environments had at least one password hash successfully cracked during simulation.

Put differently: even in well-equipped organizations using reputable tooling, average prevention sits well below 70%, detection is below 20%, and exfiltration is barely prevented or detected at all. That is why there is a need for defense in depth. It’s not a doctrine, but a response to data and the security landscape.

When one layer fails (and it will sooner or later), the next layer must be in position to detect, slow down, or contain the attacker. In practice, this means:

  • Identity. Strong, phishing-resistant MFA, conditional access, least privilege, and disciplined control over privileged and service accounts. Identity is the new perimeter, so it needs to be secured that way.
  • Network. Segmentation that prevents flat-network lateral movement, egress filtering, and visibility into east–west traffic, not just north–south.
  • Endpoint. Modern EDR with behavioral detection and the telemetry needed for threat hunting, not signature matching alone. And especially not EDR, which is a recolored antivirus. Hardening, data leak protection and tools for forensics acquisition and incident response. Times when One agent could do all are inevitably lost.
  • Email and web. The most common initial access vectors deserve disproportionate investment. Phishing is the most common initial vector across all breaches analyzed, accounting for roughly 16% of cases at an average cost of approximately USD 4.8 million per breach.
  • Data. Encryption, classification, and data loss controls that actually map to business risk rather than checkbox compliance.
  • Backup and recovery. Offline, immutable, and regularly restored. Untested backups are hope, not control.
  • Detection and response. 24/7 monitoring, tuned use cases, and a real incident response capability: internal, outsourced, or hybrid.

Each layer is designed to assume the previous one will eventually fail. Given a 62% average prevention rate against simulated attacks, which is not a pessimistic assumption, it is the baseline (and even it is little bit optimistic).

No single vendor is your security strategy.

Every security technology has weaknesses. Every EDR has detections that it misses, every firewall has bypass techniques, every SIEM has correlation rules that fire too late or not at all, every email gateway has lures it lets through, every identity provider has an authentication flow an attacker can abuse. This is not a failure of any specific product, but it is a property of the category of tools. Software has bugs, signatures have gaps, behavioral models have blind spots, cloud services have outages, and vendors have bad release days .

The practical consequence is that over-concentration on a single vendor or platform is itself a significant risk, and one that most security architectures overlooked property. This blind spot is encouraged by many vendors for their financial profits. There are three failure modes worth naming explicitly:

  • Detection monoculture If your prevention, detection, and response (in some cases also operation) all run on the same engine and the same telemetry pipeline, an attacker who learns to evade that engine evades all layers at once. Diversity of detection logic (for example, network telemetry that does not depend on the endpoint agent, identity analytics that do not depend on the SIEM, immutable backups operated outside the primary administrative domain) is what gives you a second chance when the first chance fails. And it fails.
  • Operational monoculture A single defective update from a single vendor can take an entire estate offline simultaneously. The cause was not a cyberattack. It was a routine update from a single trusted vendor running at the kernel level on millions of endpoints simultaneously. The lesson is not that the vendor in question is uniquely fragile; almost any agent on a global scale carries comparable systemic risk. The lesson is that shared dependencies create shared failure modes, and a security architecture in which one supplier’s bad day is your entire estate’s bad day is not a defensible architecture.
  • Strategic monoculture Single-vendor “platform consolidation” is regularly sold as a way to reduce complexity, and there are real benefits when done well. But every consolidation is also a concentration of risk: of single-vendor outages, of single-vendor pricing leverage, of single-vendor compromise (an attacker who breaches the vendor breaches every customer), and increasingly of single-vendor regulatory exposure under frameworks such as EU DORA for financial services and NIS2 more broadly, both of which explicitly require organizations to identify and manage concentration risk in their ICT supply chain.

The correction is not “buy one of everything.” It is deliberate, designed redundancy at the layers that matter most: independent detection paths, backups that survive the compromise of the primary platform, identity controls that do not all flow through one IdP, and a tested operational ability to keep running (even partially) when one major supplier has a bad day. Also, where necessary also usage of double vendor strategy, especially in network and endpoint protection.

The endpoint is a stack, not a product

Endpoints (workstations, laptops, servers, and increasingly cloud workloads) are where most modern attacks land. They are where phishing payloads execute, where stolen credentials are used, where ransomware encrypts, and where attackers establish persistence. Treating “we have an EDR” as a finished endpoint strategy is a recurring failure pattern.

A defensible endpoint posture is itself layered. At a minimum, it should include:

  • Prevention - Modern next-generation antivirus / anti-malware with both signature and machine-learning models, including memory protection, exploit mitigations, and script-control engines. The point is to stop trivial cases cheaply, so the more expensive layers are not flooded.
  • Detection and response (EDR / XDR) and secondary prevention - Behavioral detection, process-tree visibility, and the telemetry needed for threat hunting and forensic reconstruction. Critically, EDR is a detection layer, not a prevention layer (Picus’s data showing only 14% of attacks generating alerts in real-world environments is a reminder that even well-deployed EDR does not see everything).
  • Application control - Allow-listing or strict execution policies for what can run, especially on servers and high-value endpoints. Living-off-the-land binary abuse and unsigned binary execution are categories that prevention models routinely miss, but application control can stop outright.
  • Attack-surface reduction and hardening - OS hardening (CIS / DISA-style baselines), Microsoft Defender ASR rules where applicable, exploit protection, controlled folder access, disabled legacy protocols (SMBv1, NTLMv1, unconstrained delegation), and disabled or restricted scripting hosts where not required.
  • Privilege control - No standing local administrator rights for users. Just-in-time elevation. Local Administrator Password Solution (Windows LAPS) for workstation and server local admin accounts. Tiered administration so that workstation compromise does not equal domain compromise.
  • Credential protection on the endpoint - Credential Guard / LSA protection, restrictions on cached credentials, defences against credential dumping (Mimikatz-like tooling), and phishing-resistant MFA bound to the device for privileged actions.
  • Vulnerability and patch management at the endpoint. Continuous discovery, prioritised patching of OS and third-party software (browsers, runtimes, productivity suites), and configuration gap detection, not just monthly Microsoft updates.
  • Data protection on the endpoint - Full-disk encryption with managed recovery keys, DLP where appropriate to the data classification, and removable-media controls.
  • Backup and recoverability of the endpoint role itself. Documented re-imaging procedures, tested restoration of critical workstations and servers, and the operational ability to take a contaminated endpoint offline and replace it without losing the user’s work. This is important during ransomware response.
  • Logging and forwarding - Endpoint telemetry forwarded to a SIEM or data lake that the endpoint vendor does not control, with retention long enough to support DFIR (typically 12 months minimum, often longer for regulated industries). This is the layer that lets you reconstruct what happened when the EDR itself was bypassed, disabled, or offline.

None of these layers is sufficient on its own. The same logic that applies to the security architecture as a whole applies to the endpoint specifically. Single-product endpoint security is a single point of failure. The depth of the endpoint stack is what determines whether a compromise of any one layer becomes a compromise of the host.

Incidents will happen.What you build before they do is what matters

Incidents are not a question of if, but when. Every organization with anything worth taking will eventually be targeted. Mature security programs are not built on the fantasy of perfect prevention; they are built on the question of what happens when something gets through. The implication is that effective incident response is no longer treated as a separate discipline that activates once an alert fires. It is a property of the whole risk management program, with three of the six functions- Govern, Identify, Protect - serving as permanent preparation activities that exist long before any incident begins. In concrete terms, that preparation work includes:

  • Govern A documented incident response policy and plan, with clear definitions of what counts as an event versus an incident, named decision authorities, and pre-agreed thresholds for invoking external help, contacting regulators, or taking systems offline. Procedures must be tested or exercised periodically - not merely written and filed.
  • Identify Asset inventory, dependency mapping, and a realistic understanding of what data you hold and where. You cannot scope an incident at 02:00 if you do not know what assets exist, who owns them, and what they connect to.
  • Protect Hardening, training, segmentation, and technical safeguards that reduce both the likelihood and the radius of incidents. Backups belong in this layer, and they are useful only to the extent they have actually been restored from, end-to-end, under realistic conditions.

When an incident does occur, the Detect → Respond → Recover phases are where preparation either pays off or breaks down. The recurring failure mode is not the absence of tooling. It is the absence of a practiced procedure.

Practical readiness means investing in things that cannot be acquired during a breach:

  • A tested incident response plan - Tabletop exercises, purple-team drills, and full-scope simulations turn a written plan into something the team has actually executed. Without that, the plan is paper.
  • Pre-arranged DFIR and legal retainers - The first hours of a confirmed breach should not be spent on procurement, legal review of NDAs, or onboarding an unknown forensics provider. Have signed agreements, established communication channels, and a known point of contact long before you need them.
  • Logging and telemetry that support reconstruction - EDR, network flow, identity logs, and cloud audit trails stored long enough to answer, “what did the attacker actually do?” and not just “did they trigger an alert?” Without forensic-quality logs, the response team is reconstructing the attack from hearsay. Given that only 14% of simulated attacks generated alerts at all, this is not a hypothetical concern.
  • Recovery procedures that have been rehearsed - Restoring a critical system from backup for the first time during an active ransomware event is not a recovery plan; it is a wager. Restoration drills against realistic RTO/RPO targets belong in the calendar, not the wish list.
  • Communication playbooks - Pre-drafted templates for customers, regulators, employees, and the press, with clear ownership for each. Under EU NIS2 and GDPR, regulatory notification clocks start running from awareness, not from when communications are ready.

The cost of doing nothing

Organizations that ignore this shift are not standing still. They are falling behind every day.

The non-financial damage is harder to quantify but consistently worse: extended operational downtime, regulatory action under GDPR and NIS2, customer churn, contractual penalties, executive turnover, and in some cases, business-ending events. None of that is hypothetical. It happens every week to organizations that believed they had more time than they did.

Organizations do not have more time.

The work starts now (and ideally some organizations have already started) by reassessing security posture honestly against the relevant threat landscape, build defensive layers that assume each other will fail (because at 62% average prevention, they will), avoid betting entire organization on any one vendor or platform, build the endpoint as a stack rather than a product, treat AI deployments as production attack surface rather than productivity tools, take back actual control of cloud-resident data through identity hygiene, encryption, and visibility, and treat incident response as the permanent program - not as a binder pulled off a shelf during a crisis. Test response capability before you need it. Because the question was never whether it would be tested. The only question is whether the organization will be ready when the attacker tests it.