Super Admin Accounts and Admin Panels: Securing Them

Super admin accounts and the admin panels they sign in to can change every user, every policy and every log in a platform, so one stolen super admin session is usually the whole tenant. Most organisations have more of these accounts than they think: Google Workspace super admins, Microsoft Entra Global Administrators, Okta super administrators, the AWS root user, plus the /admin pages of their own web applications and the consoles of firewalls and backup systems. This guide gives practitioners a platform-by-platform view of how many super admins to keep, how to authenticate and isolate them, which events to alert on, and how to protect the admin interfaces of your own applications. It sits beneath the Privileged Access Management Guide and links out to the Break-Glass Account Guide for emergency accounts rather than repeating it.

Key takeaways

Keep the count small but never one. Microsoft recommends fewer than five Global Administrators and Google recommends more than one super admin, each managed by a different person; one is a lockout risk, ten is an attack surface.
Super admin is a separate account, not a setting on your daily one. Google advises each super admin to have a privileged account and a regular account, and Microsoft advises cloud-only accounts for Entra roles.
Phishing-resistant MFA is the minimum. Security keys or passkeys for every super admin, plus restrictions on who can reset them; the 2023 Okta super admin attacks began with help desk MFA resets.
Standing access is the main risk. Use just-in-time elevation (Entra PIM, Okta custom admin roles with approval, AWS centralised root access) so most of the time nobody holds the role.
Admin panels need their own perimeter. Application /admin interfaces should not be reachable from the internet without strong authentication and, ideally, a network restriction; OWASP lists force browsing to privileged pages as a core access control flaw.

What counts as a super admin

A super admin is any identity that can grant itself or others any permission in a system, change authentication policy, or disable logging. That covers more than the role literally named "super admin".

Platform	Top role	What it can do	Vendor guidance on count and use
Google Workspace	Super administrator	Every setting, every user, all data, domain and recovery	More than one, each managed by a different person; a separate admin account for each; sign out after tasks; delegate routine work to limited roles
Microsoft Entra ID and Microsoft 365	Global Administrator (plus Privileged Role Administrator and Privileged Authentication Administrator, which can grant or reset it)	Tenant-wide control of identities, roles and Microsoft 365 services	Fewer than five Global Administrators (an alert appears at five or more), two cloud-only emergency access accounts, fewer than ten privileged role assignments overall
Okta	Super administrator	All admin functions, including identity providers, policies and other admins	Least-privilege custom admin roles, minimal standing privilege, dual authorisation for just-in-time elevation (Okta Security, 2023)
AWS	Root user of each account	Everything in the account, including billing and closing it; not restricted by IAM policies	Use only for root-only tasks; no root access keys; MFA required; in AWS Organizations, centralise root access and remove member account root credentials
Your own applications	Application administrator, often /admin	Change users, data and configuration in the app	Treat as privileged; OWASP ASVS 5.0 requirement V8.4.2 calls for multiple layers of security on administrative interfaces
Infrastructure consoles	Firewall, hypervisor, backup and device management admins	Disable protection, delete backups, wipe devices	Same controls; these are prime ransomware targets

Include the "kingmaker" roles in your count: any role that can assign the top role or reset its authentication is equivalent to it. In Entra that means Privileged Role Administrator and Privileged Authentication Administrator; in Okta, any admin who can manage the super admin group; in AWS, any principal with permission to change IAM policies broadly or to use sts:AssumeRoot.

How many super admins to keep

Small organisation (under 50 staff): two named super admins on separate admin accounts, each held by a different person (for example the IT lead and a director), plus emergency access as described in the Break-Glass Account Guide. Outsourced IT should use delegated, scoped admin access in their own name rather than a shared super admin login; see the GDAP and MSP Delegated Admin Access Guide.
Mid-size: two to four eligible (not active) super admins plus two emergency accounts; everyone else on scoped roles such as user administrator, helpdesk administrator or groups administrator.
Large enterprise: zero standing super admins for named staff; elevation through PIM with approval; emergency accounts monitored with alerting on any sign-in.

Microsoft's guidance gives a useful check: count Global Administrator assignments, and if you have five or more, work through who needs it. Most requests for super admin turn out to need one narrow capability that a built-in role (Entra has more than 65) or custom role already provides.

Authentication and isolation

