Skip to content

CONCEPT Cited by 1 source

Patch lag

Patch lag is the time between a security fix being released and the user actually running the fixed software. For server-side systems, the operator controls both release and install cadence — lag is measured in minutes. For client-side systems (especially mobile OS libraries that are not auto-updated silently), lag can be months — "it could often take months for people to update to the latest version of their software" (Meta 2026-01-27).

Why it matters

  • Fixed vulnerabilities remain exploitable across the installed base for the duration of the lag window.
  • Vendor "we patched it" and user "I'm safe" diverge — the CVE being closed doesn't mean the attack surface is gone in the wild.
  • App-layer mitigations become load-bearing when the patched component lives outside the app's control (concepts/os-library-vulnerability-ungovernable) — the app has to defend its users during the lag window.

What determines the lag

  • OS-level vendor patch cadence — Apple vs Android vs desktop OS release schedules.
  • Carrier / OEM gating (Android) — patch goes vendor → OEM → carrier → user; each hop adds delay.
  • User update behaviour — auto-update opt-in/opt-out, storage space, network cost, perceived disruption.
  • Device end-of-life — unsupported devices never receive the patch; lag is unbounded.

Architectural responses

  1. Shift defense to a layer you control. If the vulnerable component is an OS library, ship an app-layer validator that rejects inputs that would trigger the bug — the patterns/format-aware-malware-check-before-os-handoff pattern. WhatsApp's wamedia after Stagefright (2015) is the canonical instance.
  2. Defense-in-depth stacked to survive outdated lower layers. concepts/defense-in-depth with the explicit assumption that lower layers have a known-exploitable-in-the-wild bug for the next N months.
  3. Feature-gate risky capabilities behind up-to-date checks. If the user's OS is behind, disable features whose safety depends on the fix — trade UX for safety.
  4. Telemetry-driven prioritisation. If you know your fleet's OS-version distribution, you can size the patch-lag window and invest mitigations proportionally.

Server-side adjacency

Patch lag exists on the server side too but at different scales — see concepts/fleet-patching + patterns/rapid-fleet-patching-via-managed-service. The server-side mitigation is usually "patch faster" (managed services can be patched across a fleet in hours). The client-side mitigation is usually "defend around it" because patching-faster isn't an option the app owns.

Seen in

Last updated · 319 distilled / 1,201 read