PatchOps

PatchOps is an informal name for running patch management as an operation: knowing which assets need which vendor fix, rolling fixes out in rings and maintenance windows, handling restarts, backing out when a fix breaks something, and proving each fix is in effect. The established name is enterprise patch management, which NIST defines as “the process of identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades throughout an organization”^[1].

In one line: PatchOps gets the fix onto every asset that needs it, on schedule, without causing the outage it was meant to prevent.

It is for engineers who run patch cycles, managers who own deadlines, and leaders deciding how much to patch in place at all.

Almost every fix needs someone to schedule disruption: a service restart, a reboot, a firmware flash. NIST states the tension: “Deploying patches more quickly reduces the window of opportunity for attackers but increases the risk of operational disruption”, while testing first does the reverse and “still might miss problems”. Because assets are so dynamic and dispersed, NIST adds, many organisations cannot keep up, and patching often becomes “primarily reactive”^[1].

Documented failures are rarely exotic. At Equifax in 2017, a company-wide fix missed the one portal attackers used (use case 2)^[2]. When WannaCry hit the UK’s National Health Service in May 2017, infected organisations “had unpatched, or unsupported Windows operating systems”, although NHS Digital had issued critical alerts in March and April^[3].

• Not a recognised discipline. No standards body, certification or manifesto defines “PatchOps”. The only use of the name found in October 2026 searches is a 2025 IEEE conference paper naming a Windows patching tool PatchOps^[4]. The practice is documented as patch management in NIST SP 800-40^[1], CIS Safeguards 7.3 and 7.4^[5] and, for industrial systems, IEC TR 62443-2-3^[6].
• Not vulnerability prioritisation. Deciding which flaws matter belongs to VulnerabilityOps; this page receives a prioritised item with a due date and delivers it.
• Not releasing your own software. That is ReleaseOps; both use staged rollouts.
• Not device management in general. Enrolment and configuration belong to EndpointOps, even when the same console deploys patches.
• Not only security updates. Microsoft’s monthly security updates also carry non-security fixes^[7], and bug-fix, firmware and feature updates travel through the same rings.

NIST’s guide has existed since 2002 (revised in 2005, 2013 and April 2022); Revision 4 argues that organisations “would benefit more from rethinking their patch management planning than their patch management technology”^[1]. Four shifts shaped current practice:

1. Vendor cadences. Microsoft publishes cumulative security updates on the second Tuesday of each month, an optional preview in the fourth week, and out-of-band (OOB) releases “as needed”^[7]. Oracle’s quarterly cumulative Critical Patch Updates arrive on the third Tuesday of January, April, July and October; since May 2026, smaller Critical Security Patch Updates fill the third Tuesday of the other eight months, so an Oracle estate now has a monthly security lane beside the quarterly one (as of October 2026)^[8]. Linux repositories publish continuously.
2. Cumulative updates. Windows client updates “include all previously released fixes”^[7], so one install catches a machine up, but one regression can now hold back a whole month of fixes.
3. Cloud management. Microsoft deprecated Windows Server Update Services (WSUS) in September 2024 in favour of cloud tools^[9]; AWS added organisation-wide patch policies in December 2022^[10].
4. Fewer reboots, more replacement. Hotpatching and kernel live patching reduce restarts^[11][12], and image-based assets are patched by rebuilding them.

Mental model: three timelines. The vendor timeline says when a fix exists. The risk deadline, set by VulnerabilityOps, says when it must be in effect. The disruption calendar (windows, freezes, restart tolerance) says when you may touch each asset. PatchOps fits the first into the third before the second runs out, and keeps the evidence.

flowchart LR
  V["VulnerabilityOps: what, by when"]:::neutral --> P
  S["SecOps: groups, exceptions"]:::neutral --> P
  I["ITOps: change authority"]:::neutral --> P
  P["PatchOps: rollout and proof"]:::core
  P --> SY["SysOps: servers"]:::neutral
  P --> EP["EndpointOps: devices"]:::neutral
  P --> CO["ContainerOps: rebuilds"]:::neutral
  P --> KO["KubernetesOps: nodes"]:::neutral
  P -.->|"verified status"| V
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

NIST’s four principles are the closest thing the field has to a charter: “Problems are inevitable; be prepared for them”, “Simplify decision making”, “Rely on automation” and “Start improvements now”. It also reframes the politics: “Disruptions from patching are largely controllable, while disruptions from incidents are largely uncontrollable”^[1].

A one-page charter (this Atlas’s proposal):

• Mission: every in-scope asset runs the fixes its maintenance plan requires, by the deadline, inside agreed disruption limits.
• Principles: decide plans before advisories arrive; let early rings be the test; count only effective fixes; give every asset, even an unpatchable one, a maintenance group; rebuild image-based assets rather than repair them; make exceptions expire.
• Goals: on-time effective coverage per group; emergency lead time; patch-caused incident rate.
• Non-goals: choosing what to fix (VulnerabilityOps), accepting risk (RiskOps), releasing your own software (ReleaseOps).

1. Inventory and applicability. Continuous, automated discovery with authenticated scanning; of the old monthly or quarterly scan-based inventory, NIST says “That model should no longer be used”^[1].
2. Sources and policy. Each vendor’s rhythm and emergency lane; maintenance groups, approval rules and ring membership.
3. Delivery and activation. Agents that download, verify and install; restarts, live patches and firmware flashes.
4. Verification and monitoring. Confirming “the patch is installed and has taken effect”, then that it stays so: not uninstalled, restored from an old backup or reset^[1].
5. Exceptions and mitigations. Dated deviations, compensating controls, and a removal date for every temporary mitigation.

This RACI is this Atlas’s proposal (R responsible, A accountable, C consulted, I informed).

Often missing: a ring captain per cycle, who can halt promotion without a meeting, and canary volunteers (administrators, engineers and early adopters, as NIST suggests^[1]) who report problems quickly.

NIST’s software vulnerability management life cycle (know, plan, execute: prepare, implement, verify, continuously monitor) covers every risk response, not only patching^[1]. Adapted here, it shows two operational exits: no usable patch, and a patch that causes problems.

flowchart TB
  K["Know: inventory matches an advisory"]:::core --> PL["Plan: pick scenario and maintenance plan"]:::decision
  PL -->|"patch available"| PR["Prepare: acquire, validate, schedule"]:::core
  PL -->|"no patch or unpatchable"| MI["Mitigate: disable, isolate, track"]:::risk
  PR --> DE["Deploy: rings and windows"]:::core
  DE -->|"gate fails"| HA["Pause, roll back or mitigate"]:::risk
  DE --> VE["Verify: installed and in effect"]:::core
  VE --> MO["Monitor: still installed, behaving"]:::core
  HA --> PL
  MI --> MO
  MO --> K
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029