Control	Google Workspace	Microsoft Entra	Okta	AWS root
Phishing-resistant MFA	2-Step Verification with security keys; enrol super admins in the Advanced Protection Program	MFA through PIM role settings or Conditional Access; use phishing-resistant authentication strengths	FIDO2 WebAuthn or Okta FastPass for sign-in, enrolment and recovery	FIDO security keys; register up to eight MFA devices for resilience
Separate account	Super admin account plus a regular account per person	Cloud-only admin accounts, not synced from on-premises	Dedicated admin policies for admin accounts	Daily work through IAM Identity Center or IAM users, not root
Just-in-time	Delegate routine tasks to limited admin roles	PIM eligible assignments with time limits, approval and notifications	Dual authorisation for elevation; minimise standing privilege	Centralised root access: sts:AssumeRoot for privileged root tasks, logged in CloudTrail
Session and device	Sign out of super admin accounts after tasks	Conditional Access requiring compliant devices for admin roles	Protected Actions and re-authentication for the Admin Console; ASN and IP session binding; managed devices; block anonymising proxies	Remove member account root credentials; deny root actions with an SCP except root-only tasks
Recovery	Review the super admin account recovery setting; recovery phone and email; spare security key; backup codes stored securely	Emergency access accounts	Restrict self-service recovery to trusted networks and the strongest authenticator	Keep the root email mailbox itself secured with strong MFA

Use a dedicated, hardened device for super admin work where you can. NCSC's secure system administration principles start with "gain trust in your management devices" and "protect your administration interfaces". See the Privileged Access Workstations Guide.

The help desk is part of the super admin perimeter

In the 2023 attacks Okta described, callers asked IT help desks to reset all MFA factors on super administrator accounts, then used those accounts to elevate others, remove MFA from policies and add an attacker-controlled identity provider as an inbound federation source so they could sign in as real users. At MGM Resorts in 2023, a help desk call based on LinkedIn research led to administrator privileges over the Okta and Azure tenants; see the MGM Resorts breach 2023. Okta's recommendations: constrain help desk roles so they cannot manage highly privileged admin groups, and strengthen caller verification. See the Account Recovery and Help Desk Security Guide.

Admin panels in your own applications

An application's admin panel is a super admin interface with whatever security the developers gave it. OWASP's Broken Access Control category explicitly includes force browsing to privileged pages as a standard user, and its example scenario treats a non-admin reaching the admin page as a flaw.

Do not expose it publicly by default: serve admin functions on a separate host name or path reachable only through VPN, zero trust access proxy or an IP allow list.
Authenticate through your identity provider: single sign-on with phishing-resistant MFA, not a separate local admin password; ASVS 5.0 V8.4.2 asks for multiple layers, including identity verification, device posture and contextual risk.
Enforce authorisation on the server for every request: hiding the menu item is not access control.
Remove defaults: no default admin usernames or passwords, no setup wizards left reachable after install.
Keep CMS and product consoles off the internet: content management, database administration and appliance management panels are routinely found by internet scanning; see the Attack Surface Management Guide.
Log admin actions in a store the admin cannot delete.

Standing, eligible or emergency: choosing the access model

Model	How it works	Good for	Trade-off
Standing assignment	The account holds the role permanently	Emergency access accounts only	Any compromise of the account is immediately a tenant compromise
Eligible, self-activated	User activates the role for a set time after MFA and a justification	Experienced admins doing frequent, low-risk changes	Fast, but a stolen session with MFA can still activate
Eligible, approval required	A second person approves each activation	Top roles such as Global Administrator and Okta super administrator	Slower; needs approvers available out of hours
Scoped role	A narrower built-in or custom role with only the needed permissions	Help desk, user lifecycle, group management, application management	Requires upfront role design; roles drift if not reviewed
Centralised root (AWS)	Member accounts have no root credentials; privileged root tasks run through sts:AssumeRoot from the management account	Multi-account AWS organisations	Concentrates power in the management account, which then needs the strongest protection

The deciding question is what the attacker gets if they steal the account at 3am. If the answer is "the whole tenant, immediately", move that account to an eligible model with approval, or make it an emergency account that nobody signs in to except during a declared incident. Small organisations often resist approval workflows because there are only two admins; in that case, the second admin approving the first is still far better than either acting alone, and the emergency account covers the case where neither is available.

Infrastructure and security product consoles

Firewall, VPN, hypervisor, backup and endpoint management consoles deserve the same treatment as identity providers, because they can disable protection, delete recovery points or push commands to every device. Put their admin interfaces on a management network, require SSO with phishing-resistant MFA where the product supports it, remove local admin accounts except one documented emergency account, and send their audit logs to a central store. A backup console administrator who can delete immutable copies, or a device management administrator who can wipe the fleet, is a super admin in all but name. See the Backup Identity Isolation Guide.

Where identity fits

