The five most common Google Workspace misconfigurations are incomplete multi-factor authentication (MFA) enforcement, public Google Drive sharing links left on by default, high-privilege accounts left out of Google's Advanced Protection Program (APP), weak or unenforced password policies, and Google Groups left open to unrestricted access. Each one is a default Google Workspace leaves permissive rather than secure, and each is fixable in the Admin Console in under an hour. Left unaddressed, these five gaps account for a large share of the account takeovers and data exposure incidents traced back to Google Workspace environments.
‍
Why Google Workspace misconfigurations still make headlines
In 2018, researchers at Kenna Security, working with security journalist Brian Krebs, identified more than 9,600 organizations, including Fortune 500 companies, hospitals, and universities, with Google Groups misconfigured to expose internal email threads, password reset lists, and confidential documents to the public internet. Boston College was among the organizations named; internal university communications sat publicly accessible to anyone who found the group's URL. The setting responsible, a Google Group's viewing access set to "Public on the internet" instead of "Private," is still one of the defaults administrators overlook today.
‍
That incident is nearly a decade old, but the underlying pattern hasn't changed. IBM's 2026 Cost of a Data Breach Report puts the average breach at $4.99 million, up more than a tenth over the prior year, and names misconfiguration among the most common root causes it tracked. Nearly every one of those breaches traces back to a setting the platform already offered, sitting unused. Google Workspace ships secure infrastructure, but many of the settings that actually protect an organization's data are opt-in, buried several menus deep in the Admin Console, or inherited from defaults nobody revisits after initial setup, and each one left unchecked expands the SaaS attack surface an organization has to manage. The five misconfigurations below are the ones IT and security teams encounter most often, and the ones attackers already know how to look for.
‍
Key takeaways
- Incomplete MFA enforcement, not the absence of MFA, is the more common misconfiguration; Google Workspace lets a user register a second factor without actually being forced to use it unless enforcement is configured correctly.
- Google Drive's "Anyone with the link" sharing option requires no authentication to view a file, and it remains one of the most frequent sources of accidental data exposure in Google Workspace environments.
- Google's Advanced Protection Program (APP) is free and enforces phishing-resistant security keys, but it's rarely enrolled for the admin and executive accounts that need it most.
- A signed Business Associate Agreement (BAA) and specific Admin Console configuration are both required before Google Workspace can be used for HIPAA-covered data; neither happens automatically.
- Google Workspace's infrastructure holds ISO 27001 certification, but an organization's own compliance posture still depends on how its admins configure the settings layer, per the shared responsibility model.
Google's shared responsibility model, and where it ends
Google secures the infrastructure underneath Google Workspace: the data centers, the network, the physical hardware, and the core platform code. Everything above that layer, who has access to what, how data is shared, which accounts require stronger authentication, is the customer's responsibility to configure. This is Google's shared responsibility model, and it's the same framework that governs Google Cloud Platform (GCP), Microsoft 365, AWS, and effectively every major cloud platform.
‍
The distinction matters because Google Workspace and Google Cloud are often conflated, and they aren't the same security surface. In practice, the split looks like this:
- Google Workspace: Gmail, Drive, Docs, Meet, Chat. Identity, sharing, and device policy for end users, managed in the Admin Console.
- Google Cloud (GCP): compute, storage, networking, and infrastructure for applications an organization builds and hosts itself, managed in Cloud IAM and the Cloud Console.
‍
An organization using Cloud Identity to manage both often assumes one console's settings extend to the other. A locked-down Cloud IAM policy has no bearing on whether Drive sharing defaults are set to public, and a hardened Workspace Admin Console has no bearing on a misconfigured Cloud Storage bucket. This is exactly the gap SaaS security posture management is built to close: continuous monitoring of configuration and access across every layer instead of a one-time console check. Treat Workspace and Cloud as two security programs that happen to share an identity layer.
‍
The 5 Google Workspace misconfigurations to fix first
Each of the five misconfigurations below follows the same pattern: a permissive Google default, a business reason it stayed that way, and a specific Admin Console fix. These are the settings that show up across nearly every Google Workspace security review, and this is also the backbone of most Google Workspace security best practices guidance: get these five right before layering on anything more advanced.
‍
1. The half-enforced MFA gap
Enforcing multi-factor authentication (MFA) is one of the single most effective controls in Google Workspace. The Cybersecurity and Infrastructure Security Agency (CISA) states that accounts with MFA enabled are 99% less likely to be compromised. The gap isn't usually whether MFA exists, it's whether it's actually enforced.
‍
In Google Workspace, a user can register a second-factor method and still be allowed to sign in with just a password if enforcement isn't configured at the organizational-unit level. A common failure mode: an organization enforces MFA for every employee at hire, but skips it for accounts provisioned before the policy existed, leaving a legacy population of unprotected users the audit never catches. Long enrollment grace periods and "optional" MFA policies both produce the same outcome: most users never turn it on. Even where MFA is enforced, weaker second factors like SMS codes and voice calls remain vulnerable to SIM-swapping and social engineering, in a way that authenticator apps and hardware security keys aren't.
‍
The fix: In the Admin Console, go to Security > Authentication > 2-Step Verification and enforce it for all organizational units, not just admins, after a short enrollment window. Restrict the allowed second-factor methods to exclude SMS and voice codes, using the "Any except verification codes via text or phone call" setting, and require hardware security keys for admin and executive accounts specifically, as part of an ongoing identity governance program. The feature itself is free; enforcement is the part that needs active management.
‍
2. The anyone-with-the-link trap
Google Drive's "Anyone with the link" sharing option requires no sign-in to view a file. It's the fastest way to share a document, and the fastest way to expose one: once a link exists, anyone who obtains it, through a forwarded email, a scraped search index, or a leaked chat log, can open the file with no authentication and no record of who accessed it. This is also the setting behind most "exposed via search engine" headlines: a publicly shared file gets indexed days or weeks after creation, long after whoever shared it has forgotten the link exists.
‍
Employees default to this setting for a simple reason: it avoids the friction of managing individual permissions or fielding access requests. It's a convenience choice, and that's exactly why it spreads across an organization faster than any deliberate policy would.
‍
The fix: In the Admin Console, disable "Anyone with the link" sharing org-wide where possible, and make "Off (restricted)" the default for new files. If a specific team genuinely needs public links, marketing assets, for example, scope that ability to a single organizational unit rather than the whole domain. Layer in Data Loss Prevention (DLP) rules to flag sensitive content, financial data, credentials, PII, in files even when they're shared internally, and run Google's Security Dashboard file exposure report on a monthly or quarterly cadence to catch drift before it becomes a leak.
‍
3. The unshielded admin account
Admin and executive accounts have the most access and the least excuse to be under-protected, yet Google's free Advanced Protection Program (APP), built specifically for high-value targets, is rarely enrolled for the accounts that need it most.
‍
APP requires a physical or phone-based security key for sign-in, which is close to phishing-proof compared to a password-plus-SMS setup. It also blocks untrusted third-party OAuth apps from connecting to an enrolled account by default, closing off one of the more common phishing paths: tricking an admin into granting a malicious app access under the guise of a legitimate integration, which is exactly the failure mode ongoing OAuth risk management is meant to catch. Account recovery is also deliberately harder under APP, which cuts off the social-engineering path attackers use to bypass MFA entirely by impersonating a locked-out user to support.
‍
The fix: Enroll every super administrator and every executive account with access to sensitive data in APP directly from the Admin Console. Enrollment takes minutes per account, and Google explicitly recommends it for anyone whose compromise would cause outsized damage: IT admins, executives, and anyone with standing access to financial systems or customer data.
‍
4. The password policy that isn't
Google Workspace's "Enforce strong password" setting is off by default. Until an admin turns it on, users can set passwords as simple as the platform allows, which leaves the organization exposed to password spraying and credential stuffing regardless of how sophisticated its other defenses are.
‍
Minimum length is the most commonly missed lever: leaving it at Google's low default, rather than requiring at least 8 characters (12+ is stronger), meaningfully weakens resistance to guessing attacks. Allowing password reuse compounds the problem, since it lets users cycle between a handful of familiar passwords instead of actually rotating credentials. Password spraying and credential stuffing don't require a targeted attacker, only a list of previously breached credentials and enough patience to try them against every account in a domain, which is why a weak length or reuse policy affects the entire organization at once, not just one account.
‍
The fix: In Security > Password Management, enable "Enforce strong password," set a minimum length of at least 8 characters, and disable password reuse (Google disables it by default, but confirm the setting hasn't been overridden). Apply the new policy at next sign-in, not next password change, so existing weak passwords don't linger indefinitely. Consider a stricter policy for admins and other privileged organizational units, since Google Workspace supports per-OU password rules.
‍
5. The public group blind spot
Google Groups controls who can view, post to, and join mailing lists and team discussion groups, and it's the setting behind the 2018 exposure incident described above. An "unrestricted" group can allow anyone on the internet to view messages or join freely, turning what was meant to be an internal discussion into a public archive.
‍
The confusion is structural: Google Groups has enough overlapping settings, and organization-wide versus group-specific permissions are similar enough in naming, that misconfiguration often happens without anyone noticing until the group is indexed or reported. A quick way to spot exposure: search your own domain name plus a distinctive project keyword in a search engine. An internal Google Group's URL surfacing in those results means the exposure is already live.
‍
The fix: Audit every Google Group's viewing access and set internal discussion groups to "Private – Only members of the group." For groups that need external participants, keep viewing access private and add those participants by invitation rather than opening the group publicly. Restrict "Who can join" to invite-only, and "Who can post" to group members, to stop external spam and prevent a former employee's personal account from lingering on an internal list, one of the gaps a thorough employee offboarding checklist is meant to catch. Older groups are the highest-risk category: Google's defaults have gotten stricter over time, but a group set up under an older, looser default rarely gets revisited unless someone goes looking for it.
‍
Google Workspace compliance: HIPAA, GDPR, and ISO 27001
Google Workspace can support all three of these frameworks, but compliance depends on how an organization configures and uses the platform on top of Google's own certifications. Treat "Google Workspace is compliant" as a starting condition to build a compliance program on top of.
‍
HIPAA. Google Workspace can be used for protected health information (PHI), but only on eligible paid editions and only after you sign a Business Associate Agreement (BAA) with Google, accepted electronically through the Admin Console under Legal & Compliance Settings. Without a signed BAA, storing or transmitting PHI in Gmail, Drive, or any other Workspace service is a violation regardless of how the account is otherwise configured.
‍
GDPR. Google Workspace's terms include a Data Processing Amendment that covers Google's obligations as a processor of personal data for EU and UK customers. That amendment addresses Google's side of the relationship; you still need your own lawful basis for processing, your own data retention policy, and your own configuration of sharing and access controls to be GDPR-compliant end to end.
‍
ISO 27001. Google has earned ISO 27001 certification for the infrastructure, data centers, and core systems supporting Google Workspace, independently audited roughly every two years. That certification covers Google's side of the shared responsibility model. It says nothing about whether a specific organization's Admin Console settings, sharing defaults, MFA enforcement, and Google Groups permissions, would themselves pass an ISO 27001 audit of that organization's own information security management system.
‍
Google Vault and the Admin Console's audit logs are the two native tools most relevant to demonstrating any of this during an actual audit: Vault retains and lets you search data for legal hold and e-discovery, and the audit logs record admin and user activity across services, the kind of evidence audit and compliance reviews typically ask for. Neither one, on its own, tells you whether the underlying settings are actually configured correctly, which is the gap the five misconfigurations above are meant to close.
‍
Why native Google Workspace settings aren't enough on their own
Every fix above lives inside the Google Admin Console, and configuring all five closes real, well-documented gaps. The Admin Console shows a point-in-time snapshot; drift detection is a separate problem it wasn't built to solve. A Google Group set to private today can be reopened by any group owner tomorrow. An admin enrolled in the Advanced Protection Program can be replaced by a new hire who never gets enrolled. Someone has to go looking for either change, because Google Workspace itself won't flag it.
‍
The Admin Console also stops at the edge of Google Workspace. It has no visibility into the other SaaS applications an OAuth grant from a Workspace account might reach, the shadow IT tools employees connect to Google Drive without IT's knowledge, or the access a former employee retains in a third-party app that was never routed through Workspace at all. A compromised OAuth grant from a Google Workspace account frequently ends up exposing data through a separate SaaS app entirely, outside anything a Workspace-native setting can see. Advanced controls like context-aware access, which restricts sign-in by device posture or location, exist in Google Workspace, but they sit behind higher-tier licensing and enough manual configuration that many organizations never turn them on.
‍
Google Workspace's native security is a reasonably complete toolkit for the surface it covers. The gap is continuous monitoring across that toolkit and everything connected to it, a problem that spans past what any single Admin Console setting is built to solve.
‍
How Nudge Security helps close the gap
Nudge Security continuously analyzes your Google Workspace environment against the settings covered here, MFA enforcement, Drive sharing defaults, APP enrollment, password policy, and Google Groups access, and surfaces any drift from your baseline as it happens. Findings get prioritized by actual risk, not just the presence or absence of a setting, and routed into remediation workflows your team can act on directly instead of re-running the same manual audit every quarter.
‍
Because Nudge Security also discovers the other SaaS and AI tools connected to your Google Workspace accounts, covering 175,000+ apps including the shadow SaaS and AI tools most other shadow IT discovery tools miss, it can tie a Google Workspace misconfiguration back to the OAuth grant, integration, or former employee account that actually created the exposure, closing the visibility gap the Admin Console leaves open on its own.
‍
See your Google Workspace security posture in Nudge Security, alongside the rest of your SaaS estate, in one place.
