Patch Operations RBAC: Separating Approval, Deployment, and Reporting in Hexnode UEM

Why separate patch duties

Separation of duties for patching answers a specific audit control: the person who decides a change is safe should not be the only person able to make it, and the person who executes it should not control what was decided.

In patch terms, three duties:

Auditors (SOC 2 CC-series change-management controls, ISO 27001 A.8, SOX ITGC change controls) look for exactly this three-way split plus an attributable record of each action. The rest of this page maps the split onto Hexnode’s role model.

How Hexnode’s permission model gates patch operations

Hexnode technicians are assigned roles — default roles or Custom Roles built from individual permissions. Because Hexnode groups patch approval and automation configuration under shared management privileges, you cannot technically prevent an admin who can approve a patch from also creating an automation.

The control that enforces the separation of duties is Scope.

When assigning a Custom Role, the administrator must define the technician’s scope (the specific devices, device groups, or domains they are authorized to manage). By scoping the security team exclusively to a “Pilot/Test” device group and the IT operations team to the “Production” device groups, neither team can execute a fleet-wide change alone.

The permissions relevant to the patch lifecycle:

Role Configuration Recipes

Because native granular approval vs. deployment permissions are merged, these recipes rely on procedural boundaries and blast-radius scoping to achieve audit compliance. All custom roles are created via Admin > Technicians and Roles > Roles > Create new Role.

Recipe 1 — Approve-only role for the security team

Goal: Security evaluates and approves patches; operations executes. Security holds no deployment capability.

1. Navigate to Admin > Technicians and Roles > Roles > Create new Role. Create a Custom Role named Patch Approver — Security.
2. Grant: Dashboard, Patches and Updates, Automate, and Reports for patch viewing, patch approval, report viewing.
3. Deny: Manage (remote actions), Admin (role modification), Policies (policy management).
4. Assign to security-team technicians. Restrict their scope entirely to your designated “Pilot/Staging” device groups.

Result: Technicians in this role see the full patch queue with CVE/severity context and can approve or decline, but the console exposes no deployment, targeting, or scheduling capability to them. What operations can deploy is bounded by what this role has approved.

If approval is not a distinct permission (the coarse-granularity case): the achievable pattern is documented under Compensating controls below — publish that version rather than this recipe if verification lands that way.

Recipe 2 — Deploy-only role for IT operations

Goal: The IT operations team deploys what security approved, on the schedule change management allows — and cannot widen the approval.

1. Create a Custom Role named Patch Operator — IT Ops.
2. Grant: Patches and Updates, Automate, Manage (for remote rollback actions), and Reports for patch viewing, deployment and automation management, maintenance window management, rollback actions, report viewing.
3. Deny: Admin, Patches for patch approval/decline (per the same granularity question), technician/role management (an operator who can edit roles can grant themselves approval — role management must stay with a separate administrator).
4. Optionally scope the role’s device visibility to the sites or groups the team operates.

While permissions dictate what actions a technician can perform, Scope dictates where they can perform them. When assigning a Custom Role to a technician, Hexnode allows administrators to define a specific boundary—restricting their visibility and authority to specific device groups, domains, or user groups. This acts as a global filter across the entire console.

By scoping your “Patch Operator — IT Ops” role to specific staging or production device groups, you create a hard structural boundary. Even with full deployment privileges, an operator physically cannot deploy a patch, alter a configuration, or execute a remote action on devices outside their defined scope. This makes blast-radius control a technically enforced reality rather than just a procedural guideline.

Result: The operator’s deployable universe is the approved set; approval changes are visible to them but not editable. Combined with Recipe 1, no single technician can both decide and execute a patch change.

Recipe 3 — Report-only role for audit

Create a Custom Role granting report viewing and Action History visibility only. Auditors get self-service evidence — who approved, who deployed, what succeeded — without a screen-share or an admin pulling exports, and without any write path.

The audit trail: who approved what

Every patch approval, decline, deployment creation, and rollback is recorded with the acting technician, the action, the object, and the timestamp.

The evidence workflow for a change-control review: filter the trail by the patch or deployment in question → the approval event names the approving technician → the deployment event names the executing technician → Action History per device shows the outcome. That chain — decision, execution, result, each attributed — is the artifact this page exists to make producible on demand.

Compensating controls when native granularity is coarse

If verification finds that approval and deployment share one permission, separation of duties is still achievable — it moves from technical enforcement to procedural enforcement with technical evidence:

• Scoped roles as blast-radius control: Give operations Manage rights only over production device groups and security manage rights only over a staging/pilot group — neither can act fleet-wide alone, and promotion from pilot to production requires both.
• Approval as a workflow stage outside the console: Approvals recorded in the change-management system (ticket), with the Hexnode audit trail evidencing that deployment followed ticket approval. Weaker than in-console enforcement, standard practice under coarse RBAC, and acceptable to most auditors when the trail is attributable.
• Two-technician account discipline: No shared technician accounts, ever — attribution is the entire audit value of the trail, and one shared “patchadmin” login voids it.

Documenting these honestly is deliberate: an RFP answer of “native approve/deploy split” that fails in the POC costs more than “procedural split with attributable audit evidence, native split on the roadmap” stated upfront.

What this model does NOT provide

• No multi-party approval: one approver’s action suffices; there is no built-in two-person rule or approval quorum for a patch.
• No approval expiry: an approved patch stays approved until declined — approval is a state, not a time-boxed grant.
• Role changes are not themselves patch-gated: a technician with role-management rights can alter this entire structure, which is why role management must be held apart from both patch roles (see Recipe 2).

Related documentation

• Manage technicians and roles
• Custom Roles
• Patch by CVE: CVE-driven patch automation
• Patch rollback and failed-update remediation
• Maintenance windows and patch scheduling
• The Hexnode patch catalog: curation and validation pipeline