Change control. Pre-approve routine cycles as standard changes, with the ring plan as the procedure, plus an emergency route (ITOps owns the change practice). Escalation. After the grace period, overdue assets go to their owner, then to the risk owner for an exception or enforcement (Rings says what enforcement means per ring).

Components, whichever products provide them (tooling):

flowchart TB
  VS["Vendor feeds and repositories"]:::neutral --> MR["Internal mirror or cache"]:::neutral
  INV["Inventory and applicability"]:::core --> POL["Policy: groups, approvals, rings"]:::core
  POL --> ORC["Orchestrator: windows, rate, error limit"]:::core
  HS["Health signals: alerts, probes, tickets"]:::risk -->|"gate input"| ORC
  MR -->|"content"| AG["Agents on servers and devices"]:::neutral
  ORC -->|"commands"| AG
  AG --> RB["Restart coordinator"]:::neutral
  AG -->|"results"| CS["Compliance store"]:::core
  CS -.->|"updates"| INV
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

Trust boundary. The patch system runs code as administrator on every asset it manages. Treat its consoles, service accounts and mirrors as tier-0: least privilege, strong authentication, logs, and separate rights to approve content and to target assets.

Happy path. Triage confirms applicability and known issues; canaries install within hours; gates pass; every ring has its own deadline and later rings meet theirs with restarts in windows; the compliance report closes the cycle.

flowchart TB
  R["Vendor release"]:::neutral --> T["Triage: applicability, known issues"]:::core
  T --> R0["Ring 0: canaries"]:::core
  R0 --> G1{{"Gate 1 healthy?"}}:::decision
  G1 -->|"yes"| R1["Ring 1: pilot"]:::core
  R1 --> G2{{"Gate 2 healthy?"}}:::decision
  G2 -->|"yes"| R2["Ring 2: broad"]:::core
  R2 --> G3{{"Gate 3 healthy?"}}:::decision
  G3 -->|"yes"| R3["Ring 3: sensitive, node by node"]:::core
  R3 --> EN["Final ring deadline: forced install"]:::core
  EN --> VF["Verify effective coverage"]:::core
  G1 -->|"no"| H["Halt: pause release, run runbook"]:::risk
  G2 -->|"no"| H
  G3 -->|"no"| H
  H -->|"fix or OOB release"| T
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

Exception paths.

• A gate fails: pause the release and follow the worked runbook.
• An asset misses its window: it rolls to the next one; after the grace period, enforcement.
• An emergency arrives mid-cycle: the emergency plan pre-empts routine rings, which resume afterwards.
• No usable patch: emergency mitigation with a removal date (decision framework).

NIST’s four scenarios are the backbone of the playbooks^[1]:

1. Routine patching. “Most patching falls under this scenario”, and it is often “postponed and neglected”, which makes later emergencies harder because earlier patches must go in first.
2. Emergency patching. The same approach “with a highly accelerated schedule”; a canary period of “a few minutes to a few hours” may still help.
3. Emergency mitigation. Disable functionality or isolate the asset while no good patch exists; schedule both the patch and the mitigation’s removal.
4. Unpatchable assets. Approved long-term mitigations per maintenance group, re-evaluated periodically, including whether the asset is still worth its cost.

Two asset classes are taught elsewhere: smartphones, one of NIST’s example maintenance groups^[1], in EndpointOps; firewall, VPN and other network appliances, upgraded one peer at a time where paired, in NetOps. Macs stay in scope: on supervised Apple devices the device-management service can defer an update by 1 to 90 days per group and enforce installation by a deadline^[13]; give Macs a maintenance group and rings of their own.

In NIST’s phased deployment “a small subset of the assets to be patched receive the patch first”: “In effect, this is how the patching gets tested”^[1]. In a 2019 study of 102 US administrators, staggered deployment was the most common testing strategy (43 of 102) and only 14 described positive testing experiences; one would “install on non-important machines and let them bake for 1+ months”^[14], longer than many risk deadlines allow. NIST’s own example sits in between: a first round of technically knowledgeable users that “lasts a few days”, then early adopters who “try app updates for a few weeks”^[1].

Vendor defaults are much faster. As of October 2026, the ring policies that Windows Autopatch groups create defer quality updates by 0, 1 and 2 days for their Test, Ring 1 and Last rings, with deadlines of 0, 0 and 1 days and grace periods of 0, 1 and 2 days^[15]; Autopatch recommends automatic approval for security updates^[16].

Shares and soaks are illustrative; three rules matter more:

• Representativeness beats size. A canary ring without each server role (domain controller, Remote Desktop Services (RDS) host, database) will pass and let a role-specific regression through. NIST wants early adopters “representative of the entire user community”^[1].
• Gates need functional probes. A clean install can still break sign-in or printing.
• Freeze what was tested. Rings that pull “everything approved today” may install packages the canaries never saw. Freeze the set per cycle with a repository snapshot, an explicit list or a cut-off date (AWS ApproveUntilDate)^[17]. On Windows Server a cut-off date has a trap: by default Windows Server 2019 and 2022 remove superseded updates, so if a newer or out-of-band release arrives after the cut-off, it is not approved, the frozen update may no longer install, and Systems Manager still reports the node compliant^[18]. Approve the new release, start it at ring 0, and check Windows rings by build number or an authenticated scan.

What “forced” means for ring 3. For strict-window assets a deadline never triggers an out-of-window restart: the next scheduled window becomes mandatory, an asset that misses it needs a dated exception from the risk owner, and enforcement is indirect, as in NIST’s example of “preventing network access for unpatched assets until they are patched”^[1], not an unscheduled push.

Many fixes take effect only after a restart of the software or the platform^[1]. The single-host checks are in SysOps; across a fleet, three facts catch teams out:

• Library updates need service restarts. A running service keeps the old library in memory; from Ubuntu 24.04, needrestart restarts affected services automatically unless they are excluded^[19].
• Tools reboot more than you expect. With AWS RebootIfNeeded, Patch Manager “doesn’t evaluate whether a reboot is required by the patch” and reboots anyway^[20].
• Deadlines override users. Once a Windows quality-update deadline and any grace period have passed, the device ignores active hours and restarts after a 15-minute warning^[21].

Live patching. Canonical Livepatch “patches high and critical Linux kernel vulnerabilities without requiring a system reboot”^[12]. Windows Server Hotpatch avoids restarts in two months out of three, but quarterly and unplanned baselines, non-security updates, .NET, drivers and firmware still need them; as of October 2026, Azure Arc-enabled Hotpatch for Windows Server 2025 is “now available at no extra cost”^[11].

Kubernetes nodes are hosts too. Kured, a CNCF Sandbox project, watches for /var/run/reboot-required, takes a cluster lock so that by default one node reboots at a time, can wait while Prometheus alerts fire, and cordons and drains each node^[22]. Replacing node pools from updated images belongs to KubernetesOps.

CIS Safeguard 7.4 asks for automated application patching “on a monthly, or more frequent, basis”, checked per asset against an authoritative source of version details^[5]. Browsers, office suites and runtimes need the same plans as the OS, with three differences:

• Verify by installed version, not deployment status: many applications update outside the OS package manager.
• Vendor channels are rings you configure. Google rolls Chrome Stable releases out “over a few weeks”; administrators can choose the Extended Stable channel or pin a version, which Google says “should be done only temporarily”, and components such as Widevine keep updating even when browser updates are off^[23]. For Microsoft 365 Apps on Monthly Enterprise Channel, Microsoft suggests that a select group of users takes each version first, then a gradual deployment^[24]. Map these groups onto your rings.
• Catalogues package updates, sometimes without rings. As of October 2026, Intune Enterprise App Management (an add-on licence) offers prepared Microsoft and non-Microsoft Win32 apps; its auto-update “doesn’t support rollout rings or deployment plans for staged update deployment” and has no rollback, and self-updating catalogue apps follow the vendor’s process^[25]. Where rings matter, use its guided supersedence instead.

“Roll back if it breaks” is a plan only if the mechanism exists for that asset type:

The common path is roll forward: install the vendor’s fixed or out-of-band release. NIST also lists “restoring the software or asset from backups”^[1], so restores (BackupOps) belong in the plan for stateful systems.

NIST maps patch planning to SP 800-53 controls including CM-8 (inventory), CM-3 (change control) and SI-2 (flaw remediation)^[1]. Prioritisation methods (CVSS severity scores, EPSS exploit probabilities, CISA’s KEV catalogue of exploited flaws, Stakeholder-Specific Vulnerability Categorization (SSVC) decision trees) live in VulnerabilityOps.

Product facts are as of October 2026.

Selection criteria: platforms; ring and deadline controls; freezing the tested set; reboot behaviour; compliance that separates installed from active; API and history export; privilege model; cost; how it reads vendor metadata (use case 3).

NIST is blunt: “There is no way that an organization can keep up with patching without automation”^[1]. Automate approval rules, calendars, gate evaluation, restarts and evidence; keep human decisions for halting a moving release, emergency changes and exceptions. Language models can summarise release notes and draft change records; use them as readers, not deciders, and never let one promote a ring.

Assumptions. About 4,000 Windows devices on a cloud update service; a few hundred Windows, Ubuntu and RHEL-family servers on premises and in AWS; one Kubernetes cluster; a few unpatchable industrial PCs; one small platform team. A starting design, not a product recommendation.

1. Maintenance plans as data. An illustrative schema in version control records who changed a deadline and feeds calendars and reports from one source.

Example status: syntax-checked (YAML), not executed; the schema is illustrative.

# patch-policy.yaml: maintenance groups and their plans (Atlas illustrative schema)
version: 3
release_anchor: second-tuesday          # routine cycle starts on the vendor release day
groups:
  - name: workstations
    rings: [ring0-it-staff, ring1-volunteers, ring2-everyone]
    routine: {deadline_days: 7, grace_days: 2, restart: deadline-forced}
    emergency: {canary_hours: 4, deadline_days: 2}
    unreporting_after_days: 7
  - name: linux-servers
    rings: [ring0-one-per-role, ring1-nonprod, ring2-prod-a, ring3-prod-b]
    routine: {deadline_days: 14, window: "Tue-Thu 01:00-05:00 UTC", restart: in-window}
    emergency: {canary_hours: 2, deadline_days: 3, change: emergency-route}
    freeze_tested_set: true             # later rings install what ring 0 tested
  - name: k8s-nodes
    method: reboot-coordinator          # Kured, one node at a time
    routine: {deadline_days: 14}
  - name: legacy-ot
    method: unpatchable
    mitigations: [network-isolation, allow-list-firewall, no-internet]
    review: quarterly
    replacement_due: 2027-06-30
exceptions:
  require: [owner, reason, compensating_control, expiry]
  max_days: 90

2. One Windows Server ring on AWS. One baseline serves all rings, which differ only in their windows^[17][37][38]. It reuses the filter of AWS’s predefined Windows baseline (which waits 7 days^[18]) but approves after 2; Microsoft publishes around 10:00 Pacific on the second Tuesday^[7], so a 01:00 UTC window three days later finds that month’s update approved. Side effects: DefaultBaseline: true sets the account and Region default for Windows; AvailableSecurityUpdatesComplianceStatus: NON_COMPLIANT reports security updates that are available but not yet approved as non-compliant^[17]. Later rings would approve anything released since; freeze them only with the Windows Server supersedence trap in Rings in mind.

Example status: syntax-checked (YAML), not deployed. Requires the SSM Agent on targets, instances tagged PatchRing=ring1, and AWS Identity and Access Management (IAM) permission to create Systems Manager resources.

AWSTemplateFormatVersion: "2010-09-09"
Description: Ring 1 Windows Server patching (illustrative; review before use)
Resources:
  WindowsSecurityBaseline:
    Type: AWS::SSM::PatchBaseline
    Properties:
      Name: windows-server-security-2d
      OperatingSystem: WINDOWS
      DefaultBaseline: true
      AvailableSecurityUpdatesComplianceStatus: NON_COMPLIANT   # Windows Server only
      ApprovalRules:
        PatchRules:
          - PatchFilterGroup:
              PatchFilters:
                - Key: CLASSIFICATION
                  Values: [CriticalUpdates, SecurityUpdates]
                - Key: MSRC_SEVERITY
                  Values: [Critical, Important]
            ApproveAfterDays: 2
            ComplianceLevel: CRITICAL
  Ring1Window:
    Type: AWS::SSM::MaintenanceWindow
    Properties:
      Name: ring1-windows-servers
      Schedule: "cron(0 1 ? * TUE#2 *)"   # 01:00 UTC on the second Tuesday...
      ScheduleOffset: 3                   # ...run three days later (Friday)
      ScheduleTimezone: Etc/UTC
      Duration: 4
      Cutoff: 1
      AllowUnassociatedTargets: false
  Ring1Targets:
    Type: AWS::SSM::MaintenanceWindowTarget
    Properties:
      WindowId: {Ref: Ring1Window}
      ResourceType: INSTANCE
      Targets:
        - Key: tag:PatchRing
          Values: [ring1]
  Ring1Install:
    Type: AWS::SSM::MaintenanceWindowTask
    Properties:
      WindowId: {Ref: Ring1Window}
      TaskType: RUN_COMMAND
      TaskArn: AWS-RunPatchBaseline
      Priority: 1
      MaxConcurrency: "10%"               # one tenth of the ring at a time
      MaxErrors: "2"                      # circuit breaker
      Targets:
        - Key: WindowTargetIds
          Values: [{Ref: Ring1Targets}]
      TaskInvocationParameters:
        MaintenanceWindowRunCommandParameters:
          Parameters:
            Operation: [Install]
            RebootOption: [RebootIfNeeded]

