Managing Superseded Patches in Hexnode UEM

TL;DR: A superseded update is a patch that has been replaced by a newer release — typically a newer cumulative update — that contains all of its fixes. Hexnode UEM tracks supersedence at the KB/version level: when a newer update supersedes a patch, the superseded patch remains listed in the Missing Patches list. Admins should add the latest update to Automation; once deployed, installing the superseding update satisfies the compliance requirement of every patch it replaces. Supersedence in this page refers to update replacement, not policy precedence.

This page covers how supersedence affects patch visibility, approval workflows, deployment, compliance evaluation, and rollback. For how patch binaries are sourced and validated, see The Hexnode patch catalog; for how they reach devices, see Patch delivery architecture.

What is update supersedence?

When Microsoft ships the March cumulative update for Windows, it contains every fix from the January and February cumulative updates. January and February are now superseded: installing them on a device that can receive March is wasted bandwidth at best, and at worst installs a patch with known, already-fixed vulnerabilities. Application vendors follow the same pattern — version 2.4.1 supersedes 2.4.0.

For an admin, supersedence answers one operational question: which patches still matter? A patch list that doesn’t account for supersedence shows every missing update ever published; a supersedence-aware list shows only the updates that a device actually needs now.

How Hexnode surfaces supersedence

In the Missing Available Patches view (Patches > [Platform] > OS Patches / Third Party Patches > Missing Patches), superseded patches remain listed without a supersedence marker. Replaced patches continue to appear alongside current updates in the missing patches list. Admins should manually select or target the latest cumulative update in patch automation (Automate > New Automation > Patches and Updates).

Where the supersedence data comes from: Supersedence relationships are registered in Hexnode’s patch catalog during catalog syncs:

• Microsoft Windows OS updates: Metadata is ingested directly from Microsoft update feeds (WSUS/CAB definitions) which define KB-level replacement chains.
• macOS & Linux OS updates: Metadata is ingested from native Apple SUCatalog feeds and official Linux distribution manifests based on build and version lineage.
• Third-party applications: Metadata is established via version lineage definitions created by Hexnode’s catalog team during application packaging and validation.

Supersedence and approval workflows

Pending approval requests do not auto-expire when a patch is superseded; they remain in the approval queue governed by the Require update approval setting in your patch automation policy (Automate > New Automation > Patches and Updates). During an approved update deployment, Hexnode scans the device’s patch status; if a newer patch supersedes the approved one, it identifies and lists that newest release as the target update.

Supersedence and rollback

Two distinct rollback questions intersect with supersedence:

Rolling back a superseding update: If the March cumulative update causes a problem and is rolled back (where the platform supports uninstall), the device regresses to needing the fixes March contained. On the next scheduled or manual device scan, Hexnode re-evaluates applicability from the device’s actual current state and re-lists all previously superseded patches that the device currently requires.

Deploying an older, superseded patch or application deliberately:

• Superseded Patch in Catalog: Admins can explicitly deploy a superseded patch by manually selecting it within an automation profile under Automate > New Automation > Patches and Updates via Manual Patch Deployment.
• Older Application Version (App Downgrade): Auto Patch only targets the latest release. To deploy a specific older version of an application not available in Auto Patch, upload the installer file as an Enterprise App under the Apps tab and distribute it using a Required Apps policy or Install Application remote action.

What Hexnode does NOT do

• Hexnode does not deploy a superseded patch to a device eligible for its replacement as part of automatic patch policies — automatic deployment always targets the latest applicable update in a supersedence chain.
• Hexnode does not flag devices non-compliant for superseded patches their installed updates already cover.
• Supersedence evaluation is performed against Hexnode’s catalog metadata, not by querying the Windows Update client at scan time (consistent with the agent-native model in Patch delivery architecture).

Troubleshooting

Patch counts dropped sharply after a catalog sync.

Expected after a new cumulative update enters the catalog: it supersedes prior updates, and applicable-patch counts contract accordingly. Verify by checking whether the new cumulative appears in Available Patches.

Two updates for the same product both show as applicable.

Either the updates address disjoint components (no supersedence relationship exists), or the supersedence registration hasn’t propagated yet. Supersedence data refreshes with each catalog sync.

A device keeps showing an old patch as missing even though newer updates are installed.

Run a fresh scan first — stale scan data is the usual cause. If the state persists after a scan, the installed update may not actually supersede the listed patch (partial-component updates), or the device may be ineligible for the superseding update (OS edition/build constraints), leaving the older patch genuinely required.

Related documentation

• Patch delivery architecture
• The Hexnode patch catalog: curation and validation pipeline
• Resolve conflicting compliance policies
• Auto patch deployment (macOS, Windows)
• Manual patch deployment (macOS, Windows)