The Triad Access Model: Identity, Permissions, and Scope in Hexnode UEM

In a modern enterprise ecosystem, the ability to delegate administrative authority without compromising security is a critical operational requirement. As organizations scale, the “all-or-nothing” approach to system access introduces significant surface area for both accidental misconfiguration and intentional insider threats.

Hexnode UEM addresses this challenge through a sophisticated Role-Based Access Control (RBAC) architecture. This framework is engineered to uphold the Principle of Least Privilege (PoLP), ensuring that administrative access is precisely calibrated to an individual’s job function and geographic responsibility.

Conceptual Architecture: The Triad Access Model

Hexnode’s permission engine is governed by three intersecting dimensions. Access is only granted when a request satisfies the requirements of Identity, Permission, and Scope simultaneously.

1. Identity (The “Who”): Verification of the administrative entity via secure protocols such as SSO, CAPTCHA, 2FA.
2. Permissions (The “What”): The functional authority granted to the identity, ranging from read-only auditing to full system modification.
3. Scope (The “Where”): The logical or geographical boundary (Device Groups, User Groups, or Domains) where the permissions are valid.

Hierarchical Authority and Built-in Roles

Hexnode employs a structured hierarchy to prevent administrative overlap and ensure clear accountability.

• Super Admin: The primary account owner. This role possesses irrevocable authority to modify any portal setting, including billing, API integrations, and global security certificates.
• Admin: Possesses near-total privileges, including device management and policy creation. However, an Admin is restricted from modifying the Super Admin’s credentials or role.
• Apps and Reports Manager: A functional silo restricted to the Apps and Reports tabs. This role cannot view or modify device policies, location data, or remote actions.
• Reports Manager: The most restricted predefined role, permitted only to access the Dashboard and Reports sections for auditing purposes.

Custom Role Granularity (The Logic of Restriction)

Custom roles allow for the creation of “Least Privilege” accounts where specific administrative modules are toggled on or off at a granular level.

Technical Guardrails for Custom Roles

Even when granted high-level permissions, Custom Roles are programmatically restricted from the following critical system actions to prevent accidental or unauthorized infrastructure changes:

• APNs Management: Cannot delete or modify the Apple Push Notification service certificate.
• Android Enterprise (AE) Core: Restricted from disenrolling the organization or altering core sync services.
• Domain & Integration: Prohibited from modifying Google Workspace or Okta directory integrations.
• Technician Governance: Cannot create, edit, or delete other technicians.
• API Access: Access to the API functionality is completely disabled for custom roles.

Custom Roles allow enterprises to move beyond “all-or-nothing” permissions. These roles are built by selecting specific functional “bits” to match a unique job description.

Strategic Investment: Feature Tiers

While there is no limit on the number of custom roles an organization can create, the level of granularity is determined by the licensing tier:

• Ultimate Plan (Module-Level): Enables high-level access management for primary portal tabs (Dashboard, Enroll, Manage, Policies, Apps, Content, Reports, Admin).
• Ultra Plan (Granular-Level): Provides “Bit-Level” control. Stakeholders can selectively delegate sub-tabs and specific Remote Actions (e.g., allowing a technician to “Scan Device” but restricting “Remote Wipe”).

Authentication and Access Security

Enterprise environments prioritize secure entry points for technicians to prevent unauthorized console access.

• Multi-Factor Authentication (MFA): Access can be secured via Time-based One-Time Passwords (TOTP) using apps like Microsoft or Google Authenticator. Recovery codes are provided as a fail-safe.
• SAML/SSO Sign-In: On Ultimate and Ultra plans, technicians can bypass local passwords to sign in via Okta, Microsoft, or Google.
• Inactivity Safeguards: The portal enforces automatic logout after a specified period of inactivity (ranging from 30 minutes to 8 hours). Regardless of activity, sessions expire every 4 days to ensure re-authentication.

Enterprise Persona Implementation Scenarios

Scenario 1: The Auditor with limited permissions

