Google Workspace security settings and controls are critical as it serves as an identity provider protecting important business tools like Gmail, Google Drive, Google Docs, and Google Meet. Designed for team collaboration, it offers features such as real-time document editing, file sharing, and video conferencing. 

As the main identity provider (IdP) for accessing Google products and third-party applications, Google Workspace is a critical component of many organizations’ IT infrastructure. However, it can also pose a potential weak spot for your identity security posture.

In this article, we’ll look at some of the Google Workspace security controls, which can help you improve your organization’s overall identity security posture and prepare for the next security audit.

Let’s get started! 

Google Workspace as an Identity Provider 

Google Workspace allows users to access Google and third-party applications using single sign-on (SSO). There are two common ways to implement this, both of which reduce the attack surface by minimizing the number of credentials each user needs to manage. 

Google Workspace as a Secondary Identity Provider 

We recommend this approach when another IdP is in use in your organization, such as Microsoft Entra ID or Okta Workforce Identity Cloud. It’s possible to federate your identities from the main IdP to Google Workspace as if it were another software-as-a-service (SaaS) application. 

Organizations often use Google Workspace applications like Drive, Gmail, and Docs while managing their identities on a different platform. By federating users from your main IdP to Google Workspace, users no longer need to authenticate directly with Google credentials. Instead, they can use SSO to access their Google accounts through the main IdP. 

You can also apply advanced security controls such as conditional access when users sign in to their Google accounts from the other IdP.

Google Workspace as a Main Identity Provider 

Regardless of whether your organization uses other IdPs, you can manage users in Google Workspace and enable SSO for various infrastructure-as-a-service (IaaS) or SaaS applications. This reduces the number of credentials users need to remember and simplifies access through the “Sign in with Google” feature or via SAML/OpenID Connect (OIDC).

Google Workspace can also be used to secure and manage access to other IdPs. For instance, if some users prefer Microsoft 365 over Google’s suite, you can allow them to log into Microsoft 365 using their Google Workspace credentials.

There’s no single correct way to manage identities in Google Workspace. As long as you set up SSO from or to Google Workspace, you increase the security posture of your users and minimize the chances of their identities being compromised. 

Read more about best practices and approaches for managing your identities using Google Workspace in Google’s official documentation. 

Creating and Securing Google Workspace Organizational Units

Google Workspace includes the option to manage identities according to their position or job description, allowing administrators to plan the identity hierarchy using organizational units (OUs). 

An OU is similar to a directory that contains identities. Different security policies can be applied to each OU, allowing administrators to apply the most suitable set of controls to each collective of identities. 

OUs work best when the identities they contain have common needs. For example, we can divide an organization into three main groups:

1. Privileged users – the administrators of the organization that need more protection than the average user (they would also not be federated users).
2. End users – users who are not privileged in the organization.
3. Service accounts – non-human identities (NHIs) that require a different security approach than the traditional controls (like multi-factor authentication).

Each group can be enforced with different security policies and strictness levels. The stronger the identity is, the more restrictive the security policy that should be applied to it.

In Google Workspace, most settings can be applied to a whole organization, a specific OU, or a specific group. Security controls are most effective when they are as granular as possible, in accordance with the identities they protect. 

To create OUs, log in to the Google Admin Center and navigate to Directory > Organizational Units:

After creating OUs, navigate to Directory > Users / Groups and relocate your identities to the newly created OUs:

To configure settings to a specific OU, you can select it from the left pane in most of the settings pages covered in this article.

Google Workspace Security Features  for Strengthening Your Audit Performance

1. MFA Enforcement and Factor Strength
   • ISO 27001 – A.9.4.2 Secure Log-on Procedures
   • NIST 800-53 – IA-2 Identification and Authentication (organizational users)

Multi-factor authentication (MFA) is one of the most reliable security controls for protecting human identities and enforcing strong access management. Yet, even though MFA has become preferred and a standard for effective access management, some organizations are not fully enforcing it. 

In some cases, a user might have registered more than one authentication method when, in fact, they can sign in to their accounts without presenting a second authentication factor (using a password only).

MFA is a crucial defense mechanism that every organization should adopt to protect their users from password-guessing attacks and social engineering techniques. 

How to Configure MFA Enforcement for Google Workspace Security