To validate, run the document with Operation: Scan on a ring-0 instance: compliance shows missing patches and nothing installs. ApproveAfterDays is not supported for Debian or Ubuntu Server^[17], so Ubuntu rings need another way to delay and freeze, such as a dated repository snapshot.

3. Ubuntu host defaults. unattended-upgrades already applies security updates daily, after a random timer delay, and reboots only if Automatic-Reboot is turned on (default off)^[19]. For ring servers, keep it for the security pocket, block packages that need manual steps, and leave reboots to the ring’s window, which takes one failure domain at a time and checks /var/run/reboot-required itself: Patch Manager might not reboot hosts whose packages another tool installed^[20]. For needrestart, add one key at a time: assigning a whole new override_rc hash replaces the shipped list that stops it restarting dbus, networking, docker, libvirt and more^[39].

Example status: not executed on a host; apt directives checked against Ubuntu’s documentation^[19]; the needrestart line evaluated in Perl 5.30 after upstream needrestart.conf (2026-10-17): 50 shipped exclusions plus haproxy remained, where the whole-hash form left only haproxy.

// /etc/apt/apt.conf.d/52patchops-local (overrides; keep the distribution file intact)
Unattended-Upgrade::Package-Blacklist {
    "postgresql-";            // database restarts handled by the DB team in-window
};
Unattended-Upgrade::Automatic-Reboot "false";   // default; the ring window reboots hosts
Unattended-Upgrade::Mail "patch-reports@example.com";
Unattended-Upgrade::MailReport "on-change";

# /etc/needrestart/conf.d/50-patchops.conf (Perl syntax)
# Add a key; never assign a new hash, which would drop the shipped exclusions.
$nrconf{override_rc}{qr(^haproxy\.service$)} = 0;   # restarted by the LB runbook

4. RHEL-family host defaults. dnf-automatic (DNF 4) can install only security advisories^[35]; for ring servers, leave reboots to the window, as on Ubuntu.

Example status: not executed; options checked against the DNF 4 documentation. DNF 5 distributions ship a different implementation.

# /etc/dnf/automatic.conf (excerpt)
[commands]
upgrade_type = security
apply_updates = yes
reboot = never
random_sleep = 1800

[emitters]
emit_via = stdio,motd

Enable it with systemctl enable --now dnf-automatic.timer. With reboot = when-needed instead, timing gets loose: the timer adds up to an hour of random delay on top of random_sleep, and the reboot waits five minutes^[35].

5. Kubernetes node reboots. Arguments for the kured container, from the configuration reference^[22].

Example status: syntax-checked (YAML fragment), not executed.

args:
  - --reboot-days=tue,wed,thu
  - --start-time=1am
  - --end-time=5am
  - --time-zone=UTC
  - --period=10m
  - --concurrency=1
  - --drain-timeout=30m
  - --prometheus-url=http://prometheus.monitoring.svc.cluster.local
  - --alert-filter-regexp=^RebootRequired$   # alert names to IGNORE; any other active alert defers reboots
  - --blocking-pod-selector=app=nightly-batch

Objective: see the difference between “available”, “installed” and “in effect” on one host. Prerequisites: an Ubuntu/Debian or RHEL-family host and a normal user account; 15 minutes. Cost and risk: none; the script only reads (apt-get -s simulates^[28]; dnf needs-restarting -r reports^[40]).

1. Save the script as patch-state.sh and run bash patch-state.sh.
2. Compare kernel_running with kernel_newest_installed.
3. On Ubuntu, read /var/run/reboot-required.pkgs if it exists: those packages asked for the restart.
4. Note which number a compliance report would show, and which reflects real protection.

Example status: verified by execution on Ubuntu 20.04.6 (apt branch, unprivileged user, 2026-10-16; revised version re-run 2026-10-17). The dnf branch was not run on a RHEL-family host; its logic was tested with stub dnf commands (plugin present or missing). Real output is not reproduced (production host).

#!/usr/bin/env bash
# patch-state.sh: read-only summary of one Linux host's patch state.
# Changes nothing; run as an ordinary user. Debian/Ubuntu (apt) or RHEL family (dnf).
set -uo pipefail
echo "host=$(hostname -s) kernel_running=$(uname -r)"
if command -v apt-get >/dev/null 2>&1; then
  sim=$(apt-get -s -o Debug::NoLocking=1 upgrade 2>/dev/null | grep '^Inst ' || true)
  total=$(printf '%s\n' "$sim" | grep -c '^Inst ' || true)
  sec=$(printf '%s\n' "$sim" | grep -c -- '-security' || true)
  echo "pending_upgrades=${total} from_security_pocket=${sec}"
  lists_mtime=$(stat -c %Y /var/lib/apt/lists 2>/dev/null || echo 0)
  echo "package_lists_age_hours=$(( ($(date +%s) - lists_mtime) / 3600 ))"
  if [ -f /var/run/reboot-required ]; then
    echo "reboot_required=yes since=$(date -r /var/run/reboot-required +%F)"
    sed 's/^/  requested_by: /' /var/run/reboot-required.pkgs 2>/dev/null | sort -u
  else
    echo "reboot_required=no"
  fi
elif command -v dnf >/dev/null 2>&1; then
  lines=$(dnf -q updateinfo list --security --available 2>/dev/null | wc -l)
  echo "security_update_lines=${lines}"   # one line per package, not per advisory
  if dnf needs-restarting --help >/dev/null 2>&1; then
    dnf needs-restarting -r >/dev/null 2>&1; rc=$?
    case $rc in
      0) echo "reboot_required=no" ;;
      1) echo "reboot_required=yes" ;;
      *) echo "reboot_required=unknown (exit ${rc})" ;;
    esac
  else
    echo "reboot_required=unknown (needs-restarting missing: dnf-plugins-core)"
  fi
else
  echo "unsupported package manager" >&2; exit 2
fi
newest=$(ls -1 /boot/vmlinuz-* 2>/dev/null | sed 's|/boot/vmlinuz-||' \
  | sort -V | tail -n 1)
echo "kernel_newest_installed=${newest:-unknown}"
if [ -n "${newest:-}" ] && [ "$newest" != "$(uname -r)" ]; then
  echo "CHECK: running kernel is not the newest installed (reboot pending?)"
fi
exit 0

