A Microsoft 365 tenant security baseline you can apply in a day

A practical one-day security baseline for a Microsoft 365 tenant has eight parts: two cloud-only emergency access accounts, fewer than five Global Administrators, MFA for everyone through security defaults or Conditional Access, legacy authentication blocked, user consent to apps restricted to verified publishers, the Standard preset security policy for email, automatic external forwarding turned off, and unified audit logging confirmed on. Then you record your Microsoft Secure Score so you can prove the change and keep improving it.

Who this is for and what you will have at the end

This guide is for administrators who have just inherited a tenant, created a new one, or been asked to "lock down Microsoft 365" without a long project. It assumes you have Global Administrator access for the day and can reach users to tell them about MFA.

At the end of the day you will have:

• A tenant you can't lock yourself out of.
• A small, documented set of privileged accounts.
• MFA and legacy authentication controls in place (enforced or in report-only, depending on your licence).
• Users unable to grant risky apps access to company data.
• Microsoft-recommended email protection applied to all recipients.
• No silent data leakage through external mail forwarding.
• A searchable audit log and a Secure Score snapshot to report against.

This baseline doesn't cover device management, data loss prevention or retention. Those are separate projects and need more than a day.

Before you start

Licences decide some choices

Check which of these your subscriptions include before you choose between security defaults and Conditional Access in Step 3.

Take a Secure Score snapshot

Open Microsoft Secure Score at https://security.microsoft.com/securescore and note the current score and the top recommended actions. Secure Score updates in real time and syncs daily, and Microsoft Entra and Teams recommendations can take longer to refresh, so expect some actions you complete today to show tomorrow or later. You need Security Administrator, Exchange Administrator or SharePoint Administrator to change action status; Global Reader and Security Reader can view.

Step 1: Create emergency access accounts first

Do this before any other change so a policy mistake later in the day can't lock you out.

1. Create two cloud-only users on the contoso.onmicrosoft.com domain, not federated and not synced from on-premises.
2. Assign them Global Administrator. If you use Privileged Identity Management, make the assignment active and permanent, not eligible.
3. Register a passkey (FIDO2) on a security key for each account, or certificate-based authentication if you already have PKI. Both satisfy mandatory MFA, which applies to emergency accounts as well.
4. Use a different authentication method from your everyday admin accounts, and don't tie the accounts to anyone's phone.
5. Put both accounts in a group such as EmergencyAccess and exclude that group from every Conditional Access policy that blocks or restricts sign-in. Report-only policies don't need the exclusion.
6. Store the keys in separate secure locations, and test sign-in at least every 90 days.

If you stream sign-in logs to Log Analytics, add an alert that fires on any sign-in by these accounts. Microsoft's guidance uses a log search alert on SigninLogs filtered by the accounts' object IDs, with a threshold greater than 0 and severity 0 (Critical).

Step 2: Reduce standing admin access

In the Microsoft Entra admin center, go to Entra ID > Roles & admins > All roles and review who holds Global Administrator and other privileged roles (marked PRIVILEGED).

Microsoft's targets are concrete:

• Fewer than five people with Global Administrator. The Entra Overview page shows an alert card when you have five or more.
• Fewer than 10 privileged role assignments. The Roles and administrators page warns you above that number.
• Cloud-native accounts for role assignments, not accounts synced from on-premises, so an on-premises compromise doesn't become a cloud compromise.
• Separate admin and day-to-day accounts.

Replace Global Administrator with the least-privileged role for each task: Exchange Administrator, SharePoint Administrator, User Administrator, Helpdesk Administrator and so on. If you have P2, convert the remaining assignments to eligible in Privileged Identity Management so admins activate roles only when needed.

Step 3: Turn on MFA and block legacy authentication

Your path depends on licensing.

Without Entra ID P1: security defaults

Security defaults are free and enforce:

• MFA registration for all users, with no 14-day grace period since July 2024.
• MFA for 16 administrator roles at every sign-in.
• MFA for users when Microsoft decides it is needed.
• Blocking of legacy authentication protocols, including Exchange ActiveSync basic authentication.
• Blocking of device code flow.
• MFA for anyone using Azure Resource Manager: the Azure portal, the Microsoft Entra admin center, Azure PowerShell and Azure CLI.

