Patch management is the systematic process of keeping software and firmware current to address security vulnerabilities and software defects. CompTIA Network+ N10-009 tests patch management as a security control. Unpatched systems are a leading cause of successful attacks — patch management is one of the highest-return security investments.
Practice this topic
Effective patch management follows a structured process: (1) Inventory: know every system, its OS, applications, and current patch level. (2) Monitor: track vendor advisories, CVE feeds, and patch release notifications. (3) Evaluate: assess whether the patch applies and the risk of the vulnerability vs the risk of patching (patch compatibility, testing requirements). (4) Test: apply patches to non-production systems first to verify compatibility and functionality. (5) Deploy: apply patches during scheduled maintenance windows using change management processes. (6) Verify: confirm patches applied successfully and systems function correctly. (7) Report: document patch status for compliance.
Patch categories: Security patches (critical — address CVEs), Bug fixes (address non-security defects), Feature updates (add new functionality), Firmware updates (device-level security and stability). Security patches should be prioritized over feature updates.
Patch management tools: WSUS (Windows Server Update Services) — Microsoft's free tool for deploying Windows/Office patches within an organization. SCCM/Endpoint Configuration Manager — enterprise Microsoft patch and software management. Ansible/Puppet/Chef — cross-platform automation for patching diverse systems. Commercial: Ivanti, SolarWinds Patch Manager, Tanium.
Risk of not patching vs risk of patching: some patches introduce bugs or compatibility issues. Test patches in non-production environments. For critical zero-days actively exploited in the wild, the risk of not patching immediately typically outweighs testing overhead — apply emergency patches with expedited change management.
Rollback: always have a rollback plan before applying patches. System snapshots (VMs), configuration backups (network devices), and restore media (servers) allow recovery from a problematic patch.
Applying patches immediately to all systems is always the right approach
Patches can introduce compatibility issues or bugs. Test in non-production first, then deploy in waves (pilot group → broader deployment). For actively exploited critical vulnerabilities, urgency may override full testing, but rollback capability must still be ensured
These questions are representative of what you will see on Network+ exams. The correct answer and explanation are shown immediately below each question.
A critical security patch is released for a vulnerability actively exploited in the wild. The patch hasn't been tested in the lab environment. What is the best approach?
Explanation: For actively exploited critical vulnerabilities, a staged deployment balances urgency with risk. Apply to a small pilot group first to detect compatibility issues, then rapidly expand if successful. Maintain rollback capability (snapshots, config backups). Waiting for full lab testing ignores active exploitation risk; applying to all systems without any testing risks widespread disruption if the patch is problematic.
A zero-day vulnerability is one that has been publicly disclosed (or actively exploited) with no vendor patch available yet. 'Zero-day patching' refers to the urgency of applying a patch on the same day (day zero) it becomes available for a critical actively exploited vulnerability. Until a patch is available, compensating controls (disable vulnerable features, block with firewall/IPS, segment affected systems) reduce risk.
Try free Patch Management practice questions with explanations, topic links and progress tracking.