Skip to content
Armature Systems Resources
June 23, 2026
The Remediation Gap Is Structural, Not a Speed Problem
Table of Contents
The Remediation Gap Is Structural. "Patch Faster" Is Not the Answer.
We picked up an intrusion last Friday on a network we monitor. A vulnerability in a widely deployed security product had been publicly disclosed about two weeks prior. The patch was in the queue. The customer’s process was running exactly as it should. But the attacker didn’t wait for the patch cycle. By the time we were in the environment, they had firewall access and were moving toward the domain controller. Thirty days is no longer a safe patching window, and this incident made that very clear.
The numbers behind it
The gap between a CVE going public and active exploitation has collapsed. Mandiant’s M-Trends 2026 report, grounded in over 500,000 hours of incident response investigations, confirms that exploitation of internet-facing systems has been the leading initial attack vector for six consecutive years. For a growing share of vulnerabilities, mean time to exploit has gone negative, meaning exploitation is already underway before a patch exists at all.
Enterprise remediation hasn’t kept pace. Veracode’s 2025 State of Software Security report found the average time to fix a security flaw has risen to 252 days, up 47% since 2020. Verizon’s 2026 Data Breach Investigations Report found that 31% of breaches now start with vulnerability exploitation, the first time in the report’s history it has overtaken credential theft as the leading breach entry point. The exploit window has collapsed. The remediation timeline hasn’t.
Slow remediation isn't negligence
The 252-day average isn’t because teams aren’t trying. A kernel update conflicts with a customer driver. A dependency upgrade changes production behavior in ways that only surface under load. A patch pushed without adequate testing causes the outage it was meant to prevent. This is the regular work of operations teams doing their jobs responsibly.
So organizations build 30, 60, 90-day cycles with change boards, test environments, and rollback plans. That structure exists for good reasons. The problem is it was designed for a threat environment where the attacker’s timeline roughly matched the defender’s. That alignment is gone.
Research consistently finds that roughly 60% of breaches involve a vulnerability for which a patch already existed but hadn’t been applied. That’s a finding about structural difficulty, not negligence.
Patching faster isn't the answer either
The obvious response is to compress remediation timelines. Faster is better, but it doesn’t solve the actual problem.
For a growing share of actively exploited vulnerabilities, mean time to exploit has gone negative, meaning exploitation was already underway before any patch existed. No patch process, however fast, helps with that.
And even where patches exist, defenders face a significant backlog. CISA’s Known Exploited Vulnerabilities catalog tracks vulnerabilities actively being exploited in the wild, and organizations consistently take weeks to act on even the highest-priority entries, because modern enterprise applications carry hundreds of direct dependencies and thousands of transitive ones. You’re not patching one thing. You’re patching a web.
The remediation gap isn’t a speed problem. It’s a structural one. The question isn’t whether you can close it, you can’t fully, it’s whether you’re managing what happens inside it.
Where the disclosure model makes it worse
When a vendor announces a vulnerability publicly, defenders and attackers get that information at the same moment. In a world where AI is now accelerating exploit development, that simultaneous disclosure increasingly benefits whoever moves faster. Right now, that’s usually not the defender.
Coordinated vulnerability disclosure, where vendors notify affected customers privately before going public, gives defenders a meaningful window to act first. CISA’s guidance on coordinated vulnerability disclosure lays out the case for it. It’s not a new concept, but it isn’t standard practice either. It should be, and the organizations with direct vendor relationships are in the best position to push for it.
What actually helps
A few things matter more than raw patch velocity. Subscribing to CISA’s Known Exploited Vulnerabilities list alongside vendor advisories helps because KEV often flags active exploitation before internal processes catch up. Pre-negotiating emergency patch windows removes friction when a critical disclosure lands. And prioritizing by exploitability, using EPSS scores alongside CVSS ratings, means the team is focused on what’s actually being weaponized, not just what’s theoretically dangerous.
Deploying compensating controls as a first move buys time for the patch cycle to complete properly. And having active monitoring coverage in the gap means that if something does land in the window, it gets caught before the attacker can move laterally.
How we think about this at Armature
We built our MDR service around the reality that the remediation gap isn’t going away. We operate inside that window continuously, monitoring for the post-exploitation behavior that tends to follow fresh CVE disclosures, and responding when something looks wrong. When we find something, we work it through. We don’t hand off an alert and disappear.
What happened last Friday is a good example. The customer’s patch process was doing exactly what it was supposed to do. What made the difference was having active coverage in the window where the process couldn’t move fast enough.
If this is something your team is working through, we’re happy to talk about what coverage looks like for your environment.
The bottom line
The exploit window will keep shrinking as AI raises the floor for attacker capability. The organizations that handle this well aren’t the ones patching fastest. They’re the ones that built a real strategy around the gap they can’t close, and pushed their vendors toward disclosure practices that actually give defenders a fighting chance.