Category filter
Architecting Administrative Authority: Scope Control in Hexnode UEM
In a complex Unified Endpoint Management (UEM) environment, the ability to delegate administrative tasks without overextending access is critical for both security and operational efficiency. While Roles define the functional capabilities of a technician, they do not inherently restrict where those capabilities are applied.
This document defines Scope Control—the mechanism that establishes precise administrative boundaries within the Hexnode UEM console. By implementing Scope Control, organizations can ensure that technicians operate within a “Least Privilege” framework, maintaining visibility only over the specific users, devices, or domains relevant to their regional or departmental responsibilities. This strategic approach prevents unauthorized access to sensitive data and eliminates the risk of accidental management actions on out-of-scope assets.
Strategic Overview: Role vs. Scope
To maintain a secure and organized UEM environment, administrators must distinguish between these two fundamental pillars of Access Control.
| Feature | Primary Question | Functional Definition |
|---|---|---|
| Role (Permissions) | “What can the technician do?” | Defines the actions available (e.g., Wipe, Install App, View Reports). |
| Scope (Boundary) | “Who/What can they do it to?” | Defines the target endpoints (Devices, Users, Domains) visible to the technician. |
Key Concept: A technician may have the “Role” of a Manager (allowing them to wipe devices), but if their “Scope” is limited to the Sales Department, they cannot see or wipe any devices belonging to the Engineering Department.
Scope Modalities: Structural Boundaries of Visibility
The following definitions provide the logical framework for administrative boundaries within the console.
Administrative Scope
Definition: The logical boundary within which a technician’s assigned permissions are active.
Mechanism: Scope acts as a Global Filter. When a scope is applied, it creates a “walled garden.”
Impact: Even if a technician has a role that allows “Remote Actions,” those actions can only be executed on resources contained within their Administrative Scope.
Domain Scope
Definition: Restricting technician authority based on specific directory services or organizational domains.
Use Case: Ideal for organizations with multi-tenant structures or distinct branches synced via different directories.
Example: A technician assigned to the “Sales” AzureAD domain scope will only see users and devices synced from that specific directory, regardless of other active directories in the portal.
Group-Based Scope
Definition: Limiting technician authority to specific Static or Dynamic groups.
Static Scope: Authority over a hand-picked list of devices or users (e.g., “VIP Executives”).
Dynamic Scope: Authority over devices that meet specific criteria (e.g., “All POS Terminals” or “All iOS Devices”).
Constraint: To create or edit Dynamic Groups, a technician typically requires a scope that encompasses “All Devices” to ensure they don’t inadvertently include devices outside their intended boundary.
The Visibility Logic: Implicit vs. Explicit Deny
Hexnode UEM utilizes an Implicit Deny model for Scope Control. This is the most critical concept for technicians to understand regarding data privacy and security.
Explicit Deny: A rule that specifically says “User cannot see X.”
Implicit Deny (The Hexnode UEM Model) : If a resource (Device, User, or Report) is not explicitly included in a technician’s assigned scope, it is implicitly invisible.
Functional Outcomes of Implicit Deny:
- Dashboard Isolation: The technician’s dashboard only reflects data (battery status, compliance, etc.) for devices within their scope.
- Search Exclusion: Devices outside the scope will not appear in search results, even if the technician types the exact Serial Number or IMEI.
- Reporting Silos: When generating reports, the UEM engine automatically filters out any data points belonging to entities outside the technician’s scope.
- Action Security: Remote actions (like “Lock” or “Wipe”) cannot be triggered for out-of-scope devices because the technician cannot access the device’s management page.
Administrative Requirements & Constraints
Based on Hexnode UEM’s structural logic, the following rules apply to Scope management:
- Predefined Roles: The “Super Admin” and “Admin” roles are hard-coded with Full Scope. Their visibility cannot be restricted.
- Custom Roles: Scope is defined at the point of Assigning a Role to a technician. While the role defines the permissions, the scope assignment validates the boundary.
- Self-Editing Restriction: An “Admin” cannot modify their own scope or role; this prevents privilege escalation.
The Security Value of Scope Precision
Effective Scope Control is the final safeguard in a robust UEM strategy. By moving beyond simple role assignments and implementing granular scope boundaries, administrators transform the Hexnode UEM console from a monolithic management tool into a tailored multi-tenant environment.
The transition to an Implicit Deny model ensures that “invisible” assets remain secure, and that regional or departmental technicians remain focused solely on the resources they are authorized to manage. As organizations scale, leveraging Domain and Group-Based Scopes will remain the most effective method for maintaining order, ensuring compliance, and protecting the integrity of the global device fleet.