Expected output (shape, values illustrative):

host=web-03 kernel_running=5.15.0-1084-aws
pending_upgrades=12 from_security_pocket=4
package_lists_age_hours=6
reboot_required=yes since=2026-10-14
  requested_by: linux-image-5.15.0-1085-aws
kernel_newest_installed=5.15.0-1085-aws
CHECK: running kernel is not the newest installed (reboot pending?)

Validation: CHECK appears exactly when the newest kernel in /boot differs from uname -r. Troubleshooting: a large package_lists_age_hours means stale counts; from_security_pocket approximates by matching a -security origin. Teardown: delete the script.

Objective: derive a ring calendar from the release day and apply promotion gates to health data. Prerequisites: Python 3.8 or later; no network. Cost and risk: none; synthetic data.

1. Save rings.py and run python3 rings.py (defaults to October 2026), then python3 rings.py 2026 11.
2. Change ring 1’s observations so that reported is 380 and failed is 5, and run again: the gate should promote.
3. Add "incidents": 1 to ring 0 and confirm the decision becomes HALT.

Example status: verified by execution (Python 3.8.10; published version re-run 2026-10-17). Self-tests confirmed the second-Tuesday function against Microsoft’s documented release dates of 2026-01-13, 2026-07-14 and 2026-09-08^[41].

"""rings.py: plan one monthly patch cycle and decide whether each ring may be promoted.

Standard library only (Python 3.8+). All data below is synthetic.
"""
import datetime as dt
import sys


def second_tuesday(year, month):
    first = dt.date(year, month, 1)
    offset = (1 - first.weekday()) % 7          # Monday=0, Tuesday=1
    return first + dt.timedelta(days=offset + 7)


# start: days after release; deadline: days after start; devices: ring size
RINGS = [
    {"name": "ring0-canary", "start": 0, "deadline": 1, "devices": 40},
    {"name": "ring1-pilot", "start": 2, "deadline": 2, "devices": 400},
    {"name": "ring2-broad", "start": 5, "deadline": 3, "devices": 3200},
    {"name": "ring3-critical", "start": 9, "deadline": 4, "devices": 120},
]
GATE = {"max_install_failure_rate": 0.02, "max_new_incidents": 0,
        "min_reporting_rate": 0.90}


def plan(release):
    for ring in RINGS:
        start = release + dt.timedelta(days=ring["start"])
        due = start + dt.timedelta(days=ring["deadline"])
        yield ring["name"], start, due


def gate(obs):
    """Return (decision, reasons) for one ring's observed health."""
    reasons = []
    reported = obs["reported"] / obs["targeted"]
    failure = obs["failed"] / max(obs["reported"], 1)
    if reported < GATE["min_reporting_rate"]:
        reasons.append(f"only {reported:.0%} of devices reported")
    if failure > GATE["max_install_failure_rate"]:
        reasons.append(f"install failure rate {failure:.1%}")
    if obs["incidents"] > GATE["max_new_incidents"]:
        reasons.append(f"{obs['incidents']} incident(s) linked to the update")
    if obs["incidents"]:
        return "HALT", reasons      # pause the release, open the runbook
    return ("HOLD", reasons) if reasons else ("PROMOTE", ["all gate checks passed"])


def main():
    year, month = (int(x) for x in (sys.argv[1:3] or ["2026", "10"]))
    release = second_tuesday(year, month)
    print(f"release (second Tuesday): {release}")
    for name, start, due in plan(release):
        print(f"  {name:15s} start {start}  install deadline {due}")
    observed = {   # synthetic health signals, one row per finished ring
        "ring0-canary": {"targeted": 40, "reported": 39, "failed": 0, "incidents": 0},
        "ring1-pilot": {"targeted": 400, "reported": 352, "failed": 9, "incidents": 0},
    }
    for name, obs in observed.items():
        decision, why = gate(obs)
        print(f"gate after {name}: {decision} ({'; '.join(why)})")


if __name__ == "__main__":
    main()

Expected output (actual run for October 2026):

release (second Tuesday): 2026-10-13
  ring0-canary    start 2026-10-13  install deadline 2026-10-14
  ring1-pilot     start 2026-10-15  install deadline 2026-10-17
  ring2-broad     start 2026-10-18  install deadline 2026-10-21
  ring3-critical  start 2026-10-22  install deadline 2026-10-26
gate after ring0-canary: PROMOTE (all gate checks passed)
gate after ring1-pilot: HOLD (only 88% of devices reported; install failure rate 2.6%)

Validation: 352 ÷ 400 = 88 % reporting (below 90 %) and 9 ÷ 352 = 2.6 % failures (above 2 %), so ring 1 holds. Troubleshooting: ValueError: month must be in 1..12 means a bad month argument. HOLD means “chase missing reports, re-evaluate”; HALT means “pause the release”; decide in advance who may override. Teardown: delete the file.

Objective: compare an honest on-time coverage figure with a typical dashboard figure from the same data. Prerequisites: Python 3.8 or later. Cost and risk: none; synthetic inventory of 16 assets.

1. Save compliance.py and run it.
2. For each group, explain the gap between honest and dashboard.
3. Change crit-03’s exception date to 2026-11-20 and re-run; note which column changes.

Example status: verified by execution (Python 3.8.10; published version re-run 2026-10-17); every figure was also checked by hand.

"""compliance.py: honest patch-compliance metrics for one release.

Standard library only (Python 3.8+). The inventory below is synthetic.
"""
import csv
import datetime as dt
import io
import statistics

AS_OF = dt.date(2026, 10, 30)
RELEASE = dt.date(2026, 10, 13)
DEADLINE_DAYS = {"workstations": 7, "servers": 14, "critical": 21, "legacy-ot": None}
STALE_AFTER_DAYS = 7

INVENTORY = """id,group,last_seen,installed,reboot_pending_since,exception_until
ws-01,workstations,2026-10-30,2026-10-14,,
ws-02,workstations,2026-10-29,2026-10-15,,
ws-03,workstations,2026-10-30,2026-10-19,,
ws-04,workstations,2026-10-30,2026-10-22,,
ws-05,workstations,2026-10-12,,,
ws-06,workstations,2026-10-30,2026-10-16,2026-10-16,
srv-01,servers,2026-10-30,2026-10-18,,
srv-02,servers,2026-10-30,2026-10-18,,
srv-03,servers,2026-10-30,2026-10-25,,
srv-04,servers,2026-10-30,,,2026-11-15
srv-05,servers,2026-10-01,,,
srv-06,servers,2026-10-30,2026-10-20,2026-10-20,
crit-01,critical,2026-10-30,2026-10-24,,
crit-02,critical,2026-10-30,2026-10-24,,
crit-03,critical,2026-10-30,,,2026-10-20
ot-01,legacy-ot,2026-10-30,,,2027-03-31
"""