To check or enable them, sign in as at least a Conditional Access Administrator, go to Entra ID > Overview > Properties, select Manage security defaults, set Security defaults to Enabled and save. Users register Microsoft Authenticator with notifications; tell them first and point them to https://myprofile.microsoft.com.

Before enabling, confirm that admins aren't using legacy protocols, and that no device or app depends on device code flow.

With Entra ID P1 or P2: Conditional Access templates

Microsoft requires you to disable security defaults when Conditional Access policies replace them, and to enable those policies immediately afterwards. When you disable them, Microsoft-managed Conditional Access policies are available to keep the same protections.

Then go to Entra ID > Conditional Access > Create new policy from templates and deploy the Secure foundation set, which Microsoft recommends as the base for all organizations:

• Require multifactor authentication for admins
• Securing security info registration
• Block legacy authentication
• Require multifactor authentication for admins accessing Microsoft admin portals
• Require multifactor authentication for all users
• Require multifactor authentication for Azure management
• Require compliant or Microsoft Entra hybrid joined device or multifactor authentication for all users
• Require compliant device

Two details catch people out. Template policies are created in report-only mode, so they protect nothing until you turn them on. And templates exclude only the admin who creates them, so edit each policy to exclude your EmergencyAccess group and remove the personal exclusion.

Review report-only results in the sign-in logs, then switch policies to On. The device compliance templates need Intune or another MDM; leave them in report-only if devices aren't enrolled yet. For a wider access design, see the Zero Trust remote access architecture.

Mandatory MFA is already enforced for admin portals

Independently of your choice, Microsoft enforces MFA for the Azure portal, Microsoft Entra admin center, Intune admin center and Microsoft 365 admin center, and for create, update and delete operations through Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tools and the Azure Resource Manager REST API. There is no opt-out, and break-glass accounts are not exempt. Any automation that signs in as a user account needs to move to a managed identity or service principal, because the resource owner password credentials (ROPC) flow doesn't work with MFA.

Because SMS and voice MFA delivered by Microsoft is being retired in 2027, steer registrations towards Authenticator and passkeys now. The details are in the SMS and voice MFA retirement guide and the passkey deployment guide.

Step 4: Restrict user consent to applications

By default, users can consent to any app for permissions that don't need admin consent, including access to their own mailbox. Malicious applications use this to trick users into granting them access to organizational data.

1. Go to Identity > Applications > Enterprise apps > Consent and permissions > User consent settings.
2. Under User consent for applications, choose Allow user consent for apps from verified publishers, for selected permissions. This is the built-in policy microsoft-user-default-low, and Microsoft recommends allowing consent only for verified publishers.
3. Classify which permissions count as low impact, so users can only grant those.
4. Enable the admin consent workflow so users can request apps they can no longer approve themselves.

Changing this setting only affects future consents. Review permissions already granted to enterprise applications separately.

Step 5: Apply the Standard preset security policy to email

Preset security policies apply Microsoft's recommended anti-spam, anti-malware and anti-phishing settings (and Safe Links and Safe Attachments with Defender for Office 365) as a block you don't have to tune.

1. Open https://security.microsoft.com/presetSecurityPolicies, or go to Email & collaboration > Policies & rules > Threat policies > Preset Security Policies.
2. Turn Standard protection on and select Manage protection settings.
3. On Apply Exchange Online Protection, choose All recipients.
4. If you have Defender for Office 365, choose recipients on Apply Defender for Office 365 protection. If only some users are licensed, target those users or groups.
5. Add executives and other likely impersonation targets for user impersonation protection (up to 350 users) and any partner domains for domain impersonation protection (up to 50). Your accepted domains are protected automatically.
6. Review and select Confirm.

Consider Strict protection for high-value users such as executives and finance. Strict is always applied first, then Standard, then any custom or default policies, so a user in both gets Strict.

Confirm the rules exist in Exchange Online PowerShell:

Connect-ExchangeOnline
 
Get-EOPProtectionPolicyRule -Identity "Standard Preset Security Policy"
Get-ATPProtectionPolicyRule -Identity "Standard Preset Security Policy"

Don't edit the individual threat policies the preset creates; Microsoft supports managing presets only through the preset page and its rules.

