Microsoft 365 Security Guide

A Microsoft 365 tenant holds an organisation's mail, files, chat and identities behind one control plane, and most of its security depends on settings the customer has to choose. Attackers rarely need an exploit: password spray against an account without MFA, a consented OAuth app, an inbox forwarding rule or an "Anyone" sharing link is usually enough. This guide covers the configuration that matters most, mapped to the CISA SCuBA baselines and Microsoft's own documented settings: Entra ID sign-in controls, privileged roles, Exchange Online and Defender for Office 365, external sharing, app consent, Copilot data access and audit. It is written for Microsoft 365 administrators and security engineers, and names Microsoft features because they are the controls.

Key takeaways

• Start from a published baseline, not from memory: the CISA SCuBA baselines give testable SHALL statements, and ScubaGear checks a tenant against them automatically.
• Identity is the tenant perimeter. Block legacy authentication and device code flow, require MFA for everyone and phishing-resistant MFA for administrators, using Conditional Access where you hold Entra ID P1 or security defaults where you do not.
• No standing Global Administrators. Keep between two and eight, make highly privileged roles eligible through PIM with approval and alerts, and keep two excluded emergency access accounts.
• User consent to OAuth apps is an access grant. Restrict it to verified publishers and low-impact permissions, route the rest through an admin consent workflow, and review existing grants.
• Logs you did not keep cannot be searched. Confirm mailbox auditing is on, know whether you have Audit (Standard) or Audit (Premium) retention, and export Entra sign-in and audit logs before the 30-day window closes.

Baselines and how to measure a tenant

Run ScubaGear (Install-Module -Name ScubaGear, Install-ScubaDependencies, then Invoke-SCuBA) before you change anything, keep the JSON output as your baseline, and rerun it after every change window. Treat Secure Score as a progress indicator, not evidence: partial points are calculated as a percentage, so 50 of 100 users on MFA scores 5 of 10 points on that action, which can look healthier than it is.

Sign-in controls: security defaults or Conditional Access

Entra ID offers two ways to enforce a baseline, and they are mutually exclusive: an organisation that moves to Conditional Access must disable security defaults first.

If you hold P1, the SCuBA Entra ID baseline is the policy set to aim for:

• Block legacy authentication (MS.AAD.1.1v1): a policy on All resources with the client apps condition set to Exchange ActiveSync clients and Other clients, action Block. Microsoft's own analysis attributes more than 99 percent of password spray attacks to legacy protocols. Basic authentication is now disabled in Exchange Online for EAS, POP, IMAP, EWS, Remote PowerShell and Outlook, but SMTP AUTH still accepts it until its announced retirement, so also disable SMTP AUTH (MS.EXO.5.1v1) except for named mailboxes that genuinely need it.
• MFA for all users (MS.AAD.3.2v2), phishing-resistant MFA for highly privileged roles (MS.AAD.3.6v1): use the built-in Phishing-resistant MFA authentication strength (FIDO2 security key, Windows Hello for Business or platform credential, multifactor certificate-based authentication). SCuBA goes further: MS.AAD.3.1v1 requires phishing-resistant MFA for all users, and MS.AAD.3.5v2 disables SMS, voice and email one-time passcodes. See the Passwordless and Passkeys Guide.
• Block device code flow (MS.AAD.3.9v1): device code phishing hands an attacker a token without a password ever being typed. Use the authentication flows condition and exclude only named meeting-room or kiosk devices.
• Block high-risk users and sign-ins (MS.AAD.2.1v1, 2.3v1): needs Entra ID P2 for Identity Protection risk signals.
• Require managed devices (MS.AAD.3.7v1, 3.8v1): the "Require device to be marked as compliant" grant ties access to Intune compliance policies. Apply it to admin portals first, then to all users once compliance reporting is reliable. See the Device Trust and Posture Guide.

Create every policy in report-only mode, leave it at least a week, and check the Conditional Access tab of interactive and non-interactive sign-in logs for "Report-only: Failure" before enforcing. Exclude emergency access accounts from every blocking policy. Policy design detail is in the Conditional Access Guide.

