Yannick LeblancEvery system ships with one identity that can do anything. It performs the initial configuration, recovers the environment after a failure, and makes the changes no narrower role can reach. In a lot of organizations, it is also the account someone signs into on a Tuesday afternoon to add a user.
Those are two different jobs. Keeping an account that can rebuild the environment when normal administration fails is a recovery capability. Giving IT professionals enough access to do their daily work is an operational one. Collapsing them into a single role hands out far more access than the daily work needs.
Reserved for recovery and exceptional change
The most powerful identity should be reserved for recovery and exceptional change. An identity-provider outage, a lost administrator account, a configuration change no other role can complete: those are the moments it exists for. Everything else is ordinary work, and ordinary work has narrower roles. Emergency access, where an organization maintains it, comes with storage rules, alerting, and a test schedule.
A break-glass account remains unused until normal administration is unavailable.
Why unrestricted roles should not be used every day
An owner or root-level role usually reaches well past routine administration. Depending on the system, it can rewrite authentication settings, create other owners, read all stored content, change audit controls, or bring the environment back after the identity provider fails.
Larger impact from mistakes
An accidental change made through an unrestricted role lands on the whole environment. A scoped administrator managing users or configuration does not also reach sensitive content and recovery settings.
Larger impact from compromise
Every use of a privileged identity is another opportunity for its session, credentials, or authentication factors to be taken. Using it less often produces fewer opportunities.
Weaker accountability
When one broad role covers every administrative task, nobody can say why a particular person held a particular capability. A scoped assignment answers that on its own, because the capability arrived attached to a stated responsibility.
Unnecessary content access
Administering information does not require reading it. An IT professional can create vaults, manage users, assign licenses, and configure settings without opening a single credential, document, or session stored inside them.
Least privilege also applies to administrators
Least privilege tends to get discussed as a rule for standard users, which quietly turns privilege into a job title. Privilege attaches to the work. The same administrator reads email, opens tickets, and browses the Web between configuration changes, and none of that requires an owner-level identity.
NIST SP 800-53 control AC-6 (Least Privilege) requires organizations to grant only the accesses necessary to accomplish assigned tasks. The same control restricts privileged accounts to defined personnel or roles, and calls for non-privileged accounts when the work does not need elevation.
That holds inside the administrative tier as well. Someone working through a scoped role is still an administrator. What shrinks is the authority attached to the session, not the job.
The three functions of an administrative model
Administrative authority divides into three functions. One person may hold more than one of them.
Ownership and recovery
Ownership is unrestricted authority over the environment: initial configuration, recovery, and the exceptional changes no narrower role can complete. Rare by design. Each use should be visible afterward and explainable to whoever asks.
Break-glass is this function with operational rules attached: stored authentication factors, an alert when the account is used, and a test schedule so recovery works on the day it matters.
Day-to-day administration
Day-to-day administration runs the environment without inheriting every capability of the owner: users, groups, licenses, templates, integrations, and the containers that hold resources. Reading what those containers hold is a separate grant, and it follows the job rather than the container.
Specialized administration
Specialized administration splits the rest by responsibility and scope: user administration, audit, log viewing, vault ownership. Each assignment ties one capability to one job function, and groups keep that tie aligned with team membership and directory processes instead of individual exceptions.
Privileged roles accumulate, and direct assignments overlap with group assignments. A useful review asks which role a person holds, what it can do, where it applies, how it was assigned, and whether the function behind it still exists. “Who is an administrator?” does not get that far.
Applying the model in the Devolutions platform
The Devolutions platform applies this separation through role assignments in Devolutions Server 2026.3.
A Workspace owner keeps unrestricted access, much like the former Administrator, and belongs to ownership, recovery, and break-glass. A Workspace administrator manages the workspace without automatically receiving access to vault content, which covers the daily work. Auditor, Workspace log viewer, Users administrator, and vault-level roles carry the specialized functions.
The implementation details, including how the roles appear in the interface, are covered in Managing access with the new roles in Devolutions Server 2026.3. You can download the latest version here.
Conclusion
An organization keeps an unrestricted identity because recovery eventually calls for one. Daily administration does not. Scoped roles cover the ordinary work and leave the owner account where it does the most good: idle, watched, and ready.