Step 6: Turn off automatic external forwarding

Inbox rules and mailbox forwarding that send mail to outside addresses risk disclosing information, and attackers set them up on compromised accounts. The control is the Automatic forwarding rules setting in outbound spam policies. Its default value, Automatic - System-controlled, behaves as Off in most organizations but as On in some older ones, so set it explicitly.

Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode Off
 
Get-HostedOutboundSpamFilterPolicy -Identity Default | Format-List AutoForwardingMode

In the portal, the setting is in Anti-spam policies (https://security.microsoft.com/antispam) > Anti-spam outbound policy (Default) > Protection settings > Forwarding rules.

If a business process genuinely needs external forwarding, create a custom outbound spam policy with forwarding On for only those senders, or allow forwarding in the policy and restrict destinations with remote domains. When two controls disagree, the block usually wins. Internal forwarding isn't affected by any of these settings.

The Auto forwarded messages report shows who was forwarding before the change.

Step 7: Confirm unified audit logging is on

Without the audit log you can't investigate a compromised mailbox or a malicious consent grant. Microsoft states that auditing is on by default for most organizations, but not for Business Basic, Business Standard and Business Premium tenants or unmanaged enterprise trials.

Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

Run this in Exchange Online PowerShell. The same cmdlet exists in Security & Compliance PowerShell, but there the property always shows False. If the value is False, turn it on:

Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

You can also select Start recording user and admin activity on the Audit solution in the Microsoft Purview portal. Enabling can take up to 60 minutes to take effect, and events can take several hours to become searchable. You need the Audit Logs role, which the Organization Management and Compliance Management role groups have by default.

Step 8: Verify and record

In Secure Score, mark recommended actions you addressed with a non-Microsoft product or an alternate mitigation accordingly, so the score reflects reality. If you use security defaults, Secure Score awards full points for the MFA and legacy authentication actions they cover.

Troubleshooting

Users report 550 5.7.520 Access denied, Your organization does not allow external forwarding. The outbound spam policy is doing its job. Either remove the inbox rule or forwarding setting, or add the sender to a custom outbound spam policy with forwarding allowed if there's an approved business need.

Forwarding still works for some users after you set the default policy to Off. A custom outbound spam policy with a higher priority applies to them, and protection stops at the first matching policy. Check Get-HostedOutboundSpamFilterRule and the policies it references.

UnifiedAuditLogIngestionEnabled shows False even though audit search works. You ran the cmdlet in Security & Compliance PowerShell. Run it in Exchange Online PowerShell.

Admins locked out after enabling a template policy. The template excluded only its creator. Sign in with an emergency access account, set the policy to report-only, add the EmergencyAccess exclusion and review again.

Scripts fail after MFA enforcement. They sign in as a user, often through ROPC. Move them to a service principal or managed identity; workload identities aren't affected by mandatory MFA.

Users don't see a preset policy applied. Dynamic distribution groups and Microsoft 365 Groups with dynamic membership aren't supported as recipient conditions in preset security policies. Use a static distribution group, a mail-enabled security group, individual users or the domain condition instead.

Checklist

• Two cloud-only emergency access accounts with passkeys, excluded from blocking policies, tested.
• Fewer than five Global Administrators, fewer than 10 privileged assignments, cloud-native admin accounts.
• Security defaults on, or Secure foundation Conditional Access policies switched from report-only to on.
• Legacy authentication and device code flow blocked.
• User consent limited to verified publishers; admin consent workflow enabled.
• Standard preset security policy for all recipients; Strict for high-value users.
• AutoForwardingMode set to Off on the default outbound policy.
• Unified audit log confirmed on.
• Secure Score snapshot taken before and after.

References

• Configure security defaults for Microsoft Entra ID
• Conditional Access templates
• Plan for mandatory Microsoft Entra multifactor authentication
• Manage emergency access admin accounts
• Best practices for Microsoft Entra roles
• Configure how users consent to applications
• Preset security policies in EOP and Defender for Office 365
• Control external email forwarding and fix 5.7.520 errors
• Configure outbound spam policies
• Set-HostedOutboundSpamFilterPolicy
• Turn auditing on or off
• Microsoft Secure Score