Hexnode – Architecture

Hexnode UEM is a cloud-based Unified Endpoint Management solution that can manage and secure devices from a single centralized web console. It allows users to securely manage both personal and corporate devices either via its unified web console or APIs. Using Hexnode, an IT manager can easily enroll devices over the air, impose settings/policies, manage apps, and check compliance with the enterprise’s standards.

Components of Hexnode UEM

Hexnode Cloud Server

The Mobile Device Management (MDM) software required for managing endpoints is hosted on the Hexnode cloud server. The server must be accessible via public IP address, as many users will be out of the office network.

Hexnode uses Amazon Web Services (AWS) to host its cloud servers for ensuring core security and compliance standards. It includes data encryption programs, DDoS mitigation techniques, and network management policies to protect your information, identities, applications, and devices. Hexnode’s data centers are strategically positioned among the most secure locations to ensure maximum protection from security attacks.

Hexnode cloud server uses:

1. Amazon Storage Service (Amazon S3) for storing and protecting any amount of data. This database stores both the device and the management data (policies/configurations). It leverages Amazon Lightsail and Amazon EC2 services for executing secure and flexible cloud computational operations.
2. Amazon CloudFront to deliver website/application content including static.hexnodemdm.com and downloads.hexnode.com.
3. Amazon Relational Database Service (Amazon RDS) to manage scalable CRUD operations in the cloud.

Admin Console

The admin console refers to the unified browser-based console used for managing and monitoring devices. Once a technician makes a configuration change from the console, the request will be sent to the Hexnode cloud and is then pushed from the Hexnode cloud to the relevant devices via the notification services (APNs, FCM, WNS, or MQTT).

Directory Services

Hexnode supports the connectivity with your organizations’ existing directory infrastructures such as Microsoft Active Directory, Microsoft Entra ID, Google Workspace, and Okta. An organization can connect to these directory services for federated authentication and user synchronization.

For authenticated enrollments, directory users are requested to authenticate themselves with their dedicated credentials. Upon successful authentication of the user, the directory service will provide an OAuth token to the Hexnode server for establishing the user’s authenticity. However, for on-prem directory services like Microsoft Active Directory, the Hexnode AD agent app is needed to establish communications between the directory service and the cloud server.

Firewall

Hexnode’s firewall establishes a secure barrier between the internal network of an enterprise and the internet. It controls the incoming and outgoing network traffic based on a predefined set of rules. In this way, it ensures strong network infrastructure security by blocking access to untrusted traffic.

Notification Services

Hexnode cloud sends notifications to the devices using the appropriate notification services to communicate with Hexnode UEM to check for commands or queries.

• Apple Push Notification Service (APNS) is a highly efficient service created by Apple to enable communication from a third-party service to Apple devices.
• Firebase Cloud Messaging (FCM), previously known as Google Cloud Messaging (GCM), is Google’s notification service used to send notifications to not only Android devices but iOS and Chrome web apps.
• Windows Push Notification Services (WNS), developed by Microsoft, allows communication between a third-party service and any Windows devices, including PCs, and Xbox consoles.
• MQTT is a standards-based messaging protocol used to send notifications to Windows, macOS, and Android devices.
• Pushy is used as a backup push notification provider for Android devices if FCM registration fails.

Data-Plane & Security Posture

Hexnode UEM enforces strict data segregation, encrypted transit, and secure data handling across all endpoint management workflows in alignment with Hexnode’s Cloud Infrastructure & Security standards.