Sign in to the Google Admin console and navigate to Security > Authentication > 2-step verification. Make sure that you allow users to turn on 2-step verification and that the enforcement is set to On. 

In addition to requiring users to sign in with MFA, admins can configure the required Factor Strength:

1. Factor Strength: In the MFA settings page, under methods, you can select which type of MFA is allowed in your organization:
   • Any type (not recommended) – all factor types are accepted, including weak MFA types like SMS messages and phone calls that can be bypassed with social engineering. 
   • Any except verification codes via text or phone call (recommended) – accepting strong factor types does not require the strongest type possible. This is a good choice to balance security and ease of use. It allows users to use authenticator apps, which are considered a strong factor type.
   • Only security key – the strictest option. This requires users to authenticate with a physical FIDO security key. 

2. Grace Period: New user enrollment period controls the maximum amount of time before the MFA restrictions are enforced for new users. Best practices recommend setting it to a maximum of one week.

Want to see which users are not currently using MFA today?

Download our step-by-step guide for using Google Cloud Shell to spot unprotected identities in your environment. It’s a straightforward process broken down into three easy steps.

2. Advanced Protection Program
   • ISO 27001 – A.9.4.2 Secure log-on Procedures
   • NIST 800-53 – IA-2 Identification and Authentication (organizational users)

Google Workspace offers a free security service called the Advanced Protection Program (APP), which protects Google users from targeted attacks. 

The Google APP is responsible for:

1. Stronger Account Protection – enforces the use of passkeys (YubiKey or other biometric hardware devices like a fingerprint reader) for two-factor authentication.
2. Enhanced Security for Third-Party Apps – restricts access to your Google account data from third-party apps and services.
3. Safeguards against Phishing – Google applies more security checks on emails, attachments, and downloads to prevent phishing attacks.
4. Restricted Account Recovery Options – account recovery processes are stricter and require extensive identity verification steps.

Google Workspace administrators can allow users to enroll themselves in the app but cannot enforce the enrollment. Each user must enroll on their own. When enrollment is enabled, users can enroll using this link. To enroll, a user must configure a passkey, recovery phone number, and a recovery email address: 

For more information about the Advanced Protection Program, visit Google’s official documentation.

How to Enable Advanced Protection Platform Enrollment for Google Workspace Security

In the Google Admin console, navigate to Security > Authentication > Advanced Protection Program.

Choose the Enable user enrollment setting. After configuration, users can self-enroll to the program:

3. Password Strength and Expiration 
   • ISO 27001 – A.9.4.3 Password Management System
   • NIST 800-53 – IA-5(1) Authenticator Management | Password-based Authentication

While passwordless solutions are on the rise, it still might take time for most organizations to adopt them. You can require users’ passwords to be safer and harder to guess with the following configuration:

1. Enforce strong passwords – require the password to combine letters, numbers, and symbols
2. Minimum password length
3. Deny password reuse
4. Expire passwords after a configured period

How to Configure Password Strength and Expiration

We recommended that multiple policies be created with different strictness levels and applied to the appropriate OUs.

Sign in to the Google Admin console. Navigate to Security > Authentication > Password management. 

The following settings are recommended for end users:

1. Enable Enforce strong password.
2. Set the minimum password length as 8.
3. Check Enforce password policy at next sign-in. Otherwise, the configuration will be applied after the next password change.
4. Do not check Allow password reuse.
5. Set the Expiration to 90 days.

We recommended that you create a stricter rule set for more privileged users.

4. Account Recovery
   • ISO 27001 – A.9.2.3 Management of Privileged Access Rights
   • NIST 800-53 – IA-5(1) Authenticator Management | Password-based Authentication

When using Google Workspace as a main IdP, a user or an admin who forgets their password can recover their account if the organization admins enable them. While self-service password recovery (SSPR) can lower the overhead for administrators, it might put your organization at risk since anyone can claim the account if they have access to the configured recovery information (usually a recovery email, security question, or phone number). 

To keep your organization safe, we recommend addressing this feature differently for admin and non-admin accounts:

1. Super admins should not be able to use SSPR
2. Other users are allowed to use SSPR

Since administrative users are more sensitive than other users, we recommend denying them the ability to recover their own accounts. Super-admins can use other super-admins to recover their account. In that case, a threat actor will not be able to claim an administrative account using the Forgot my password feature. 

How to Disable Admin Account Recovery

Sign in to the Google Admin console. Navigate to Security > Authentication > Account recovery and apply the following:

1. Super admin account recovery: OFF
2. User account recovery: ON
   1. You can take a stricter approach and deny SSPR to non-administrative users.

5. Custom Administrative Roles
   • ISO 27001 – A.6.1.2 Segregation of Duties
   • NIST 800-53 – AC-5 Separation of Duties, AC-6 Least Privilege

Google Workspace offers multiple administrative roles that can be assigned to identities in the directory. In some cases, administrators might not find the roles with the desired permissions and assign a more privileged role, which results in over-privileged users. 

For example, a Read-Only administrator is a common role in different IdPs and SaaS applications but does not exist in Google Workspace. You can create a custom admin role if the default roles do not suit your needs. 

How to Create a Custom Admin Role

Sign in to the Google Admin console. Navigate to Account > Admin roles and select Create new role. Name the role as you wish and select the permissions that you’d like to include in the custom role. To create a least-privilege role, each role should only include the required permissions and should not be utilized by more than one specific job function in the organization:

6. Domain-Wide Delegation
   • ISO 27001 – A.9.1.2 Access to Networks and Network Services
   • NIST 800-53 – AC-3 Access Enforcement

Google Workspace domain-wide delegations allow administrators to grant applications API access to Google Workspace users’ data across an entire domain without further consent by the end users. 

With domain-wide delegation, an OAuth app can be granted specific scopes and authorized by an administrator to perform actions on behalf of users, such as reading emails, managing calendars, or accessing Google Drive files across the domain. Domain-wide delegation should be granted with caution, only to trusted applications, especially those requesting write permissions. 

How to Review Domain-Wide Delegation

Sign in to the Google Admin console. Navigate to Security > Access and data control > API control > Domain-wide delegation > Manage domain wide delegation. 

Each row in the table represents a group of scopes that were configured by one of the administrators of your Google Workspace tenant: 

7. Google Chrome Restrictions

Administrators can manage Google Chrome for signed-in Google Workspace users using various Chrome-related settings. Multiple settings can be enforced. We recommend reviewing the settings page and configuring it to align with your organization’s standards.

How to Configure Chrome Restrictions

Navigate to Chrome > Chrome > Apps & extensions. Choose the User & browser settings. The settings are grouped by categories like security, sign-in, apps and extensions, and so on. 

While we recommend you thoroughly review the settings page, here are some important settings to address:

1. Chrome Safe Browsing, Safe Browsing Protection – protects users from sites that might contain malware or phishing content. We recommend that this be activated in standard or enhanced mode.
2. Security settings, Advanced Protection Program – controls whether enrolled users will receive extra protection via Chrome browser. We recommend that this be enabled.
3. Security settings, Device-Bound Session Credentials – specifies whether authentication cookies are bound to a specific device (hardware bound). We recommend that this be enabled.

8. Chrome Web Store and Google Play Restrictions
   • ISO 27001 – A.12.6.2 Restrictions on Software Installation
   • NIST 800-53 – SI-3 Malicious Code Protection

The Google Chrome Web Store is an online marketplace for applications, extensions, and themes. Users can use the store to install Chrome apps and extensions. Google Workspace administrators can control which applications their users can install and can even enforce specific installations. To reduce the chance of initial access through malicious apps and extensions, we recommend restricting users from installing any applications they want. 

How to Configure Web Store Restrictions

Navigate to Devices > Chrome > Apps & extensions. Choose the Users & browsers tab and click Additional settings. In the Allow/block mode, select Edit and set the Chrome Web Store settings to Block all apps, admin manages allowlist, users may request extensions and click Save. 

To add applications and extensions to your allowlist, head back to the Users & Browsers tab and click the + sign in the bottom right corner of the screen. You can search applications and extensions via the store itself. When you find the desired application, choose Select.

After adding the application to your allowlist, you can choose the installation policy to be one of the following:

1. Force install and pin to the browser toolbar
2. Force install
3. Allow install
4. Block

You can configure additional settings for the selected app, such as requiring it to be usable in incognito mode or to be included in the Web Store Recommended section.

9. Sign-In with Google to Untrusted Applications
   • ISO 27001 – A.12.6.2 Restrictions on Software Installation
   • NIST 800-53 – SI-3 Malicious Code Protection

One of Google Workspace’s most used features is Sign-In with Google. It allows users to SSO into most SaaS applications. When users use this feature, they must consent to the permissions the target application requests. 

While some applications only need to read basic profile information from the user, others may request more sensitive permissions, such as access to Google Drive or Gmail. Although some apps require these permissions to function properly, others might exploit unaware users to gain unauthorized access.

Administrators can ensure safer use of the Sign-in with Google feature by configuring a simple option: third-party applications can sign in with a Google Workspace account only if they request basic information. This prevents users from signing in to untrusted apps, such as an online calendar that requests full access to their Google Drive.

How to Configure Untrusted Application Limitation

Sign in to the Google Admin console. Navigate to Security > Access and data control > API control > Settings. Configure Unconfigured third-party apps to allow users to access third-party apps that only request basic info needed for Sign in with Google.

10. Google Workspace Marketplace Restrictions
    • ISO 27001 – A.12.6.2 Restrictions on Software Installation
    • NIST 800-53 – SI-3 Malicious Code Protection

Google Workspace has an application marketplace that can be used to install applications that integrate with Google Workspace services such as Google Drive, Docs, Gmail, and others. To reduce the chances of exposing your business data to third parties, administrators can restrict users from installing applications via the Google Workspace marketplace. Instead of allowing users to install any application they want, admins can maintain an application-allow list for their Google Workspace users. 

How to Configure Marketplace Restrictions

Navigate to Apps > Google Workspace Marketplace apps > Settings. Under Manage access to apps, select Allow users to install and run allow listed apps from the Marketplace. If your organization uses internal Google Workspace applications, click Allow exception for internal apps.

To allow-list an application, navigate to Apps > Google Workspace Marketplace apps >  App list. At the top of the screen, select Allowlist App. In the new dialog screen, search the app by its name and click Select. Choose Allow users to install this app and Continue. Select the groups or the OUs you wish to allowlist the application for and click Finish.

11. Google Cloud Platform Re-Authentication Settings
    • ISO 27001 – A.9.4.2 Secure log-on Procedures
    • NIST 800-53 – IA-11 Re-authentication

To sign in interactively to Google Cloud Platform (GCP), a Google Workspace account must be involved, even if indirectly through another IdP. Google Workspace allows administrators to limit the session lifetime to minimize the risk of a hijacked GCP session. We recommend requiring users to reauthenticate at least once a day to ensure session authenticity.

How to Configure Re-Authentication Settings

Navigate to Security > Access and data control > API control > Google Cloud session control. Select Require Reauthentication and set the time frame to the desired number of hours. Federated users will be prompted to reauthenticate via the external identity provider.

12. Setting Up Rules and Alerts
    • ISO 27001 – A.12.4.1 Event Logging
    • NIST 800-53 – IR-5 Incident Monitoring

Google Workspace includes a built-in alerting mechanism that uses system-defined or user-defined rules to notify administrators of unusual or suspicious events. By default, only a few system-defined alerts are active, and you may not receive notifications for all of them.

We recommend reviewing the built-in rules page and activating relevant alerts. When a rule is activated, it can be sent to Google Workspace’s alert center and trigger email notifications to users.

How to Activate System-Defined Rules

In the Google admin console, navigate to the Rules section. To activate a rule, click on a specific rule and then click on the Actions section:

You can choose what happens when a rule detects an event based on its logic, i.e., send it to the alert center, or send email notifications to users (or both):

To create a rule of your own, click Create rule and choose Reporting from the drop-down. Name the rule as you wish and click Next. 

The Conditions section is the logic of your rule. Using the condition builder, you can decide which data source to monitor and create custom conditions. For example, the screenshot below shows a custom rule that is triggered when a user is added to a group whose email contains the string ‘admin’ and sends it to the alert center:

To review triggered alerts, navigate to Security > Alert Center. 

13. Gmail Security Settings
    • ISO 27001 – A.13.2.3 Electronic Messaging
    • NIST 800-53 – SC-7 Boundary Protection

Most business-related conversations take place in Gmail. It’s one of the primary gateways to your organization and should be treated as such. Google offers many configurable settings to protect your Google Workspace Gmail. 

Here are three settings that aim to protect youfrom data exfiltration, phishing, or any type of fraud or social engineering attempt:

1. Auto Forwarding: Allows users to forward received emails to other recipients. Threat actors use this technique as part of business email compromise (BEC) campaigns. Administrators can deny their users auto-forwarding emails by navigating to Apps > Google Workspace > Gmail > End User Access and turning Automatic forwarding off.

2. Default Routing: Allows administrators to manage domain-wide email routing rules. Threat actors might use this feature to automatically forward emails with specific keywords sent to any user in your Google Workspace domain. To review the configured routing rules, navigate to Apps > Google Workspace > Gmail > Default routing. 

3. Spoofing and Authentication: Used to alert users about spoofed email addresses by showing a warning message to the user. Currently, contains five different security controls that we recommend turning on:
   1. Protect against domain spoofing based on similar domain names
   2. Protect against spoofing of employee names
   3. Protect against inbound emails spoofing your domain
   4. Protect against any unauthenticated emails
   5. Protect your Groups from inbound emails spoofing your domain

To configure these settings, navigate to Apps > Google Workspace > Gmail > Safety > Spoofing and Authentication.

To read more about Gmail protection, visit Google’s documentation.

14. Google Drive and Collaborative Documents Security Settings
    • ISO 27001 – A.13.2.1 Information Transfer Policies & Procedures
    • NIST 800-53 – SC-7 Boundary Protection

Google Workspace provides cloud-based tools for creating and collaborating on text documents, presentations, and spreadsheets. Using Google Drive, Docs, Sheets, and Slides, multiple users can edit and comment in real-time, with automatic saving and easy sharing features, accessible from any device with internet access.

However, from a security standpoint, the ease of access to these documents may increase the risk of data exfiltration or unauthorized access to sensitive business information.

Like other Google Workspace applications, the collaborative suite can also be configured to restrict access to the shared online content. Here are three key settings: 

1. Sharing settings: Navigate to Apps > Google Workspace > Drive and Docs > Sharing settings to control who users can share documents with. There are three options:
   1. External sharing is not allowed. Sharing is only possible for users within the same Google Workspace tenant.
   2. Sharing to allow listed domains. Users can share documents with members of pre-configured domains.
   3. No restrictions. Users can share content with everyone, including anonymous entities.

*Even if you do not restrict sharing, we advise you to deny the option of sharing content with Everyone with a link.

2. Manage shared drives: Navigate to Apps > Google Workspace > Drive and Docs > Manage shared drives to review the shared drives in your tenant and revoke any unwanted access.

3. Transfer Ownership: When an employee leaves the company, their Google Workspace entity might still own content in your tenant. You can use this feature to transfer ownership of files of offboarded employees under Apps > Google Workspace > Drive and Docs > Transfer ownership.

Protect Your Google Workspace and Ace the Audit

If Google Workspace forms the backbone of your IT infrastructure and serves as your primary identity provider, it’s crucial to configure it properly to keep threats at bay. By using this guide to properly set up your Google Workspace security controls, you can strengthen your identity security posture, address any vulnerabilities, and set yourself up for success in your next audit.

Don’t let security gaps go unnoticed. Download our step-by-step guide for using Google Cloud Shell to spot unprotected identities in your environment. It’s a straightforward process broken down into three easy steps.

Want to Streamline Your Access Review Efforts?

User access reviews have emerged as a critical weapon against unauthorized access and potential breaches. The secret to success relies on the consistency, contextual understanding, and continuous monitoring of your identities and their access. Here are 5 ways Rezonate can help you achieve this in Google Workspace and beyond into other identity providers, your cloud infrastructure, and business-critical SaaS applications:

1. Get real-time visibility into user access privileges and security controls for your human and non-human identities
2. Identifies dormant identities across the identity fabric – from workforce identities no longer active to inactive machine identities such as roles and access keys
3. Review application and system access for specific subsets or groups of identities based on specific attributes
4. View compliance status with intuitive dashboards and swiftly address compliance gaps
5. Continuously monitor user access privileges and identify when a policy violation or misconfiguration occurs in real time

Learn more about Rezonate’s Identity Compliance capabilities and see how our platform can help boost your audit performance while strengthening identity security across your cloud, SaaS, and identity providers.