Privileged roles and PIM

Global Administrator controls the whole tenant, including the ability to grant any application access to every mailbox and file. The SCuBA privileged access policies are specific:

• Count: a minimum of two and a maximum of eight Global Administrators (MS.AAD.7.1v1), with finer-grained roles such as Exchange Administrator, SharePoint Administrator or Security Administrator used instead (MS.AAD.7.2v1).
• Cloud-only admin accounts (MS.AAD.7.3v1): privileged accounts must not be synchronised from on-premises Active Directory, so a domain compromise does not become a tenant compromise. The Storm-0501 hybrid cloud attacks show what happens when the sync path is the bridge.
• No permanent active assignments (MS.AAD.7.4v1): use Privileged Identity Management so roles are eligible, activated just in time with MFA and justification, and time-bound. Emergency access accounts are the documented exception.
• Approval and alerts (MS.AAD.7.6v1 to 7.9v1): require approval to activate Global Administrator, and alert on any new eligible or active assignment and on every Global Administrator activation.
• Emergency access: two or more cloud-only *.onmicrosoft.com accounts with Global Administrator, passkey or certificate authentication that differs from other admins, excluded from blocking Conditional Access policies, alerted on any sign-in and tested at least every 90 days. See the Break-Glass Account Guide.

PIM covers Entra roles, Azure resource roles and PIM for Groups, and requires Entra ID Governance licensing. Small tenants without it should still separate admin accounts from daily accounts and keep the Global Administrator count minimal. For the wider model see the JIT Access Guide.

Exchange Online and Defender for Office 365

Microsoft publishes Standard and Strict values for every protection policy and applies them through preset security policies. Applying the Standard preset to all users and Strict to executives and finance staff is faster and less error-prone than hand-built policies. Settings that matter most:

• Safe Attachments beyond email: turn on EnableATPForSPOTeamsODB (SharePoint, OneDrive and Teams) and EnableSafeDocs. These are global settings, not part of the Standard or Strict presets.
• Automatic forwarding: SCuBA MS.EXO.1.1v2 disables automatic forwarding to external domains. Set the outbound spam policy to Off rather than leaving Automatic, because inbox rules that forward mail persist after a password reset (ATT&CK T1114.003 Email Forwarding Rule).
• Sender authentication: publish SPF that fails non-approved senders (MS.EXO.2.2v3), enable DKIM signing for every accepted domain (MS.EXO.3.1v1), and publish DMARC at p=reject (MS.EXO.4.2v1). Microsoft advises fixing SPF, DKIM and DMARC before tightening filtering, or legitimate mail lands in quarantine. See the Email Security Guide.
• External sender warnings and sharing: implement external sender tagging (MS.EXO.7.1v1) and do not share calendar details or contact folders with all domains (MS.EXO.6.1v1, 6.2v1).

Safe Links and Safe Attachments need Defender for Office 365 Plan 1 or higher. Tenants with only Exchange Online Protection still get anti-spam, anti-malware, spoof intelligence and zero-hour auto purge, so the sender authentication and forwarding controls are the priority there.

SharePoint, OneDrive and Teams sharing

External sharing is set at the organisation level in the SharePoint admin center (Policies, Sharing), and every site and OneDrive can only be the same or more restrictive. The four levels are Anyone, New and existing guests, Existing guests, and Only people in your organization.

• Anyone links: unauthenticated, cannot be attributed to a person, and work if forwarded. If the business needs them, require expiry, restrict them to view-only, and allow them only on specific sites. Otherwise set the organisation level to New and existing guests.
• Default link type: set "Specific people" as the default so users have to choose to widen a link.
• Guest expiry: set "Guest access to a site or OneDrive will expire automatically after this many days" and limit sharing by domain (allow list or block list, up to 5,000 domains, or Set-SPOTenant -SharingDomainRestrictionMode).
• Who can share: use "Allow only users in specific security groups to share externally" for regulated data. Teams and Microsoft 365 Groups guest settings also govern the sites behind each team. See the Collaboration Tool Security Guide.
• Entra B2B integration: with it enabled, every external share creates a guest account that Entra external collaboration settings, Conditional Access and access reviews can govern.

