Patch latency is the elapsed time between a security fix becoming publicly available and that fix actually running in your production environment. It is not the time between CVE publication and a Jira ticket, and it is not your scanner's "first seen" timestamp. It is fix-available to fix-deployed, measured per vulnerability instance, and it is the single most honest number you can put in front of leadership about how fast your organization actually remediates. Most teams that measure it for the first time discover their median is somewhere between 60 and 200 days, which is uncomfortable, because exploit code for a newly disclosed CVE now routinely appears in under a week.
Patch latency is not MTTR
Teams love to report mean time to remediate (MTTR), and MTTR is usually gamed without anyone intending to game it. If your scanner only detects a vulnerability 40 days after the fix shipped, and you patch 5 days later, your MTTR dashboard says 5 days. Your patch latency was 45. The clock for patch latency starts at the upstream fix release — the Fixed in 2.17.0 line in the advisory — not at detection.
The distinction matters because the attacker's clock also starts at fix release. Patch diffing is a standard workflow: when lodash or OpenSSL publishes a fix, people diff the patched release against the previous one and work backwards to the exploit. Google's Project Zero has documented n-day exploitation beginning within days of a patch, and CISA's KEV catalog exists precisely because known, fixed vulnerabilities keep getting exploited months later. Every day of patch latency is a day you are exploitable with a fix sitting on a shelf.
A workable set of fields to record per finding:
| Field | Example |
|---|---|
| Fix released | 2025-06-10 (from advisory) |
| First detected in your estate | 2025-06-14 |
| PR opened | 2025-07-02 |
| Merged | 2025-07-09 |
| Deployed to production | 2025-07-21 |
| Patch latency | 41 days |
Track the percentiles, not just the mean. A p50 of 12 days with a p90 of 210 days means you have a long tail of ancient, probably transitive, findings — and the tail is where breaches live.
Why patch latency balloons
The failure modes are boring and structural, which is why they persist:
- Transitive dependencies. The fix exists in
qs@6.11.0, but you don't depend onqs— a dependency of a dependency ofexpressdoes. Nobody owns the bump. Overrides or a parent-package update are needed, and that requires someone to actually understand the dependency graph. - Major version walls. The patched version is
4.0.0and you're on2.9.x. The fix is available; adopting it is a migration project. Latency quietly becomes six months. - Deploy cadence. A service that ships quarterly has a floor of roughly 45 days of patch latency on average, no matter how fast the PR merges. The patch sits merged and undeployed.
- Ticket routing. The scanner files 4,000 findings, dedup is poor, and the one that matters waits in a backlog behind 3,999 that don't. Prioritization by reachability and KEV status, rather than raw CVSS, is how you fix this — it's the core argument for reachability-aware SCA instead of manifest-only scanning.
- Orphaned services. The repo's last commit was 2022, the team was reorged, and CI is red. Latency is effectively infinite until someone adopts the service.
What good looks like
There is no universal benchmark, but reasonable targets by severity, based on what mature teams actually hit:
| Severity / condition | Target patch latency |
|---|---|
| KEV-listed or actively exploited | 48–72 hours |
| Critical, network-reachable | 7 days |
| High | 30 days |
| Medium/Low | 90 days, batched |
Log4Shell is the calibration event: the fix (log4j 2.17.x after two incomplete attempts) was out in December 2021, yet scans years later still found vulnerable instances in double-digit percentages of Java estates. If your process would have left Log4j unpatched for 90 days, the targets above are aspirational fiction — start by measuring, then move the p90. Our Log4Shell remediation cheat sheet is a decent template for the "actively exploited" tier.
How to actually cut it
Three interventions move the number more than anything else:
- Automated upgrade PRs. Renovate or Dependabot opening the PR the day a fix ships removes the "someone has to notice" step. Configure grouping (
groupNameinrenovate.json) so you're not reviewing 60 PRs a week, and enable automerge for patch-level bumps that pass tests. Teams with automerge on patch bumps routinely get p50 latency under 7 days for direct dependencies. - Deploy on merge. Continuous deployment is a security control. If merged code reaches production in hours, the deploy leg of patch latency drops to near zero. If you can't do CD everywhere, do it for your internet-facing services first.
- Kill the long tail. Schedule a recurring "oldest finding" rotation: one engineer, half a day a week, works strictly from the oldest open finding down. The tail is where the p90 lives, and no automation fixes an archived repo — a human has to decide to patch it or decommission it.
Safeguard's remediation planning does the graph work for the transitive cases — computing which direct-dependency bump or override actually clears a nested finding — which is the step where manual efforts usually stall.
Reporting it without lying to yourself
Report patch latency per environment (production only — staging doesn't count), per severity tier, as p50/p90, with the fix-release date as the start of the clock. Resist the urge to exclude "risk-accepted" findings from the denominator; track them as a separate accepted-risk count with an expiry date instead. And report the trend, not the snapshot. A p90 that went from 220 to 140 days in two quarters is a better story than any single number, and it's the story auditors and customers increasingly ask for in security questionnaires.
Frequently asked questions
How is patch latency different from mean time to remediate (MTTR)?
MTTR usually starts its clock when your scanner detects the issue; patch latency starts when the upstream fix was released. Patch latency therefore includes your detection lag, which is often the largest and least visible component. The two converge only if your detection is near-instant.
What is an acceptable patch latency?
For vulnerabilities on CISA's KEV list or with public exploits, 48 to 72 hours to production. For other criticals, 7 days is a common contractual and compliance target; 30 days for highs. Anything beyond 90 days for a fixable critical is hard to defend in an audit or a post-incident review.
Does patch latency apply to transitive dependencies?
Yes, and that's where most of the tail is. The clock starts when the patched version of the vulnerable package ships, even if adopting it requires a parent-package update or an override. Tooling that computes the minimal upgrade path — see how Safeguard compares to Snyk on this — is what makes transitive latency tractable.
Can I reduce patch latency without continuous deployment?
Partially. Automated upgrade PRs with automerge cut the merge leg to days, and an expedited out-of-band deploy path for KEV-listed issues covers the emergencies. But if your normal release train runs quarterly, your average latency has a structural floor that no ticketing process removes.