Patch Management Guide: Windows, macOS, Linux and Third-Party Apps

Most organisations know how to install a patch; far fewer can prove that every exposed asset received it before attackers used the flaw. Patch management breaks down at the edges: the appliance nobody owns, the third-party application outside the update tool, the server exempted from reboots, the software whose vendor stopped shipping fixes. This guide covers the end-to-end process for Windows, macOS, Linux and third-party applications: remediation SLAs, deployment rings, emergency and out-of-band patching, rollback, unsupported software, tooling choices and the metrics that show it is working. It is written for endpoint, infrastructure and vulnerability management teams, and for the security leads who set their targets.

Key takeaways

• Patch by maintenance group, not by exception. NIST SP 800-40 Rev. 4 recommends grouping assets with similar characteristics and giving each group a maintenance plan, rather than carrying a long list of "exceptions".
• Known exploitation sets the clock. A vulnerability in the CISA Known Exploited Vulnerabilities (KEV) catalogue on an internet-facing system deserves a deadline measured in days, regardless of its CVSS score.
• Rings make speed safe. Deploying to a small pilot ring first, with an agreed halt-and-rollback trigger, lets you shorten broad deployment instead of lengthening testing.
• Patching does not evict an attacker. If a flaw leaked sessions, keys or credentials, you must revoke and rotate them after patching, as CitrixBleed and ToolShell showed.
• Measure coverage by deadline. Report the percentage of assets patched within each maintenance plan's deadline and the median time to remediate, not raw vulnerability counts.

What patch management covers

NIST SP 800-40 Rev. 4 defines enterprise patch management as identifying, prioritising, acquiring, installing and verifying patches, updates and upgrades, and frames it as preventive maintenance rather than an occasional project. In practice the scope is wider than "Windows Update":

• Operating systems: Windows client and server, macOS, Linux distributions, mobile operating systems and hypervisors.
• Third-party applications: browsers, PDF readers, runtimes such as Java and .NET, collaboration clients, developer tools and line-of-business software.
• Edge and network devices: VPN concentrators, firewalls, load balancers and remote access gateways. These are internet-facing, often run vendor-managed operating systems and are a recurring entry point.
• Firmware and drivers: BIOS/UEFI, storage controllers, network cards and baseboard management controllers.
• Containers and images: base images must be rebuilt and redeployed; patching a running container in place does not persist.

Everything starts with inventory. SP 800-40 is explicit that organisations should "establish and constantly maintain up-to-date software inventories" and that the old model of refreshing inventories monthly or quarterly "should no longer be used". You cannot set a deadline for software you do not know is installed.

Setting remediation SLAs

A remediation SLA turns a policy ("patch promptly") into a deadline someone can be held to. The strongest public reference points are CISA Binding Operational Directive (BOD) 22-01, issued on 3 November 2021, which requires US federal civilian agencies to remediate KEV entries within two weeks (six months for CVE IDs assigned before 2021), and the UK Cyber Essentials requirements (v3.2), which require critical or high-risk updates, or those fixing vulnerabilities with a CVSS v3 base score of 7 or above, to be applied within 14 days of release. CIS Controls Safeguards 7.3 and 7.4 set a floor of monthly or more frequent automated operating system and application patching.

Two design points matter more than the exact numbers. First, the clock should start at vendor release (or KEV listing), not at the date your scanner noticed the vulnerability. Second, BOD 22-01 binds only US federal agencies, but CISA recommends that every organisation use the KEV catalogue "as an input to their vulnerability management prioritization framework". A vulnerability enters KEV only when it has a CVE ID, clear remediation guidance and reliable evidence of exploitation in the wild, which makes it a low-noise trigger for the emergency tier.

Platform reference: Windows, macOS, Linux and third-party apps

Windows specifics

• Patch Tuesday and out-of-band releases: Microsoft quality updates are typically released on the second Tuesday of each month, but "can be released at any time". They are cumulative, so the latest one carries all earlier fixes for that feature update, and servicing stack updates must stay current because they install everything else.
• Deferrals and deadlines: the policies "Select when Quality Updates are Received" and "Select when Preview Builds and feature updates are Received" set deferrals per ring. On Windows 11 22H2 and later, "Specify deadline for automatic updates and restarts for quality update" (CSP Update/ConfigureDeadlineForQualityUpdates) and its grace period (Update/ConfigureDeadlineGracePeriod) are what turn an offered update into an installed one.
• WSUS: Microsoft lists Windows Server Update Services as "no longer actively developed", while existing capabilities remain available. It still works for disconnected or tightly controlled server estates, but new client designs should use cloud-based update policies, Autopatch or Configuration Manager.
• Windows Autopatch: a cloud service that automates Windows, Microsoft 365 Apps, Edge and Teams updates in sequential deployment rings and Autopatch groups. Microsoft states that it aims to keep at least 95% of Up to Date devices on the latest quality update. Microsoft made it available to Business Premium and A3+ licences from April 2025.