Where identity fits: app consent and OAuth

Every OAuth app with delegated or application permissions on Microsoft Graph is a non-human identity with standing access to tenant data, and it is not stopped by user MFA. By default, Entra ID lets all users consent to applications for permissions that do not require administrator consent. Change that:

• Restrict user consent (MS.AAD.5.2v1): assign the built-in microsoft-user-default-low policy, which allows consent only for apps from verified publishers or registered in your tenant, and only for permissions you classify as low impact. Changing the setting does not remove existing grants.
• Admin consent workflow (MS.AAD.5.3v1): lets users request apps they cannot consent to, with a named reviewer.
• Only administrators register apps (MS.AAD.5.1v1) and app credential hygiene: block application password addition (MS.AAD.5.5v1), passwords no longer than 180 days and certificates no longer than 365 days (MS.AAD.5.6v1, 5.7v1).
• Review existing grants: look for tenant-wide grants (ConsentType AllPrincipals) and high-risk scopes such as Mail.*, Files.*, Directory.AccessAsUser.All and any application permission on Exchange. When investigating, disable the service principal rather than deleting it, because a deleted app can return if another user consents again.

The Midnight Blizzard breach began with a password spray against a forgotten test tenant account and pivoted through an OAuth app with elevated access into executive mailboxes. CoPhish showed consent phishing hosted on a trusted Microsoft domain. Inventory and lifecycle for these app identities is covered in the SaaS and OAuth App Governance Guide.

Copilot and data access

Microsoft 365 Copilot "only surfaces organizational data to which individual users have at least view permissions", and its Semantic Index honours the same identity-based access boundary. Copilot creates no new access, but it makes existing oversharing instantly searchable: a spreadsheet shared with "Everyone except external users" years ago becomes an answer to a casual prompt.

• Fix permissions before licensing: review sites with organisation-wide or Anyone links, broken inheritance and large Microsoft 365 Groups before rolling Copilot out widely.
• Use sensitivity labels with encryption: Copilot honours the usage rights a user holds on Purview-encrypted content.
• Retain and search interactions: prompts and responses are stored and can be found with Content search and governed with Purview retention policies; Microsoft states they are not used to train foundation models.

Prompt injection through shared content is a separate risk, illustrated by EchoLeak. See the Enterprise AI Copilot Security Guide.

Audit, detection and metrics

Mailbox audit logging is on by default for user, shared and Microsoft 365 Group mailboxes. Confirm it with Get-OrganizationConfig | Format-List AuditDisabled (False means on), and check nobody has been exempted with Get-MailboxAuditBypassAssociation. Default owner, delegate and admin actions include MailItemsAccessed, Send or SendAs, UpdateInboxRules and UpdateFolderPermissions.

The Storm-0558 breach is the case for keeping mail access logs: forged tokens read government mailboxes, and mail access auditing is what made the activity visible. Send Entra and Purview logs to your SIEM (SCuBA MS.AAD.4.1v1) and alert on: new inbox rules that forward or delete, consent grants and new app credentials, role assignments outside PIM, Conditional Access policy changes (T1556.009), mailbox delegation changes (T1098.002), and sign-ins by emergency access accounts. See the Log Management and Retention Guide.

Metrics that show it is working:

• ScubaGear pass rate for SHALL policies, tracked per run, with every failure either fixed or documented as accepted risk.
• Percentage of privileged role holders with phishing-resistant authentication registered and enforced (target 100).
• Number of standing (permanent active) highly privileged assignments outside emergency access accounts (target 0).
• Legacy authentication and device code sign-ins per week from the sign-in logs (target 0 outside approved exceptions).
• Tenant-wide OAuth grants and apps with high-risk permissions, reviewed in the last quarter.
• Active Anyone links and guests without expiry, trending down.

