Super admins in Google Workspace: security best practices
By Kike Gandia · Co-Founder & CEO, OSCP
The super admin account is the master key to your Google Workspace: it accesses everything, changes any setting and creates or deletes users. It's also the most coveted target for an attacker. Managing it well is one of the most important security decisions in your environment.
How many super admins you should have
The CIS Benchmark recommends two or fewer. Too many super admins multiply the attack surface of the most valuable accounts; having just one, on the other hand, exposes you to being locked out if that account is lost. The usual balance is two accounts, strongly protected and monitored.
Separate admin accounts from day-to-day accounts
A super admin shouldn't use that same account to read email or browse daily. It's advisable to have dedicated admin accounts, with no everyday use, so that phishing a normal employee account never compromises admin privileges.
Least privilege with delegated roles
Not the whole IT team needs to be a super admin. Google Workspace lets you create delegated admin roles (user management, help desk, group management, etc.) that grant only the necessary permissions. Applying least privilege drastically reduces the impact if one of those accounts is compromised.
Enhanced protection of admin accounts
Protect every admin account with security keys or passkeys, enroll them in the Advanced Protection Program and configure alerts for privilege changes. Periodically review who holds admin roles and remove those no longer needed.
Which role to delegate for each task
Most surplus super admins exist because nobody sat down to work out which role was actually enough for each task. This is the usual mapping.
| Common task | Sufficient role | Why super admin is not needed |
|---|---|---|
| Create, suspend and reset users | User management admin | Does not need to touch domain security settings |
| Handle password and 2SV issues | Help desk admin | Resets credentials without being able to change policy |
| Manage distribution lists and groups | Groups admin | Isolated from the rest of the environment |
| Review logs, reports and alerts | Custom read-only reporting role | Auditing does not require the ability to change anything |
| Manage Drive sharing | Custom role with Drive privileges | Confines the damage of a compromise to that service |
| Manage mobile devices | Mobile device admin | Does not touch identities or permissions |
Every row you move out of the super admin column and into a delegated role reduces the number of accounts whose compromise means losing everything.
The break-glass account: why you need one and how to store it
If you protect admin accounts properly, sooner or later you hit the opposite problem: locking yourself out. An outage at an external identity provider, a lost key or a sudden departure can leave you without administrative access to your own domain.
The answer is a break-glass account: a super admin account that belongs to no individual, is never used day to day, does not depend on third-party SSO (so an identity provider incident cannot lock you out), has a security key stored under physical control, and triggers an alert on any use. Test it periodically: a break-glass account nobody has ever validated tends to fail on precisely the day it is needed.
FAQ
Why not use a single super admin account for everything?
For two reasons: if that account is lost or locked, you're left without admin access; and if it's compromised, the attacker controls everything. The recommendation is two protected accounts and delegated roles for the rest of the team.
How do I detect if new admins are created without authorization?
By configuring alerts in the admin console for privilege changes and reviewing the audit logs. The creation of a new super admin is one of the events that should always trigger an alert.
What do you deliver in an admin review?
An inventory of every account holding an administrative role, the effective privileges of each one (which almost never match what the organization believes it has), the list of roles to remove, the delegated roles proposed to replace them, and the audit alerts you need in place to learn about future privilege changes.
Do you have to touch production to review it?
No. Enumerating roles, effective privileges and the history of changes is done with read-only permissions. Configuration changes come afterwards, already validated with you, and are applied in phases so nobody is left unable to work.
Can the super admin role be granted only temporarily?
Google Workspace has no native equivalent to Entra ID just-in-time activation, so temporary grants have to be supported by process: grant the role, record who requested it and why, and revoke it when done, with an alert on the privilege change so revocation does not depend on somebody remembering.
What if the super admin leaves the company or loses their key?
That is what the second admin account and the break-glass account are for. The classic mistake is having a single super admin tied to one person: when that person leaves, loses their phone or changes department, recovery turns into a slow process with Google support at the worst possible moment.
Related service
Google Workspace security audit