def d(s):
    return dt.date.fromisoformat(s) if s else None


def main():
    rows = list(csv.DictReader(io.StringIO(INVENTORY)))
    print(f"as of {AS_OF}, release {RELEASE}, {len(rows)} assets in inventory")
    print(f"{'group':13s} {'in':>3s} {'stale':>5s} {'on_time':>7s} {'honest':>7s} "
          f"{'dashboard':>9s} {'inst_lag':>8s} {'reboot>3d':>9s} {'exc_expired':>11s}")
    for group, days in DEADLINE_DAYS.items():
        g = [r for r in rows if r["group"] == group]
        stale = [r for r in g if (AS_OF - d(r["last_seen"])).days > STALE_AFTER_DAYS]
        fresh = [r for r in g if r not in stale]
        effective = [r for r in g if r["installed"] and not r["reboot_pending_since"]]
        on_time = [r for r in effective if days is not None
                   and (d(r["installed"]) - RELEASE).days <= days]
        exc = [r for r in g if r["exception_until"]]
        exc_expired = [r for r in exc if d(r["exception_until"]) < AS_OF]
        # "dashboard" view: counts exceptions as compliant and ignores stale agents
        dash_num = len([r for r in fresh if r["installed"] or r["exception_until"]])
        dashboard = dash_num / len(fresh) if fresh else 0.0
        honest = len(on_time) / len(g) if g else 0.0
        # median install lag, including assets still waiting for a restart (not the KPI)
        lags = [(d(r["installed"]) - RELEASE).days for r in g if r["installed"]]
        median = statistics.median(lags) if lags else float("nan")
        reboot_old = [r for r in g if r["reboot_pending_since"]
                      and (AS_OF - d(r["reboot_pending_since"])).days > 3]
        print(f"{group:13s} {len(g):3d} {len(stale):5d} {len(on_time):7d} "
              f"{honest:7.0%} {dashboard:9.0%} {median:8.1f} "
              f"{len(reboot_old):9d} {len(exc_expired):11d}")


if __name__ == "__main__":
    main()

Expected output (actual run):

as of 2026-10-30, release 2026-10-13, 16 assets in inventory
group          in stale on_time  honest dashboard inst_lag reboot>3d exc_expired
workstations    6     1       3     50%      100%      3.0         1           0
servers         6     1       3     50%      100%      6.0         1           0
critical        3     0       2     67%      100%     11.0         0           1
legacy-ot       1     0       0      0%      100%      nan         0           0

Validation: workstations ws-01–03 were active within 7 days, ws-04 was late (day 9), ws-05 is stale and ws-06 awaits a restart: 3 of 6 = 50 %. The dashboard drops ws-05 and counts ws-04 and ws-06: 5 of 5 = 100 %. It also counts crit-03, whose exception expired on 2026-10-20. inst_lag is the median install lag and includes assets awaiting a restart, so it is not the KPI “time to effective patch”. Troubleshooting: dates must be YYYY-MM-DD. Interpretation: the legacy-OT row is not a patch figure; that group’s metric is mitigations verified each quarter. Teardown: delete the file.

1. A monthly update with two regressions (documented, September 2026). After the 8 September 2026 security update (KB5124008), Microsoft recorded that “some organizations might experience issues with Remote Desktop Services”; an out-of-band update on 14 September resolved it. Another issue that month could break the domain trust of some Credential Guard-protected Windows 11 devices; Microsoft offered a Known Issue Rollback and fixed it on 22 September^[41]. Method: a ring 0 with one RDS host and one Credential Guard device, gated by synthetic remote-desktop and domain sign-ins. Trade-off: halting delays the month’s security fixes, so scope the halt to the affected role. Success: the affected role contained within a day. Pitfall: a laptop-only canary ring, which passes both.

2. Patched everywhere except where it mattered (documented, Equifax 2017). Equifax officials told the US Government Accountability Office (GAO) that the Apache Struts flaw “was not properly identified as being present on the online dispute portal when patches for the vulnerability were being installed throughout the company”^[2] (SecOps tells the full story). Method: route advisories from inventory to owners, not mailing lists. Trade-off: it needs authenticated, component-level inventory whose agents or scan credentials are privileged. Success: for any component, a query lists every asset running it, with its owner, in minutes. Pitfall: trusting one scan; NIST warns that passive scans “will generally underreport vulnerabilities”^[1].

3. A tool approved the wrong thing (documented, November 2024). Some Windows Server 2019 and 2022 machines upgraded themselves to Windows Server 2025 where third-party products managed updates; Microsoft said feature-update metadata “must be interpreted as Optional and not Recommended”^[42]. Method: approval rules by classification (never auto-approve upgrades) and a canary ring that also tests the patch tool after it changes. Success: an unexpected classification stops at ring 0. Trade-off: wanted upgrades need their own project. Pitfall: assuming the tool excludes upgrades; Microsoft asked organisations to check that third-party tools are “configured not to deploy feature updates”^[42].

NIST warns that “Overly simplistic metrics” such as organisation-wide counts of vulnerabilities and the percentage patched “are not actionable”; it proposes the share patched by the deadline and mean and median time to patch, per combination of asset importance and vulnerability importance^[1].

Worked calculation. Lab 3’s 15 patchable assets give 8 ÷ 15 = 53 % on-time effective coverage, and 13 ÷ 13 = 100 % on the dashboard view. CIS’s Update Effectiveness measure, (M2 + M4) ÷ M1, also counts out-of-date systems with a documented exception (M4)^[5]: a legitimate design choice, but report exceptions beside the figure so nobody mistakes one for a fix.

Targets: start from today’s median per group, pair every speed target with a disruption measure, review quarterly.

• The patch system is a privileged attack path (see the trust boundary); protect internal mirrors like the vendor’s servers.
• Update channels outside your rings. In July 2024 CrowdStrike customers chose sensor versions (N, N-1, N-2) through Sensor Update Policies, but the crash came from Rapid Response Content, “configuration data; it is not code or a kernel driver”, delivered separately; CrowdStrike then added customer control over its deployment^[43]. Ask each vendor which channels you can stage (ReleaseOps covers the release-safety lessons).
• Regulated and certified systems. Some manufacturers require delayed updates for safety-related assets, and self-applied updates may void the warranty^[1]; industrial systems have IEC TR 62443-2-3^[6]. Give them their own maintenance group.
• Evidence and privacy. Keep per-asset history (what, when, who, restart, verification); retention follows your audit regime. Telemetry identifies devices and users: collect only what reports need.

