For most small and mid-sized companies, mail, files and contacts all live in Microsoft 365 or Google Workspace. Attackers rarely need to break into a server; they need one working username and password, whether phished, stolen from an employee's computer by an infostealer (see Infostealers and leaked credentials) or guessed by trying common passwords one account at a time. Once signed in, the next moves are setting up automatic forwarding, tricking users into authorizing a malicious app, and sharing files out. Most of these paths can be closed in advance with tenant-level settings, but many defaults favor convenience and have to be tightened deliberately.

This guide is for the one or two IT staff who administer a company's Microsoft 365 or Google Workspace tenant. It introduces CISA's SCuBA secure configuration baselines and free assessment tools, walks through the settings most worth changing first and the attack each one blocks, and ends with what to do if you only have one afternoon. If an account has already been compromised, see Compromised company email account: response steps; this article covers the preventive settings.

Use CISA SCuBA as your checklist

CISA set up the SCuBA (Secure Cloud Business Applications) project in 2022 to write secure configuration baselines for Microsoft 365 and Google Workspace. Its main purpose is to protect US federal data in the cloud, but CISA says any organization can use it to strengthen SaaS security[1]. CISA also publishes two free assessment tools: ScubaGear for Microsoft 365 tenants and ScubaGoggles for Google Workspace. They compare a tenant's current settings against the baselines item by item and produce a report showing what needs to improve; the tools and baselines are open to private-sector organizations[1].

On December 17, 2024, CISA issued Binding Operational Directive BOD 25-01, which requires US Federal Civilian Executive Branch (FCEB) agencies to comply with a defined set of baseline settings, deploy automated assessment tools and remediate deviations[2]. The directive binds only US federal civilian agencies and has no legal force for Taiwanese companies; CISA "strongly recommends" that other organizations adopt the settings and tools as well[2]. The list of required configurations keeps changing: the most recent Microsoft 365 entry was added in September 2026, and federal agencies must complete the Google Workspace entries by December 1, 2026[2].

Keep two things in mind when you use it. First, the baselines were written for US federal agencies, and some entries make no sense for a Taiwanese company, such as sending DMARC aggregate reports to a US Department of Homeland Security mailbox or setting the Google Workspace data region to the United States[2]. Second, some entries depend on features such as Conditional Access, which requires at least Microsoft Entra ID P1[3] and may not be in an SME's plan. For each "not met" item in the report, weigh the risk and feasibility before deciding how to close it; don't change settings just to raise a score.

In practice, run ScubaGear or ScubaGoggles once and treat the report as a to-do list; CISA explains that running the latest version of the tool automatically checks the tenant against the baselines and lists any non-compliance in a generated report[2]. The sections below pick the items that matter most for SMEs and give the matching SCuBA policy IDs so you can cross-reference the report.

Identity: MFA, legacy authentication and admin accounts

MFA on every account

Why: once a password has leaked, MFA is what keeps the attacker out. Microsoft says that using MFA and blocking legacy authentication stops more than 99.9% of common identity-related attacks[3]. But MFA only checks at sign-in: an attacker who steals the session cookie issued after sign-in can skip it, which is why the settings that follow still matter (see Infostealers and leaked credentials).

Microsoft 365 offers two approaches. Security defaults need no extra license. When enabled, they require all users to register for MFA, require administrators to do MFA every time they sign in, require users to do MFA when Microsoft decides it is necessary, and block legacy authentication and device code flow; attackers abuse device code flow in phishing by tricking users into entering a code on another device[3]. Tenants created on or after October 22, 2019 may already have them on, and tenants with no Conditional Access policies, no premium licenses and no active legacy authentication clients are notified and then have them enabled automatically[3]. Conditional Access lets you write custom rules by user, application and sign-in context, but requires at least Microsoft Entra ID P1. To switch to Conditional Access you must disable security defaults and should immediately enable replacement policies; Microsoft also provides Microsoft-managed Conditional Access policies that cover the same protections[3].

Separately, Microsoft now enforces MFA on its admin portals regardless of tenant settings. Phase 1 began in October 2024 for the Azure portal, Microsoft Entra admin center and Intune admin center, and extended to the Microsoft 365 admin center from February 2025; Phase 2 began on October 1, 2025 for create, update and delete operations through Azure CLI, Azure PowerShell, the Azure mobile app, IaC tools and REST APIs[4]. The latest dates tenants could postpone to were September 30, 2025 for Phase 1 and July 1, 2026 for Phase 2, and both have passed. Enforcement also covers emergency access accounts, and Microsoft recommends passkeys (FIDO2) or certificate-based authentication for them[4]. If automation scripts run under ordinary user accounts, Microsoft recommends moving them to workload identities such as managed identities or service principals[4].

