# 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. PillarFocusKey Mechanisms**Identity**Security & AuthSSO, 2FA, CAPTCHA, Logout Timeouts. **Permissions**Functional AbilityCustom Roles, Predefined Roles, Granular Remote Actions.**Scope**Target VisibilityDevice Groups, User Groups, Domain-level filtering.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. RoleAccess LevelFunctional ScopePrimary Restriction**Super Admin**IRREVOCABLEFull Global AuthorityNone (Account Owner)**Admin**NEAR-TOTALAll Management & EnrollmentCannot modify Super Admin**Apps/Reports**SILOEDApps & Reports Tabs + DashboardNo Policy or Remote Actions**Reports Manager**AUDITORReports & DashboardNo Management/ModificationCustom 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.