A person working on a laptop with a digital 2FA login interface, fingerprint icon and security lock overlay. Illustrating multi-factor authentication and account security in Google Workspace.
Short Answer
The most effective way to secure Google Workspace beyond standard 2-Step Verification is to set the 2SV method to "Only security key," which restricts everyone to passkeys and hardware security keys. The two factors that cannot be phished. Standard MFA using codes or push prompts can be defeated by an attacker relaying the login in real time and stealing the resulting session cookie. The setting is available on every Google Workspace edition and costs nothing.
The Uncomfortable Statistic
You did the responsible thing. You turned on 2-Step Verification, enforced it across the company and moved IT security down the list.
Then somebody's account got taken over anyway.
This is not unusual and it is not a failure of your judgment. Proofpoint's research on cloud account compromise found that 65% of compromised accounts had MFA enabled, across a monitored population where 99% of organizations were targeted and 62% experienced at least one successful compromise.
Read that again. MFA was on. The accounts fell anyway.
That doesn't mean MFA is pointless. An environment without it is far worse off. It means MFA stopped being a finish line somewhere around 2023 and a lot of companies never got the memo.
How Attackers Actually Get Past 2-Step Verification
The technique has a name: adversary in the middle. It's worth understanding the mechanism, because the mechanism is what tells you which defenses work.
The old attack was simple credential theft. Fake login page, you type your password the attacker collects it. MFA broke this completely. The attacker had your password but couldn't produce your second factor.
The current attack doesn't try to beat your second factor. It borrows it.
Here's the sequence:
You click a link and land on a page that looks exactly like the Google sign-in screen. It isn't a copy. It’s a proxy, relaying your traffic to the real Google in real time.
You enter your password. The proxy passes it to Google. Google, seeing a legitimate login, issues the 2-Step Verification challenge.
You receive the code or the push prompt. It's real, because the login is real. You are actually signing in. You approve it.
Google authenticates the session and issues a session cookie, the token that says "this browser is signed in and doesn't need to prove it again."
The proxy captures that cookie and hands it to the attacker.
The attacker now has an authenticated session. No password needed. No second factor needed. They import the cookie into their own browser and they are you, from Google's perspective, for as long as the session lives.
Nothing about this is exotic anymore. It's packaged software that runs on rented infrastructure.
And the window is short. CrowdStrike's 2025 Global Threat Report put the average breakout time following a compromise. The gap between initial access and lateral movement at 48 minutes.
The second path to the same place is malware. An infostealer on a laptop doesn't need to phish anyone; it reads session cookies straight out of the browser. Google reported an 84% increase in email delivered infostealers in 2024 and Verizon's 2026 DBIR found infostealer malware on 54% of devices appearing in the initial-access-broker logs where stolen corporate logins are traded.
Both paths end with the same thing: an attacker holding a valid session your MFA already approved.
Why Passkeys and Security Keys Are Different
A code from an authenticator app is just a number. You can be tricked into typing it into the wrong page, because the number doesn't know what page it's on.
A passkey or hardware security key is cryptographically bound to the website it was registered for. When the proxy presents its lookalike domain, your key checks the origin, sees a domain it has no credential for and refuses silently, with no decision for you to make.
That is what "phishing-resistant" means. Not harder to phish. Structurally unable to be phished, because the thing being asked for is a signature only the real domain can request.
Google's documentation treats security keys and passkeys as equivalent here, noting both provide the same level of phishing protection. A passkey on a phone or laptop gets you the benefit without buying hardware.
1. Set 2SV Methods to "Only Security Key"
Security > Authentication > 2-Step Verification > Methods
This is the highest-leverage change in this post, it's available on every Google Workspace edition and most admins have never opened the setting.
Google gives you three options:
Any — the default. Everything is allowed, including SMS.
Any except verification codes via text, phone call — removes the weakest factors. A real improvement, still phishable.
Only security key — restricts everyone to security keys and passkeys. This is the one.
Despite the name, "Only security key" accepts passkeys too, so nobody has to buy anything. Most of your team can enroll a passkey on the laptop or phone they already carry.
How I'd roll it out. Start with the accounts where a compromise is worst. Founders, anyone with admin roles, finance and whoever handles customer data. Get them enrolled and confirm they can sign in. Then extend to the rest of the company with a grace period and close the grace period on a date you've actually put in the calendar. Use Google's 2SV policy suspension grace period so a lost key is a support ticket rather than a lockout. If your team is seeing the message that 2-Step Verification is enforced, the enforcement section below explains what it means and how to avoid lockouts.
Do this before anything else on this list.
2. Turn On Advanced Protection for the Accounts That Matter Most
Security > Authentication > Advanced Protection Program
Free on every edition, enrollment takes minutes and almost nobody at startup scale uses it. Advanced Protection enforces security keys or passkeys, applies stronger verification and blocks untrusted third-party OAuth apps by default for enrolled accounts.
Enroll your super admins, your founders and anyone whose account would be catastrophic to lose. Note that 2SV has to be enabled at the top-level organizational unit before enrollment becomes available and each enrolled user needs a backup factor on file.
3. You Already Have Session Binding On Some Machines
Device Bound Session Credentials (DBSC) ties a session cookie to the device that authenticated. A stolen cookie replayed from the attacker's machine doesn't work, because it's cryptographically bound to hardware it isn't running on. It attacks exactly the mechanism described earlier.
As of May 2026, DBSC is generally available and on by default for all Google Workspace customers. There is no admin setting — you can't enable it and you can't turn it off.
The caveat: it currently runs on Chrome for Windows only.
For Mac-heavy teams, that makes DBSC useful background protection. Not something to build your strategy around.
4. Shorten the Session Window
Security > Access and data control > Google session control (Business Plus and Enterprise editions)
A stolen session cookie is only useful while the session is valid, and Google's default web session length is 14 days. Shortening it forces re-authentication — which, once you've done item 1, means the attacker hits a passkey challenge they can't satisfy.
Eight to 24 hours suits most companies at this size. Not available on Business Starter or Business Standard, and note that the Admin console session is fixed at one hour regardless of what you set here.
5. Know What a Stolen Session Looks Like
Security > Alert center, and Reporting > Audit and investigation > Login audit log
The signs: a session appearing from a new country or unfamiliar IP shortly after a normal login. Two active sessions in places one person can't be, a new OAuth app authorized right after a login, new mail forwarding or filter rules, or a change to recovery options nobody requested.
Alert Center is available on all Business editions and most companies have never set where its alerts go. Route them to an address a human reads.
If you suspect a session is compromised, resetting the password is not enough. The attacker's cookie keeps working. Sign the user out of all sessions from the Admin console to invalidate it. Then reset the password, check OAuth grants, forwarding rules, filters, app passwords and recovery options for anything added recently. Those outlive the session that created them.
6. What Enterprise Adds
Two controls sit above the Business tiers and are worth knowing about, if only so you can tell whether you need them.
Context-aware access (Enterprise editions) makes access conditional on device state, location, or IP — so a valid session presented from an unmanaged machine in an unexpected place can be refused outright. This is the one capability in this post you genuinely cannot approximate on a Business edition.
Passwordless sign-in (Enterprise Standard and Plus, Frontline Standard and Plus, Enterprise Essentials Plus, Education Standard and Plus, Cloud Identity Premium) lets users skip the password entirely, leaving nothing to steal or reuse. Worth being precise, because people conflate these: passkeys as a 2SV method work on every edition. It's full passwordless login that's edition-dependent.
What Your Edition Supports
Feature availability verified September 2026 — confirm against your current Workspace edition before relying on it.
2SV method restriction ("Only security key") — all editions
Passkeys and security keys as a 2SV factor — all editions
Advanced Protection Program — all editions
Device Bound Session Credentials — all editions, automatic, Chrome on Windows only
Alert Center and login audit log — all editions
Fundamental endpoint management — all editions
Google session control (session length) — Business Plus and Enterprise
Context-aware access — Enterprise
Passwordless "skip passwords" — Enterprise tiers and Cloud Identity Premium, not Business
The Realistic Sequence
If you're starting from "we have 2SV turned on and that's it":
This week: enroll admins and founders in passkeys, then set 2SV methods to "Only security key" for that group.
This month: extend the method restriction company wide with a grace period and enroll admins in Advanced Protection.
This quarter: shorten session length if your edition supports it, point Alert Center at a monitored address and confirm every company laptop is enrolled in endpoint management.
Send the email explaining the change before you flip the switch. That's the step people skip, and it's why these projects stall.
What Does "2-Step Verification Is Enforced Across Your Organization" Mean?
It means a Google Workspace admin has turned on 2-Step Verification enforcement for your organization, or for the group or organizational unit you belong to. Once enforcement starts, anyone who hasn't set up 2-Step Verification may be unable to finish signing in until they enroll or bring their sign-in method into compliance with the policy. It usually means the account does not currently meet the organization's enforced 2-Step Verification requirements.
Enforced vs. Enrolled
Enforcement is an admin setting. It lives in the Admin console under Security > Authentication > 2-step verification and applies to the whole organization or to a specific organizational unit or group. Enrollment happens one user at a time, when each person adds a second step to their own account. That's why you can see 2-Step Verification "enforced" while some users still aren't enrolled: the rule is on, but those people haven't completed setup yet. Before you enforce, check 2-Step Verification enrollment in the Admin console's security reports so you know exactly who still has to do it.
Enrollment Period and Grace Period
These are two different settings, and they're easy to mix up.
The new user enrollment period gives people who join after enforcement starts time to set up 2-Step Verification before enforcement blocks sign-in. Google lets admins choose an enrollment period based on their rollout needs.
If the organization uses the "Only security key" enforcement method, Google also provides a 2-Step Verification policy suspension grace period. This lets an administrator generate a backup verification code so a user who has lost their security key can sign in temporarily while an approved replacement method is set up. Since Google added passkeys, the "Only security key" option supports both security keys and passkeys.
Common Enforcement Messages
The most common message users report is:
"Your sign-in settings don't meet your organization's 2-Step Verification policy."
It means the account doesn't currently meet the organization's 2-Step Verification policy. Usually either the user hasn't finished enrolling, or they enrolled with a sign-in method the current policy no longer accepts — for example, someone who set up text-message codes before the organization switched to "Only security key." The fix is to bring the account into compliance with the allowed methods rather than turning enforcement off for everyone.
Another message admins may see is:
"You must activate 2-step verification for your own account before enforcing it for your organization."
That is a reminder that administrators should secure their own accounts before requiring the policy for others.
Locked Out After Enforcement: How Admins Reset 2-Step Verification
If someone can't sign in, an admin can generate backup verification codes for that user from the Admin console and send them through a communication channel you've verified, such as a phone call. The user can sign in with a backup code and then set up an allowed 2-Step Verification method.
Google also documents a way to give users more time to enroll: put them in a configuration group where 2-Step Verification isn't enforced, then move them back into the enforced policy once they've enrolled. Treat it as a temporary exception, and note that a 2-Step Verification policy on a child organizational unit takes precedence over the group setting.
The bigger risk is an admin locking themselves out. Keep a second super admin enrolled and tested, and keep emergency access documented before you enforce anything. Our guide to Google Workspace super admin best practices covers how to set that up, and our account recovery and emergency access plan walks through the rest.
Frequently Asked Questions
Is MFA enough to protect Google Workspace?
No. Proofpoint found 65% of compromised cloud accounts had MFA enabled. Standard MFA using SMS codes, app codes or push prompts can be defeated by adversary in the middle phishing, where an attacker relays the login in real time and steals the session cookie. MFA remains essential; restricting it to passkeys and security keys is what closes the gap.
How do attackers bypass 2-Step Verification?
Most commonly through a proxy that relays the victim's traffic to the real Google sign in, so the password prompt and the 2SV challenge are both genuine. Once the user approves the challenge, Google issues a session cookie and the proxy captures it. The attacker imports that cookie and holds an authenticated session without the password or a second factor. Infostealer malware reaches the same result by reading cookies from the browser.
What is phishing-resistant MFA?
Authentication that cannot be relayed to a fake site, because the credential is cryptographically bound to the legitimate domain. Passkeys and hardware security keys qualify — they check the request's origin and refuse to sign for a lookalike domain. Codes and push prompts do not, because a code can be typed anywhere and a prompt can be approved for a login the user didn't start.
Are passkeys as secure as hardware security keys?
Google's documentation treats them as equivalent for phishing resistance. Hardware keys add physical separation from the device, which matters for the highest-risk accounts, but a passkey on a phone or laptop delivers the core benefit without buying anything. Google's "Only security key" setting accepts both.
Does Google Workspace protect against session cookie theft?
Partly, and automatically. Device Bound Session Credentials binds a session cookie to the device that authenticated it, so a stolen cookie fails when replayed elsewhere. It went generally available in May 2026, is on by default with no admin control, and currently runs on Chrome for Windows only — so Mac-based teams aren't covered today.
How long should a Google Workspace session last?
The default is 14 days. Eight to 24 hours is a reasonable target for most 5–50 person companies. It's set at Security > Access and data control > Google session control and requires Business Plus or Enterprise. The Admin console session is fixed at one hour and can't be changed.
What should I do if an account may be compromised?
Resetting the password alone isn't enough, because a stolen session cookie keeps working. Sign the user out of all sessions from the Admin console, reset the password, then audit for persistence: recent OAuth grants, mail forwarding rules, filters, app passwords, and changes to recovery phone or email.
Do I need Google Workspace Enterprise for phishing-resistant sign-in?
No. Restricting 2-Step Verification to security keys and passkeys works on every edition, as does Advanced Protection. Enterprise adds context-aware access and full passwordless sign-in meaningful additions, not prerequisites.
How do I enforce 2-factor authentication (2FA) in Google Workspace?
In the Admin console, go to Security > Authentication > 2-step verification. Select the organizational unit or group, allow users to turn on 2-Step Verification, choose an enforcement option such as turning it on now or from a start date, set a new user enrollment period, and choose which methods to allow. Give people a deadline and a short explanation before enforcement starts. Most avoidable lockouts happen when people are not prepared before enforcement begins.
How do I reset the 2-factor authentication (2FA) for a user in Google Workspace?
An admin can generate backup verification codes for the user from the user's security settings in the Admin console. The user can sign in with a backup code and then set up 2-Step Verification again with an allowed method. Confirm the user's identity before sending recovery codes, because reset requests can be used in social engineering attempts.
Take the Next Step
If your team has 2-Step Verification on and you're not sure whether it's the phishing-resistant kind, that's a five-minute check and usually the most valuable thing you'll do to your environment this quarter.
Our free Startup IT Readiness Assessment scores your environment across Google Workspace authentication, identity and access, devices, and monitoring, so you finish with a ranked list of what's missing.
👉 [Take the Free Startup IT Readiness Assessment]
If you'd rather have someone roll this out without locking your team out of their accounts, Carter Systems IT helps growing B2B software and AI companies across the San Francisco Bay Area move to phishing-resistant sign-in and tighten session controls.
👉 [Book a Free 15-Minute Startup IT Assessment]
Related Reading
Sources Cited
Proofpoint — cloud account compromise research (account takeover and MFA figures)
CrowdStrike, 2025 Global Threat Report (average breakout time)
Google Workspace Blog — Defending against account takeovers: top threats, passkeys and DBSC
Google Workspace Updates — Device Bound Session Credentials now generally available in Chrome for Windows (May 2026)
Google Workspace Admin Help — Deploy 2-Step Verification; Allow users to skip passwords at sign-in; Advanced Protection Program; Google session control
Verizon, 2026 Data Breach Investigations Report (infostealer prevalence)
