Implementing N+1 Redundancy for MDM Infrastructure: The Hexnode Protocol

Executive Summary

In Unified Endpoint Management (UEM), the foundational trust between the Hexnode UEM server and the device ecosystems (Apple and Google) relies entirely on cryptographic certificates and binding tokens. The most critical of these are the Apple Push Notification service (APNs) certificate and the Android Enterprise (AE) binding token.

If APNs expires, or if either connection is broken due to lost credentials from IT staff turnover, the UEM server loses its communication channel. For a fleet of 5,000+ devices, this results in a catastrophic “bricked” management state—devices will not receive new policies, cannot be remotely wiped, and will require manual factory resets to regain control.

This document outlines the “N+1” Redundancy Protocol: a strategic framework enforcing dedicated service accounts, hardware-backed MFA, and a strict lifecycle management protocol to guarantee zero downtime.

The Anatomy of a “Bricked” Fleet

A “bricked” fleet in the context of UEM means the management tether is permanently severed. This is rarely a software bug; it is almost always an operational failure caused by one of two scenarios:

1. Certificate Decay (Apple): Allowing a certificate like APNs, which is valid for exactly 365 days, to expire. This immediately halts all UEM commands to the affected ecosystem.
2. Credential Loss (The “Bus Factor”): An IT administrator binds Hexnode UEM to Apple or Google using their personal corporate email (e.g., john.doe@company.com). When that administrator leaves, their account is deactivated. The new IT team, unable to access the original account, generates a new certificate instead of renewing the existing one (for Apple), or loses administrative control over the enterprise bind (for Google). The devices reject the mismatch, permanently breaking the connection.

The “N+1” philosophy dictates that no single human identity should be the single point of failure (N=1) for infrastructure communication.

Apple Push Notification Service (APNs) Lifecycle

The APNs certificate is the lifeline for Apple device management. Hexnode UEM uses it to securely wake up iOS, iPadOS, macOS, visionOS and tvOS devices to receive commands.

The “Topic Mismatch” Fatal Flaw

You must renew the APNs certificate using the exact same Apple Account used to initially create it. If you upload an APNs certificate generated from a different Apple Account, Hexnode UEM will flag a Topic Mismatch error. If forced, all currently enrolled Apple devices will immediately become unmanageable.

APNs “N+1” Redundancy Strategy

• Never use an individual’s email address. Create a dedicated corporate alias (e.g., apple-uem-admin@company.com) tied to a shared distribution list or a Microsoft 365/Google Workspace Shared Mailbox.
• This ensures multiple IT administrators receive Apple’s automated expiration warnings, which are sent 30, 10, and 1 day(s) prior to expiration.

Android Enterprise (AE) Binding and Redundancy

Android Enterprise relies on a binding token between your organization’s Google infrastructure and Hexnode UEM. Unlike APNs, Android Enterprise bindings do not expire after a set time; they remain active indefinitely unless explicitly disenrolled. There are two distinct methods for this integration, each requiring a different redundancy strategy.

Method 1: Managed Google Play Accounts (Managed Domain)

This is the recommended method for most organizations. It creates a dedicated enterprise bind without requiring your company to use Google Workspace for email or identity.

• The Risk: If the standard Google account used to bind the enterprise is lost or deleted, the bind cannot be recovered or transferred.
• The “N+1” Strategy: Create a dedicated, generic Google account (e.g., android-mgmt@company.com). Store these credentials in your Enterprise Password Manager (PAM). Do not use an IT Director’s personal Google account.

Method 2: Google Workspace (formerly G Suite)

This method integrates directly with your existing Google Workspace directory, allowing you to sync users and groups seamlessly.

• The Risk: This bind requires a Google Workspace Super Admin account. If the specific Super Admin who configured the bind has their account suspended, downgraded, or deleted upon leaving the company, the Android Enterprise integration breaks. Additionally, accidentally unbinding the account in Hexnode UEM triggers an immediate disenrollment command, wiping the Work Profile and enterprise data from all devices.
• The “N+1” Strategy: Do not use an employee’s Super Admin account. Provision a dedicated Service Account within Google Workspace with the necessary admin privileges specifically for UEM binding.

The 30-60-90 Day Protocol (Renewal vs. Audit)

To prevent APNs decay and handle IT turnover gracefully across all platforms, organizations must program a strict timeline into their IT Service Management (ITSM) tool (e.g., Jira, ServiceNow) as an automated, recurring ticket.

90 Days Out: Audit & Identify

• Trigger: Automated ITSM ticket generated 90 days before APNs expiration (or quarterly for AE).
• Action Items:
  • Log into the Hexnode UEM portal and navigate to Admin > APNs and Admin > Android Enterprise.
  • Identify the exact Apple Account and Google Account listed as the owners of the configurations.
  • Verify that the credentials for these accounts are active, accessible in the corporate Password Vault, and that Two-Factor Authentication (2FA/MFA) is routing to an accessible shared inbox or IT phone number.
• Goal: Confirm access across both platforms. Do not renew anything yet.

60 Days Out: Prep & Shadow (The Handover Phase)

• Trigger: ITSM ticket escalation.

  Action Items:

  • If there has been IT turnover, execute the “Handover Protocol.”
  • Update the recovery phone numbers and secondary emails on the Apple Account / Google account to reflect the current IT personnel.
  • Run a simulated login to the Apple Push Certificates Portal (identity.apple.com/pushcert) and Google Play Admin console to ensure no security lockouts or unexpected MFA prompts exist.
• Goal: Ensure the current team has absolute control over the binding accounts.

30 Days Out: Execution & Verification (APNs ONLY)

• Trigger: Final ITSM priority ticket. Apple sends the 30-day automated warning.
• Action Items (APNs):
  • Download the new Certificate Signing Request (CSR) from the Hexnode UEM portal.
  • Log into the Apple Push Certificates Portal using the exact verified Apple Account.
  • Locate the certificate nearing expiration and click Renew (Do NOT click “Create a Certificate”).
  • Upload the Hexnode UEM CSR, download the resulting .pem file, and upload it back to Hexnode UEM.
  • Send a test “Lock” or “Location Scan” command from Hexnode UEM to a test iOS device to verify the communication channel is active.
• Action Items (Android Enterprise):
  • No action required. Because AE bindings do not expire, do not attempt to “renew” or unbind the configuration in the Hexnode UEM portal. Simply verify that Android devices are still checking in successfully.

Critical Fail-Safes for IT Turnover

To fully insulate a large-scale deployment from human error during staff transitions, enforce the following technical fail-safes:

• Immutable Shared Inboxes: Accounts managing UEM infrastructure must be tied to a Shared Mailbox, not a forwarded alias to an individual.
• Hardware-Backed MFA: Bind the 2FA for these critical Apple/Google accounts to a physical FIDO2 security key (e.g., YubiKey) stored in a physical company safe. Avoid using SMS 2FA tied to a specific employee’s mobile device.
• The “Topic ID” Verification Check: Before pressing “Save” on an APNs upload in Hexnode UEM, visually verify that the Topic ID (e.g., com.apple.mgmt…) on the new certificate matches the old certificate exactly. If it differs, abort the upload immediately.