ControlUp ONE provides powerful IT management capabilities that demand a structured security approach, utilizing its granular permission model, robust authentication, and comprehensive auditing to effectively balance productivity with control.
The platform emphasizes a multi-layered, granular permission model, allowing IT to assign precise access for functionalities like remote control, file systems, and registry, directly aligning with user job functions rather than simple on/off switches.
Security is further enhanced through mandatory MFA, SSO integration, conditional access policies, and extensive audit logging for all RMM operations, which provides accountability and enables more productive, auditable access to advanced tools.
Recommended best practices include implementing user consent for remote control, leveraging feature flags for controlled capability rollouts, and conducting regular audits of critical permissions to maintain a least-privilege security posture.
ControlUp ONE is a powerful platform, and that power cuts both ways. The same capabilities that let IT teams monitor sessions, access devices remotely, run scripts, and manage infrastructure at scale are exactly the capabilities that need to be handled carefully from a security standpoint. The challenge isn’t choosing between a locked-down environment and a productive one; it’s recognizing that the two aren’t mutually exclusive.
With the right approach to role assignments, permission scoping, authentication, and audit logging, you can give your teams the access they need to do their jobs effectively while maintaining meaningful control over what gets touched, by whom, and when.
Think in Permission Layers, Not Just On/Off
ControlUp’s permission model isn’t binary — it’s highly granular across several distinct capability areas. The key is matching the permission layer to the user’s actual job function.
For Remote Control, for example, the docs define these as separate, independently assignable permissions:
- Allow remote control connections
- Skip user consent requirement (restrict this one)
- Allow file transfer during a session
- Allow elevated command prompt
- Allow remote control of unmanaged devices (higher risk)
This means you can give a helpdesk technician remote control access without giving them the ability to bypass user consent or run elevated commands — keeping their experience productive while protecting end users and the environment.
Similarly, File System permissions split across view / modify / create / delete / upload / download independently, and Registry access splits view from modify. The practical approach: grant view liberally, restrict modify and delete tightly.
Understand the Three Real-World Role Tiers
Across ControlUp products, the docs converge on a natural three-tier model:
| Tier | What they can do | Who this is for |
| Read-Only / Viewer | View metrics, dashboards, session data, settings | Analysts, junior helpdesk, reporting |
| Operator | Day-to-day actions — remote control, session management, host lifecycle | Helpdesk, desktop engineers |
| Admin | Everything including RBAC, settings, script management, credential management | Senior IT, security leads |
The underlying system enforces individual atomic permissions rather than rigid role names, which means you can fine-tune within each tier rather than being stuck with coarse presets. One useful behaviour to know: any user with a manage permission automatically gets view access implied — you don’t need to double-assign, which reduces permission management overhead.
Authentication Strengthens Lockdown Without Hurting Usability
The docs describe several authentication controls that add security without friction for day-to-day use:
- JWT-based UAT tokens with configurable expiry — set these appropriately for your environment (shorter for sensitive roles, longer for read-only)
- SSO / Azure AD integration with MFA support — SSO reduces login friction while MFA adds the security layer; the docs explicitly recommend enabling MFA for all users
- Conditional access policies via MSAL integration — enforce stricter auth for certain actions or device states without impacting routine workflows
- Device Access Tokens (DAT) for agent connections, with automatic rotation on security events
The recommended baseline: enable MFA for all users and configure SSO so security sits in the authentication layer, allowing you to be somewhat more permissive with day-to-day feature access.
Audit Everything, Restrict Selectively
A key theme across the security documentation is using audit logging as a safety net, which lets you be more permissive with some capabilities because you have a full record of what happened. Every RMM operation generates an audit event capturing:
- Who did it (user ID, username)
- What they did (action type, parameters)
- Where (device ID, device name, IP)
- When (timestamp)
- Whether it succeeded or failed
- The session ID for correlated actions
The practical implication: rather than locking down remote shell entirely (which hurts productivity), enable pr_remote_shell_audit_commands so every command is logged. You get the audit trail, the team keeps the capability. The docs call this out explicitly as a best practice: “Always audit remote shell commands.”
The same logic applies to file operations and registry changes — log them granularly so you can detect misuse without pre-emptively blocking legitimate work.
The Consent Model for Remote Control
One of the most important usability-vs-security tradeoffs documented is the user consent requirement for remote control sessions. The permission pc_allow_to_not_require_user_consent lets you skip the consent prompt, but the docs recommend keeping consent enabled unless there’s a specific operational reason not to.
A sensible tiered approach:
- Standard helpdesk: remote control requires user consent — protects end-user trust
- Elevated/admin tier: can bypass consent for unattended maintenance scenarios
- Screenshot capture: the most sensitive variant (capturing without notifying the user) should be restricted to the narrowest possible group
This preserves end-user trust — people are less resistant to IT tools when they know they’ll be notified.
Feature Flags as an Additional Control Layer
On top of individual permissions, feature-level access control via DEX feature flags lets you enable or disable entire capabilities independently. Remote shell, file explorer, device profiler, and registry access can each be toggled at the feature flag level. This gives you:
- A way to roll out capabilities incrementally to specific user groups
- A fast kill switch if a capability causes issues
- A way to prevent a capability from being accessible at all, even if someone technically has the underlying permission assigned
This is particularly useful for cautious rollouts — you can keep a capability locked at the feature level while you build confidence, then open it up without touching individual role configurations.
What to Review Periodically
The docs explicitly recommend regular permission reviews as a best practice. Given the breadth of ControlUp’s permission surface, a practical review cadence should focus on:
- Who has Change Permissions — this should be a very short list
- Who has pc_allow_to_not_require_user_consent — check this hasn’t drifted
- Who has pr_remote_shell_run_as_admin — elevated shell is high risk
- Any wildcard tag scopes — these override specific restrictions and are easy to set accidentally
- Custom roles that have grown over time — these tend to accumulate permissions
The underlying principle is consistent throughout the docs: start from least privilege, expand deliberately, and use logging to catch anything that slips through.
