Securing Google Workspace is a shared responsibility, and the settings that matter most are the ones customer admins control, such as SMS codes as the only second factor, a dozen everyday super admins, or any user free to grant a third-party app access to their mailbox. This list ranks the ten Workspace configuration mistakes that most often turn one phished user into a mailbox, Drive or whole-tenant compromise, with how to check each, how to fix it and how to detect when it is being used. Each fix cites the matching policy in CISA's Secure Cloud Business Applications (SCuBA) Google Workspace baselines, which are public and testable with the ScubaGoggles tool. It is written for Workspace administrators, security teams and IT leads in organisations of any size. The full control set is in the Google Workspace Security Guide and the setting-by-setting list in the Google Workspace Security Checklist; this page is the short list of what goes wrong.
This is an independent guide from NHI Mgmt Group, based on Google's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.
The Top 10 at a glance
| # | Mistake | What it enables | SCuBA policy |
|---|---|---|---|
| 1 | 2-Step Verification optional, or SMS and voice allowed | Account takeover from a phished password or relayed code | GWS.COMMONCONTROLS.1.1 to 1.5 |
| 2 | Too many super admins, used day to day | One phished admin controls the whole tenant | GWS.COMMONCONTROLS.6.1, 6.2, 8.1, 9.1 |
| 3 | Users can grant any third-party app access | Consent phishing and token theft that bypasses MFA | GWS.COMMONCONTROLS.10.1 to 10.4, 11.1 |
| 4 | Over-scoped domain-wide delegation | A service account that reads every user's mail and files | Admin console API controls |
| 5 | Legacy access left on: POP, IMAP and less secure apps | Password-only access paths that skip modern controls | GWS.COMMONCONTROLS.10.5, GWS.GMAIL.9.1 |
| 6 | Open Drive sharing and "anyone with the link" | Files readable by anyone who obtains the URL | GWS.DRIVEDOCS.1.1 to 1.8 |
| 7 | Automatic forwarding and mail delegation allowed | Silent, persistent copying of mail to an attacker | GWS.GMAIL.1.1, 11.1, 12.1 |
| 8 | Weak SPF, DKIM and DMARC | Spoofing of your domain to customers and staff | GWS.GMAIL.2.1, 3.1, 4.1, 4.2 |
| 9 | Alerts off and logs left in the console | Compromise noticed weeks late, or never | GWS.COMMONCONTROLS.13.1, 14.1, 14.2 |
| 10 | Long sessions and no device or context checks | Stolen sessions that last, access from any device | GWS.COMMONCONTROLS.2.1, 4.1, 12.1 |
The ranking is our editorial judgement of how directly each mistake leads to compromise. Items 1 to 5 decide who and what can get in; items 6 to 8 decide what leaves; items 9 and 10 decide how long an attacker stays.
1. 2-Step Verification optional, or SMS and voice allowed
The mistake: 2-Step Verification (2SV) left to user choice, SMS or voice codes accepted, long enrolment grace periods, and "Allow users to trust the device" left on.
Why it matters: a password from a phishing page or a spraying run is enough to sign in (MITRE ATT&CK T1110.003 Password Spraying), and SMS or one-time codes can be relayed by adversary-in-the-middle kits. Trusted devices skip 2SV on later sign-ins, so a stolen laptop or browser profile keeps working.
How to check: in the 2SV settings for each organisational unit, record enforcement status, allowed methods, the new-user enrolment period and the trust device option. Run the Security report for users not enrolled.
How to fix: SCuBA requires phishing-resistant MFA for all users (GWS.COMMONCONTROLS.1.1), an alternative MFA method where that is not yet possible (1.2), no SMS or voice (1.3), an enrolment period between one day and one week (1.4) and trusted devices disabled (1.5). Roll out security keys or passkeys to admins first, then high-risk groups. If you federate sign-in to another identity provider, enable post-SSO verification (3.1, 3.2) or Google's 2SV settings are not applied to those users. See the Top 10 MFA Mistakes.
2. Too many super admins, used day to day
The mistake: super admin granted to every IT staff member, the same account used for email and browsing, admin accounts synced from the on-premises directory, and self-service recovery left on.
Why it matters: a super admin can reset any password, change 2SV, authorise domain-wide delegation and export data. One phished super admin is a tenant compromise (ATT&CK T1078.004 Cloud Accounts).
How to check: list holders of the Super Admin role and of custom roles with user, security or API control privileges, and whether each account is also used for daily work.
How to fix: SCuBA sets a minimum of two and a maximum of eight separate super admin users (GWS.COMMONCONTROLS.6.2), admin accounts as cloud-only accounts separate from federated identity (6.1), super admin self-recovery disabled (8.1) and highly privileged accounts enrolled in the Google Advanced Protection Program (9.1). Give each admin a separate admin account used only for administration, delegate narrower admin roles for routine tasks, and turn on multi-party approval for sensitive admin actions (17.1). See the Admin panels and super admin accounts guide.
3. Users can grant any third-party app access
The mistake: API controls left at defaults, so any user can approve any OAuth app, including unverified ones, to read mail, Drive or calendar.
Why it matters: consent issues a token without a new sign-in, so MFA does not help (ATT&CK T1528 Steal Application Access Token). A user with MFA can still approve a malicious app through a genuine consent screen, so restrict which apps users can authorise.
How to check: review the accessed apps list in API controls, sorted by number of users and by scopes requested, and look for apps marked unconfigured or unverified.
How to fix: use app access control to restrict access to Workspace services by third-party apps (GWS.COMMONCONTROLS.10.1), do not let users consent to low-risk scopes on their own (10.2), do not trust unconfigured internal apps (10.3), block unconfigured third-party apps (10.4) and allow only approved Marketplace apps (11.1). Mark the apps you rely on as trusted or limited, then switch the default to blocked. Review OAuth token events monthly. See the SaaS and OAuth App Governance Guide.
4. Over-scoped domain-wide delegation
The mistake: service accounts authorised for domain-wide delegation (DWD) with full Gmail or Drive scopes for a migration or integration, and never removed.
Why it matters: Google's own admin documentation warns that a client with DWD can access data belonging to all of your users without their consent. Whoever holds that service account's key or can impersonate it in Google Cloud can read every mailbox. This is a non-human identity risk that crosses from Google Cloud IAM into Workspace.
How to check: list every client ID under domain-wide delegation with its scopes, trace each to its Google Cloud project and service account, and check who can create keys for or impersonate that account.
How to fix: Google recommends keeping scopes as narrow as possible, reviewing them periodically, deleting clients you no longer need (a migration tool after the migration) and deleting unused service accounts. Only super admins can manage DWD, and multi-party approval, where enabled, requires a second super admin to approve changes. Scope changes can take up to 24 hours to apply. See the Google Workspace Domain-Wide Delegation Security Guide and How to audit Google Workspace domain-wide delegation grants.
5. Legacy access left on: POP, IMAP and less secure apps
The mistake: POP and IMAP enabled for all users, and old mail clients, scanners and scripts still connecting with passwords or app passwords.
Why it matters: legacy protocols give mail access through clients that do not enforce context-aware access, and they keep alive the password-based paths that attackers spray.
How to check: review POP and IMAP settings per organisational unit and the login audit for sign-ins by protocol and by app password.
How to fix: SCuBA requires POP and IMAP to be disabled (GWS.GMAIL.9.1) and access by less secure apps to be prevented (GWS.COMMONCONTROLS.10.5). Move devices that send mail, such as printers, to the SMTP relay service with IP restrictions. See Google Workspace Less Secure Apps Retirement.
6. Open Drive sharing and "anyone with the link"
The mistake: external sharing allowed to any domain, "anyone with the link" available, and new files created shared with the whole organisation by default.
Why it matters: link-shared files spread through email threads, chat and search indexes. Once a link is out, anyone who has it can read the file (ATT&CK T1530 Data from Cloud Storage).
How to check: run a Drive audit or security investigation for files shared externally or publicly, grouped by owner and by organisational unit.
How to fix: SCuBA restricts external sharing to allowlisted domains (GWS.DRIVEDOCS.1.1), requires warnings when sharing outside them (1.3), recommends disabling "anyone with the link" in units that allow external sharing (1.5), sets access checking to "recipients only" (1.6) and makes "private to owner" the default for new items (1.8). Apply the stricter settings to the organisational units holding sensitive data first, and use shared drives with managed membership for team content.
7. Automatic forwarding and mail delegation allowed
The mistake: users free to set up automatic forwarding to any address, grant mailbox delegation, or route outbound mail through their own gateway.
Why it matters: a forwarding rule or delegate added during a short compromise keeps copying mail after the password is reset (ATT&CK T1114.003 Email Forwarding Rule). Business email compromise crews rely on this to watch invoice threads.
How to check: search admin and email logs for forwarding addresses and delegates added in the last 90 days, especially to external domains.
How to fix: SCuBA recommends disabling automatic forwarding, especially to external domains (GWS.GMAIL.11.1), and mail delegation (1.1), and requires that per-user outbound gateways be disabled (12.1). Where forwarding is genuinely needed, allow it per organisational unit with an approved destination list. Turn on unintended external reply warnings (13.1).
8. Weak SPF, DKIM and DMARC
The mistake: DKIM signing never switched on, SPF records ending in a soft fail, and DMARC left at p=none indefinitely.
Why it matters: anyone can send mail that appears to come from your domain to your customers, suppliers and staff (ATT&CK T1566.002 Spearphishing Link).
How to check: query DNS for each sending and alias domain, and confirm DKIM is on for each domain in the Gmail authentication settings.
How to fix: SCuBA recommends DKIM for all domains (GWS.GMAIL.2.1), requires an SPF policy that fails all non-approved senders (3.1), a DMARC record for every Workspace domain including alias domains (4.1) and p=reject (4.2). Also enable Gmail's spoofing protections for similar domain names, employee names and inbound mail spoofing your domain (7.1 to 7.4), and never add domains to spam filter bypass lists (18.1). See the Top 10 Email Authentication Mistakes.
9. Alerts off and logs left in the console
The mistake: system-defined alert rules not reviewed, nobody receiving the alert emails, and audit logs kept only in the Admin console.
Why it matters: Google raises alerts for suspicious sign-ins, government-backed attacks and admin privilege changes, but an alert nobody reads is the same as no alert. Console retention also limits how far back an investigation can go.
How to check: open Rules, filter to system-defined, and confirm each rule has alerts on and a monitored recipient. Check whether any logs reach your SIEM.
How to fix: SCuBA requires the listed system-defined alerting rules to be enabled with alerts (GWS.COMMONCONTROLS.13.1), the Admin, Enterprise Groups, Login, OAuth Token, SAML and Context-Aware Access logs to be sent to a central SIEM (14.1), and audit logs to be searchable for at least three months and retrievable for at least twelve (14.2). See the Google Workspace Audit Log Detection Guide.
10. Long sessions and no device or context checks
The mistake: default session lengths, no context-aware access, any personal device able to sync Drive, and Google Takeout open to every user.
Why it matters: a session cookie stolen by an infostealer works until it expires, and unmanaged devices keep offline copies of mail and files. Takeout lets a departing or compromised user export a whole account in one job (ATT&CK T1567.002 Exfiltration to Cloud Storage).
How to check: review session length settings, context-aware access levels assigned to apps, Drive for desktop settings and Takeout status per organisational unit.
How to fix: SCuBA requires re-authentication after a 12-hour session (GWS.COMMONCONTROLS.4.1), recommends context-aware access policies based on device signals (2.1), allows Drive for desktop only on authorised devices (GWS.DRIVEDOCS.5.1) and requires Takeout to be disabled (GWS.COMMONCONTROLS.12.1). Start with context-aware access for admin accounts and the Admin console, then extend to Drive and Gmail.
Detection: what to alert on
| Log source | Event to alert on | Mistake it exposes |
|---|---|---|
| Admin audit log | Super Admin or privileged custom role assigned; 2SV enforcement changed for a unit | 1, 2 |
| Admin audit log | Client authorised or scopes changed under domain-wide delegation | 4 |
| OAuth Token audit log | New grant to an app with Gmail, Drive or admin scopes, or the same app granted by many users in a short window | 3 |
| Login audit log | Sign-in via POP, IMAP or app password; suspicious sign-in; 2SV disabled by user | 1, 5 |
| Drive audit log | Visibility changed to public or external on files in sensitive units | 6 |
| Admin and Gmail logs | Forwarding address or mail delegate added, especially to an external domain | 7 |
| Admin audit log | Alert rules disabled, log export settings changed, Takeout enabled | 9, 10 |
Track five measures: percentage of users on phishing-resistant MFA (admins at 100 percent); super admin count between two and eight; third-party apps with restricted-scope access that are not on the approved list (target zero); files shared publicly in sensitive units; and median time from a high-severity Workspace alert to triage.
Common failure patterns
- Fixing the root unit only: settings applied to the top organisational unit are overridden by older settings on child units. Check every unit and group-based override.
- Blocking new apps, keeping old tokens: changing API controls does not remove tokens users already granted. Revoke them as part of the change.
- Federated sign-in without post-SSO verification: admins enforce 2SV in Google and assume it applies, while SSO users never see it.
- Break-glass account that is also a daily account: the emergency super admin has a mailbox, a browser profile and no security key.
- DMARC stuck at p=none: reports are collected for years and nothing is ever rejected.
- Groups open to the world: SCuBA requires that group access from outside the organisation be disabled unless the owner grants it (GWS.GROUPS.1.1); public groups leak internal threads and can be used to send mail as an internal list.
Mapping to ATT&CK and NIST
| Item | MITRE ATT&CK | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|---|
| 1. 2SV and methods | T1110.003, T1621 | IA-2(1) | PR.AA-03 |
| 2. Super admins | T1078.004 | AC-6(5) | PR.AA-05 |
| 3, 4. Apps and delegation | T1528 | AC-6, AC-3 | PR.AA-05 |
| 5. Legacy access | T1078.004 | IA-2 | PR.AA-03 |
| 6. Drive sharing | T1530 | AC-21 | PR.DS-01 |
| 7. Forwarding | T1114.003 | AC-21 | PR.DS-01 |
| 8. Email authentication | T1566.002 | SI-8 | PR.PS-01 |
| 9. Alerts and logs | T1685 | SI-4(5), AU-11 | DE.CM-03 |
| 10. Sessions and context | T1567.002 | AC-12 | PR.AA-03 |
Where to start
- Week one, read only: run ScubaGoggles against the tenant to get a baseline report against the SCuBA policies, and record the five measures above.
- Week one: cut super admins to between two and eight, give each a separate admin account with a security key, and enrol them in Advanced Protection (item 2).
- Weeks two to four: review accessed apps, mark the approved ones trusted or limited, revoke the rest, and switch unconfigured third-party apps to blocked; remove DWD clients nobody owns (items 3 and 4).
- Month two: enforce 2SV without SMS for all users in waves by organisational unit, disable POP, IMAP and automatic external forwarding (items 1, 5, 7).
- Month three: tighten Drive sharing on sensitive units, move DMARC to p=reject after reviewing reports, send logs to the SIEM and apply context-aware access to admins (items 6, 8, 9, 10).
- Test and roll back: apply each change to a pilot organisational unit or group first, watch the help desk and login audit for a week, and roll back by moving the pilot back to its previous unit rather than changing the setting tenant-wide.
Small businesses can complete most of this from the Admin console in a few weeks; see Google Workspace for Small Business. Large tenants should manage settings by organisational unit and group, run ScubaGoggles on a schedule to catch drift, and follow the Google Workspace Compromise Playbook if one of these mistakes has already been used.
Practitioner checklist
- 2SV enforced for all users; SMS and voice not allowed; trusted devices off; admins on security keys or passkeys.
- Post-SSO verification on for federated users.
- Two to eight super admins, each a separate cloud-only admin account enrolled in Advanced Protection; self-recovery off.
- Unconfigured third-party apps blocked; approved apps marked trusted or limited; existing tokens reviewed.
- Every domain-wide delegation client has an owner, minimal scopes and a review date.
- POP, IMAP and less secure app access disabled.
- External Drive sharing limited to allowlisted domains; new files private to owner.
- Automatic external forwarding, mail delegation and per-user outbound gateways disabled.
- DKIM on, SPF failing unapproved senders and DMARC at p=reject for every domain.
- System-defined alert rules on with a monitored recipient; key logs in the SIEM with 12 months' retention.
Standards and references
- CISA: SCuBA Google Workspace Common Controls Baseline
- CISA: SCuBA Google Workspace Gmail Baseline
- CISA: SCuBA Google Workspace Drive and Docs Baseline
- CISA: SCuBA Google Workspace Groups for Business Baseline
- Google Workspace Admin Help: Control API access with domain-wide delegation
- CISA: ScubaGoggles assessment tool
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Google Workspace Security Guide · Google Workspace Security Checklist · Google Workspace Compromise Playbook · Top 10 Microsoft 365 Security Misconfigurations · Top 10 OAuth Security Risks