Google Workspace Security Guide

A Google Workspace tenant keeps an organisation's mail, files, chat and meetings behind one Admin console, and many of its defaults favour convenience over security. Users can sign in to any third-party app with their Google account, files can be shared outside the domain, and one super admin session or domain-wide delegation grant can reach every mailbox. This guide covers the settings that matter most, by Admin console name and mapped to the CISA SCuBA Google Workspace baselines, from 2-Step Verification and OAuth app trust to Gmail, Drive, DLP, Vault and audit logging. It is written for Workspace administrators and security engineers.

Key takeaways

• Measure against a published baseline. The CISA SCuBA baselines give numbered, testable policies such as GWS.COMMONCONTROLS.1.1v1, and ScubaGoggles checks a tenant against them.
• Security keys or passkeys for admins. Enforce the "Only security key" 2SV method and enrol super admins in the Advanced Protection Program.
• Unconfigured third-party apps are allowed by default. Change "Allow any third-party apps" under API controls and restrict Gmail and Drive as services.
• Domain-wide delegation is tenant-wide access. An authorised client "has access to the data belonging to all of your users", so its service account key is a privileged credential.
• Logs expire unless exported. Activity data is kept for 180 days; send Login, Admin, OAuth Token, SAML and Context-Aware Access events to a SIEM.

Baselines and edition dependencies

The NCSC cloud security principles that depend most on customer configuration are 9 (secure user management), 10 (identity and authentication), 13 (audit information and alerting for customers) and 14 (secure use of the service).

Several controls depend on edition. Google's help pages list:

None of these lists includes the Business editions. A Business tenant can still apply every sign-in, app access, Gmail and sharing setting below, but collects logs through the Reports API and has no device-based access policies.

Sign-in: 2-Step Verification, security keys and Advanced Protection

2-Step Verification (2SV) is set at Security > Authentication > 2-step verification, per organisational unit (OU) or configuration group. Google's sequence is: tick "Allow users to turn on 2-Step Verification" with Enforcement off, let users enrol, track enrolment in Reporting > User Reports > Security, then enforce.

• Methods: "Any" allows SMS and voice. "Any except verification codes via text, phone call" removes them, as GWS.COMMONCONTROLS.1.3v1 requires. "Only security key", which now accepts passkeys, is the phishing-resistant method required for all users by 1.1v1. Pair it with a "2-Step Verification policy suspension grace period" so admins can issue backup codes.
• Enforcement and enrolment: "Turn on enforcement from date" reminds users and takes 24 to 48 hours to apply. Keep the new user enrollment period between one day and one week (1.4v1).
• Trusted devices: disable "Allow user to trust the device" (1.5v1); Google advises against it unless users often switch devices.
• Session and SSO: force re-authentication after 12 hours under Security > Access and data control > Google session control (4.1v1), and enable post-SSO verification under Login challenges when another identity provider signs users in (3.1v1, 3.2v1).
• Account recovery: disable self-recovery for super admins and users (8.1v1, 8.2v1) so a hijacked recovery phone is not a way in. See the Account Recovery and Help Desk Security Guide.

The Advanced Protection Program (APP) bundles stronger settings for high-risk accounts: sign-in requires a security key or passkey, even with a third-party identity provider; apps requesting high-risk scopes are blocked unless an admin trusts them; Gmail applies enhanced pre-delivery scanning and, for enterprise users, the security sandbox; Chrome warns on downloads it cannot verify; and recovery goes through an admin. SCuBA requires APP for highly privileged accounts (9.1v1) and recommends it for sensitive users (9.2v1). See the Phishing-Resistant MFA Guide.

Super admins and delegated admin roles

A super admin can change every setting and authorise domain-wide delegation. Google's administrator best practices and SCuBA agree on the essentials:

