█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Cybersecurity/Vulnerability Management/Enterprise Patch Management
45 minIntermediate

Enterprise Patch Management

After this lesson, you will be able to: Explain enterprise patch management (WSUS, SCCM/Intune, the patch Tuesday cadence) and prioritise what to patch first.

Knowing a CVE exists is easy. Getting it patched across thousands of machines is where vulnerability management actually lives. This lesson covers the tools, the rhythm, and the prioritisation logic that real enterprises use to keep up.

Prerequisites:CVE/CVSS Deep Dive

The patch Tuesday cadence

Microsoft releases security patches on the second Tuesday of every month, 'Patch Tuesday'. The whole industry pivots around this rhythm. Most enterprises run a 'patch Tuesday +1 week' cycle: deploy to test, observe, then push to production. Out-of-band emergency patches (CISA KEV entries, actively exploited zero-days) break the cadence and get same-day deployment when they're critical.

WSUS, SCCM, Intune, what each does

WSUS (Windows Server Update Services), free Microsoft tool that hosts patches locally and lets you approve which updates go to which groups of Windows machines. Solid for small shops. SCCM (now Microsoft Configuration Manager), enterprise-class patch + config + software-deployment tool. The standard for Windows-heavy on-prem environments. Intune (Microsoft Endpoint Manager), cloud-native MDM. The modern path. Co-management with SCCM is common while organizations migrate. For Linux: Ansible, Satellite (Red Hat), Landscape (Ubuntu). For macOS: Jamf, Kandji. Cross-platform: Tanium, BigFix.

Patch prioritisation: a real workflow

Tier 0 / Same-day: CISA KEV, actively exploited, internet-facing. Tier 1 / 7 days: CVSS 9+, critical business apps, externally exposed. Tier 2 / 30 days: CVSS 7-8.9, internal systems. Tier 3 / next maintenance window: CVSS <7, low-impact systems. Tier 4 / accept risk: end-of-life systems with compensating controls. Real teams document this in a written patch policy and review quarterly.

💡 Why 'just patch everything immediately' is malpractice

Patches break things. A reverse-proxy update can take down login. A driver update can blue-screen workstations. A SharePoint patch can break a custom workflow that runs payroll. Mature patch management has a staged rollout: pilot ring (IT, opt-in) → broad ring (a subset of users) → fast ring (most of the org) → slow ring (sensitive systems). Each ring is observed for breakage before the next. Done well, this still ships critical patches inside CISA KEV deadlines.

Design a patch policy for a fictional 500-person company

Practice writing the patch policy you'd hand to leadership.

  1. 1

    List the systems: Windows laptops (250), Mac laptops (100), Linux servers (50), three SaaS apps, on-prem Exchange

  2. 2

    Define ownership: Helpdesk owns endpoints, Infrastructure owns servers, Security defines policy and audits compliance

  3. 3

    Write the rings: Pilot (Helpdesk + Security, 20 people) → Broad (Engineering, 100 people) → Fast (everyone else, 380 people) → Slow (Finance + Exec, sensitive)

  4. 4

    Define deadlines per tier (use the prioritisation tiers above)

  5. 5

    Define emergency override: who can authorise a same-day patch (CISO or designate)

  6. 6

    Define the metrics you'll track: % machines patched within deadline, mean time to patch, # CISA KEV findings still open

Common mistakes only experienced engineers catch

Patching the test ring AND production in the same maintenance window (zero observation time). Skipping reboots after patching (Windows updates often don't take effect until reboot, your scan still shows the bug). Ignoring third-party software (Java, Chrome, Adobe), most enterprise scanners detect it; patch tools sometimes don't. Treating EOL software as patchable (Windows Server 2012 R2 is out of support, no patch is coming, this is a compensating-control problem). Not auditing actual deployment. Helpdesks report 'patched' optimistically; rescan to verify.

Quick Check

When should you skip the staged rollout?

Choose the only justified bypass.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Reading CVEs and Writing the Report
Back to Vulnerability Management
Vulnerability Management Resources and Next Steps→