How to enforce MFA for every Google Cloud user

Why this matters

Google Cloud does not have an MFA switch in IAM. A human signs in with a Google Account, a Cloud Identity or Google Workspace account, or a federated identity, and the second factor is checked there. If you only review IAM roles, you can miss that a personal Gmail account with Project Owner can read buckets and run jobs.

The blast radius is bigger than one project. Roles granted at the organization or folder level flow down. A stolen password on an account with those roles can create service accounts, change logging, or grant access to others. MFA stops password-only attacks at the front door.

You also have to separate people from workloads. Service accounts do not enroll in MFA and cannot use a security key. They authenticate with keys, tokens, or workload identity. Enforcing MFA for users is necessary, but it is not complete unless you also close long-lived key paths and limit impersonation.

Before you start

Find out which identity system authenticates your Google Cloud users. Companies often use Cloud Identity or Google Workspace. Some use a third party identity provider with SSO, and some use Workforce Identity Federation for external identities. Write down the organization ID and the admin console you will change.

Inventory human access. Use Cloud Asset Inventory IAM policy search to find principals with roles on projects, folders, and the organization. Include group memberships, because a role granted to a group reaches every member. Flag consumer accounts, contractors, and service accounts that are used by people.

Choose a short enrollment window, such as two weeks, and a small exception list. Decide which second factors you will allow. Security keys or passkeys for admins and anyone with billing or security roles. Authenticator codes for other users. SMS and voice as backup only where you accept the risk.

Prepare a break-glass admin. One or two accounts with strong security keys, stored and monitored, that can still get in if the identity provider or the main admin account fails. Do not use shared accounts.

How to do it

Work from the identity layer outward. Change one organizational unit or group at a time, test with a pilot, then widen. The steps below assume Cloud Identity or Google Workspace; if you use federation, do the equivalent in the identity provider and keep Google Cloud role mapping in sync.

Keep a written record of who is in scope, which enforcement rule applies, and who approved each exception. That record is what you will check later when a new project or contractor arrives. It also keeps the break-glass account from becoming a permanent gap.

1. List every principal with Google Cloud access. Run an IAM policy search in Cloud Asset Inventory across the organization. Export the results and mark each principal as a Google account, group, federated identity, or service account. Pay attention to groups, because one group role can cover hundreds of users.
2. Pick one enforcement point. If users sign in through Cloud Identity or Workspace, enforce 2-Step Verification in the Admin console. If they sign in through a third party identity provider, enforce MFA there and require it for the Google Cloud application. Do not leave two half configured paths.
3. Turn on 2-Step Verification in the Admin console. Open Security, then Authentication, then 2-step verification. Set enforcement to on for the root organizational unit or a pilot group, choose a short enrollment period, and save. Test with a non admin pilot account first.
4. Require strong factors for privileged users. Create a group for Google Cloud admins, billing users, and security reviewers. Enforce security keys or passkeys for that group. Keep backup codes and a second key in a controlled place.
5. Remove easy bypasses. Review trusted devices, SMS and voice fallbacks, and app passwords. Disable or restrict any method that lets a user skip the second factor. If your edition does not allow a setting, document the gap and compensate with conditional access at the identity provider.
6. Cover federated identities at the identity provider. Create or update the Google Cloud app in the identity provider, require MFA in its access policy, and set a session length that fits your risk. Map identity provider groups to Google Cloud groups so role changes are reviewed in one place. Check that users cannot bypass the identity provider with a Google password.
7. Close service account key paths. Apply the organization policy constraint iam.disableServiceAccountKeyCreation where you can. Move workloads to Workload Identity Federation or attached service accounts. List existing keys, rotate or delete them, and restrict iam.serviceAccounts.actAs and Service Account Token Creator.
8. Test and then widen enforcement. Ask a pilot user to sign in from a new browser and a new device. Confirm the second factor prompt, then remove the pilot exception and move to the next group. Keep the break-glass account out of the rollout only until the final check.

How to check it worked

Open the 2SV enrollment report in the Admin console, under Security, Authentication, 2-step verification. It shows which users in scope are enrolled and which are not. Cross check that list against the Google Cloud principals from your IAM inventory. A user who is enrolled but not in the Google Cloud group still cannot reach the console. A user in the group who is not enrolled is a finding.

Test from a clean browser profile. Sign in with a normal user account and confirm Google asks for the second factor. Try the same with an admin account. Then check the login audit log for the sign-in and 2SV events. For federated users, use the identity provider sign-in log and confirm the MFA claim is present for the Google Cloud app.

Check non-human access separately. Run gcloud iam service-accounts keys list for each service account in the projects you care about, and confirm no new user managed keys were created after the policy change. Search IAM for Token Creator and actAs grants. Remove broad grants and document the remaining ones.

Repeat the check after any merger, contractor intake, or new project. Access drifts when teams add a group or invite an external account. A quarterly review of the enrollment report and the IAM inventory catches most drift.

Mistakes to avoid

Enforcing MFA only for admins. A normal user with broad project roles can expose as much data as an admin. Cover every human principal that can read data, change IAM, or run workloads.

Treating service accounts as users. They cannot do MFA, so long-lived keys are the real risk. Disable key creation, rotate what remains, and use impersonation with short sessions.

Leaving bypasses open. Trusted devices, app passwords, SMS fallback, and a growing exception list defeat the policy. Review them on a schedule and keep exceptions time bound.

Forgetting federated identities and groups. If the identity provider MFA policy excludes contractors or the Google Cloud app has a weaker policy, the gap is real. Test with a contractor account and a group granted at the folder level. If you want an outside read of the identity and access setup, the Cloud security review from Cloudverg is a fixed price of $6,500 and covers up to five cloud accounts, among other options.

Frequently asked questions