Implementation plan

1. Assess: run ScubaGear and export Secure Score. Confirm audit and mailbox auditing are on and start exporting Entra logs before changing anything, so you can see the effect of each change.
2. Protect admins first: create the two emergency access accounts, register phishing-resistant credentials for every administrator, move roles into PIM as eligible, and enforce the phishing-resistant strength on admin roles.
3. Close legacy paths: block legacy authentication and device code flow in report-only for a week, review the non-interactive sign-in tab for service accounts and printers using SMTP AUTH, then enforce. Rollback is disabling the policy; keep the emergency accounts excluded.
4. All-user MFA and mail protection: enforce MFA for all users, apply the Standard preset to everyone and Strict to a pilot group of high-risk users, and turn off external automatic forwarding after checking for legitimate business forwarders.
5. Consent and sharing: switch user consent to the low-impact policy with an admin consent workflow, review existing grants, then tighten external sharing defaults and guest expiry, starting with new sites.
6. Devices and Copilot: require compliant devices for admin portals, then for all users; complete the oversharing review before broad Copilot licensing.
7. Operate: rerun ScubaGear monthly and after major changes, review metrics quarterly, and alert on drift in Conditional Access and role assignments.

A small business on Business Premium can complete steps 1 to 5 in a few weeks using security defaults or the Conditional Access templates. A large enterprise should expect each step to take a change cycle with pilot rings, and should manage Conditional Access and Defender policies as code.

Framework mapping

Common failure patterns

• Forgotten tenants and test accounts: controls applied to production but not to old test or trial tenants with privileged links into it, as in the Midnight Blizzard breach.
• Conditional Access with silent gaps: exclusions that grew over time, policies left in report-only, or service accounts excluded "temporarily". The Conditional Access Gap Analyzer workbook lists legacy and unprotected sign-ins.
• Standing Global Administrators used daily: a single phished admin session then controls every workload, including device management; the Stryker Intune wiper attack shows how far one hijacked admin account reaches.
• Default user consent left on: users approve a convincing app and grant offline mail and file access that survives password resets, as seen in the Microsoft Verified Publisher OAuth phishing campaign.
• Password reset treated as remediation: inbox forwarding rules, delegate permissions, app consents and refresh tokens all survive it. Revoke sessions and review all four.

Practitioner checklist

• Run ScubaGear, store the JSON baseline, and rerun after every change window.
• Keep two to eight Global Administrators, all cloud-only, all eligible through PIM with approval and alerts.
• Create and test two emergency access accounts excluded from blocking policies, with sign-in alerts.
• Enforce phishing-resistant MFA for privileged roles and MFA for all users; block legacy authentication, SMTP AUTH and device code flow.
• Apply Standard or Strict preset security policies and turn off external automatic forwarding.
• Publish SPF, enable DKIM for all domains and move DMARC to p=reject.
• Restrict user consent to microsoft-user-default-low, enable the admin consent workflow and review tenant-wide grants.
• Default sharing links to Specific people, expire Anyone links and guests, and review oversharing before Copilot rollout.
• Confirm mailbox auditing and Purview audit, and export Entra and Graph activity logs to a SIEM with retention beyond your detection time.

Standards and references

• CISA: Secure Cloud Business Applications (SCuBA) Project
• CISA ScubaGear: Microsoft Entra ID Baseline
• CISA ScubaGear: Exchange Online Baseline
• Microsoft Learn: Security defaults in Microsoft Entra ID
• Microsoft Learn: Recommended settings for EOP and Microsoft Defender for Office 365 security
• Microsoft Learn: Configure how users consent to applications
• Microsoft Learn: Learn about auditing solutions in Microsoft Purview
• CIS: Microsoft 365 Benchmarks

Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · Conditional Access Guide · Enterprise AI Copilot Security Guide · Active Directory and Entra ID Hardening Guide · Email Security Guide