Non-human identities can hold super admin power too: an Entra application granted RoleManagement.ReadWrite.Directory, a Google service account with domain-wide delegation, an Okta API token created by a super admin (it inherits that admin's permissions), or automation using an AWS role with broad IAM rights. These rarely appear in a super admin count and seldom have MFA. Inventory them alongside human super admins. See the Google Workspace Domain-Wide Delegation Security Guide and How to audit Okta API tokens and service apps.

Detection and measurement

Platform	What to alert on	Where
Google Workspace	Admin role assignments, super admin sign-ins, changes by other admins, suspicious sign-ins; super admin activity is labelled _SEED_ADMIN_ROLE in the Admin log	Admin log events and admin email alerts; see the Google Workspace Audit Log Detection Guide
Microsoft Entra	New Global Administrator or privileged role assignment, PIM activation outside change windows, emergency account sign-in, Conditional Access policy changes	Entra audit logs and PIM alerts
Okta	user.mfa.factor.reset_all; system.mfa.factor events; system.idp.lifecycle.create; user.authentication.auth_via_IDP if you do not use inbound federation; user.session.start with securityContext.isProxy true	Okta System Log; see the Okta System Log Detection Guide
AWS	Any root sign-in or root API usage; sts:AssumeRoot sessions	CloudTrail with CloudWatch, EventBridge and SNS, or GuardDuty, as AWS recommends

Metric: number of standing super admin assignments per platform (target: at or below your documented ceiling, zero standing for named staff in large tenants).
Metric: super admins with phishing-resistant MFA (target: 100%).
Metric: median time from a new super admin assignment to review (target: same day).
Metric: non-human identities with tenant-wide admin permissions, with an owner (target: 100% owned, count falling).
Metric: internet-reachable admin panels found by external scanning (target: 0 without SSO and network restriction).

Reducing super admins: a phased approach

Inventory: list every top role and kingmaker role assignment across Workspace, Entra, Okta, AWS and your applications, including non-human identities.
Justify: for each, record the tasks that need it; map each task to a narrower built-in or custom role.
Prepare emergency access first: create and test break-glass accounts before removing anyone, so a mistake cannot lock you out.
Pilot: move the IT team to eligible or scoped roles for two weeks; log every time someone needed to elevate.
Enforce: require phishing-resistant MFA and dedicated admin policies, then remove standing assignments.
Rollback: if a critical task fails, grant a time-bound eligible assignment rather than restoring permanent super admin.
Review: recurring access reviews (Microsoft recommends them for role assignments) at least quarterly.

Common failure patterns

Daily account is super admin: the person reads email and browses with the same account that can change everything.
Help desk can reset super admin MFA: the path used against Okta customers in 2023 and against MGM Resorts.
Synced admin accounts: an on-premises compromise flows into the cloud tenant; Microsoft advises cloud-only accounts for Entra roles.
Root access keys in AWS: long-lived keys for the one identity IAM cannot restrict.
Shared super admin login with the MSP: no attribution in logs and no way to remove one person.
Uncounted API tokens and apps: machine identities with tenant-wide admin rights, outside every review.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	AC-6 Least Privilege; AC-6(5) Privileged Accounts; AC-2(7) Privileged User Accounts; AU-6 Audit Record Review	Few, role-based, reviewed admin accounts
NIST CSF 2.0	PR.AA-01 identities and credentials managed; PR.AA-05 access permissions with least privilege	Admin identity lifecycle
CIS Controls v8.1	Safeguard 5.4 Restrict Administrator Privileges to Dedicated Administrator Accounts; 6.5 Require MFA for Administrative Access	Separate admin accounts and MFA
MITRE ATT&CK	T1078.004 Cloud Accounts; T1098.003 Additional Cloud Roles; T1556.007 Hybrid Identity	Use of stolen admin accounts, role escalation, federation tampering
OWASP ASVS 5.0	V8.4.2 administrative interfaces	Application admin panels

Practitioner checklist

Count super admin and kingmaker roles on every platform, human and non-human.
Keep at least two and, in Entra, fewer than five Global Administrators.
Give each super admin a separate, cloud-only, named admin account.
Require security keys or passkeys for every super admin.
Stop the help desk resetting MFA on privileged accounts without strong verification.
Move to just-in-time elevation with approval for routine admin work.
Remove AWS root access keys and centralise root access in Organizations.
Alert on new admin assignments, IdP changes and root sign-ins.
Put application admin panels behind SSO and a network restriction.
Review admin role assignments at least quarterly.

Admin panels and super admin accounts: How many to keep and how to protect them