A critical CVE drops. The security team flags it. IT pushes the patch that afternoon.

By the next morning, the deployment dashboard is green. Ticket closed.

Nobody checks whether the old, vulnerable binary is still sitting on the twenty laptops that were asleep during the push.

Or on the third-party app nobody remembered to add to the patching list.

“Patched” and “fixed” get used as if they were the same word. They aren’t.

Deployment is fast. Remediation isn’t.

The industry has gotten genuinely better at pushing patches quickly. That part of the story is real progress, not marketing.

But “pushed” measures the wrong end of the process. The number that matters is how long the vulnerable version keeps running somewhere in the fleet.

Those two numbers describe the same fleet. One is the headline. The other is the fine print nobody reports up the chain.

Where the gap actually lives

Complex applications nobody wants to touch

Java runtimes, .NET frameworks, Citrix Workspace App — anything with compatibility risk gets deprioritized. Testing takes weeks. Rollback plans take longer. The CVE sits open the whole time.

Third-party software nobody owns

Most patching programs were built around the operating system and a short list of core applications. Everything installed outside that list is often nobody’s job.

The handoff between security and IT ops

Security prioritizes. IT ops deploys. Between those two steps sits a spreadsheet, a ticket queue, or a chat thread — and that’s where vulnerabilities go quiet without anyone deciding to leave them open.

Speed without confirmation is just a faster way to lose track of where the risk went.

Third-party apps are the biggest blind spot

This isn’t a hunch. Adaptiva’s 2026 survey of more than 200 IT and security professionals found that 74% had experienced a vulnerability in a third-party application in the past year.

Only 49% currently include third-party applications in their patching process at all.

Put those together and the picture is uncomfortable: the software most likely to carry an unpatched vulnerability is the software least likely to be covered by the process built to catch it.

Coordinating prioritization and remediation across that many moving parts is now the single issue cited most often by security teams — 74% name it as their biggest challenge.

Automation closes the gap — where it’s actually used

Qualys customers deployed roughly 150 million patches over the past 12 months. About 40 million of those — a little more than a quarter — went out through autonomous, policy-driven deployment rather than a person clicking approve.

Browser patching shows what that looks like at scale: over 8 million Chrome patches went out through automated channels in the same period, closer to real time than any manual cycle could manage.

But automation maturity is still shallow industry-wide. Only 8% of organizations report fully autonomous patch execution today. Just over 60% still rely on manual steps somewhere in the lifecycle.

How INGITE helps

If a breach happened tonight, could you prove the patch actually landed?

Not that the deployment job ran. That the vulnerable version is gone, on every machine, including the ones that were offline during the push.

• Do you track remediation confirmation separately from deployment confirmation?
• Are third-party applications inside your patching process, or outside it?
• Can you produce, right now, a list of machines still running a version with a known CVE?

If the honest answer to any of those is “not really,” the problem isn’t how fast patches go out. It’s whether anyone can see where they didn’t land.