In Google Workspace, go to Security > Authentication > 2-step verification in the Admin console, first allow users to turn on 2SV, track enrollment, and then enforce it. When enforcing, you can set a new user enrollment period (1 day to 6 months, during which users can sign in with just a password), and you can restrict methods, for example excluding codes sent by text or phone call, or allowing only security keys and passkeys[5]. Google notes that passkeys and security keys have the same level of phishing protection, and says it is enforcing 2SV for administrator accounts[5]. SCuBA goes further: both platforms require phishing-resistant MFA for all users (MS.AAD.3.1v1, GWS.COMMONCONTROLS.1.1v1), Microsoft 365 must disable SMS, voice call and email one-time passcodes (MS.AAD.3.5v2), and the Google new-user enrollment period may be at most one week (GWS.COMMONCONTROLS.1.4v1)[2]. For a comparison of MFA methods and rollout order, see the MFA rollout guide.

Block legacy authentication and find devices still using SMTP AUTH

Why: legacy authentication (for example, clients that send a username and password directly over IMAP, POP3 or SMTP) does not support MFA, so even when the tenant requires MFA an attacker can sign in over an older protocol and bypass it; Microsoft says most compromising sign-in attempts come from legacy authentication[3].

Microsoft 365: security defaults block all legacy authentication requests, and tenants not using security defaults can block it with Conditional Access[3]. The usual sticking point is multifunction printers, scanners and older systems that send mail via SMTP AUTH. The timeline Microsoft published after its January 2026 revision is: no change in behavior through December 2026; from the end of December 2026, SMTP AUTH Basic authentication is disabled by default for existing tenants, though administrators can still turn it back on; tenants created after December 2026 will not have it available by default and OAuth will be the supported method; the final removal date will be announced in the second half of 2027[6]. The timeline has been revised before, so check the Message Center in the Microsoft 365 admin center again before you act. Rather than turning Basic authentication back on later, find those devices now and move them to OAuth or another way of sending mail. SCuBA simply requires SMTP AUTH to be disabled (MS.EXO.5.1v1)[2].

Google Workspace: on March 14, 2025 Google turned off access to less secure apps for all Google Accounts, so CalDAV, CardDAV, IMAP, SMTP and POP no longer accept password-only Basic authentication and must use OAuth. The one exception is app passwords, and Google lists configuring an app password as one option for scanners and similar devices[7]. On the Google side, then, the job is to inventory app passwords and delete the ones nobody needs. SCuBA additionally requires POP and IMAP access to be disabled (GWS.GMAIL.9.1v1)[2].

Admin accounts: least privilege, plus two emergency accounts

Why: if a Global Administrator or super admin account is compromised, the whole tenant belongs to the attacker. Google warns that super admins can manage every aspect of the company's account and access all business and employee data, so they should sign in only to do specific tasks and then sign out, using an account with limited admin roles for daily administration[8].

  • Keep the count within limits: SCuBA requires between two and eight Global Administrators and between two and eight Google super admins, with other admin work done through finer-grained roles (MS.AAD.7.1v1, MS.AAD.7.2v1, GWS.COMMONCONTROLS.6.2v1)[2]. Google's small-business security checklist also recommends a second super admin, managed by a different person, as a backup if the primary account is lost or compromised[8].
  • Separate admin and daily work: Microsoft recommends that admins have separate accounts for administration and for everyday productivity tasks[3]; SCuBA also requires privileged accounts to be cloud-only rather than synced from an on-premises directory (MS.AAD.7.3v1)[2].
  • Two emergency access ("break-glass") accounts: Microsoft recommends creating two or more, for situations such as all of an administrator's MFA devices being unavailable, a federation outage, or the last Global Administrator leaving the organization[9]. They should be cloud-only *.onmicrosoft.com accounts assigned the Global Administrator role and not tied to an individual employee; sign in with a passkey (FIDO2) or certificate-based authentication, using a different method from your normal admin accounts; be excluded from Conditional Access policies that block or restrict sign-in; have their credentials, such as security keys, stored in separate secure locations; trigger an alert on every sign-in; and be tested at least every 90 days[9].

Create the emergency accounts before you turn on MFA, block legacy authentication or add Conditional Access policies. Conditional Access policies can first be set to report-only, which does not block sign-ins[9]; switch them on once you have confirmed the impact.

Mailbox: forwarding, app consent and mail protection

Turn off automatic forwarding to external addresses

Why: once inside a mailbox, attackers often create inbox rules that forward mail out automatically, so they can keep reading the conversation and later send a fake payment notice at the right moment (see Phishing and business email compromise). Microsoft also notes that inbox rules forwarding to external recipients may be set up deliberately by users or as a result of a compromised account, and that the disclosed information can be used to attack the organization or its partners[10].