• Data in transit: Device telemetry, policy configurations, status reports, scripts, and command payloads between endpoints and the Hexnode cloud are protected with TLS 1.2+ over HTTPS (port 443). Real-time signaling uses MQTT on outbound ports 1883 and 8883 (TLS on 8883 where enabled), with platform push services (APNs, FCM, WNS) for device wake-up/signaling over their own secure channels. No inbound management ports are required on endpoints, and raw remote-access channels such as inbound SSH (port 22) are neither required nor exposed for management.
• Data at rest: Device inventory attributes, policy configurations, and management metadata are stored in isolated Amazon RDS databases and Amazon S3 buckets. Persistent data is encrypted at rest using AES-256 with AWS-managed encryption keys (including KMS where applicable). Local user credentials are stored using one-way hashing. Directory integrations use OAuth and do not store directory passwords; sensitive management secrets are protected with encryption rather than plaintext storage.
• Data handling & privacy: Hexnode collects administrative telemetry, endpoint health status, and compliance data required for device management, plus optional attributes enabled by policy (for example location or usage reports). Organizational content shared or deployed through Hexnode (such as apps, scripts, and admin-uploaded files) is stored as part of management workflows. Raw personal files and private end-user device contents are not collected into the management cloud.

Integrations

Hexnode combines a plethora of enterprise and technology solutions to deliver the ultimate device management experience. It enables seamless integrations with solutions, such as Apple Business Manager, Android Enterprise, Samsung Knox, and more to simplify device onboarding and management. It also integrates with directory services like Microsoft Active Directory, Microsoft Entra ID, Google Workspace, and Okta to let you easily import your directories to the MDM console.

Zendesk

Hexnode’s integration with Zendesk enables users to leverage the management suite in Hexnode from the Zendesk Support console. You can manage and view devices associated with a particular user along with the raised tickets through the Hexnode plugin on the Zendesk console. With this integration, you can execute several management actions, such as Scan Device, Scan Device Location, Lock Device, Wipe Device, and so on. Thus, handling queries through tickets and performing MDM actions can be achieved simultaneously from the support platform.

Endpoints

The endpoints can be personal or corporate-owned devices of employees that need to be managed in an organization.

Hexnode’s Architecture for Android devices

Hexnode provides extensive management functions for Android 5.0+ devices. The Hexnode UEM app is the end-user component that acts as the agent app for communication between the MDM server and the Android devices. With this agent app installed on the Android devices, an admin can remotely define configurations, check device compliances, wipe, or lock devices, etc. Ensure to keep the required ports open for managing Android devices.

1. To communicate with a managed device running the Hexnode UEM app, Hexnode sends a silent notification via FCM, MQTT or Pushy to that device.
2. Once the devices are notified, they will connect directly to Hexnode UEM over the standard HTTPS protocol with strict certificate validation. Hexnode will now send commands to the device.
3. The device will execute the commands and report the data back to the Hexnode server.

Ports

• Communications for enrolling and managing devices use HTTPS on TCP 443.
• Hexnode uses standard FCM ports and services (Ports 5228, 5229, and 5230). The port 1883 (outbound) can be used for devices without FCM.
• Ports 1883 and 8883 are used to communicate with MQTT.
• Port 53 (TCP/UDP) must be open for DNS resolution. Without DNS, devices cannot reach Hexnode servers or related services.

IP Ranges

Hexnode requires certain IP ranges to be allowlisted on your Firewall to seamlessly manage your Android devices. However, some IP ranges have to be mandatorily allowlisted whereas others are specific to certain enrollment types.

The IP ranges to be allowlisted can be found in the below-mentioned links:

• FCM (Firebase Cloud Messaging) – https://www.gstatic.com/ipranges/goog.json
• AWS (Amazon Web Services) – https://ip-ranges.amazonaws.com/ip-ranges.json
• Android Enterprise (Optional) – https://bgp.he.net/AS15169#_prefixes
• Samsung Knox (Optional) – Knox Cloud Services can utilize both AWS and FCM for communicating with the UEM server.

Allowlisting the IP ranges required for FCM and AWS is required for the smooth functioning of the UEM console. However, other IP ranges are optional and need to be allowlisted if the devices are enrolled using the specified methods.

Hexnode’s Architecture for Apple devices

Hexnode supports management of the following Apple devices:

• iOS 11.0 and later
• macOS 10.7 and later
• tvOS 6.0 and later
• visionOS 1.1 and later

Hexnode leverages the Apple Push Notification service (APNs) to manage Apple devices. APNs certificate installed in the Hexnode server ensures that the managed devices communicate through a secure channel using Apple Push Notification Service. The Apple devices use TLS based authentication to connect to the Hexnode server. Make sure to enable the required ports for managing Apple endpoints.