• Count: more than one super admin, each a separate person; SCuBA sets two to eight, excluding break-glass accounts (6.2v1).
• Separate, cloud-only accounts: an identifiable admin account plus a non-admin account for daily work, provisioned in Google rather than federated (6.1v1). Super admins cannot sign in through a third-party IdP anyway. Do not stay signed in.
• Recovery material: two security keys per admin, the spare stored safely, plus printed backup codes. See the Break-Glass Account Guide.
• Delegated roles: limited roles with only the privileges needed.
• Multi-party approval: enable "Require multi-party approval for sensitive admin actions" (17.1v1). Authorising, editing or deleting a domain-wide delegation client then needs a second super admin.

Context-aware access and device signals

Context-Aware Access (CAA), at Security > Access and data control > Context-Aware Access, grants access based on user identity, IP range, geographic origin, device policy and OS, company-owned status or custom expressions. Start with Admin console access only from company-owned devices (SCuBA 2.1v1).

• Coverage: core services including Gmail, Drive and Docs, Meet, Chat, Calendar, Vault, Gemini and the Admin console are evaluated continuously; SAML apps only at sign-in.
• Service accounts are out of scope: policies "apply only to end-user accounts, not Google API calls from service accounts". Backup, migration and eDiscovery tools are blocked unless their subnets are allowed or their service account is exempted, and each exemption is a path CAA no longer protects.

See the Zero Trust Identity Guide.

Where identity fits: OAuth apps, domain-wide delegation and service accounts

API controls (Security > Access and data control > API controls) decide which OAuth apps can obtain tokens for Workspace data, and data theft that does not start with a password usually starts with one of those tokens:

Under Manage Google Services, restrict Gmail and Drive so only Trusted or Specific Google data apps reach them, or restrict just their high-risk scopes (sending mail, deleting Drive files). Restricting a service revokes the tokens of untrusted apps already installed, so inventory the accessed-apps list first; it can take 48 hours to update. SCuBA 10.1v1 to 10.5v1 require app access control on all services, no user consent even for low-risk scopes, no automatic trust for unconfigured internal apps and blocking less secure apps; 11.1v1 limits Marketplace installs to approved apps. Allow user requests so blocked apps land in "Apps pending review". The Cyberhaven Chrome extension breach began with one consent on a Google account.

Domain-wide delegation (Manage Domain Wide Delegation, super admins only) lets a service account or OAuth client act as any user for the listed scopes, without consent.

• Scopes: authorise the narrowest scope, for example read-only Calendar rather than full Gmail, and confirm what is stored under View details.
• The key is the identity: a delegated service account with a JSON key is a non-expiring credential for every mailbox in scope. Prefer keyless authentication and block key creation with the organisation policy described in the Google Cloud Security Guide.
• Ownership: record an owner and purpose per client ID, review quarterly and delete unused clients. Deletion stops dependent apps immediately; scope changes can take up to 24 hours.
• Vendor integrations: in the Salesloft Drift breach, Google's threat intelligence team reported that Drift Email tokens were also used to access Google Workspace accounts.

See the SaaS and OAuth App Governance Guide, the OAuth 2.0 and OpenID Connect Guide and the Service Account Security Guide.

Gmail protection

Gmail settings sit under Apps > Google Workspace > Gmail, in Safety, End User Access and Spam, phishing, and malware.

Enable DKIM for every domain under Gmail > Authenticate email (2.1), publish SPF that fails non-approved senders (3.1) and move DMARC to p=reject (4.2). See the DMARC, SPF and DKIM Guide and the Email Security Guide.

Drive, Chat and Meet sharing

Drive settings are at Apps > Google Workspace > Drive and Docs > Sharing settings. Set them per OU, so sales can share externally while finance cannot.