Microsoft 365 controls automatic forwarding in the outbound spam policy, which has three options. The default, Automatic - System-controlled, can behave differently from one organization to another, so Microsoft recommends setting On or Off explicitly[10]. Off disables every inbox rule and mailbox forwarding setting that redirects mail to external addresses, and senders receive a 5.7.520 bounce; forwarding between internal users is not affected. If there is a real business need, you can allow forwarding in the policy and use remote domains to limit which external domains it can go to; when settings conflict, the block typically wins[10]. SCuBA likewise requires automatic forwarding to external domains to be disabled (MS.EXO.1.1v2)[2]. In Google Workspace automatic forwarding is on by default; you can turn it off under Apps > Google Workspace > Gmail > End User Access > Automatic forwarding in the Admin console, or allow forwarding to internal addresses only, and you can set it per organizational unit[11].

Restrict users from consenting to third-party apps

Why: malicious applications try to trick users into clicking "Accept" so they can gain access to the organization's data[12]; this technique is often called consent phishing.

By default, Microsoft Entra lets all users consent to permissions that don't require admin consent, for example letting an app access their own mailbox. Microsoft recommends allowing user consent only for apps from verified publishers and only for permissions you classify as low impact, sending everything else to admins for review, and you can enable the admin consent workflow so users can submit requests[12]. Note that changing the setting only affects future consent; grants already given remain in place and have to be reviewed separately[12]. SCuBA requires that only admins can register applications, that user consent is restricted and that an admin consent workflow is configured (MS.AAD.5.1v1, 5.2v1, 5.3v1)[2].

In Google Workspace the setting is under Security > Access and data control > API controls in the Admin console. For unconfigured third-party apps the default is "Allow users to access any third-party apps", and those apps can request unrestricted Google data. You can change it to allow only apps that request the basic sign-in information (name, email address and profile picture), or to block all third-party apps until an admin configures them, and let users request access[13]. SCuBA requires that users not be allowed to access unconfigured third-party apps (GWS.COMMONCONTROLS.10.4v1)[2].

Turn on built-in attachment and link protection

Why: phishing mail depends on malicious attachments and links. Both platforms scan mail out of the box, but the stricter settings have to be switched on by an admin.

Microsoft 365 preset security policies bundle anti-spam, anti-malware and anti-phishing settings at Microsoft's recommended values: Standard suits most users, Strict is for high-value targets or priority users, and neither takes effect until an admin turns it on and assigns users[14]. Safe Links, Safe Attachments and impersonation protection belong to Defender for Office 365, so availability depends on your plan; in organizations with those licenses, the Built-in protection policy applies Safe Links and Safe Attachments to all recipients by default[14]. For Microsoft 365, SCuBA requires blocking click-to-run attachments including at least .exe, .cmd and .vbe files, and quarantining or dropping mail identified as containing malware (MS.SECURITYSUITE.1.1v1, 1.3v1)[2].

Google's small-business security checklist recommends turning on enhanced pre-delivery message scanning in Gmail and the additional malicious file and link screening for attachments, links and external images[8]; SCuBA lists the Gmail protections to enable one by one, such as protecting against encrypted attachments and attachments with scripts from untrusted senders, identifying links behind shortened URLs, and showing a warning before any click on links to untrusted domains (GWS.GMAIL.5.1v1, 5.2v1, 6.1v1, 6.3v1)[2]. Stopping others from spoofing your domain takes SPF, DKIM and DMARC; see the SPF, DKIM and DMARC deployment guide.

File sharing and audit logs

Tighten external sharing defaults

Why: "Anyone" links open without signing in, and once a link is forwarded you can't track who has access or who has accessed the files[15].

Organization-level external sharing for SharePoint and OneDrive has four levels: Anyone, New and existing guests, Existing guests, and Only people in your organization. OneDrive can be more restrictive than SharePoint but not more permissive, and each site's setting must be the same as or more restrictive than the organization's[15]. You can also set the default link type users see when sharing (Specific people, Only people in your organization, Anyone with the link), require Anyone links to expire within a set number of days or give view-only access, and allow or block specific domains[15]. SCuBA requires external sharing to be limited to "Existing guests" or "Only people in your organization", the default link to be "Specific people" with view-only permission, and Anyone links to expire in 30 days or less (MS.SHAREPOINT.1.1v1, 1.2v1, 2.1v1, 2.2v1, 3.1v1)[2]. An SME that exchanges files with customers all the time may not be able to turn external sharing off, but it can at least make "Specific people" the default link and put an expiry on Anyone links.

