The 60-Day Gap That Hackers Love
Sixty percent of breaches involve vulnerabilities for which a patch was available but not applied. Ponemon Institute research documents the gap between patch availability and patch deployment. The average organization takes 60-150 days to apply patches. Attackers exploit vulnerabilities within 7-14 days.
Math is brutal. For 46-136 days, patched vulnerabilities remain exposed in most environments. Each day within that window carries risk. The organization knows a fix exists. The vulnerability persists anyway.
Why Patches Don’t Get Applied
The patch delay stems from legitimate operational concerns. Patches break things. Faulty patches cause 15% of all unplanned application downtime. The history of patch-induced outages conditions organizations toward caution.
| Delay Factor | Root Cause | Mitigation Complexity |
|---|---|---|
| Testing requirements | Fear of breakage | Medium, requires test environment |
| Change approval | Governance overhead | Medium, requires streamlined CAB |
| Downtime windows | Business availability needs | High, requires off-hours work |
| Resource constraints | Not enough hands | High, requires staffing or automation |
| Compatibility uncertainty | Application dependencies | Very high, requires vendor coordination |
Each factor extends the window. Combined, they create the 60-150 day average that attackers rely upon.
The Cadence Tradeoff Matrix
Patch cadence involves explicit tradeoffs. Faster patching reduces exposure. Faster patching increases breakage risk. No perfect answer exists.
| Cadence | Security Exposure | Operational Risk | Resource Demand |
|---|---|---|---|
| Weekly | Minimal | Elevated | Very high |
| Bi-weekly | Low | Moderate | High |
| Monthly | Moderate | Lower | Moderate |
| Quarterly | High | Lowest | Low |
Industry standard for non-critical systems has settled around monthly patching with weekly capability for critical vulnerabilities. The compromise accepts some exposure in exchange for manageable operational burden.
Critical vulnerabilities demand faster response. CISA’s Known Exploited Vulnerabilities catalog creates emergency patching obligations for government contractors and increasingly sets expectations industry-wide.
The Test Environment Myth
“Patches should be tested before deployment” sounds prudent. The advice assumes organizations have representative test environments. Most don’t.
Test environments typically reflect production configuration at deployment time. Production drifts. Applications update. Configurations change. The test environment becomes progressively less representative.
Patching in a non-representative test environment provides false confidence. The patch installs fine in test. Production breaks anyway because production contains elements test doesn’t.
Organizations with legitimate test capability share characteristics:
Automated environment refresh. Test environments regularly synchronize with production configuration.
Representative workloads. Test simulates actual usage patterns, not just installation success.
Dependency parity. Third-party integrations exist in test, not just core systems.
Data equivalence. Test data volumes and patterns match production within orders of magnitude.
Without these characteristics, testing delays patching without reducing risk.
Rollback Failures: When the Safety Net Tears
Rollback capability enables aggressive patching. If the patch breaks something, roll back. Resume operations while troubleshooting. The theory is sound. The practice is fragile.
Rollback failures occur when:
Database schema changes. The patch modified database structure. Rolling back the application leaves data in the new schema. Incompatibility results.
Configuration propagation. The patch triggered configuration changes that propagated to dependent systems. Rolling back the patch doesn’t roll back propagation.
Checkpoint age. The snapshot used for rollback is stale. Restoring it loses recent changes.
Interdependency complications. System A patched. System B depends on System A. System B adjusted to new behavior. Rolling back System A breaks System B.
Rollback planning must address each failure mode. Not all patches support clean rollback. Identifying which patches require extra caution before deployment prevents crisis discovery.
Automation: Promise and Peril
Automated patching solves resource constraints. Patches deploy without human intervention. The approach scales. It also removes human judgment from a decision that sometimes requires it.
Automated patching failures follow patterns:
Timing conflicts. Auto-patch deploys during peak usage. Performance degrades. Users notice before IT does.
Cascade effects. Multiple systems patch simultaneously. Interdependencies create complex failure states.
Incomplete completion. Patch installation requires reboot. Reboot doesn’t occur. System runs in partially patched state.
Exception blindness. Automation can’t assess whether this system requires special handling. It treats all systems identically.
Effective automation includes exception frameworks. Systems requiring manual handling get flagged rather than auto-patched. Critical systems get deferred to maintenance windows. The automation handles bulk work while preserving human judgment for edge cases.
The Third-Party Patch Problem
Microsoft patches arrive predictably. Patch Tuesday. Monthly cadence. Clear documentation. Third-party applications follow no such discipline.
Java updates arrive unpredictably. Adobe products patch on their own schedule. Industry-specific applications may patch quarterly or less. Each vendor creates its own patching burden.
Third-party patch management requires:
Inventory accuracy. You can’t patch what you don’t know exists. Shadow IT complicates third-party patching.
Vulnerability monitoring. Subscribe to security notices for each vendor. Track CVEs affecting your software.
Prioritization framework. Not all third-party patches are equal. Business-critical applications deserve faster attention.
Vendor coordination. Some patches require vendor involvement. Knowing which vendors will help versus which will obstruct matters.
Measuring Patch Management Effectiveness
Three metrics reveal patch management health:
Patch currency. Percentage of systems fully patched at any moment. Target varies by risk tolerance. 95% is aggressive. 85% is common. Below 80% indicates serious gaps.
Time to patch. Average days between patch release and deployment. Segment by criticality. Critical vulnerabilities should measure in days. Routine patches can measure in weeks.
Patch failure rate. Percentage of patches causing operational impact. Track over time. Increasing rates indicate declining patch quality or environmental complexity.
The Downtime Calculation Nobody Does
Patching requires maintenance windows. Maintenance windows mean downtime. Downtime has business cost. The calculation should influence cadence decisions.
| Patching Approach | Monthly Downtime | Annual Downtime | Exposure Window |
|---|---|---|---|
| Weekly windows | 4-8 hours | 48-96 hours | Minimal |
| Bi-weekly windows | 2-4 hours | 24-48 hours | Low |
| Monthly windows | 1-2 hours | 12-24 hours | Moderate |
| Quarterly windows | 0.5-1 hour | 6-12 hours | High |
The tradeoff: less frequent patching means less downtime but more exposure. More frequent patching means more downtime but less exposure. The optimal point depends on what breach impact costs versus what downtime costs.
MSP Patch Management Realities
MSPs manage patching across multiple clients. Economy of scale should improve effectiveness. Sometimes it does. Sometimes it creates new risks.
Risks of MSP patch management:
Standardization pressure. MSP wants consistent patching across clients. Your environment has unique requirements.
Lowest-common-denominator cadence. Patch timing accommodates the least flexible client, not the most security-conscious.
Tool-driven approach. MSP uses their preferred patching tool. Tool limitations become your limitations.
Visibility gaps. MSP monitors patch status. You see summary reports. Details hide in their systems.
Contract terms should address patch management explicitly. Define acceptable currency levels. Specify critical vulnerability response times. Require detailed reporting. Reserve audit rights.
The MSP that resists patch management specificity is telling you something about their capability.
Sources
- Patch gap and breach correlation: Ponemon Institute
- Patch-induced downtime percentage: IT operations incident analysis
- Time to exploit versus time to patch: Vulnerability lifecycle research