Third-party and distributed estates

Third-party applications are where coverage usually collapses, because each vendor ships on its own schedule and many installers run per user. Treat the third-party catalogue as a maintenance group with the same SLA tiers, report versions centrally, and remove applications that have no owner. For remote and branch offices, use peer-to-peer distribution such as Delivery Optimization or BranchCache, and cloud-delivered updates for devices that rarely connect to the corporate network, so that compliance does not depend on VPN sessions.

Deployment rings, testing and rollback

Microsoft's deployment planning guidance describes three rings: Preview (IT staff evaluating changes), Limited (a representative sample of hardware and applications) and Broad (everyone else), with mission-critical devices optionally held back until broad deployment completes. It notes that "there are no definite rules for exactly how many rings to have" and that extensive advanced testing is not required: only business-critical applications need it, with the rest validated through pilot rings. SP 800-40 makes the same point, recommending phased deployments for routine patching and, even for emergencies, a first deployment to a small number of canary assets.

1. Build maintenance groups: group assets by platform, criticality, exposure and change constraints (for example "internet-facing Linux web tier", "clinical workstations", "executive laptops"). Give each an owner and a maintenance window.
2. Define rings inside each group: a Preview ring (IT and willing volunteers), a Limited ring that represents every hardware model and critical application, and Broad. Exclude IT-only devices from the Limited ring; Microsoft warns they are rarely representative.
3. Set ring timing: for example Preview on release day, Limited at day 2 to 3, Broad at day 7, with compliance deadlines that land within the SLA tier.
4. Agree the halt criteria in advance: crash rates, application failures or help desk volume above an agreed threshold pause the next ring. Microsoft calls this a "red button" model, where content flows until someone stops it, and notes it suits update velocity better than a "green button" approval at each stage.
5. Prepare rollback: on Windows, pause the ring (up to 35 days) and uninstall the update where the vendor supports it; on Linux, keep the previous kernel in the boot menu and pin package versions; for servers and appliances, take snapshots or configuration backups first. SP 800-40 suggests asking vendors whether they provide rollback capabilities before you buy.
6. Verify, do not assume: confirm installation from the endpoint's reported state or an authenticated vulnerability scan, not from the deployment job's success count.

Emergency and out-of-band patching

SP 800-40 describes emergency patching as the same process run on "a highly accelerated schedule". Write the emergency runbook before you need it:

• Trigger: KEV listing, vendor exploitation notice or national CERT advisory affecting an asset you run. Confirm exposure from inventory within hours, not days.
• Mitigate first if no fix exists: apply vendor mitigations, restrict management interfaces, or take the service offline. During the Ivanti Connect Secure exploitation in 2024, attackers exploited two VPN zero-days and exposed credentials and service accounts.
• Do not treat a WAF rule as a patch: in the ShinyHunters FBI breach claim, organisations that patched the PeopleSoft flaw were protected, while those relying only on WAF rules were not; the FBI breach itself has not been confirmed.
• Revoke what the flaw exposed: after CitrixBleed, Citrix told customers to upgrade and "kill all active and persistent sessions", because stolen session cookies stayed valid after patching. After ToolShell, Microsoft told SharePoint customers to rotate ASP.NET machine keys and restart IIS, because patching did not remove the attacker's access.
• Hunt for prior compromise: if exploitation began before the patch, assume the asset may already be compromised and check for web shells, new accounts and outbound connections.
• Shorten, do not skip, testing: deploy to canaries for hours rather than days, then broad.

End-of-life and unsupported software

When the vendor no longer ships fixes, there is nothing to patch. Cyber Essentials requires in-scope software to be licensed and supported and removed when it becomes unsupported, or moved out of scope into a sub-set with no internet traffic. CISA's KEV guidance says to remove a product from the network if it is end-of-life or cannot otherwise be updated. Windows 10 reaching end of support in October 2025 put this on many risk registers at once.

Where removal is not yet possible, SP 800-40 offers four risk responses, which make a useful decision framework:

Build the problem out at procurement: SP 800-40 suggests asking suppliers for how many years they are committed to correcting vulnerabilities in the software, and CIS Safeguard 2.2 requires that authorised software is currently supported.

Choosing a tooling model

