What Google actually requires, and by when
Google is phasing in a requirement that Google Cloud users enable 2-step verification (2SV) — but the specifics matter more than the headline, and they’re easy to get wrong secondhand. This requirement governs sign-in to the Google Cloud console and the Firebase console only. It does not touch Gmail, Drive, Sheets, or Slides, and Google’s own documentation says so explicitly.
The deadline also isn’t one date — it’s four, based on account type:
- Personal Google Accounts (used as principals in Google Cloud): required on or after May 12, 2025
- Reseller accounts: required on or after April 28, 2025
- Enterprise Cloud Identity accounts not using SSO: required on or after October 20, 2026
- Enterprise accounts using federated authentication (Workspace SSO, Cloud Identity SSO, or Workforce Identity Federation): to be announced — no fixed date yet
The personal-account and reseller dates have already passed. The one that should actually be on your calendar is October 20, 2026 — a little over two months out at the time of writing — which is when non-SSO Enterprise Cloud Identity accounts become locked out of the Cloud console and Firebase console without 2SV enabled. Google sends email and console reminders at least 90 days ahead of each account’s date (60 days for resellers), but any user added to your org after enforcement is already active gets no grace period at all — they’re prompted to set up 2SV the first time they try to sign in.
Notice what’s missing from that list: a real date for federated/SSO accounts. That’s not an oversight on our part — Google’s own documentation lists it as “to be announced.” More on why that matters below.
Where Google Workspace actually fits in
Google’s documentation draws a clean line: this specific requirement is a Google Cloud console / Firebase console control, and Google Workspace apps are explicitly called out as unaffected. So if your organization only ever uses Google Workspace and never touches the Cloud console or Firebase, none of the dates above apply to you directly.
In practice, that line is thinner than it sounds for a lot of organizations, for two reasons. First, a Google Workspace domain is a Cloud Identity organization under the hood — the same users, the same directory. Any of those users who also manage Google Cloud or Firebase resources (increasingly common as Workspace customers adopt Cloud services) are Enterprise Cloud Identity accounts for the purposes of this policy, on the October 20, 2026 date, regardless of what they use Workspace for day to day.
Second, and more usefully: Google’s documentation states that Workspace’s own, separate 2SV enforcement setting is recognized by Google Cloud. In other words, if your Workspace admin already enforces 2-Step Verification domain-wide — the long-standing Security → Authentication → 2-Step Verification setting in the Admin console — that satisfies the Cloud-side requirement too, for any of those same users who touch Cloud or Firebase. For most Workspace-first organizations, turning that setting on (if it isn’t already) is the single action that covers both bases at once.
The part that actually catches people out: SSO with Entra ID or Okta
Here’s the nuance that matters if your organization has already centralized sign-in through a third-party identity provider — which describes a lot of mid-sized and larger Workspace deployments. When a user signs in through SAML or OIDC federation, Google never sees a password, and it never shows its own 2-Step Verification prompt. Authentication happens entirely inside Entra ID or Okta before Google ever gets involved. Google’s own documentation is upfront that it has no visibility into this: in its conformance logs, every federated user is tagged MFA_ELIGIBILITY_UNSPECIFIED and ENFORCEMENT_STATE_NO_ENFORCEMENT_SSO_USER — Google’s system, in its own words, simply can’t tell whether that user has MFA or not. That’s also why there’s no fixed date yet for federated accounts: Google can’t enforce what it can’t verify until it defines how it will check.
That’s not a loophole — it’s exactly where the compliance gap opens. It’s easy to read “no fixed date” as “not our problem yet.” In reality, the requirement will apply to every federated user the moment Google announces it, with the same short notice window as the other phases, and Google’s own guidance is that “you can use the 2SV provided by that IdP to comply” — which only works if it’s already configured. An IdP with SSO wired up but no MFA policy attached to the Google Workspace application satisfies neither a soon-to-exist Google requirement nor genuine security best practice today. Getting it right now costs nothing and closes the actual risk immediately, instead of leaving it for a scramble later.
If you use Microsoft Entra ID
- Confirm the Google Workspace/Google Cloud enterprise application has a Conditional Access policy that includes it, with “Require multifactor authentication” as a grant control — not just “Require SSO.”
- Check that legacy authentication protocols are blocked for that application; legacy auth is a common way MFA enforcement gets silently bypassed.
- Review sign-in frequency / session controls so a stolen session token doesn’t outlive a reasonable re-authentication window.
If you use Okta
- Check the App Sign-On Policy attached specifically to the Google Workspace app — a global Okta sign-on policy doesn’t automatically cascade to every downstream app.
- Require Okta Verify or FastPass (or another phishing-resistant factor) as the enforced method, not just “any factor.”
- Review Okta’s own session lifetime and re-authentication settings alongside the app policy.
Either way: don’t forget break-glass accounts
Almost every SSO setup keeps at least one emergency super admin account that signs in directly with a Google username and password, specifically so admins aren’t locked out if the IdP itself goes down. That account, by design, bypasses your SSO policy entirely — which also means it bypasses whatever MFA your IdP enforces. Give it its own MFA directly in the Google Admin console, ideally a physical security key kept somewhere secure, and audit who actually has access to it.
How to check your actual compliance status, not guess at it
Google Cloud logs a real, per-user conformance record every time an account interacts with the Cloud console — this is the fastest way to see where you actually stand instead of assuming. In the Google Cloud console, open Logs Explorer, select your organization, and run:
jsonPayload.@type="type.googleapis.com/google.identity.mfaforall.LogEntry"Each entry includes userEmail, mfaEligibility (ELIGIBLE, INELIGIBLE, or UNSPECIFIED for SSO users), and enforcementState (UPCOMING_ENFORCEMENT, ENFORCED, MFA_COMPLIANT, NO_ENFORCEMENT_ORG_OPTED_OUT, or NO_ENFORCEMENT_SSO_USER). Filter to a specific user with jsonPayload.userEmail: "[email protected]" to check one account, or scan broadly for anything still showing UPCOMING_ENFORCEMENT ahead of October 20, 2026.
If your organization needs more runway on that date specifically, Enterprise Cloud Identity (non-SSO) orgs can request a one-time, 90-day extension: in the Cloud console’s Organizations page, select your organization, and click “Extend by 90 days” on the 2SV notification (requires the Organization Administrator role). Opting out entirely is also technically possible from the same page, but Google doesn’t recommend it, and re-enabling afterward carries a mandatory 30-day grace period — treat the extension as a way to buy real preparation time, not a way to avoid this indefinitely.
A quick compliance checklist
- Workspace-first organizations: turn on Security → Authentication → 2-Step Verification enforcement domain-wide in the Admin console if it isn’t already — this is recognized by Google Cloud and is likely the single action that covers you.
- Anyone with Enterprise Cloud Identity (non-SSO) accounts: confirm those users are enrolled well before October 20, 2026 — check Logs Explorer rather than assuming, and use the 90-day extension only as a genuine buffer if you need it.
- Entra ID shops: verify a Conditional Access policy with an MFA grant control actually covers the Google Workspace application, and that legacy auth is blocked — don’t wait for Google’s federated date to be announced.
- Okta shops: verify the Google Workspace app’s own sign-on policy — not just the org-wide default — requires a strong factor.
- Everyone: find and separately secure break-glass/emergency admin accounts with their own MFA.
- Everyone: while you’re in there, take stock of service account keys and CI/CD integrations — not covered by user MFA, but worth reviewing on the same pass, per Google’s own guidance toward Workload Identity Federation.
None of this requires ripping out your existing SSO setup. It’s a policy-configuration exercise inside the IdP you already run, plus a couple of Google Admin console settings most organizations set once and never revisit.
Getting this right the first time
Reconciling MFA enforcement across Google Workspace and a third-party identity provider is exactly the kind of cross-platform identity work that’s easy to get partially right — a policy that covers “most” users, or a break-glass account nobody remembered to check. Our managed security services team can audit your Entra ID or Okta configuration alongside your Google Workspace setup and confirm you’re actually covered, not just assumed to be. Get in touch if you’d like a second set of eyes before an auditor — or an attacker — finds the gap first.
References: Mandatory MFA is coming to Google Cloud (Google Cloud Blog) and 2-step verification requirement for Google Cloud (Google Cloud Documentation) — the documentation is the authoritative source for dates and account-type scope used throughout this post.