Manual vs. Automated Patching: Building a Risk-Based Architecture

Effective patch management is the cornerstone of endpoint security. Think of patching your fleet of devices like maintaining a large fleet of delivery vans. Automated Patching is like a self-updating GPS—it happens in the background to keep things running smoothly without you lifting a finger. Manual Patching is like a major engine overhaul; you want to test it on one van first to make sure it doesn’t break down in the middle of a delivery.
This guide outlines a strategic framework for balancing Automated Patching (for speed) and Manual Patching (for stability), ensuring your fleet remains resilient without compromising operational uptime.

Overview

Patch management in Hexnode UEM allows IT administrators to orchestrate software updates across Windows and macOS devices. By adopting a risk-based architecture, organizations can automate high-frequency security updates while retaining manual oversight for mission-critical system changes. This hybrid approach minimizes the “vulnerability window” while preventing “update-induced downtime.”

Prerequisites

• Hexnode Pricing Plan: Enterprise or higher (for advanced Automation features).
• Permissions: Admin access to the Automate and Policies tabs.
• OS Support:
  • Windows 10/11 (Pro, Enterprise, or Education).
  • macOS 10.13+ (Declarative Device Management requires macOS 13.0+).
• Network: Devices must have access to *.hexnode.com and vendor update servers (Microsoft/Apple).

Strategic Decision Logic

Choosing between manual and automated workflows depends on the Risk Profile of the update and the potential impact on business continuity.

Automated Patching (The “Fast-Track” Model)

Automated patching is designed for high-velocity environments where the objective is to shrink the Mean Time To Remediate (MTTR). By removing human intervention from the approval chain, you eliminate the delay between a vulnerability announcement and its fix.

• CVE-Based Triggers: Hexnode can automatically deploy patches based on Common Vulnerabilities and Exposures (CVE) severity. For instance, any patch with a “Critical” rating can be set to deploy within hours of release.
• Third-Party App Management: Automation is mandatory for “leaky” apps like Chrome, Zoom, or Slack. Hexnode’s repository handles packaging and silent installation, ensuring users stay secure without manual intervention.
• Remote/BYOD Workers: Automation ensures off-network devices stay compliant with the security baseline without waiting for an admin to manually push updates.

Manual Patching (The “Validation” Model)

Manual patching is a governance-heavy approach used when the Cost of Downtime exceeds the risk of an unpatched vulnerability. It introduces a “Human-in-the-loop” phase to verify stability.

• Major OS Upgrades: (e.g., Windows 10 to 11). Requires extensive User Acceptance Testing (UAT) to ensure hardware compatibility and application performance.
• Drivers & Firmware: BIOS/UEFI updates can “brick” devices. These must be manually approved after testing on a pilot group to avoid catastrophic hardware failure.
• Legacy Environments: If your organization relies on legacy ERP or custom-built internal apps, manual validation ensures the update doesn’t deprecate a library or framework the app requires.

The “Three-Ring” Deployment Strategy

A phased rollout is the most effective way to balance speed and safety. Hexnode utilizes Dynamic Groups to automate the movement of devices through these rings based on their department or device tag.

Ring 0: The Canary Group (5% of Fleet)

This group consists of IT staff and tech-savvy volunteers.

• Logic: Patches are Automated immediately upon release.
• Goal: To identify immediate “showstopper” bugs (e.g., Blue Screen of Death or network loss) within the first 24–48 hours before the wider organization is affected.

Ring 1: The Pilot Group (15% of Fleet)

This group includes a cross-section of users from different departments (Finance, HR, Sales).

• Logic: Patches are deployed manually only after Ring 0 reports no critical failures.
• Goal: To ensure that department-specific software (e.g., specialized accounting tools or CRM plugins) functions correctly with the new update.

Ring 2:The Production Fleet (80% of Fleet)

The remainder of the organization.

• Logic: Patches are Automated with a Deferral Period (e.g., 7 days after the initial patch release).
• Goal: Full-scale deployment once the patch has been “vetted” by Rings 0 and 1, ensuring maximum security with minimal support tickets.

Conflict Resolution & Policy Precedence

In a complex UEM environment, multiple policies may target the same device. Hexnode uses a strict hierarchy to ensure device stability and respect organizational guardrails.

The Maintenance Window Guardrail

If an Automation is triggered to install a patch during business hours, but a Policy defines a Maintenance Window for late-night hours, Hexnode will prioritize the Maintenance Window.

• Queuing Logic: The update is queued on the device. The Hexnode Agent will wait until the system clock enters the permitted window before initiating the download and install process.
• Reboot Hygiene: If a patch requires a restart, Hexnode follows the Reboot Settings defined in the Policy. If “Force Reboot” is disabled, the device will wait for the user to manually restart, or for the next scheduled maintenance window.

Policy Conflict Resolution

When multiple policies target a single device:

• Restrictive Overrides: Generally, the most restrictive policy regarding “Update Deferrals” takes precedence to prevent accidental early deployments of unvetted patches.
• DDM (macOS): For macOS 13+, Declarative Device Management allows you to set a hard Enforcement Deadline. Even if a user ignores notifications, the DDM protocol will override local “Do Not Disturb” settings to ensure the update occurs by the deadline.

Associate with Entities

To apply your patching architecture to your organization:

1. Navigate to your defined Automation or Policy.
2. Go to the Targets tab.
3. Click Add Targets and select the appropriate Device Groups, Users, or Dynamic Groups representing your deployment rings.
4. For remote workers, utilize Dynamic Groups with criteria such as Device Status = Compliant to ensure only healthy devices are targeted for automated flows.

Troubleshooting & Best Practices

Operational Best Practices

Common Troubleshooting Steps

• Patch Stuck at “Pending”: This often occurs if the device is outside its Maintenance Window or has insufficient disk space. Check the Action History for specific error codes like 0x80244017 (Proxy issues) or OS_UPDATE_NOT_ALLOWED.
• Verification Mismatch: If Hexnode shows a patch as missing but the user claims they updated, use the Scan Device action to force an immediate sync of the device’s software inventory.
• Handling Update Conflicts: If a device is part of multiple groups with conflicting patch schedules, Hexnode resolves this by applying the policy with the highest Priority value. You can adjust this under Policies > Policy Priority.