Qualys on June 3, 2026 announced peer-to-peer patch distribution for Qualys Cloud Agent for Windows 6.5, a feature that lets managed Windows endpoints share patch content locally to reduce repeated internet downloads and accelerate remediation across enterprise networks. The claim is not merely that patching can be made cheaper, though that matters. It is that the last mile of remediation has become the weak link in vulnerability management. The security industry has spent years getting better at deciding what matters; now the fight is over whether those decisions can turn into action before attackers finish their own automation loop.
The modern vulnerability program is full of dashboards that can tell a security team exactly what should ruin its week. CISA’s Known Exploited Vulnerabilities catalog, vendor telemetry, exploit intelligence, EPSS-style probability scoring, asset criticality, and platforms such as Qualys TruRisk have all pushed the industry away from treating every CVE as equal. That is progress.
But progress in prioritization has exposed a more embarrassing bottleneck. Once a team knows which vulnerability matters, it still has to move bytes to machines, schedule installs, survive change windows, and prove completion. The remediation process is often less like incident response and more like freight logistics.
That distinction matters because exploitation has become brutally compressed. Public exploit code, botnet scanning, ransomware playbooks, and AI-assisted targeting do not wait for a comfortable maintenance cycle. When a critical Windows, VPN, browser, or edge-device flaw becomes useful to attackers, the contest is no longer “did you identify the risk?” It is “did your environment actually change state?”
Qualys is positioning P2P distribution as an answer to that second problem. The company says endpoints can act as both consumers and distributors of patch artifacts, so that once content enters a local network, other managed systems can pull from peers rather than repeatedly downloading the same package from the cloud. That is not a new idea in Windows administration, but its arrival inside a cloud-agent patching workflow is notable because it attacks the unglamorous part of remediation: propagation.
Those numbers should not be read as a simple indictment of lazy IT departments. In many organizations, the exact opposite is true: endpoint, security, and infrastructure teams are working harder than ever. The problem is that manual and centralized processes do not scale gracefully when the number of endpoints, locations, patch sources, and urgent vulnerabilities all rise at once.
The classic vulnerability management model assumed that better visibility would lead to better outcomes. In practice, visibility often created a larger queue. Every new scanner, agent, and exposure-management platform sharpened the picture, but the same people and networks still had to perform the physical act of remediation.
That is why the phrase remediation gap has become more useful than the older language of patch compliance. Compliance asks whether an asset eventually reached the desired state. The remediation gap asks how long it was exploitable while everyone agreed it needed fixing.
Qualys uses the example of a roughly 5GB cumulative Windows update deployed to 1,000 endpoints. In a straightforward centralized model, that becomes about 5TB of external bandwidth demand. The math is not complicated, which is precisely why the operational pain is so predictable.
The cost is not only internet bandwidth. WAN links between sites, VPN concentrators, firewall inspection paths, proxies, and local office networks can all become part of the choke point. Remote offices and distributed users feel the delay first, but the risk belongs to the whole organization because patch state becomes uneven.
This is the strange irony of cloud-first endpoint management. Moving control planes to the cloud simplified administration, but it often moved content pressure to links that were never designed to behave like a software distribution backbone. The console may be global; the packets are still local.
In Qualys’ framing, only a small number of endpoints need to pull from the cloud before the rest of a network segment can reuse local copies. The company says that, in the 1,000-endpoint example, external bandwidth could fall from terabytes to tens of gigabytes, with local peer sharing handling the rest. That is the kind of architectural shift administrators notice immediately because it changes the conversation from “how do we throttle this?” to “how fast can we safely let it run?”
The performance test cited by Qualys makes the same point in miniature. In a controlled environment distributing an approximately 8GB feature update, the initial endpoint downloading from the CDN took 1 hour, 31 minutes, and 38 seconds. A peer endpoint retrieved the content in 8 minutes and 57 seconds. A multi-peer endpoint completed the download in 3 minutes and 33 seconds.
Vendor benchmarks deserve the usual caution. Lab conditions are not branch offices with old switches, congested Wi-Fi, split tunnels, and half-broken name resolution. Still, the principle is sound: when content can be fetched in parallel from multiple nearby sources, the limiting factor stops being the internet edge and starts being local topology.
What is different here is the packaging of the capability inside Qualys Cloud Agent for Windows 6.5 and its connection to risk-based remediation. Qualys is not pitching P2P as a generic Windows bandwidth trick. It is pitching it as the execution layer for the vulnerabilities its platform has already decided are important.
That matters because patching tools and vulnerability tools have often lived in adjacent but culturally different worlds. Security teams identify urgency; endpoint teams manage blast radius; network teams absorb the traffic; application owners plead for exceptions. The more those workflows are stitched together, the less time is lost in translation.
But there is also a risk in marketing the stitching as magic. P2P distribution accelerates content movement; it does not eliminate testing, compatibility assessment, reboot management, ring deployment, rollback planning, or business exceptions. A faster delivery network can make a mature patch process more effective. It can also make an immature one fail faster.
Qualys says its model verifies patch artifacts using cryptographic Content Identifiers, with endpoints accepting only content whose hash matches the verified identifier. Peer communication is described as staying inside the enterprise-controlled network boundary, such as the LAN, rather than connecting to arbitrary external peers. Participating systems are managed and authenticated through the Cloud Agent.
Those design choices are not optional niceties. They are the difference between a distribution system and a malware propagation nightmare. If the content identity is strong and the agent enforces it correctly, peers can be treated as untrusted carriers of trusted bytes rather than trusted authorities.
The remaining questions are the ones security teams will ask during deployment. How are peers discovered? How are segments defined? What logs prove where content came from? How does the system behave on hostile or semi-trusted networks? What happens when a laptop moves between office, home, and hotel Wi-Fi? The architecture can be sound and still require careful policy boundaries.
The simplicity of the toggle should not seduce anyone into a global first-day rollout. Endpoint storage varies. Network segmentation varies. Firewall policy varies. Some sites have abundant LAN capacity and constrained internet links; others have flat networks that security teams would rather not encourage to behave like sharing pools.
A sensible deployment starts with rings. Pilot a few controlled office networks, measure bandwidth reduction, watch endpoint CPU and disk behavior, verify logging, and confirm that the agent handles interrupted downloads gracefully. Then move to larger sites where the benefit is obvious and the network team is already nursing Patch Tuesday scars.
For remote workers, the calculus is different. A user on a home network may have only one corporate endpoint, making P2P irrelevant. A shared workspace, lab, call center, or campus network may benefit enormously. The point is not to turn on peer sharing everywhere; it is to stop treating every endpoint as if it lives alone on the far side of the internet.
That distinction is important because enterprises tend to ask new infrastructure features to solve every old problem. QGS is about control at the edge and predictable communication paths. P2P is about speed inside the network and reducing repeated content downloads. They can complement one another, but they are not substitutes.
In a well-designed environment, QGS can be the front door and P2P can be the hallway traffic. The gateway gets content and agent communication into the site in a controlled way. The endpoints then share approved content locally so the gateway and WAN do not become the next bottleneck.
The combined model is especially attractive for distributed enterprises with many medium-sized offices. These are the environments where a full software distribution point at every site may be overkill, but pure cloud download can be wasteful. A managed gateway plus peer distribution offers a middle path: centralized policy, decentralized content movement.
Peer distribution does not change the need for deployment rings. If anything, it makes rings more important because faster content movement reduces one source of delay while leaving decision-making intact. The best version of this model is not “everything patches instantly.” It is “the approved ring receives content quickly enough that network logistics stop dictating security policy.”
That distinction matters during emergency remediation. When a vulnerability is actively exploited, organizations often want to compress normal windows. The blocker is not always fear of the patch; sometimes it is the knowledge that pushing the patch at full speed will saturate links, break user experience, or overload infrastructure. P2P gives administrators another lever.
It also changes the psychology of patch deadlines. A seven-day SLA sounds reasonable until the first two days disappear to content staging and the next two disappear to remote-site failures. If distribution time collapses, more of the SLA can be spent on testing, exception handling, and actual installation success.
Defenders, by contrast, often automate identification but leave remediation trapped in procedural sludge. A system flags a KEV. A ticket opens. An owner is assigned. A patch job is scheduled. A network link groans. A subset fails. Another ticket opens. The attacker’s workflow is a loop; the defender’s workflow is a committee.
That is why Qualys’ claim lands even if one discounts the marketing gloss. The remediation gap is not only a people problem. It is a systems design problem. If the patching architecture scales linearly with endpoints while attack tooling scales automatically with opportunity, defenders are structurally behind.
P2P distribution is not the whole answer, but it is the right kind of answer: remove a bottleneck that humans should not be managing by hand. No administrator should have to choose between patching a critical vulnerability quickly and preserving the WAN because 1,000 machines need the same 5GB payload.
Centralized distribution creates obvious choke points. If the route to the CDN is slow, the proxy is overloaded, or a gateway is underprovisioned, the patch wave slows down everywhere behind that dependency. P2P creates multiple local paths for the same content, which can make large deployments less fragile.
This matters in messy real-world environments. Offices have partial outages. VPN pools behave differently by region. Some endpoints are online only briefly. A content mesh can opportunistically use the machines that are available instead of waiting for every system to make the same external trip.
There is a limit to this argument. Peer distribution cannot compensate for bad endpoint health, broken agents, insufficient disk, or install failures. It can, however, reduce the number of failures caused by the delivery mechanism itself. That is a meaningful distinction for administrators who spend too much of every patch cycle separating true install problems from content-transfer noise.
For vendors, the prize is control of the remediation loop. If a platform can identify risk, rank it in business terms, push the fix, and report closure, it becomes much harder to displace than a scanner or patch catalog alone. TruRisk Eliminate is Qualys’ entry in that race, and P2P distribution gives it a more credible operational story for Windows endpoints.
For customers, the prize is fewer seams. Every handoff between tools creates latency and ambiguity. The vulnerability platform says one thing, the endpoint tool says another, the network team sees traffic spikes, and leadership sees a red compliance number. Integrated remediation is attractive because it promises one chain of custody from finding to fix.
The danger is lock-in by convenience. Enterprises should welcome tighter remediation workflows while preserving the ability to validate outcomes independently. The agent that says it distributed a patch should not be the only evidence that the vulnerability is gone.
Patch Management Has Become a Distribution Problem
The modern vulnerability program is full of dashboards that can tell a security team exactly what should ruin its week. CISA’s Known Exploited Vulnerabilities catalog, vendor telemetry, exploit intelligence, EPSS-style probability scoring, asset criticality, and platforms such as Qualys TruRisk have all pushed the industry away from treating every CVE as equal. That is progress.But progress in prioritization has exposed a more embarrassing bottleneck. Once a team knows which vulnerability matters, it still has to move bytes to machines, schedule installs, survive change windows, and prove completion. The remediation process is often less like incident response and more like freight logistics.
That distinction matters because exploitation has become brutally compressed. Public exploit code, botnet scanning, ransomware playbooks, and AI-assisted targeting do not wait for a comfortable maintenance cycle. When a critical Windows, VPN, browser, or edge-device flaw becomes useful to attackers, the contest is no longer “did you identify the risk?” It is “did your environment actually change state?”
Qualys is positioning P2P distribution as an answer to that second problem. The company says endpoints can act as both consumers and distributors of patch artifacts, so that once content enters a local network, other managed systems can pull from peers rather than repeatedly downloading the same package from the cloud. That is not a new idea in Windows administration, but its arrival inside a cloud-agent patching workflow is notable because it attacks the unglamorous part of remediation: propagation.
The Remediation Gap Is Where Good Security Programs Still Bleed
The uncomfortable lesson in recent vulnerability data is that organizations can improve and still lose ground. Qualys cites analysis of more than one billion CISA KEV remediation records showing that teams are closing far more tickets than in previous years, while exposure windows remain stubbornly large. The reported figures are stark: 88 percent of weaponized vulnerabilities remediated slower than they were exploited, 63 percent of critical vulnerabilities still unpatched after seven days, and 6.5 times more tickets closed than a few years ago.Those numbers should not be read as a simple indictment of lazy IT departments. In many organizations, the exact opposite is true: endpoint, security, and infrastructure teams are working harder than ever. The problem is that manual and centralized processes do not scale gracefully when the number of endpoints, locations, patch sources, and urgent vulnerabilities all rise at once.
The classic vulnerability management model assumed that better visibility would lead to better outcomes. In practice, visibility often created a larger queue. Every new scanner, agent, and exposure-management platform sharpened the picture, but the same people and networks still had to perform the physical act of remediation.
That is why the phrase remediation gap has become more useful than the older language of patch compliance. Compliance asks whether an asset eventually reached the desired state. The remediation gap asks how long it was exploitable while everyone agreed it needed fixing.
Centralized Downloads Were Built for Order, Not Urgency
Traditional patch distribution is orderly in the way a single checkout lane is orderly. Each endpoint reaches out, requests content, downloads the same files, and reports back. At small scale, this is easy to understand and easy to control. At enterprise scale, especially during Patch Tuesday or emergency out-of-band response, it becomes a bandwidth multiplication machine.Qualys uses the example of a roughly 5GB cumulative Windows update deployed to 1,000 endpoints. In a straightforward centralized model, that becomes about 5TB of external bandwidth demand. The math is not complicated, which is precisely why the operational pain is so predictable.
The cost is not only internet bandwidth. WAN links between sites, VPN concentrators, firewall inspection paths, proxies, and local office networks can all become part of the choke point. Remote offices and distributed users feel the delay first, but the risk belongs to the whole organization because patch state becomes uneven.
This is the strange irony of cloud-first endpoint management. Moving control planes to the cloud simplified administration, but it often moved content pressure to links that were never designed to behave like a software distribution backbone. The console may be global; the packets are still local.
P2P Turns Endpoint Count From Liability Into Capacity
Peer-to-peer distribution changes the scaling curve. Instead of every endpoint being a separate consumer of the same external content, endpoints become local sources once they have the patch. The first systems seed the cache; later systems retrieve chunks from nearby peers; additional participants increase the number of available sources.In Qualys’ framing, only a small number of endpoints need to pull from the cloud before the rest of a network segment can reuse local copies. The company says that, in the 1,000-endpoint example, external bandwidth could fall from terabytes to tens of gigabytes, with local peer sharing handling the rest. That is the kind of architectural shift administrators notice immediately because it changes the conversation from “how do we throttle this?” to “how fast can we safely let it run?”
The performance test cited by Qualys makes the same point in miniature. In a controlled environment distributing an approximately 8GB feature update, the initial endpoint downloading from the CDN took 1 hour, 31 minutes, and 38 seconds. A peer endpoint retrieved the content in 8 minutes and 57 seconds. A multi-peer endpoint completed the download in 3 minutes and 33 seconds.
Vendor benchmarks deserve the usual caution. Lab conditions are not branch offices with old switches, congested Wi-Fi, split tunnels, and half-broken name resolution. Still, the principle is sound: when content can be fetched in parallel from multiple nearby sources, the limiting factor stops being the internet edge and starts being local topology.
Windows Admins Have Seen This Movie, but the Casting Matters
Microsoft has long had its own peer-assisted content story through Delivery Optimization, which can share Windows Update and Microsoft Store content across devices on local networks and, depending on configuration, broader peer groups. Configuration Manager, BranchCache, WSUS designs, and third-party endpoint tools have all tried to solve versions of the same problem. Nobody who has managed Windows fleets should be shocked by the idea that local content reuse beats repeated downloads.What is different here is the packaging of the capability inside Qualys Cloud Agent for Windows 6.5 and its connection to risk-based remediation. Qualys is not pitching P2P as a generic Windows bandwidth trick. It is pitching it as the execution layer for the vulnerabilities its platform has already decided are important.
That matters because patching tools and vulnerability tools have often lived in adjacent but culturally different worlds. Security teams identify urgency; endpoint teams manage blast radius; network teams absorb the traffic; application owners plead for exceptions. The more those workflows are stitched together, the less time is lost in translation.
But there is also a risk in marketing the stitching as magic. P2P distribution accelerates content movement; it does not eliminate testing, compatibility assessment, reboot management, ring deployment, rollback planning, or business exceptions. A faster delivery network can make a mature patch process more effective. It can also make an immature one fail faster.
The Security Model Is the Feature That Decides Whether Admins Trust It
Any system that lets endpoints fetch executable content from other endpoints will trigger healthy suspicion. Administrators have spent years being told to reduce lateral movement, distrust peer machines, segment networks, and prevent unmanaged content sharing. A patch-delivery mesh sounds efficient, but efficiency is not the same thing as trust.Qualys says its model verifies patch artifacts using cryptographic Content Identifiers, with endpoints accepting only content whose hash matches the verified identifier. Peer communication is described as staying inside the enterprise-controlled network boundary, such as the LAN, rather than connecting to arbitrary external peers. Participating systems are managed and authenticated through the Cloud Agent.
Those design choices are not optional niceties. They are the difference between a distribution system and a malware propagation nightmare. If the content identity is strong and the agent enforces it correctly, peers can be treated as untrusted carriers of trusted bytes rather than trusted authorities.
The remaining questions are the ones security teams will ask during deployment. How are peers discovered? How are segments defined? What logs prove where content came from? How does the system behave on hostile or semi-trusted networks? What happens when a laptop moves between office, home, and hotel Wi-Fi? The architecture can be sound and still require careful policy boundaries.
The Toggle Is Simple; the Rollout Is Not
Qualys emphasizes that administrators can enable P2P through the Cloud Agent Configuration Profile. The available controls include cache size from 10GB to 100GB, retention from 2 to 30 days, a transport port defaulting to 4001, and an admin port defaulting to 5001. This is the kind of practical detail that makes the feature feel deployable rather than conceptual.The simplicity of the toggle should not seduce anyone into a global first-day rollout. Endpoint storage varies. Network segmentation varies. Firewall policy varies. Some sites have abundant LAN capacity and constrained internet links; others have flat networks that security teams would rather not encourage to behave like sharing pools.
A sensible deployment starts with rings. Pilot a few controlled office networks, measure bandwidth reduction, watch endpoint CPU and disk behavior, verify logging, and confirm that the agent handles interrupted downloads gracefully. Then move to larger sites where the benefit is obvious and the network team is already nursing Patch Tuesday scars.
For remote workers, the calculus is different. A user on a home network may have only one corporate endpoint, making P2P irrelevant. A shared workspace, lab, call center, or campus network may benefit enormously. The point is not to turn on peer sharing everywhere; it is to stop treating every endpoint as if it lives alone on the far side of the internet.
QGS and P2P Solve Different Bottlenecks
Qualys also draws a line between Peer-to-Peer distribution and Qualys Gateway Service. QGS centralizes Cloud Agent communication through a gateway, with caching, TLS termination support for legacy operating systems, and simplified egress control. P2P focuses on distributing patch content locally once it has entered the environment.That distinction is important because enterprises tend to ask new infrastructure features to solve every old problem. QGS is about control at the edge and predictable communication paths. P2P is about speed inside the network and reducing repeated content downloads. They can complement one another, but they are not substitutes.
In a well-designed environment, QGS can be the front door and P2P can be the hallway traffic. The gateway gets content and agent communication into the site in a controlled way. The endpoints then share approved content locally so the gateway and WAN do not become the next bottleneck.
The combined model is especially attractive for distributed enterprises with many medium-sized offices. These are the environments where a full software distribution point at every site may be overkill, but pure cloud download can be wasteful. A managed gateway plus peer distribution offers a middle path: centralized policy, decentralized content movement.
Patch Tuesday Is the Test Lab Nobody Gets to Skip
Patch Tuesday remains the recurring stress test for Windows operations. Even organizations that have moved to rings, expedited updates, and cloud management still face a monthly reality: large packages, many endpoints, reboots, user disruption, and business pressure to prove the fleet is protected. The Windows ecosystem has improved, but the operational rhythm is still recognizable to anyone who has watched update compliance crawl upward across a dashboard.Peer distribution does not change the need for deployment rings. If anything, it makes rings more important because faster content movement reduces one source of delay while leaving decision-making intact. The best version of this model is not “everything patches instantly.” It is “the approved ring receives content quickly enough that network logistics stop dictating security policy.”
That distinction matters during emergency remediation. When a vulnerability is actively exploited, organizations often want to compress normal windows. The blocker is not always fear of the patch; sometimes it is the knowledge that pushing the patch at full speed will saturate links, break user experience, or overload infrastructure. P2P gives administrators another lever.
It also changes the psychology of patch deadlines. A seven-day SLA sounds reasonable until the first two days disappear to content staging and the next two disappear to remote-site failures. If distribution time collapses, more of the SLA can be spent on testing, exception handling, and actual installation success.
Attackers Automate the Boring Parts, So Defenders Must Too
The security industry likes to talk about attacker innovation, but much of the attacker advantage comes from automating boring work. Scan the internet. Match versions. Try exploit paths. Reuse infrastructure. Chain known weaknesses. Move on if the target is not ready. None of that requires cinematic sophistication.Defenders, by contrast, often automate identification but leave remediation trapped in procedural sludge. A system flags a KEV. A ticket opens. An owner is assigned. A patch job is scheduled. A network link groans. A subset fails. Another ticket opens. The attacker’s workflow is a loop; the defender’s workflow is a committee.
That is why Qualys’ claim lands even if one discounts the marketing gloss. The remediation gap is not only a people problem. It is a systems design problem. If the patching architecture scales linearly with endpoints while attack tooling scales automatically with opportunity, defenders are structurally behind.
P2P distribution is not the whole answer, but it is the right kind of answer: remove a bottleneck that humans should not be managing by hand. No administrator should have to choose between patching a critical vulnerability quickly and preserving the WAN because 1,000 machines need the same 5GB payload.
The Hidden Win Is Resilience, Not Just Speed
Bandwidth savings are easy to sell because they fit neatly into charts. Speed improvements are easy to sell because they map directly to remediation SLAs. The subtler benefit of peer distribution is resilience.Centralized distribution creates obvious choke points. If the route to the CDN is slow, the proxy is overloaded, or a gateway is underprovisioned, the patch wave slows down everywhere behind that dependency. P2P creates multiple local paths for the same content, which can make large deployments less fragile.
This matters in messy real-world environments. Offices have partial outages. VPN pools behave differently by region. Some endpoints are online only briefly. A content mesh can opportunistically use the machines that are available instead of waiting for every system to make the same external trip.
There is a limit to this argument. Peer distribution cannot compensate for bad endpoint health, broken agents, insufficient disk, or install failures. It can, however, reduce the number of failures caused by the delivery mechanism itself. That is a meaningful distinction for administrators who spend too much of every patch cycle separating true install problems from content-transfer noise.
Vendor Platforms Are Racing to Own the Remediation Loop
Qualys is not alone in trying to collapse the space between exposure management and remediation. The broader security market is moving away from “here is a list of problems” and toward “here is the prioritized action, the deployment mechanism, and the proof it worked.” That shift is driven partly by customer fatigue and partly by attacker speed.For vendors, the prize is control of the remediation loop. If a platform can identify risk, rank it in business terms, push the fix, and report closure, it becomes much harder to displace than a scanner or patch catalog alone. TruRisk Eliminate is Qualys’ entry in that race, and P2P distribution gives it a more credible operational story for Windows endpoints.
For customers, the prize is fewer seams. Every handoff between tools creates latency and ambiguity. The vulnerability platform says one thing, the endpoint tool says another, the network team sees traffic spikes, and leadership sees a red compliance number. Integrated remediation is attractive because it promises one chain of custody from finding to fix.
The danger is lock-in by convenience. Enterprises should welcome tighter remediation workflows while preserving the ability to validate outcomes independently. The agent that says it distributed a patch should not be the only evidence that the vulnerability is gone.
Windows Fleets Need Faster Pipes and Better Judgment
The concrete news is that Qualys Cloud Agent for Windows 6.5 now includes P2P patch distribution. The larger story is that Windows endpoint security is entering a phase where remediation architecture matters as much as detection accuracy. The organizations that benefit most will be the ones that treat this as a way to improve disciplined patch operations, not as permission to skip discipline.- Qualys’ new P2P capability lets managed Windows endpoints share patch content locally after an initial download, reducing repeated external transfers.
- The feature is aimed at the remediation gap between knowing a vulnerability is dangerous and actually getting the fix installed across the fleet.
- Qualys claims up to 92 percent faster download times, up to 25 times faster delivery in multi-peer scenarios, and 99 percent-plus WAN bandwidth savings in large deployments.
- Administrators can control cache size, retention, and ports through Cloud Agent configuration profiles rather than deploying new distribution servers.
- P2P and Qualys Gateway Service are best understood as complementary tools, with QGS controlling agent communication and P2P accelerating local patch propagation.
- The security value depends on careful rollout, cryptographic content verification, network boundaries, and independent validation that endpoints are actually remediated.
References
- Primary source: Qualys
Published: 2026-06-03T07:22:07.682845
P2P Patch Distribution: Faster Remediation at Scale | Qualys
Qualys peer-to-peer (P2P) patch distribution delivers patches up to 25× faster and cuts external bandwidth use ~99%, speeding remediation at scale.
blog.qualys.com
- Related coverage: darkreading.com
- Related coverage: bleepingcomputer.com
Analysis of one billion CISA KEV remediation records exposes limits of human-scale security
Analysis of 1 billion CISA KEV remediation records reveal a breaking point for human-scale security. Qualys shows most critical flaws are exploited before defenders can patch them.www.bleepingcomputer.com