• Role: Custom Role with limited permissions only.
• Scenario: An external compliance team needs to verify BitLocker encryption status across the Windows fleet.
• Result: The technician can export compliance reports but the “Wipe,” “Lock,” and “Modify Policy” buttons are disabled.

Scenario 2: The Regional Support Lead

• Role: Admin role with a custom Scope.
• Scenario: A technician in the European branch needs full control over local devices but must not see the North American fleet.
• Result: By assigning the technician to the “EU-Devices” Group, the portal dynamically filters all tabs (Devices, Policies, Reports) to show only relevant assets.

Scenario 3: The Content Distributor

• Role: Apps and Reports Manager.
• Scenario: A marketing team member needs to upload and update Enterprise apps without seeing sensitive device data (like location or SMS logs).
• Result: The technician is restricted to the App inventory and distribution reports, maintaining employee privacy while allowing functional autonomy.

Scenario 4: The Kiosk Maintenance Specialist

• Role: Custom Role (Scoped Admin).
• Scenario: A retail contractor needs to maintain digital signage and POS terminals across storefronts without accessing corporate user data or system settings.
• Result: Access is restricted to the “Retail-Kiosks” group for remote restarts, while visibility into executive devices, directory integrations, and billing remains strictly revoked.

Scenario 5: The App Catalog Custodian

• Role: Custom Role (Restricted “Add” Permission).
• Scenario: A software coordinator is responsible for managing the existing app library but should not have the authority to upload new enterprise binaries or store links.
• Result: The technician can view, assign, and refresh apps in the catalog, but the “Add Apps” button is hidden, preventing unauthorized or unvetted software from entering the organization’s repository.

Scenario 6: The Training Content Moderator

• Role: Custom Role (Restricted Content Repository).
• Scenario: A regional lead needs to distribute training manuals to field staff using files already vetted and uploaded by the corporate headquarters.
• Result: The technician is permitted to associate existing files with policies or devices but is disallowed from adding new content, ensuring that only approved enterprise documentation is circulated within their scope.

Scenario 7: The Automated Compliance Auditor

• Role: Custom Role (Restricted Reporting).
• Scenario: An internal auditor is tasked with ensuring that weekly compliance snapshots are delivered to the C-suite via automated email.
• Result: By enabling the “Reports” tab, the technician can configure automated email delivery for existing reports, even if they lack broader management permissions to modify device settings or policies.

Scenario 8: The Provisioning Specialist

• Role: Custom Role (Enroll-Only Access).
• Scenario: A warehouse technician needs to configure directory sync and enrollment settings without access to sensitive global logs or technician management in the Admin tab.
• Result: While the “Admin” tab is disabled, the technician can still manage Microsoft Entra ID and Active Directory settings through the “Enroll” tab, demonstrating how Hexnode allows functional access to core configurations while maintaining strict tab-level silos.

Scenario 9: The Tier-1 Support Technician

• Role: Custom Role (Selective Remote Actions).
• Scenario: A helpdesk agent needs to assist users with password resets and device scans but must be prevented from accidentally or intentionally erasing a device.
• Result:The role is configured with selective action bits; the technician sees the “Scan Device” and “Clear Password” options in their UI, while the “Wipe Device” action is unavailable to use.

Scenario 10: The Dynamic Asset Coordinator

• Role: Custom Role (Full-Scope Dynamic Management).
• Scenario: An IT manager needs to automate device grouping based on real-time attributes like battery level, compliance status, or OS version.
• Result: To permit the creation or editing of Dynamic Groups, the technician is assigned a scope of “All Devices” (a technical requirement for dynamic logic), granting them the visibility needed to define criteria that apply across the entire organizational fleet.

Scenario 11: The Account Governance Lead

• Role: Admin (Irrevocable Billing Safeguard).
• Scenario: An organization wants to ensure that only senior IT leadership can make financial changes or modify the UEM subscription plan.
• Result: Access to the Subscription and Billing pages is strictly locked to Super Admin and Admin roles; even a high-level Custom Role is programmatically blocked from viewing or modifying the organization’s license and credit card details.