Patch Management

The Patch Management page is the Console's view of the fleet-wide patching pipeline. It answers two questions: which patches are approved to install anywhere in the estate? and what is my compliance posture against the patches that exist?. It deliberately does not answer "when does a specific policy's devices actually reboot?" — that configuration lives inside a policy.

7.1 Scope — this page versus the policy editor

Patch Management in NetLock RMM is split across two places on purpose:

• The Patch Management page at /patch-management — the subject of this chapter — is global. It shows every patch the system knows about, holds the approval state for each, tracks compliance against SLA thresholds, displays known vulnerabilities, and configures deployment-wide patch defaults. It is a queue and an observatory, not a scheduler.
• The Policy Settings → Patch Management tab — documented in Chapter 6.12 — is per-policy. It decides when and how the devices assigned to a given policy actually install the patches that have been approved on this page. That is where the per-platform rollout rules, deployment rings, maintenance windows, reboot behaviour, notifications, and retry configuration live.

Both chapters cross-link. Do not expect to find rollout scheduling or reboot controls on the page covered here.

7.2 The four tabs

Patch Management is a single page with four tabs across the top:

Actions in this chapter all happen inline — there are no standalone dialog windows on this page. Row menus and toolbar buttons take you through the workflows directly.

7.3 The approval workflow

Every patch in the Update Approval tab is in one of four states:

• Pending — newly discovered; no admin decision yet.
• Approved — eligible for installation anywhere the policy-level rules allow it.
• Rejected — explicitly blocked fleet-wide; no device will install it.
• Deferred — postponed. The default defer period is 7 days; after the timer expires the patch returns to Pending.

From the table toolbar you can act on one or many selected rows. Available actions:

• Approve — set state to Approved.
• Reject — set state to Rejected. A confirmation is shown ("Are you sure?") because rejection is a fleet-wide block.
• Defer — postpone for N days (default 7).
• Reset to Pending — revert from any other state.

Every state change triggers an immediate re-sync of every device. Devices do not wait for their next scheduled poll — the updated approval set lands on every agent as soon as the server can deliver it.

Important: Approval on this page is global. There is no per-device, per-group, per-location, or per-tenant approval on the Patch Management page. Narrowing a patch's rollout to a subset of the fleet is done with the Approval & Filtering and Deployment Rings sub-tabs inside a policy (see Chapter 6.12).

7.4 The compliance model

Each row in the Update Approval tab carries three compliance indicators in addition to its approval state:

• Installed — count of devices that already have the patch installed.
• Pending — count of devices where the patch is available but not yet installed.
• SLA Status — one of Compliant, At Risk, Overdue.

SLA status is computed per row based on the patch's severity and how long it has been known. The threshold for each severity is the number of days after first discovery within which a device is expected to have installed the patch:

SLA state transitions:

• Compliant — within SLA. The deadline has not passed.
• At Risk — three days or fewer to the deadline.
• Overdue — the deadline has passed on at least one device.

Change the thresholds on the Settings tab if your environment operates to a different cadence.

7.5 The Vulnerabilities tab (cooming soon)

The Vulnerabilities tab shows known CVEs that affect devices in your fleet. Data comes from two sources:

• The National Vulnerability Database (NVD) — the authoritative public feed of CVE records.
• The Console's own device inventory, which pairs each device's installed software with the CVE records that reference those products.

The tab is a cross-reference of the two: rows represent CVEs affecting devices you manage, with counts of how many devices are exposed and links through to those devices.

NVD data is refreshed on an interval controlled by the nvd_auto_download_enabled flag on the Settings tab. When the toggle is on, the server downloads NVD feeds automatically; when it is off, the existing data is still available but is not refreshed until you turn the toggle back on.

7.6 The Settings tab

The Settings tab holds the page's configuration knobs. These are deployment-wide — they affect the whole Patch Management page, not a particular policy.

Changes to SLA thresholds apply immediately; the next render of the Update Approval tab uses the new values to compute SLA status.

7.7 Platforms and sources

The Update Approval tab filters by platform and by source. The platform dropdown supports:

• Windows
• Linux
• MacOS
• Docker

The source dropdown supports:

Approval is per patch regardless of source. An Approved patch from Winget installs under the same rules as an Approved patch from OS-Mandatory — the per-policy Approval & Filtering sub-tab is where you gate which sources a particular policy's devices accept.

7.8 What is not on this page

Several controls that admins from other RMMs look for on a "patch management" page live elsewhere in NetLock RMM. Knowing where to find them saves time.

• Per-device or per-group exclusion lists. Not here. A patch is Rejected fleet-wide or not at all. If you need to exclude a subset, use the Approval & Filtering sub-tab inside the relevant policy (Chapter 6.12) — or split those devices into a different policy with stricter filters.
• Rollout scheduling — maintenance windows, allowed days, time ranges. Not here. Configure them on the Schedule sub-tab inside a policy's Patch Management tab.
• Deployment rings. Not here. Configure them on the Deployment Rings sub-tab inside a policy's Patch Management tab.
• Reboot behaviour and user prompts. Not here. Configure them on the Reboot sub-tab inside a policy's Patch Management tab.
• Retry on failure. Not here. Configure it on the Retry sub-tab inside a policy's Patch Management tab.
• Notifications. Not configured here. Per-event patch notifications are toggled on the Notifications sub-tab inside a policy's Patch Management tab; the channels and recipients those notifications are sent through live in A.8 Notifications deep dive.

The split is deliberate: one global decision ("may this patch install anywhere?") and many per-policy decisions ("how do these particular devices install the things that are allowed?").

Permissions

Patch Management is gated by a single permission flag in the current release:

• patch_management_enabled — master flag. Users without this flag do not see the Patch Management navigation entry and cannot reach /patch-management.

There is no finer-grained approve / reject / defer / view-only permission. A user who has the flag can perform every action on the page.

Related chapters

• Chapter 6 — Policies — the per-policy Patch Management tab, where rollout rules live.
• Chapter 6.12 — direct link to the per-policy Patch Management sub-tab reference.
• Chapter 12 — Events & Audit — event records for patch installs and approval changes.
• A.8 Notifications deep dive — channels and recipients for patch notifications.
• A.2 Updates & maintenance — Console and server update cadence, distinct from endpoint patching.