# 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 any vulnerability with a “High” CVSS 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 deploy 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](https://www.hexnode.com/mobile-device-management/help/dynamic-device-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](https://www.hexnode.com/mobile-device-management/help/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. [![Screenshot of Hexnode console showing the policy target association page.](https://cdn.hexnode.com/mobile-device-management/help/wp-content/uploads/2026/01/Target-Association-page.png)](https://cdn.hexnode.com/mobile-device-management/help/wp-content/uploads/2026/01/Target-Association-page.png "Target Association oage") 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 - **Enforce Reboot Notifications**: Never force a restart without warning. Always enable a 15-minute notification window within your Hexnode policy to allow users to save active work. - **Implement Update Deferrals**: For the Production Fleet, implement a 7-day deferral. This provides a safety net in case a vendor (Microsoft/Apple) “pulls” a buggy update shortly after release. - **Audit “Ghost Failures”**: Regularly audit the **Patch compliance** report. If a patch reports success in Hexnode but the device remains vulnerable, it usually indicates a corrupted local update cache that requires a manual reset via script. - **Prioritize DDM for macOS**: Whenever possible, use Declarative Device Management (DDM) over standard MDM commands. DDM is more autonomous and handles enforcement deadlines more reliably on modern macOS versions. ### 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. ### **Pro-Tip: Emergency Rollback Logic** When a validated patch causes unforeseen issues in the production fleet, speed is critical. Use **Hexnode Genie (AI)** to quickly generate a removal script. For Windows, navigate to **Manage > Devices > Actions > Execute Custom Script** and deploy: Patch rollback script wusa /uninstall /kb:500XXXX /quiet /norestart 1 wusa /uninstall /kb:500XXXX /quiet /norestart Monitor the **Action History** in the Hexnode portal to verify the rollback status in real-time.