Implementing a Global Hardware Refresh and Decommissioning Workflow

1. Document Overview

In an enterprise of 500,000 devices, hardware lifecycle management is a multi-billion dollar logistics challenge. Outdated hardware increases Digital Experience (DEX) friction and introduces security vulnerabilities from aging firmware. This document defines the administrative workflow for the Global Hardware Refresh & Decommissioning loop.

By utilizing Custom Attributes to store external telemetry and Dynamic Device Groups to automate lifecycle stages, the organization ensures a circular hardware economy. The workflow concludes with absolute data sanitization and hardware securing via Hexnode’s native Wipe Device, Lock Device, and Firmware Security remote actions.

2. The Data Core: Ingesting Third-Party Values

Hexnode acts as the central orchestrator, bridging external intelligence with native MDM controls using Custom Attributes.

We populate Hexnode’s Custom Attributes with data from external streams:

1. DEX Telemetry (e.g., Nexthink / Lakeside): Performance scores are extracted from third-party tools and mapped to the custom-created Hexnode %dex_score% attribute via CSV imports.
2. Procurement & Leasing (e.g., ServiceNow): “Purchase Dates” and lease statuses are imported via CSV uploads to custom-created %purchase_date% or %lease_status% attributes.
3. Logistics Partners (ITAD): Return-shipment tracking IDs are synced into the %itad_tracking% attribute.

3. The Logic Engine: Dynamic Device Groups

The transition from an “Active” device to a “Retired” one is governed by Dynamic Device Groups. As Custom Attributes are updated via CSV uploads, device membership evaluates accordingly.

Automated Membership Criteria

We define the Refresh Required Dynamic Group using the following logical comparators:

• Condition A: Custom Attribute: DEX_Score Less Than 6.0
• Condition B: Custom Attribute: Lease_Status Equal To Expired

Result: When the CSV upload updates the DEX_Score to 5.5, Hexnode immediately moves the device into the “Refresh Required” group, applying restrictive transitional policies without manual IT intervention.

4. The 4-Phase Transition Workflow

Phase 1: Eligibility (SENSE)

Hexnode identifies EOL devices through Dynamic Group criteria. Once a device enters the group, IT administrators can utilize scheduled reports or dashboard monitoring to notify the regional logistics hub. The logistics team then registers the new replacement device for Zero-Touch Provisioning (e.g., Apple Business Manager, Windows Autopilot) and ships the physical hardware to the user.

Phase 2: User Migration (THINK)

To ensure zero downtime, the user is granted a 5-day window to operate their old and new hardware side-by-side.

• Soft Lockdown (Transitional Policy): When the legacy device enters the “Refresh Required” Dynamic Group, Hexnode automatically applies a transitional Policy utilizing native Restrictions and Media Management configurations to mandate the transition:
  • Media Management: Hexnode blocks write access to external storage (USB drives, SD cards, etc.) across macOS and Windows, preventing data exfiltration.
  • OS Restrictions: Hexnode disables new app installations (e.g., blocking the App Store, Microsoft Store, and Google Play Store) using restriction policies across Windows, macOS, iOS, and Android to prevent the creation of new local data on the aging asset.

Phase 3: Remote Decommissioning (ACT)

Once the new device is confirmed as “Operational,” the legacy device undergoes a strict, native Hexnode terminal sequence:

• Immediate Securing (Lock Device): To immediately halt access, Hexnode triggers the native Lock Device remote action. This instantly locks the screen and suspends the active session across supported OS platforms.
• Firmware Security: To prevent unauthorized OS installations or booting from external media before physical recovery:
  • macOS: Hexnode executes the Set Firmware/Recovery Lock Password remote action. This natively secures both Intel Macs (Firmware Password) and Apple Silicon Macs (Recovery Lock). IT can continuously audit this state via the Verify Firmware Password remote action.
  • Windows: Hexnode deploys OEM-specific custom scripts (e.g., via PowerShell) as a remote action to randomize UEFI passwords and disable USB boot.
• Cryptographic Erasure (Wipe Device): Hexnode triggers the native Wipe Device remote action. This executes an OS-level factory reset, destroying encryption keys and rendering the storage permanently unrecoverable.

Phase 4: Verification (VERIFY)

• Compliance Log: Hexnode’s Action History logs a successful “Wipe Device” execution.
• Firmware Clearing (macOS): Upon receipt at the IT Asset Disposition (ITAD) facility, Hexnode executes the Clear Firmware/Recovery Lock Password remote action, allowing the ITAD partner to securely refurbish the Apple device. (Equivalent script reversals are triggered for Windows).
• Asset Retirement: The device is archived, and the final “Certificate of Sanitization” is generated for the audit trail.

5. Implementation Checklist

• Map Data Imports: Ensure third-party DEX and Purchase Date data is formatted correctly for Hexnode Custom Attribute CSV uploads.
• Define Dynamic Logic: Configure the Dynamic Group criteria for “Refresh Eligibility.”
• Configure OS-Specific Firmware Security: Prepare the custom Windows BIOS scripts and document the macOS Set Firmware/Recovery Lock Password remote action for the ACT phase.
• Automate the Wipe Sequence: Sequence the Lock Device and Wipe Device remote actions to trigger once the new asset registers in Hexnode.
• ITAD Integration: Document the procedure for the ITAD facility to request the Clear Firmware Lock action (or Windows equivalent) upon physical receipt of the hardware.