Cost drivers: staff time per cycle, canary and test capacity, downtime windows, tooling, paid extended support for old versions (Ubuntu’s Expanded Security Maintenance extends security updates to 10 years^[30]) and unpatchable software. NIST suggests asking suppliers about maintenance before buying, and fewer components, managed services and smaller platforms to reduce the patch load^[1]. These levers probably cut energy use too (our inference; no measurements found).

Capacity arithmetic (illustrative). 600 servers, a 4-hour window with a 1-hour cutoff, about 45 minutes per server including restart and checks, and at most 10 % (60) at a time: 3 usable hours give 4 waves, so 240 servers per window and 3 windows per cycle. If the deadline allows only two windows, raise concurrency, shorten restarts, or move workloads to replaceable images.

• Two sources must agree. Reconcile the patch tool’s view with an authenticated scan monthly; disagreement is a finding.
• Sample by hand. Each month, check a few assets per group directly (version, restart time, service state).
• Leading indicators. Rising unreporting rate or restart age, a shrinking canary ring, gates that never fail.

Illustrative runbook built on documented mechanisms.

Trigger. Eighteen hours after ring 1 installed the monthly update, the synthetic remote-desktop sign-in fails on 3 of 8 RDS hosts. Ring 0 passed because it had no RDS host.

1. Halt (15 minutes). The ring captain pauses promotion; an Autopatch pause can take up to eight hours to reach devices^[16]. For server tools, disable the next ring’s window or task. Tell the service desk.
2. Scope (1 hour). Which roles, builds and configurations fail, and what do they share? Record the update identifiers.
3. Check the vendor (1 hour). Read the known-issues page; in September 2026 it held exactly this problem (use case 1).
4. Contain per role. Apply a vendor-documented mitigation; a Known Issue Rollback if the faulty change is non-security^[26]; or fail over to healthy hosts. Uninstalling reopens the month’s vulnerabilities, so it needs a time-boxed exception from the risk owner.
5. Keep the rest moving. If the tool can scope the pause, continue for unaffected groups; their fixes are still due.
6. Roll forward. Run the fixed or out-of-band release through the rings from ring 0 (it is cumulative^[7]). In September 2026 the out-of-band fix was itself one of the updates behind that month’s Credential Guard sign-in issue^[41].
7. Close. Remove mitigations on a date, close exceptions, add an RDS host and its sign-in probe to ring 0, and record time to halt.

• “Test every patch in a lab for two weeks first.” Labs rarely match production and delay extends exposure (FAQ).
• “Exceptions are permanent.” NIST’s answer is a maintenance group of their own, with planned mitigations^[1].
• “Change freeze means patch freeze.” Keep an emergency lane open, with named approvers.

Run a formal practice with more than a few dozen assets, several operating systems or owners, audit duties, strict uptime, or a history of patch-caused outages.

Keep it light, or move the work, when most of the estate is SaaS (patching transferred to the provider^[1]); when hosts and containers are rebuilt from images, so patching lives in the pipeline and this practice only sets deadlines and verifies; or when the estate is small enough that unattended updates and a weekly check meet the deadlines (deep comparisons).

Do not create a “PatchOps team” just to hold the label if endpoint and platform teams can own their rings with a shared calendar and one report, and do not force a monthly routine on assets that cannot take it (OT, certified medical devices).

For each asset class, decide the delivery mechanism before the next advisory arrives.

flowchart TB
  Q1{"Fix exists?"}:::decision -->|"no"| A2["Emergency mitigation, re-check"]:::risk
  Q1 -->|"yes"| Q2{"Built from an image?"}:::decision
  Q2 -->|"yes"| A1["Rebuild and redeploy"]:::core
  Q2 -->|"no"| Q3{"Restart in window?"}:::decision
  Q3 -->|"yes"| A3["Patch in place through rings"]:::core
  Q3 -->|"no"| Q4{"Live patch?"}:::decision
  Q4 -->|"yes"| A4["Live patch now, restart later"]:::core
  Q4 -->|"no"| Q5{"Workload can move?"}:::decision
  Q5 -->|"yes"| A5["Drain, patch, return"]:::core
  Q5 -->|"no"| A6["Unpatchable plan: isolate, replace"]:::risk
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029

Assumptions: a “fix” is a patch or a fixed image; “built from an image” means an automated, tested rebuild; “restart in window” includes verifying health afterwards.

This is this Atlas’s model, not an industry standard.

Quick start (one maintenance group, one cycle)

• Inventory reconciled with agent check-ins; unreporting assets listed with owners
• Vendor cadences and emergency lanes written down
• Ring 0 holds at least one asset per role, build and configuration, with functional probes
• Deadlines, grace periods and windows set; reboot behaviour tested on ring 0
• Report counts only active fixes against the whole group

Monthly cycle preflight (release day)

• Release notes and known issues read; applicability confirmed
• Tested set frozen; ring calendar sent to owners and the service desk
• Ring captain, backup and halt authority named
• Rollback or mitigation path known for each major role

Quarterly governance audit

• Every asset in a maintenance group; no “miscellaneous” group
• No exception past expiry; each has an owner and compensating control
• Ring membership still representative; patch-system access reviewed
• End-of-support dates for the next 18 months listed with plans

Maintenance plan record (one per maintenance group; this Atlas’s template)

MAINTENANCE PLAN  group: linux-servers-prod          owner: platform-team
Assets: ~420 Ubuntu 24.04 / RHEL 9 VMs (tag PatchGroup=linux-servers-prod)
Business limits: restarts Tue-Thu 01:00-05:00 UTC; no restarts in the
  quarter-end freeze except via the emergency route
Routine:   rings ring0 (8) -> ring1 (40) -> ring2 (180) -> ring3 (192)
           start release+2d; deadline 14d; tested set frozen per cycle
Emergency: canary 2h; all rings within 3d; emergency change route
Mitigation: web application firewall (WAF) rules; service disable runbooks;
  isolation VLAN
Unpatchable members: none (move any to group legacy-isolated)
Verification: effective = installed + restarted; weekly authenticated scan
Review: quarterly; last reviewed 2026-10-01 by <name>

Exception record

EXCEPTION  id: PX-2026-031      group: critical      asset: crit-03
Fix not applied: October 2026 cumulative update
Reason: vendor-certified application not yet validated on this build
Compensating control: inbound restricted to app subnet; endpoint detection
  and response (EDR) agent in block mode
Risk owner: <name>     approved: 2026-10-14     expires: 2026-11-20
Exit plan: vendor certification due 2026-11-10; patch in next window
Review: weekly status to PatchOps lead; auto-escalate on expiry

Emergency patch change (one page)