• External sharing: restrict to allowlisted domains (GWS.DRIVEDOCS.1.1v1) with warnings (1.3v1). Where an OU must share wider, block sharing with people without a Google account (1.4v1) and "anyone with the link" (1.5v1).
• Defaults: "Private to owner" for new items (1.8v1), access checker "recipients only" (1.6v1), and "Mark files shared or owned externally" (1.9v1).
• Shared drives: stop managers overriding creation settings (2.1v1) and block moving content to another organisation's shared drives (1.7v1).
• Integrations: disable Drive SDK access where unused (4.1v1), allow Drive for desktop only on authorised devices (5.1v1), and turn on ransomware monitoring for unusual file changes (5.2v1).
• Chat: history on and locked (GWS.CHAT.1.1v1, 1.2v1), external file sharing "No files" (2.1v1), external chat limited to allowlisted domains (4.1v1), content reporting on (5.1v1). See the Collaboration Tool Security Guide.
• Meet: uninvited external users ask to join (GWS.MEET.1.1v1), meetings created outside any Workspace tenant blocked (2.1v1), host management on (3.1v1), external participants labelled (4.1v1), automatic recording and transcripts off (5.1v1, 5.2v1).

DLP, Takeout and Vault retention

Workspace DLP applies rules to Drive, Gmail, Chat and Calendar, and DLP for Chrome extends them to the browser. Actions range from audit to warn to block, and rules can depend on Context-Aware Access conditions. SCuBA asks for a custom policy across all four services detecting at least payment card numbers and US taxpayer and social security numbers (GWS.COMMONCONTROLS.18.1v1), set to block (18.2v1). See the Data Loss Prevention (DLP) Guide. Disable Google Takeout for managed users (12.1v1), and Early Access apps and additional services that have no individual control (16.1v1, 16.2v1).

Vault retention decides how long data survives deletion. Each service has at most one default rule; custom rules target accounts or conditions, the latest expiry wins, and holds override retention. Google warns: "An improperly set up retention rule might allow Google services to immediately and irreversibly purge data." Test rules on a small group; expired data stays available to Vault administrators for only about 30 days. Turn on comprehensive mail storage (GWS.GMAIL.17.1v1). Vault is not a backup: see the Backup Security and Immutable Backup Guide.

Audit, alerting and SIEM export

Activity logs are in Reporting > Audit and investigation and are retained for 180 days. SCuBA requires the Admin, Enterprise Groups, Login, OAuth Token, SAML and Context Aware Access audit logs in a SIEM (14.1v1), searchable for three months and retrievable for twelve (14.2v1).

• BigQuery export: Reporting > Data integrations, with the Reports administrator privilege; [email protected] needs an editor role on the project. Events arrive within about 10 minutes, tables expire after 60 days unless you change it, and activity logs incur ingestion charges.
• Alert center: enable the required system-defined rules (13.1v1). Alerts include "Leaked password", "Suspicious login blocked", "User granted Admin privilege", "Device compromised" and "Government-backed attacks"; settings-change alerts link to "Search in audit logs".
• Security investigation tool: searches Gmail messages and logs, Drive logs, devices and users, and can erase malicious messages from inboxes. Admin queries in it are logged.

Build detections for: OAuth Token grants of Gmail or Drive scopes to untrusted apps (T1528, T1671); new delegation clients or scope changes; super admin grants (T1098.003); 2SV turned off for an admin; mail forwarding changes (T1114.003); mass external sharing or ownership transfer (T1530, T1537); sign-ins from new countries (T1078.004); and password spray or repeated 2SV prompts (T1110.003, T1621). See the SIEM Guide and the Log Management and Retention Guide.

Metrics that show it is working:

• ScubaGoggles SHALL pass rate per run, with every failure fixed or accepted as risk.
• Admins on "Only security key" or APP (target 100 percent).
• Super admin count (two to eight) and delegation clients without a named owner (target 0).
• Third-party apps holding Gmail or Drive scopes without Trusted or Specific Google data status (trending to 0).
• Files shared with "anyone with the link" or non-allowlisted domains, trending down.

Implementation plan

