I have seen a few system designs in my time and one question keeps cropping up:

Is it bad practice to have 'super admin' - single user - or 'super admin' privileges in your system?

By that I mean giving one or many users 'super admin' privileges so they basically never see a "you do not have permission" error and are never prevented from doing anything in the system.

This is from a security standpoint mainly - If someone somehow managed to login to an account that has 'super admin' privileges (when they shouldn't have access) they could wreak havoc as they can change anything in the system

  • 13
    He who can scribble on the boot disk is the super admin.
    – Joshua
    Sep 2, 2022 at 4:28
  • 1
    What do you mean by "system"? Is this an application? A single host machine? Or is this something like the complete IT infrastructure of a company?
    – Bakuriu
    Sep 2, 2022 at 6:22
  • 3
    @Joshua: So you are telling me that my hammer is a super admin...
    – user96551
    Sep 2, 2022 at 20:17
  • 1
    I'm pretty sure this is a no-no in the banking sector :-)
    – Richard
    Sep 3, 2022 at 19:32

4 Answers 4


I would split my answer into two parts:

Super admin in general

When designing a system, you do not want to get into a situation where no one is able to access the system and manage it as needed, especially when an emergency is at hand.

On the other hand, you probably don't want a single entity to be able to manage and control all properties of the said system.

For this particular reason, many designs include this role but with a limited assignment.
This role is mostly assigned to either "non-personal" user account that its credentials are safeguarded by a quorum of trusted people.
Another option is to have this role assigned to multiple trusted users with an approval quorum to apply sensitive modifications.

Sometimes similar account is also created as a local account (in case the others are governed by an organization's centralized identity management platform such as Okta) to allow out-of-band access in case of emergencies.

Users assuming super administrative privileges at all times

Per security design principles, you want to avoid excessive privileges assigned to personnel.
Your system should support access packages and roles to bind for the specific actions they need to perform over your system.
Let them perform whatever operations they need, nothing else.

It doesn't necessarily mean you are giving them the key to your castle if they are system administrators. You can put senstive operations under additional security measures such as just-in-time access with an external supervisor to allow the grant, etc.

  • Having a quorum could be a sensible option but.... do you have any real example of this actually being used in the wild? The only case I know regards nuclear launches which require multiple keys to be engaged at the same time, but I've never seen or heard of a software system which implements that kind of interaction. I guess it is complicated to handle so 99.99% of solutions use other options?
    – GACy20
    Sep 2, 2022 at 7:13
  • 3
    @GACy20: A few examples I've seen are cryptography software which splits backups of the master encryption or signing keys using Shamir's Secret Sharing, e.g. Hashicorp Vault or various HSM appliances.
    – grawity
    Sep 2, 2022 at 12:32
  • @user1686 That's not really what I'm asking. Because in that case the quorum is built into the cryptography. I'm thinking of software where you have an action "A" (say: change role for user, or delete user) which, instead of simply executing the action for an administrator somehow "triggers" the request for further approval by other admins and when a certain quorum of approvals is reached the action A is performed. At least, this is how I've interpreted the description in this answer.
    – GACy20
    Sep 2, 2022 at 14:37
  • 2
    @GACy20 In the fintech industry it is quite common actually, for instance in payment processing systems. There are such systems that allows you to define rules that enforce quorum supervision over execution of sensitive operations or significant payments.
    – Harel M
    Sep 2, 2022 at 17:32
  • 2
    @GACy20, while not cryptography, code review before allowing merge to master branch seems like exactly the option you are asking for
    – dEmigOd
    Sep 3, 2022 at 6:37

You've confused a few different topics into one:

  • is it bad practice to have the permission set?
  • is it bad practice to assign the permission set to an active user?
  • is it bad practice to have weak controls on the reserved user with super-admin permissions?

Of course it is not bad practice to have the permission set if the system requires it. Unix/Linux has had the "root" user for decades. So, the existence of the permission set is not an issue.

Multiple standards, regulations, and advice beg people not to assign super-user permissions to a normal active user. Active normal users tend to interact with untrusted data and code, which is open to compromise. This is why there is an open debate about developers having local admin permissions. They need it (#1), but it is a massive exposure (#2).

Which brings us to your third point, which becomes self-answerable. Because you should not have super-user permissions on a normal user, then you should also have increased protections on that account, since your whole point is to protect it from compromise. In other words, make it impossible for a non-authorised person to log in with that permission set. So, the security of the system is extended to the security of the account.


As a general rule, having some sort of all-powerful role (or user) is probably poor design. However, practicalities should be taken into account.

The root user on a Linux system is all-powerful on that server. They can do absolutely anything - read/modify the RAM or files in use, or shutdown the server or anything else. You could well argue they're a "super admin", and we do generally refer to the root user as a super user.

However, that root user cannot do anything to other servers, or the network infrastructure or anything else "outside" the server in question. Thus, they're not a "super admin" of the whole system - just of that one server. This is an example of segmented access - which is absolutely something that a new systems design should incorporate.

The principle at play here is to allow a human to do the work they need to do (especially in an emergency), but not to allow the human to do more than that. If there's a problem with Server1, then they can do whatever they need to fix Server1, but can't go and mess with Server2 (to work on Server2, they'd have to authenticate again, and separately with Server2). The point being that just because they somehow got the credentials to log on as the super user on Server1 doesn't immediately give them the ability to do it on Server2 - so they can't accidentally do something to Server2, and nor can a hacker use one point of entry to move "sideways" into other areas of the system.

Moving on to non-emergency situations, you have to allow administrators (and users) to work on the system. For that, you'd ideally want to give them a reduced set of permissions, so they're not a "root" type super user anywhere, but can still perform the likely maintenance and other activities that they need to do. This is generally called the Principle of Least Privilege, where you give people just enough permissions to do their work, but nothing more than that (and ideally no where near enough to do any damage).

Assuming an administrator is using their least-privilege credentials/account, then they can do their normal job. However, if a non-normal task comes along (like an emergency, or a special request), then they can (temporarily) elevate themselves to a higher level of privilege (perhaps a super user). This "elevation" step should be an explicit action so that it's something they must have deliberately done, and couldn't have done accidentally (you probably want to log that it's taken place too, so you have an audit). The point here being that if they go on to do something bad, they can't claim it was an accident, or their finger slipped or whatever. When they've finished the special task, they should go back to their normal (restricted) level of permissions. To that end, some "privilege elevations" are time limited so you have to keep renewing them if you want to stay in the higher level - as a means to avoid having people stay at higher privilege indefinitely.


OSes in common use all have such "super admin" capabilities. Clearly, the regular user does not have such privileges and even the administrative user(s) should minimize their use of escalated privilege. This principle is called "least privilege" and some of the other answers cover it in detail. Minimizing privilege use is obviously a "best practice" for the security conscious administrator.

However, even following these best practices does not eliminate the presence of the "super admin" capability. This capability is removed in high security specialized operating systems with a practice called "two person control." Typically, admin accounts have all the normal privileges one associates with them now, but a separate security admin account also exists. Regular admin accounts make security-sensitive privilege changes BUT those changes do not go into effect until approved by a security admin account. A security admin account cannot make privilege or ownership changes, but only approve or disapprove changes made by a regular admin. By restricting those roles to different people, you prevent a single person from having the "super admin" capability.

  • Even with non specialized OS, it can be good practice to keep this kind of privileges on log servers, monitoring servers, backup servers, etc, with a separate team - this will not hinder any legitimate action of an administrator, but will ensure that any tampering by an authorized or unauthorized privileged user is evident. Sep 1, 2022 at 18:16
  • @rackandboneman And making the person who can delete the backups a different person makes sure you need 2 people to delete all the data, just in case one person gets very angry and decides they don't care anymore.
    – Patrick M
    Sep 3, 2022 at 18:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .