The following are secure settings that I recommend, but which are not enabled by default, usually because they come at the cost of convenience, configuration, or compatibility.
Most headings refer to the settings sections in Google Admin.
Authentication
Most organizations using Google Workspace also use it for email. That makes it the critical system to secure in any setup. Email is the master key to your online identity and when an attacker gains access to it, they can reset your passwords or impersonate you.
This section describes the most effective ways to prevent attackers from logging into your users’ accounts.
2-step verification
The most obvious and most important setting. The minimum setting here should be Enforcement: ON, with any methods except “verification codes via text, phone call” allowed. The most secure setting is to only allow security keys.
Why are text/SMS-based verification codes not secure?
Text/SMS are fundamentally insecure for a number of reasons:
SIM swapping: Attackers can hijack a phone number in most cases by calling the phone carrier and convincing them to transfer the number to a new SIM card. This is a common occurrence, even more so for high-profile targets.
SMS interception: SMS can be intercepted with tools mimicking cell towers.
Unencrypted: SMS were built for convenience, not security. They are sent in plaintext over cellular networks.
These are the steps I follow:
- Check how many users already enabled 2-Step verification
- Go to Google Admin > Users
- Click the gear icon in the upper right corner
- Add new column: 2-step verification enrolment
- Notify team of upcoming change. Explain what they need to do and give them time to set it up and answer questions.
- Turn on enforcement, e.g. 1 week from now
- If some users need more time, either adjust your deadline or temporarily move them to a new organizational unit “No 2FA enforcement” which you exempt from the enforcement.
- Note that users who haven’t set it up will be unable to login after the deadline.
If you choose to only allow security keys, plan additional time to get the hardware security keys to your team. I recommend the Yubico Security Key NFC for most orgs, or the YubiKey 5C NFC if you require additional protocols or are price insensitive.
Best practice is to have at least two redundant security keys and store them in a way that one can’t lose both at the same time. However, for regular team members it’s fine to only have one as admins can always reset a user’s 2-step verification in case they lose their security key. Admins should either use multiple keys themselves or ensure other admins can help them recover their account.
Note that Google considers passkeys to be security keys as well, but passkeys alone won’t let you enable two-factor authentication. Passkeys are a great compromise to gain increased security over simple one time verification codes but without the friction that can come with hardware security keys.
Security keys and passkeys
Security keys are small physical devices used for authentication only. You plug them in or tap to verify your identity. Examples: YubiKey, Google Titan.
Passkeys are a fairly new type of digital credentials stored on your phone, laptop, or in a password manager. They are often unlocked by using biometrics (Face ID, fingerprint).
Both are phishing-resistant and more secure than passwords. Security keys are considered a step up from passkeys since it’s a lot harder to compromise the dedicated device. One generally requires physical possession of the key to login.
If you aim for the highest security, you can disable passkeys not on hardware security keys in Authentication > Passwordless > Passkey restriction.
Advanced Protection
This is a lesser-known account setting. It’s available to all accounts by default but users have to enroll manually. Here are the most important things it does:
- Requires security key for logging in
- Limits many non-Google apps from accessing your data
- Major, verified apps like Apple Mail or Calendar or desktop email clients continue to work
- Apps Script won’t be able to access most of your data
- More comprehensive scanning of email attachments
- Account recovery process requires stricter identity verification
I usually recommend this for admins and high-profile people at risk of getting targeted. There is no downside other than stricter default settings. One can enroll here.
Note these equivalents you might want to recommend to your team:
- Apple iCloud Advanced Data Protection
- Apple Lockdown Mode (for devices)
- Advanced Protection for Android (coming June 2025)
Password management
Set minimum length to (at least) 16 characters.
This is generally considered very secure for a generated password. Password managers generate 14-20 characters by default (1Password: 20, Bitwarden: 14, Dashlane: 16, Chrome: 15, Apple Keychain: 20).
Google session control
Only available on plans Business Plus and above.
This sets the web session duration, i.e. after X amount of time, users will need to re-enter their password. It counts time since last login, not inactivity. Mobile apps like Gmail are not affected (they are never logged out). The lower the better, but note that it adds some friction for users.
I recommend 12 hours for high-risk users. That way users login once at the start of their workday.
Third-party apps
API controls
Other apps can request access to a user’s Google data (usually via the OAuth protocol). This can be harmless (“Sign in with Google”) or risky (read and modify all emails and Drive documents).
- First I check which apps users already granted access to and to what data (“scopes”).
- I usually ignore all apps which only requested “Google sign-in”
- Common finds are calendar apps like Calendly, SavvyCal, or Notion Calendar
- If I find dubious or unvetted apps, I talk to the team about it and configure them to have access to the scopes we deem reasonable.
- Once all existing apps are configured, I block future access for unconfigured third-party apps beyond “Sign-in with Google”.
Marketplace
-
Check for installed apps and allowlist them once vetted
-
Allow users to install and run allowlisted apps from the Marketplace
Gmail
Only relevant if you use Google Workspace Gmail.
Check for any outdated automatic email forwarding rules set in Routing or Default Routing. These persist even after a user account has been suspended or deleted and are thus often forgotten.
Safety
Google’s defaults are sensible here but you can tighten it further by enabling some extra checks and considering sending suspicious emails to quarantine first. Admins (or whoever you set) will get notified when an email is sent to quarantine and they have to approve it before it gets delivered.
Enable this if you don’t trust all your users will heed the warning Google displays by default.
-
Protect against encrypted attachments from untrusted senders: Quarantine
-
Protect against attachments with scripts from untrusted senders: Quarantine
-
Protect against anomalous attachment types in emails: Show warning
-
Enable IMAP link protection: ON
-
Protect against any unauthenticated emails: Show warning
-
Protect against inbound emails spoofing your domain: Quarantine
- Only after you configured SPF or DKIM
End user access
- Enable IMAP and POP access for all users: OFF
- Ask the team before turning this off. This prevents many desktop email clients from accessing a user’s email account. It does not affect the Gmail mobile app.
- Allow users to forward incoming email automatically to another address: OFF
- This can be a controversial change. Oftentimes people prefer to receive all their emails in a single place, so they set up a forwarding rule to their personal email account. While convenient, it’s pretty risky since it makes the user’s security depend on their personal account, which may have weaker protections. The account might use an old non-generated password, lack two-factor authentication, or have its recovery email set to a long forgotten Yahoo address.
- Note this does not remove existing forwards created by users.
Spam, phishing, and malware
- Use blocklists and machine learning to identify dangerous links (only available for some plans)
- Enable security sandbox for attachments (only available for some plans)
- This makes Gmail perform more extensive scans. It can cause some emails with attachments to get delayed up to 15min.
Authenticate email (DKIM)
This doesn’t directly impact security since it applies to outgoing email but it’s a powerful tool to combat phishing. Note this takes a bit more time to set up. See instructions.
Drive
Don’t allow users to install un-vetted Google Docs add-ons.
In many organizations’ setups team members’ personal email addresses have sneaked in for convenience reasons. This is hard to prevent with settings, so here are the options I usually consider:
- Create a blocklist of team members’ personal email addresses with Drive Trust Rules (Enterprise plans only)
- Run a Google Apps script to remove all personal email addresses once
- Educate users about the risk involved
Chrome
In addition to enforcing strong authentication methods, we also want to control the environment in which users use them. In an ideal world that would be fenced off offices with managed devices. For most small non-profits and organizations that is not an option. Their reality is personal MacBooks in coffee shops.
Even in a remote-first culture, mobile device management adds a lot of security. I’ve found that for orgs which don’t want to take this step yet, managed Chrome profiles can be a good compromise.
Below I’ll describe how to set up your Workspace in a way that makes sure users only log in using a more secure, organization-managed Chrome profile.
Force separate profile
In Devices > Chrome > Settings > Users and browsers > Separate profile for managed Google Identity, choose Force separate profile (only works in browsers enrolled as part of Chrome Enterprise Core).
Note that this does not force users to use Chrome to log into the Workspace. This is only possible with context-aware access (enterprise only).
If you don’t use Chrome Enterprise Core and don’t have Enterprise licenses, you’ll have to ask your users to use a separate profile and login to their Google Workspace account there.
Secure settings
Found under Devices > Chrome > Settings.
- Site isolation: Require site isolation for all websites
- Prevents data leaking between websites via shared memory, bugs, or exploits
- May lead to a bit more memory use
- DNS-over-HTTPS: Prefer with insecure fallback (or require if you know what you’re doing)
- Prevents DNS spoofing or manipulation and hides DNS queries from local networks
- Some hotel or airport WiFis may block DoH
- Allow HTTPS-only mode to be enabled: Force enable
- Outdated Flash: Disallow outdated Flash
- Safe Browsing Protection: Active in enhanced mode
- Chrome Update > Relaunch notification: Force relaunch after 24 hours
- This could be annoying to users but ensures browser updates are installed quickly
- Chrome Update > Auto-update check period: 60 minutes
Extensions
A commonly overlooked attack vector hides in browser extensions. While undeniably useful, most users don’t stop to question the risks that come with granting these little scripts broad permissions.
Read our full guide on how to protect yourself from browser extensions.
Misc
Housekeeping
Unless setting up a new Workspace, I coordinate with the organization to remove and suspend users who shouldn’t be users. I also check existing groups, group memberships, and email aliases.
I also check which users have admin roles assigned in Account > Admin roles.
Impersonation
Should a user account get compromised after all, one can slightly reduce the potential impact by disallowing users to edit their own names (Directory > Directory settings). That makes it harder for an attacker to use a compromised account to impersonate a person with more privileges (e.g. in a video call).