1. Hexnode initiates the communication by sending a notification to the APNs server to wake up the managed device (via TCP port 443).
2. For Apple devices to receive APNs notifications, the devices should maintain a live TCP outbound connection to APNs on port 5223. Make sure that this port remains open because, in some cases, your Wi-Fi router may block this port, preventing notifications from reaching the devices.
3. The device listens for the commands, policy settings, and configurations sent by Hexnode.
4. The device will execute the commands, apply the configurations/policies, and report the data back to the Hexnode server.

Ports

• Communications for enrolling and managing devices use HTTPS on TCP 443.
• Hexnode uses the port TCP 443 to communicate with APNs (Host Address is “*.push.apple.com”).
• Ports 1883 and 8883 are used to communicate with MQTT.
• If the Apple devices are connected to the internet through Wi-Fi and fail to receive APNs notifications, there are chances that the firewall in your network blocks the outbound port 5223. Make sure that this port remains open to TCP traffic for notifications to work. Learn more.
• Port 53 (TCP/UDP) must be open for DNS resolution. Without DNS, devices cannot reach Hexnode servers or related services.

Hexnode’s Architecture for Windows devices

Hexnode offers comprehensive support for Windows PCs running Windows 10 and later versions by combining native Windows MDM framework protocols with the Hexnode Windows Agent Architecture.

• Dual Management Engine: Native MDM handles standard policy enforcement, while the Hexnode Windows Agent extends management capabilities for advanced software deployment, OS patching, and custom script execution.
• Notification Pathways: Commands are delivered through Windows Push Notification Services (WNS), MQTT, and HTTPS polling channels to maintain reliable endpoint reachability.
• Connection Security: Device-to-server traffic is secured using TLS encryption over standard outbound HTTPS (Port 443) and MQTT (Ports 1883/8883).

1. Hexnode initiates communication with Windows devices by sending notifications via the WNS channel.
2. Once notified, the devices directly ping the Hexnode server for tasks or queries. The server will then send commands or actions to the devices.
3. The device will execute the commands sent by Hexnode and report the data back to the Hexnode server via the notification service channel.

Ports

• TCP port 443 is used in the case of the Windows Notification Service.
• Ports 1883 and 8883 are used to communicate with MQTT.
• Port 53 (TCP/UDP) must be open for DNS resolution. Without DNS, devices cannot reach Hexnode servers or related services.

Hexnode’s Architecture for Linux devices

Hexnode supports enterprise Linux distributions (Ubuntu, Debian, Fedora, Linux Mint) through a lightweight, persistent Linux agent architecture.

• Agent Mechanics: The Hexnode Linux Agent (HLA) runs as a native systemd daemon that initializes at system boot and operates continuously in the background. Onboarding is performed via terminal command-line interface (CLI-based enrollment).
• Dual Channel Communication: HLA leverages an outbound-only Dual Channel architecture combining MQTT push notifications for instant command delivery with HTTPS API polling on Port 443 as a fallback. This removes any dependency on inbound network connectivity or port exposure.
• Execution & Monitoring: Remote management commands (e.g., script execution, device lockdown, wipe) execute locally in the background, reporting real-time status and compliance data back to the Hexnode server.

1. Hexnode employs a Dual Channel communication model using MQTT and HTTPS API polling. This design removes dependency on inbound connectivity and ensures command delivery under restrictive network conditions.
2. Administrators can execute remote actions such as Lock Device, Execute Custom Script, and more, in real time. The device executes the commands sent by Hexnode and reports data back to the Hexnode server.
3. A persistent MQTT socket — an outbound, always-on binary protocol, maintains real-time command readiness without exposing SSH port 22.

Ports

• TCP port 443 is used for HTTPS communications for enrolling and managing devices.
• Ports 1883 and 8883 are used to communicate with MQTT.
• Port 53 (TCP/UDP) must be open for DNS resolution. Without DNS, devices cannot reach Hexnode servers or related services.