Lock down the Google Cloud root or owner account

Why this matters

Google Cloud does not give you one root user with a password. Control sits in two places: the Google Workspace or Cloud Identity super admin who owns the organization, and the IAM roles that can change the organization, billing, and every project under it. That split is useful, but it hides the real root. A super admin can reset an admin password, add another super admin, and turn off sign-in controls. An Organization Administrator can grant themselves Owner on any project. A Billing Account Administrator can link projects to a payment method and run up spend.

Project Owner is not a harmless developer role. Owner can change IAM, delete resources, create service accounts, and grant access to data. If an attacker gets one Owner account through phishing, they can add a service account key and keep access after the password reset. Default service accounts with Editor make this worse. The top of the chain trusts everything below it, lock the top first.

The goal is not to make the super admin impossible to use. It is to make it boring: a small set of dedicated accounts, hardware keys, no daily Cloud work, and logs that show every use.

Before you start

Inventory before you change anything. In the Google Admin console at admin.google.com, open Directory, then Users, and filter by admin role to list every Super Admin. In the Google Cloud console, open IAM at the organization, folder, and project levels and record every principal with Owner, Organization Administrator, Folder Admin, Project Creator, and Billing Account Administrator. Include groups, service accounts, and external identities in the list.

Decide who will hold the break-glass accounts. You need two people, not one, and a place to store hardware keys and recovery codes that does not depend on one laptop. Buy at least two security keys per break-glass account and keep them in separate physical locations. Check that recovery email and phone numbers point to company controlled mailboxes and phones, not personal accounts.

Pick a low traffic window and keep your current session open. Test every change with a normal test user in an incognito window before you remove your own access. Confirm whether your organization uses Google Workspace or Cloud Identity. Run gcloud organizations list to get the organization ID and confirm you can change IAM at that level.

How to do it

Work from the top down. First make the super admin accounts safe, then move Cloud administration to groups and temporary grants, then add organization policies and logging. Do not start by removing project Owners. If the org level is weak, a project Owner can recreate what you removed.

Treat the super admin as an admin console role only. It should not be your Cloud architect account, your billing account, or your daily email. Use separate accounts for Cloud work and put people in Google Groups. Assign IAM roles to groups, not to individuals, so access reviews become a group membership check.

1. List every super admin and top level role. In admin.google.com, open Directory, Users, and filter by admin role to find every Super Admin. In the Cloud console, open IAM at the organization, folder, and project levels and record every grant of Owner, Organization Administrator, and Billing Account Administrator. Put each entry in a sheet with a named human owner and a reason.
2. Create two break-glass super admins. Create two dedicated accounts such as breakglass-1@yourdomain and breakglass-2@yourdomain. Give each a hardware security key, a company recovery phone, and no routine email. Do not use them for Cloud console work.
3. Move Cloud admin to groups. Create a Google Group for organization admins and one for billing admins. Grant roles/resourcemanager.organizationAdmin and roles/billing.admin to the groups, not to people. Remove those roles from daily accounts and from super admins that do not need them.
4. Enforce security keys and reauthentication. In the Admin console, open Security, Authentication, 2-step verification and enforce security keys for the super admin organizational unit. Turn off SMS and voice as backup methods for those accounts. Set Google Cloud session control to require reauthentication for sensitive actions.
5. Cut standing Owner and Organization Admin. Replace permanent Owner grants with narrower roles such as Project IAM Admin, Storage Admin, or Compute Admin. Use Privileged Access Manager or IAM Conditions for temporary elevation where you can. Review every service account with Owner or Editor and remove the role unless a documented workload needs it.
6. Turn off default grants and service account keys. Set the organization policy constraints/iam.automaticIamGrantsForDefaultServiceAccounts to false. Set constraints/iam.disableServiceAccountKeyCreation to true at the organization, then handle exceptions with a written reason. Move workloads to Workload Identity Federation instead of downloaded keys.
7. Restrict membership and public exposure. Set constraints/iam.allowedPolicyMemberDomains to your company domains so personal accounts cannot be added to IAM. Set constraints/compute.vmExternalIpAccess to deny by default and constraints/storage.publicAccessPrevention to enforced. Add a deny policy at the organization for actions you never want, such as changing the audit log sink.
8. Log and alert on the top of the chain. Create a separate audit project and an organization level log sink for Admin Activity and Data Access logs. Lock the log bucket retention so logs cannot be shortened. Alert on super admin sign-ins, IAM grants of Owner or Organization Administrator, and changes to 2-step verification enforcement. Enable Access Transparency and Access Approval for Google support access.

How to check it worked

Re-run the inventory. Confirm no daily user account has Super Admin. Confirm every Super Admin is in the break-glass set and has a security key. In Cloud IAM, confirm no human account has Owner at the organization and no service account has Organization Administrator or Billing Account Administrator. Check the groups: a person who left the team should be gone from the group.

Test as an attacker would. Sign in as a normal engineer and try to grant Owner on a test project. Try to add a gmail.com address to IAM. Try to create a service account key. Each attempt should fail with a policy or permission error, and the denial should show in the audit log.

Test the break-glass path. Have one named person retrieve a key, sign in, open the Admin console, do one read only action, and sign out. Confirm the sign-in produced an alert and an audit log entry. Check that the recovery phone and email still work. Verify the log bucket has recent entries and that a test IAM change triggered the alert.

Schedule a monthly access review. Open the group memberships, the super admin list, and the billing administrators. Remove anyone who no longer needs access. Check that the organization policies are still in place, because a project Owner can request an exception and a quick yes becomes permanent.

Mistakes to avoid

The first mistake is leaving Super Admin on a daily account. It is convenient until a phishing page captures the session. The second is using SMS as the only second factor. SIM swaps and carrier support are outside your control. Use hardware keys.

Another mistake is keeping one super admin. A single lost key becomes an outage. Two dedicated accounts with keys in separate safes is the practical minimum. Do not share one break-glass password between four people. The log will not tell you who used it.

Teams also forget service accounts, project Owners, and billing. A service account with Owner is a permanent key that never gets a password reset. A project Owner can grant access to data and create resources that cost money. A billing admin can link a new project to the company account. Do not lock down the org and skip the logging. If you cannot see a super admin sign-in or an IAM grant, you cannot tell whether the lockdown held. If you want an outside read, the Cloud security review from Cloudverg is a fixed price engagement at $6,500 that reviews identity, exposure, logging, and backups across up to five cloud accounts and gives you a ranked fix list. It is one option among others.

Frequently asked questions