Why Patching is Non-Negotiable
Unpatched software is the single most exploited attack vector in cybersecurity. When a vendor releases a security patch, they are publicly announcing that a vulnerability exists — and attackers immediately begin scanning for systems that haven't applied it. The window between patch release and exploitation is shrinking every year. In some cases, weaponized exploits appear within hours of a patch announcement.
As IT support staff, you may not own the patching process, but you need to understand it. You will field user complaints about reboots, troubleshoot post-patch issues, and occasionally need to make judgment calls about whether a system can wait for the next maintenance window.
The Vulnerability Window
The vulnerability window is the period between when a vulnerability becomes exploitable and when it is patched on your systems.
Timeline of a Typical Vulnerability
- Vulnerability discovered — A researcher, vendor, or attacker finds a flaw
- Vendor develops a fix — The vendor creates and tests a patch
- Patch released — The vendor publishes the update (e.g., Microsoft Patch Tuesday)
- Attackers reverse-engineer the patch — By comparing patched and unpatched code, attackers understand the vulnerability
- Exploit code published — Proof-of-concept or weaponized exploits appear
- Your organization tests the patch — Change management, lab testing, compatibility checks
- Patch deployed to production — The vulnerability is finally closed on your systems
The danger zone is between steps 3 and 7. Every day your systems remain unpatched after a fix is available, you are running known-vulnerable software that attackers can exploit using publicly available tools.
Zero-Day Vulnerabilities
A zero-day is a vulnerability that is exploited before the vendor releases a patch — the window starts before step 2. These are the most dangerous because there is no fix available. Mitigation relies on workarounds, detection, and network-level protections until a patch arrives.
It's safe to delay patching for a few months as long as you haven't heard of any active exploits targeting the vulnerability.
Patch Cycles and Schedules
Most organizations follow a structured patching schedule to balance security with stability.
Microsoft Patch Tuesday
Microsoft releases security updates on the second Tuesday of every month. This predictable schedule allows IT teams to plan testing and deployment. However, Microsoft also releases out-of-band emergency patches for critical vulnerabilities that cannot wait.
Typical Patch Workflow
- Patch Tuesday (Day 0) — Patches released. IT security reviews the bulletin for severity and relevance.
- Testing (Days 1-7) — Patches deployed to a lab environment or pilot group. Check for compatibility issues with business applications.
- Staged rollout (Days 7-14) — Deploy to non-critical systems first. Monitor for issues.
- Production deployment (Days 14-30) — Roll out to all remaining systems. Schedule reboots during maintenance windows.
- Verification (Days 30+) — Confirm patches were applied successfully. Investigate systems that failed to update.
CVSS Scores: Understanding Severity
The Common Vulnerability Scoring System (CVSS) rates vulnerabilities from 0.0 to 10.0:
| Score | Severity | Typical Response |
|---|---|---|
| 9.0-10.0 | Critical | Patch within 24-72 hours, may require emergency change |
| 7.0-8.9 | High | Patch within 1-2 weeks |
| 4.0-6.9 | Medium | Patch within standard cycle (30 days) |
| 0.1-3.9 | Low | Patch in next maintenance window |
These are guidelines, not laws. A medium-severity vulnerability in your internet-facing web server may warrant faster patching than a critical vulnerability in an isolated lab system.
Emergency Patches
Sometimes a vulnerability is so severe or actively exploited that it cannot wait for the normal patch cycle. Emergency patches (often called out-of-band patches) require a different approach.
It's Wednesday morning. Microsoft released an emergency out-of-band patch last night for a critical remote code execution vulnerability in Exchange Server. Your security team confirms that exploit code is already circulating online and your Exchange server is internet-facing. Your change management process normally requires 7 days of testing before production deployment. What do you recommend?
How would you respond? Choose the best option:
Patching Challenges in the Real World
Patching sounds straightforward, but real environments present complications:
Legacy Systems
Some systems run software that the vendor no longer supports (end-of-life). Windows Server 2012 R2, Java 8, or that custom line-of-business application that only works on a specific OS version. These systems receive no patches, yet they often run critical business processes.
Mitigation for unpatchable systems:
- Network isolation — Place them on a separate VLAN with restricted access
- Enhanced monitoring — Extra logging and alerting on these systems
- Compensating controls — Web application firewalls, intrusion prevention, strict firewall rules
- Migration planning — The only real fix is moving off unsupported software
Third-Party Software
Operating system patches get the most attention, but vulnerabilities in third-party software (Adobe, Java, Chrome, Zoom, etc.) are just as dangerous. Ensure your patch management covers all software, not just the OS.
Reboot Resistance
Users resist reboots, and critical servers have narrow maintenance windows. But a pending reboot means the patch isn't fully applied.
Handling reboot resistance:
- Communicate early and clearly — "Reboots are scheduled for Saturday 2 AM. Save your work by Friday evening."
- Enforce reboot deadlines — Patches pending reboot for more than 7 days should trigger forced reboots
- Stagger reboots — Don't reboot all servers simultaneously. Maintain redundancy during patching.
Key Takeaways
- Unpatched systems are the number one attack vector — Patch quickly, patch consistently
- The vulnerability window shrinks every year — Attackers reverse-engineer patches within days, sometimes hours
- CVSS scores guide priority, but context matters — An internet-facing system needs faster patching than an isolated one
- Emergency patches require emergency processes — Your change management must have a fast lane for critical vulnerabilities
- Patch everything, not just the OS — Third-party software is just as vulnerable
- Legacy systems need compensating controls — If you can't patch it, isolate and monitor it