Google Workspace Security Hardening: Admin Console to Zero Trust
Google Workspace is the productivity platform for hundreds of millions of users, and its default configuration prioritizes ease of use over security. Many organizations complete initial setup and never revisit the Admin Console's security settings -- leaving MFA unenforced, external sharing unrestricted, OAuth apps uncontrolled, and audit logging unconfigured. This guide walks through every significant security control in Google Workspace, organized by risk priority, with exact Admin Console navigation paths and the configuration values that represent a defensible security posture.
Authentication and MFA Hardening
Authentication controls are the first and most important layer. Account takeover is the primary Google Workspace attack vector.
Enforce 2-Step Verification (2SV) organization-wide:
Admin Console path: Security > Authentication > 2-step verification
Settings:
- Allow users to turn on 2-Step Verification: On
- Enforcement: Turn on enforcement now (or set a grace period for rollout)
- New user enrollment period: 1 week (maximum)
- Methods allowed: Any (initially); migrate to Security keys only or Passkeys only for privileged users
Phishing-resistant MFA for admins:
Require hardware security keys (FIDO2/WebAuthn) or passkeys for all super admins and delegated admin accounts. SMS and TOTP are phishable via real-time phishing proxies (Evilginx2, Modlishka). Configure at:
Admin Console > Security > Authentication > 2-step verification > Security key enforcement: Require security key
Apply this policy to admin organizational units (OUs) before expanding to the full user base.
Password policy:
Admin Console > Security > Authentication > Password management
- Minimum length: 12 characters
- Strength and length enforcement: On
- Allow password reuse: Off
- Expiration: Never (NIST 800-63B guidance: do not force routine expiration without evidence of compromise; expiration drives password cycling patterns)
Login challenges:
Admin Console > Security > Authentication > Login challenges
Enable:
- Post-SSO verification -- requires re-authentication for sensitive operations
- Login activity monitoring -- flags sign-ins from new devices or unusual locations
Super admin account hygiene:
- Create dedicated super admin accounts separate from day-to-day user accounts (e.g., admin@domain.com for daily use; superadmin@domain.com for admin-only tasks with hardware key required)
- Super admin accounts should never have Google Workspace licenses -- this reduces their exposure in phishing attacks
- Enable Admin alerts for super admin sign-in at: Admin Console > Reporting > Audit and investigation > Admin log events
Context-Aware Access (Zero Trust for Workspace)
Context-Aware Access (CAA) is Google Workspace's zero trust enforcement layer. It allows you to define access policies based on device posture, network location, and user attributes -- blocking access that does not meet your policy even if credentials are valid.
Requirements: Google Workspace Enterprise Standard, Enterprise Plus, Education Plus, or Cloud Identity Premium.
Enable and configure access levels:
Admin Console > Security > Access and data control > Context-Aware Access
Steps:
-
Enable the BeyondCorp enterprise extension or Google's Endpoint Verification Chrome extension on managed devices
-
Create access levels (Security > Access and data control > Context-Aware Access > Access levels > Add access level):
- Corporate managed device: Requires Endpoint Verification, device encrypted, screen lock enabled, OS up to date
- Corporate network: Requires source IP in your office or VPN CIDR range
- High-assurance: Requires corporate managed device AND registered device
-
Apply access levels to Workspace apps:
- Gmail: require Corporate managed device for access outside corporate network
- Drive: require Corporate managed device for external sharing
- Admin Console: require High-assurance (hardware key + managed device)
Example access level conditions:
| Access Level | Device Encrypted | Screen Lock | OS Patch | Registered |
|---|---|---|---|---|
| Basic | Yes | Yes | No | No |
| Managed Device | Yes | Yes | Yes | Yes |
| High Assurance | Yes | Yes | Yes | Yes + Hardware Key |
What CAA protects against:
- Credential-stuffed accounts accessed from attacker infrastructure
- Stolen session tokens used from non-corporate devices
- Personal device access to sensitive Workspace data without MDM enrollment
- Access from high-risk geographic regions (use IP-based access levels)
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Google Drive Sharing and DLP Controls
Google Drive external sharing is the most common data loss vector in Workspace environments. Overly permissive defaults allow users to share files publicly or with any Google account without IT visibility.
External sharing restrictions:
Admin Console > Apps > Google Workspace > Drive and Docs > Sharing settings
Recommended settings:
- Sharing options: Users in [your domain] can share files with anyone -- but set Warn when sharing outside domain to On
- For high-security OUs (finance, legal, executives): restrict to Users can only share within the domain and approved domains
- Prevent users from changing this setting: On
Link sharing defaults:
Change the default link sharing from "Anyone with the link" to:
- Restricted (only specific people) as the default for all new files
- Users can still change to broader sharing, but must actively choose to do so
Admin Console > Apps > Google Workspace > Drive and Docs > Link sharing
Google Workspace DLP (Data Loss Prevention):
Admin Console > Security > Access and data control > Data protection
Create DLP rules for sensitive data patterns:
- Credit card numbers in Drive: Scan Drive files for PAN patterns; block sharing externally; alert admin
- Social Security Numbers in Gmail: Block outbound Gmail with SSN patterns; quarantine for review
- Source code in Drive: Alert when files with code patterns (.py, .js, .go extensions) are shared externally
DLP rule structure:
- Trigger: Sharing event (Drive) or Send event (Gmail)
- Condition: Content matches [predefined detectors or custom regex]
- Action: Block, Warn, Quarantine, or Audit
Shared drives governance:
- Audit shared drives with external members: Admin Console > Reporting > Audit > Drive
- Require manager approval for new shared drives: Apps > Google Workspace > Drive > Shared drives settings
- Disable "Anyone with the link" for shared drives in sensitive OUs
Gmail Security: Anti-Phishing and Email Authentication
Gmail is the most common initial access vector in Workspace compromises. Google provides robust anti-phishing controls that are frequently left at defaults.
Enhanced pre-delivery message scanning:
Admin Console > Apps > Google Workspace > Gmail > Safety
Enable ALL of the following:
- Attachments: Protect against encrypted attachments from untrusted senders; protect against attachments with scripts; protect against anomalous attachment types
- Links and external images: Identify links behind short URLs; scan linked images; show warning prompt for any click on links to untrusted domains
- Spoofing and authentication: Protect against domain spoofing based on similar domain names; protect against spoofing of employee names; protect against inbound emails spoofing your domain; protect against unauthenticated emails (no SPF/DKIM)
Email authentication (SPF, DKIM, DMARC):
Publish and enforce in DNS:
# SPF record (replace with your authorized senders)
v=spf1 include:_spf.google.com ~all
# DKIM: generate in Admin Console > Apps > Google Workspace > Gmail > Authenticate email
# Select your domain, generate key, publish the CNAME record provided
# DMARC (start with p=none, move to p=quarantine then p=reject)
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; pct=100"
Recommended Gmail routing rules:
- Blocked senders list: Maintain a list of known malicious sending domains; block at routing level
- Quarantine for executive impersonation: Create a routing rule that quarantines any email to a senior executive that fails DMARC and contains urgency keywords (wire transfer, invoice, password reset)
- Reject unauthenticated external email to internal groups: Prevent external senders from emailing internal mailing lists unless they pass SPF/DKIM
Google Workspace Alert Center:
Admin Console > Security > Alert center
Enable alerts for:
- Suspicious login activity
- Government-backed attacks (Google notifies affected users)
- Phishing message reported by users
- Mobile device compromised
- User granted admin privilege
OAuth App Control and Marketplace Restrictions
Third-party apps connected via OAuth are a significant and frequently overlooked attack surface. Any Google account holder can authorize an OAuth app to access their Drive, Gmail, or Calendar without IT approval -- and some of those apps are malicious or acquire excessive scopes.
Restrict third-party app access:
Admin Console > Security > Access and data control > API controls > Manage Google Services > Drive and Docs
Set:
- Trust internal, domain-owned apps: Yes (allow apps created by your organization)
- Trust apps that G Suite Marketplace admins have selected: Yes (only curated marketplace apps)
- Trust all apps: No (blocks any uncurated third-party OAuth app)
This forces all third-party OAuth apps to be explicitly approved by an admin before users can authorize them.
Audit existing OAuth grants:
Admin Console > Security > Access and data control > API controls > App access control > Manage third-party app access
Review all apps with access to your domain. Look for:
- Apps with broad scopes (Gmail full access, Drive full access) that are not business-critical
- Apps from unknown publishers
- Apps with no users still holding grants (stale authorizations)
Revoke access for any app that cannot be justified. Export the list and schedule quarterly reviews.
Block high-risk OAuth scopes:
Create a blocklist for apps requesting these high-risk scopes:
https://mail.google.com/(Gmail full access)https://www.googleapis.com/auth/drive(Drive full access)https://www.googleapis.com/auth/admin.directory.user(user directory admin)
Admin Console > Security > Access and data control > API controls > App access control > Configure new app access
Audit Logging, Alerts, and Workspace Security Posture
Visibility into your Workspace environment requires proper audit log configuration and export to a SIEM or SSPM tool.
Key audit logs to monitor:
| Log | What to Alert On |
|---|---|
| Admin log | Super admin sign-in, privilege grants, security setting changes |
| Login log | Failed logins, login from new country, suspended account login attempt |
| Drive log | External sharing of files containing sensitive keywords, mass download |
| Gmail log | BCC to external address by exec, forwarding rule creation |
| OAuth log | New OAuth app authorized with high-risk scopes |
| Groups log | User added to privileged group (admins@, finance@) |
Export audit logs to SIEM:
Use the Google Workspace Admin SDK Reports API to pull logs into your SIEM:
- Google's native export: Admin Console > Reporting > Audit > Configure BigQuery export (requires Google Cloud project)
- Splunk Add-on for Google Workspace: Direct pull via Reports API
- Chronicle SIEM: Native Google integration
- Third-party SSPM tools: Obsidian Security, AppOmni, Nudge Security provide pre-built Workspace security posture dashboards
Automated security health checks:
Run a Workspace security health check quarterly: Admin Console > Security > Security health page
This surface shows a prioritized list of misconfigured settings with remediation guidance. Common findings include:
- MFA not enforced for some OUs
- External sharing not restricted for shared drives
- 2-Step Verification grace period still active
- Admin accounts with active Gmail licenses
- Inactive super admins not cleaned up
CIS Benchmark for Google Workspace:
The CIS Google Workspace Foundations Benchmark provides 58 controls across authentication, Drive, Gmail, and admin settings. Use it as your configuration baseline and run automated assessments with tools like Vanta, Drata, or Secureframe that include Workspace connectors.
The bottom line
Google Workspace security is an ongoing configuration discipline, not a one-time setup. The highest-impact controls in order: (1) enforce MFA with phishing-resistant methods for all admins and hardware security keys for super admins; (2) enable Context-Aware Access to enforce device posture; (3) restrict Drive external sharing defaults; (4) audit and restrict third-party OAuth apps; (5) enable all Gmail anti-phishing protections and enforce DMARC p=reject. Schedule a quarterly security health page review and export audit logs to a SIEM for continuous monitoring.
Frequently asked questions
What is the difference between Google Workspace and Google Cloud security?
Google Workspace security covers the productivity suite -- Gmail, Drive, Docs, Meet, Calendar, and the Admin Console that manages users, devices, and settings. Google Cloud (GCP) security covers infrastructure -- compute, storage, networking, and IAM for cloud workloads. They share the same identity layer (Google Accounts and Cloud Identity) and can be integrated via Context-Aware Access policies, but they have separate admin consoles and distinct configuration surfaces. Most organizations need to harden both independently. This guide covers Workspace; see the GCP security best practices guide for cloud infrastructure.
Is Google Workspace's built-in security sufficient or do we need a third-party SSPM tool?
Google's built-in security health page and Alert Center provide a solid baseline at no additional cost, but they have gaps: limited historical audit log retention (180 days for most events), no cross-tenant benchmarking, limited automated remediation, and no integration with non-Google SaaS in your portfolio. Third-party SSPM tools like Obsidian Security, AppOmni, and Nudge Security provide continuous posture monitoring with drift detection, more granular risk scoring, and the ability to correlate Workspace events with other SaaS platforms (Salesforce, GitHub, Slack). For organizations with multiple critical SaaS platforms, a dedicated SSPM tool is worth the investment.
How do we handle Google Workspace security for contractors and external users?
Create a dedicated organizational unit (OU) for contractors with stricter sharing restrictions -- no external Drive sharing, Gmail sending limited to your domain and approved partners, no access to sensitive shared drives. Use the Guest Access feature in Google Meet and shared drives for collaboration rather than provisioning full Workspace licenses. For contractors who need ongoing access, require MFA enrollment before provisioning and set account expiration dates in the Admin Console. Review contractor accounts quarterly and deprovision promptly when contracts end.
What is Context-Aware Access and which Workspace plan is required?
Context-Aware Access is Google's implementation of zero trust access control for Workspace. It allows you to define policies that grant or deny access to Workspace apps based on device posture (is the device corporate-managed, encrypted, with screen lock?), network location (is the user on a corporate IP or VPN?), and user attributes. It requires Google Workspace Enterprise Standard, Enterprise Plus, Education Plus, or Cloud Identity Premium. If you are on a lower tier (Business Starter, Business Standard, Business Plus), you do not have CAA but you still have basic 2SV enforcement and some sharing controls.
How do we prevent OAuth phishing attacks against Google Workspace users?
OAuth phishing (consent phishing) tricks users into authorizing a malicious third-party app that then accesses their Google data without needing their password. The primary defense is restricting which apps users can authorize: Admin Console > Security > API controls > App access control -- set to only allow apps trusted by your admin or from the Google Marketplace. This blocks users from authorizing uncurated apps. Also enable Gmail's link scanning to flag OAuth consent URLs from unknown apps, and train users to verify the app publisher before granting any OAuth consent.
What audit logs should we export to our SIEM for Google Workspace monitoring?
Priority log categories for SIEM integration: (1) Login events -- failed logins, logins from new countries or devices, suspended account login attempts; (2) Admin events -- any change to security settings, privilege grants, new admin accounts; (3) Drive events -- external sharing events, mass downloads, public link creation; (4) Gmail events -- forwarding rule creation (common persistence mechanism after account compromise), BCC to external addresses by executives; (5) OAuth events -- new app authorizations with broad scopes. Use the Google Workspace Admin SDK Reports API or a native SIEM connector (Splunk, Chronicle, Sentinel all have Workspace integrations).
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.