1. Assess: run ScubaGoggles and start log export before changing anything, so each change can be measured.
2. Protect admins: separate admin accounts with two keys each, "Only security key" on an admin OU, APP enrolment, no super admin self-recovery, multi-party approval. Keep one break-glass super admin outside the new OU until the rest are proven.
3. Inventory apps: export accessed apps and delegation clients, assign owners, configure the apps you keep.
4. Close the app door: move unconfigured apps to "Allow only basic-info apps", then restrict Gmail and Drive on a pilot OU for a week. Untrusted tokens are revoked on restriction, so rolling back restores access only after users consent again.
5. All-user 2SV: enforce from a date, then remove SMS and voice; move high-risk groups to keys.
6. Mail and sharing: apply the Gmail table, turn off forwarding and POP and IMAP after checking business use, tighten Drive defaults for new items, then review existing external shares.
7. Devices, DLP and retention: deploy Endpoint Verification, run CAA in warn mode then enforce, run DLP in audit, test Vault rules on a small group.
8. Operate: rerun ScubaGoggles monthly; review metrics quarterly.

Decision guidance

• "Only security key" or APP: the 2SV method is an OU setting you control; APP adds app restrictions, stricter scanning and admin-led recovery. Use both for admins and executives; roll "Only security key" out more widely first, because APP recovery adds help desk work.
• Block all third-party apps or basic-info only: blocking is cleanest but needs a working approval queue; basic-info keeps Sign in with Google working while stopping data scopes. Most organisations start with basic-info.
• Allowlisted domains or open sharing: allowlisting suits regulated teams with known partners. Others can keep sharing on for named OUs, without "anyone with the link", and add DLP.
• Small and large tenants: a Business tenant should prioritise 2SV methods, app access, Gmail safety, sharing defaults and Reports API logs. Enterprise tenants add CAA, BigQuery export, blocking DLP and ScubaGoggles in change control.

Framework mapping

Common failure patterns

• Default app access left on: any user can grant a convincing app offline access to mail and files, and a password reset does not revoke it. Revoke the token too.
• Delegation grants nobody owns: broad Gmail or Drive scopes from an old migration project, with a service account key still valid.
• Personal accounts on work devices: the Okta support system breach traced back to a service account credential saved in an employee's personal Google profile. Use CAA and Chrome management to keep corporate data in managed accounts.
• Retention defaults: logs left at 180 days, BigQuery tables at 60, or a Vault rule purging data the organisation had to keep.
• Gemini outside the review: AI features read the same mail, calendars and files; the Gemini Calendar prompt injection used a calendar invite. Include Gemini in CAA, DLP and Vault scope.

Practitioner checklist

• Run ScubaGoggles, keep the report as a baseline, rerun after every change window.
• Keep two to eight cloud-only super admins with separate daily accounts, two keys each, APP and multi-party approval.
• Enforce 2SV for all, remove SMS and voice, require "Only security key" for admins, disable trusted devices and self-recovery.
• Change the default for unconfigured third-party apps and restrict Gmail and Drive.
• Review delegation clients and scopes quarterly; remove service account keys where keyless options exist.
• Apply Gmail attachment, link and spoofing protections, disable forwarding and POP and IMAP, move DMARC to p=reject.
• Default Drive items to "Private to owner", restrict external sharing by OU, set Chat and Meet external controls.
• Run DLP in audit then block; test Vault rules on a small group.
• Export the six SCuBA audit logs to a SIEM with 12 months' retention.

Standards and references

• CISA: Google Workspace Common Controls Minimum Viable Secure Configuration Baseline
• CISA: Google Gmail Minimum Viable Secure Configuration Baseline
• CISA: Google Drive and Docs Minimum Viable Secure Configuration Baseline
• Google Workspace Admin Help: Control which apps access Google Workspace data
• Google Workspace Admin Help: Control API access with domain-wide delegation
• Google Workspace Admin Help: Protect users with the Advanced Protection Program
• CIS: Google Workspace Benchmarks
• NCSC: The cloud security principles

Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · Microsoft 365 Security Guide · SaaS Security Guide · Google Cloud Security Guide · Service Account Security Guide