• Cloud-native policies (Intune with Windows Update client policies, Autopatch, MDM with DDM): best for mobile and remote workforces and small IT teams. Trade-off: less granular approval control, and reliance on the vendor's ring logic.
• On-premises management (Configuration Manager, WSUS, Linux repository mirrors such as a local apt or dnf mirror): suits regulated, disconnected or bandwidth-constrained estates and servers that need explicit approval. Trade-off: infrastructure to maintain, and WSUS receives no new features.
• Third-party patching tools and "autonomous patching": add catalogues for non-Microsoft applications and can auto-approve updates by policy. Trade-off: the tool's agent and catalogue become part of your supply chain, and auto-approval without rings simply moves the outage risk.
• Small organisations: turn on automatic updates everywhere, use the native cloud tools, enforce deadlines and spend effort on the few systems that cannot auto-update (edge devices, line-of-business servers).
• Large organisations: invest in maintenance groups with named owners, ring telemetry, an emergency runbook and reporting that joins inventory, deployment state and vulnerability scan results.

Where identity fits

Patch and endpoint management platforms hold some of the most powerful credentials in the estate: an account that can push software to every device can also push malware or a wipe command. In the Stryker cyberattack, one hijacked admin account used Microsoft Intune to wipe tens of thousands of devices.

• Admin roles: scope patch administrators to the device groups they manage, require phishing-resistant MFA and just-in-time elevation for tenant-wide actions. See the Privileged Access Management Guide.
• Service accounts: distribution point, deployment and scanning accounts often have local admin rights on every server. Inventory them, remove interactive logon and rotate their credentials. See the Service Account Security Guide.
• API credentials: integrations between scanners, ticketing and patch tools use API keys and app registrations; vault and scope them. See the Secrets Management Guide.

Detection and measurement

SP 800-40 warns against "overly simplistic metrics, such as counting the number of vulnerabilities" and recommends measuring the percentage of assets patched by each maintenance plan's deadline, alongside average and median time to mitigate. Useful KPIs:

• Patched by deadline: percentage of assets in each maintenance group compliant by the SLA deadline, reported per tier.
• Median time to remediate: from vendor release (or KEV listing) to verified installation, for emergency and critical tiers separately.
• KEV exposure: count and age of open KEV entries on internet-facing assets. The target is zero past deadline.
• Coverage: percentage of inventoried assets reporting into a patch tool, and percentage of third-party applications under central management.
• Unsupported software: number of end-of-life installations, each with a risk response and review date.
• Change quality: ring halts and rollbacks per month; a rising number points to weak Limited-ring representation.

Monitor pending-reboot state (installed but not active), devices that have not checked in for more than a cycle, and changes to update policies, deferrals and pause settings, since a quiet pause on a ring has the same effect as not patching. Reconcile the patch tool's view against authenticated vulnerability scans, as required by CIS Safeguard 7.5.

Framework mapping

Common failure patterns

• Edge devices outside the process: VPNs and gateways are patched by a network team on a different schedule, without the emergency tier, despite being the most exploited assets.
• "Patched" means "deployment job succeeded": updates sit pending a reboot for weeks, or fail silently on devices that never check in, while dashboards show green.
• Patching without revocation: sessions, machine keys and credentials stolen before the fix stay valid afterwards, as with CitrixBleed.
• Permanent exceptions: servers excluded "temporarily" from reboots or rings, with no owner or review date, become the oldest software in the estate.
• Unrepresentative pilot ring: the Limited ring is all IT staff on new hardware, so breakage appears first in Broad and the organisation responds by slowing every future cycle.
• Over-privileged patch tooling: one compromised admin account or agent can deploy to every device; the management plane needs the same protection as domain controllers.

Practitioner checklist

• Maintain a continuously updated software inventory covering OS, third-party apps, firmware and edge devices.
• Define maintenance groups with owners, windows and rings instead of open-ended exceptions.
• Publish SLA tiers with KEV listing on exposed assets as the emergency trigger, starting the clock at vendor release.
• Configure deferrals, compliance deadlines and grace periods on every Windows ring, and DDM enforcement dates on Apple devices.
• Enable unattended-upgrades or DNF Automatic on Linux where appropriate, and track pending reboots.
• Write and rehearse an emergency runbook that includes session, key and credential revocation.
• Agree ring halt criteria and test rollback for each platform.
• Give every unsupported product a documented risk response and retirement date.
• Scope, protect and monitor admin roles and service accounts in patch tooling.
• Report patched-by-deadline, median time to remediate and open KEV age monthly.

Standards and references

• NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• CISA: BOD 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities
• CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities (KEV)
• NCSC: Cyber Essentials Requirements for IT Infrastructure v3.2
• CIS: Control 7, Continuous Vulnerability Management
• Microsoft Learn: Create a deployment plan
• Microsoft Learn: Enforcing compliance deadlines for updates
• Apple Platform Deployment: Install and enforce software updates

Related NHI Mgmt Group resources: Privileged Access Management Guide · Service Account Security Guide · Active Directory and Entra ID Hardening Guide · Identity Security Metrics Guide · Remote Access Identity Guide