EMERGENCY PATCH  change: CHG-<id>        due (from VulnerabilityOps): <date>
Item: <advisory or KB>   scope: <groups, asset count>   exposure: <public?>
Plan: canary <assets> for <hours>; then rings <list> by <times>
Restart impact: <services, failover steps>
Fallback: <mitigation if patch fails>; <rollback or restore path>
Verification: <scan or version check>; evidence to <ticket>
Approvers: <change authority>, <service owner>    halt authority: <name>

Supplier patch-support questions (adapted from the questionnaire in NIST SP 800-40 Rev. 4, section 3.7^[1])

1. Will you release security updates for this product, and for how many years?
2. How many updates per year do you expect, how fast do you fix a vulnerability,
   and how often do you release emergency updates?
3. Do you release on a schedule (weekly, monthly, quarterly), as needed, or both?
4. Do you run a vulnerability disclosure and incident response programme?
5. When no patch exists yet, what mitigation do you recommend?
6. What does an update disrupt: a service restart, a reboot, downtime?
7. How do you test updates, how often do customers hit problems, and can an
   update be rolled back?
8. Which update channels (agent, content, firmware) can customers stage in rings?

NIST’s eight questions are condensed into questions 1–7 (its questions 1 and 3 become question 1 here); question 8 is this Atlas’s addition, prompted by the July 2024 content-update incident^[43].

Monthly report (one page per cycle; values illustrative)

CYCLE 2026-10   release 2026-10-13   report date 2026-10-30
Group          in-scope  on-time active  days to active  restart>3d  unreporting
                                         (median)
workstations       4,100          91 %             3.5          55          120
linux-servers        420          88 %             6.5           4            9
critical             140          81 %            12.0           0            0
Exceptions: 14 open, 1 past expiry (escalated)   Patch-caused incidents: 1
Gate halts: 1 (ring1, RDS sign-in probe; resumed with OOB release)

Alternatives to in-place patching; neighbours are compared earlier.

Should we test every patch before deploying it? Test on real assets first. NIST calls phased deployment to canaries the way patching “gets tested”^[1]. A lab helps for high-risk systems but should not delay the canary ring.

How long should each ring soak? Long enough for probes and users to surface problems, short enough for the risk deadline. Autopatch group defaults promote within days^[15]; NIST’s example rounds take days, then weeks^[1]. Measure which ring catches problems, then tune.

“We redeploy containers, so we do not patch.” Right? Rebuilding is patching: it needs a cadence, a deadline and proof that the running workload uses the new image. The build practice belongs to ContainerOps and ServerlessOps.

What about servers that can never reboot? Use live patching, move the workload to a partner node, or give it an unpatchable-asset plan with isolation and a replacement date. A server that cannot restart cannot recover from a crash either.

Is WSUS dead? Deprecated, not removed: as of October 2026, Microsoft’s 2024 statement stands (no new features, continued updates, no current plan to remove it from in-market Windows Server, including 2025)^[9].

• Boot-chain and firmware updates are routine work now. Microsoft’s 2011 Secure Boot certificates carry 2026 expiry dates: 24 June for the Key Enrollment Key (KEK) certificate authority (CA), which signs updates to the boot databases; 27 June for the third-party UEFI CA; 19 October for the Windows Production PCA, the CA that signs the Windows boot loader. Devices without the 2023 certificates “will continue to start and operate normally” but can no longer receive new early-boot protections; most get the new certificates automatically, and many OEMs provide firmware updates when needed^[44]. Run it as a firmware programme with its own rings.
• End-of-support waves. Windows 10 reached end of support on 14 October 2025^[45], CentOS Linux 7 on 30 June 2024^[46]; Ubuntu 22.04’s standard security maintenance ends in May 2027^[30]. Each wave needs an upgrade, paid extended support or an unpatchable-asset plan.
• Component-level inventory. NIST notes that suppliers’ software bills of materials (SBOMs) can augment inventories^[1].

• Decide in advance: maintenance groups, a plan per scenario, ring membership, deadlines, windows, and who may halt.
• Practices: representative canaries with functional probes; frozen tested sets; restarts in windows; forced installs; expiring exceptions.
• Metrics: on-time effective coverage over the whole inventory; time to effective patch; unreporting rate; restart age; patch-caused incidents; emergency lead time.
• Watch-outs: tool reboot defaults, upgrade classifications, update channels outside your rings, dashboards that drop silent assets.
• Next actions: reconcile inventory; build ring 0 properly; publish one honest report.

Situation (illustrative). A hospital group runs 9,000 Windows devices and 600 servers. Since a bad update broke a clinical application two years ago, every monthly update waits for a 14-day lab test and change-board approval; median time to effective patch is 31 days. The CISO wants automatic approval with rings measured in days.

Option A: keep manual approval and lab testing. Trusted by the clinical lead. But the lab has never had the clinical application’s newest version, the 14 days add exposure to every fix, and the board approves almost everything anyway.

Option B: automatic approval with short rings. Matches vendor guidance^[16] and fits NIST’s phased model, although NIST’s example rounds run days, then weeks^[1]: short rings are a choice, not NIST’s prescription. But ring 0 has no clinical workstation, so the next regression would reach wards by day 2.

Decision. Assumptions: the application runs on about 1,200 devices; its vendor certifies monthly updates within 10 days; one ward can tolerate half a day of disruption. Choose B for everything except a “clinical” maintenance group, which gets its own rings (IT clinical test devices, then one volunteer ward, then the rest) and a deadline tied to the vendor’s certification.

Why the attractive choice can be wrong. A feels safe because patching harm is visible and self-inflicted, while delay harm stays invisible until an incident; yet, as NIST notes, patching disruptions are “largely controllable” and incident disruptions “largely uncontrollable”^[1]. Uncertainty: if the vendor certifies slowly, the problem becomes supplier management.

After this page you can explain where the label fits, design maintenance groups, rings and gates, operate a cycle with an emergency lane, measure effective coverage honestly, and decide when to patch in place, rebuild, live-patch or isolate.

PatchOps is a new name for an old, unglamorous job: getting other people’s fixes onto your systems without breaking them. The label adds nothing the standards lack; the practice decides whether known flaws stay open for days or months. Done well, it is decided in advance, and each month is execution. If you remember one thing: a patch counts when it is active on an asset you can see, not when a console says it was sent.

Further reading: NIST SP 1800-31, Improving Enterprise Patching for General IT Systems (NCCoE, April 2022), the technology companion to SP 800-40. Evidence ledger: research/patchops-ledger.md.

Changelog: 2026-10-16, revision 0 — first complete draft. 2026-10-17, revision 1 — answered review r1 (3 major, 20 minor); four sources added. 2026-10-17, revision 2 — answered review r2 (1 major, 8 minor) and the first score’s S2–S4; one source added. 2026-10-17, post-score polish: date-proof Secure Boot wording, shorter figure 4, use-case trade-offs, dated name search, trims to the length band.