Google's small-business security checklist recommends turning default link sharing off, so that only the creator can open a new file until they explicitly share it, and warning users when they share a file with people outside the company[8]; SCuBA goes further and requires external sharing to be restricted to allowlisted domains (GWS.DRIVEDOCS.1.1v1)[2].

Make sure audit logging is actually on

Why: when an account is compromised, finding out what the attacker read and changed depends on audit logs; if logging was off, there is nothing to investigate afterwards. If auditing is turned off in Microsoft 365, audit log searches in Purview return no results[16].

Microsoft says audit logging is on by default for Microsoft 365 organizations, but not for small and medium business licenses, including Microsoft 365 Business Basic, Business Standard and Business Premium, or for unmanaged tenants on free trials of enterprise licenses; those must turn it on manually[16]. To check, run Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled in Exchange Online PowerShell; True means auditing is on. It has to be Exchange Online PowerShell, because in Security & Compliance PowerShell the value always shows False[16]. If it is off, open the Audit page in the Microsoft Purview portal and select the Start recording user and admin activity banner; it can take up to 60 minutes to take effect[16]. SCuBA requires unified audit logging and mailbox auditing to be enabled (MS.SECURITYSUITE.5.1v1, MS.EXO.13.1v1)[2].

In Google Workspace, log events are searched under Reporting > Audit and investigation in the Admin console, for all users regardless of their edition; the more capable security investigation tool is available only in certain editions[17]. You can also opt in to share log event data with Google Cloud, where Cloud Logging lets you query the logs and control how they are routed and stored; the types of data you can share depend on your plan[17]. SCuBA also requires Google's specified system-defined alerting rules to be enabled (GWS.COMMONCONTROLS.13.1v1)[2]. For how long each cloud log is kept and whether to export it to storage you control, see What to log and how long to keep it.

Only one afternoon: do these five things first

  1. Confirm audit logging is on: check Microsoft 365 with the command above, especially on SME plans. It affects no users and decides whether you can investigate anything later.
  2. Prepare a way back in: in Microsoft 365, create two emergency access accounts and register passkeys or security keys for them; in Google Workspace, make sure there are at least two super admins. Every setting that tightens sign-in from here on relies on them so you don't lock yourself out.
  3. Get MFA on everyone: Microsoft 365 tenants without a Conditional Access license should simply turn on security defaults, which also block legacy authentication; licensed tenants should use Conditional Access. In Google Workspace, enforce 2SV first for admins, finance and executives, then set an enrollment period and enforce it for everyone. Tell staff before you switch it on.
  4. Turn off external auto-forwarding: set the Microsoft 365 outbound spam policy to Off; in Google Workspace, turn automatic forwarding off or restrict it to internal addresses. For accounts that genuinely need it, ask why and keep a register of exceptions.
  5. Tighten third-party app consent: in Microsoft Entra, allow consent only for verified publishers and low-impact permissions and enable the admin consent workflow; in Google Workspace, set unconfigured third-party apps to basic sign-in information only or block them. While you are there, look at the list of apps already authorized.

With the rest of the afternoon or next week: find the devices still sending mail with SMTP AUTH or app passwords, tighten file sharing defaults, turn on preset security policies and Gmail's advanced protections, then run ScubaGear or ScubaGoggles and use the report as your next to-do list. If you don't have the people in-house to work through the report, consider a security health check.

Action checklist

  • Download the latest ScubaGear or ScubaGoggles, run it once and keep the report as your starting baseline.
  • Confirm the Microsoft 365 unified audit log shows True; in Google Workspace, make sure admins know where to search log events, and plan log exports.
  • Create two Microsoft 365 emergency access accounts (passkey sign-in, excluded from blocking Conditional Access policies, alert on every sign-in) and keep at least two Google Workspace super admins; test them every 90 days.
  • Keep Global Administrators and super admins between two and eight, and use limited-role accounts for daily work.
  • Enforce MFA on every account, moving admins to passkeys or security keys first.
  • Block legacy authentication; list the devices and systems still sending mail via SMTP AUTH and move them to OAuth or another method before the end of December 2026; delete Google Workspace app passwords that are no longer needed.
  • Turn off external auto-forwarding, keep a register of exceptions and review it regularly.
  • Restrict user consent to third-party apps and review existing grants.
  • Make "Specific people" with view-only access the default sharing link, and set an expiry on Anyone links or disable them.
  • Turn on Microsoft 365 preset security policies (at least Standard for everyone, Strict for executives and finance) and Gmail's enhanced scanning.
  • Re-run the assessment tool every quarter, and watch the advisories for cases of cloud account compromise.