Microsoft 365 Tenant Hardening: Complete Security Baseline for Enterprise

Why Default M365 Configuration Is Insecure

Every Microsoft 365 tenant starts life in the same state: legacy authentication enabled, no Conditional Access policies, every admin with standing Global Admin, and Defender for Office 365 running on its default — not Standard or Strict — configuration.

This is not a criticism of Microsoft's defaults. They optimise for compatibility and accessibility. But they are not a security baseline. They are a starting point.

The consequence is predictable. Password spray attacks succeed against accounts without MFA. Legacy authentication bypasses Conditional Access entirely — it does not understand the concept. A compromised Global Admin account has permanent, unrestricted access to everything. Defender's default policies miss a meaningful proportion of known attack patterns.

I hardened tenants at Ericsson and Körber across different environments and scales. The attack surface is the same in both. So is the remediation.

Conditional Access: Design Before You Deploy

The most common Conditional Access mistake is deploying policies before designing them. A policy stack has to be thought of as a system — not a collection of individual rules.

The baseline stack I deploy covers five distinct layers:

Layer 1 — MFA for all users, all apps. No exceptions except break-glass. This is the highest-value, lowest-disruption control in the stack. Use Conditional Access, not per-user MFA — per-user MFA creates exceptions that are never cleaned up.

Layer 2 — Block legacy authentication. A dedicated policy with condition: client apps = legacy authentication clients. Action: block. This single policy eliminates the entire class of password spray attacks that bypass MFA via IMAP, POP3, SMTP Auth and Basic Auth.

Layer 3 — Require device compliance. Scope: all apps, all users. Controls: require compliant device OR hybrid-joined device. Combined with an Intune compliance policy, this ensures that only managed, healthy devices can access corporate data.

Layer 4 — Admin hardening. Scope: directory roles. Controls: require phish-resistant MFA (FIDO2 or Windows Hello for Business), require compliant device. Admins get a stricter policy than regular users. This is deliberate.

Layer 5 — Risk-based. Scope: all users. Conditions: sign-in risk = high OR user risk = high. Controls: block (high), require MFA + password change (medium). This requires Entra ID P2 but is straightforward to configure once the baseline is in place.

Each policy is deployed in report-only mode first. You validate against 30 days of sign-in logs before enforcement. This is not optional — it is how you avoid locking out a business-critical service account at 9am on a Monday.

MFA and Phishing-Resistant Authentication

MFA matters, but not all MFA is equal. SMS OTP and TOTP codes are phishable — adversary-in-the-middle attacks capture the code and replay it in real time. This is not theoretical; it is the mechanism behind the majority of successful MFA bypass attacks in the wild.

Phishing-resistant authentication methods:

• FIDO2 security keys (YubiKey, etc.) — the gold standard
• Windows Hello for Business — certificate or key-based, device-bound
• Passkeys (preview in Entra ID, production in 2025)

Prioritisation:

• All admin accounts: FIDO2 or WHfB required. No exceptions.
• Priority accounts (executives, finance, HR): phish-resistant MFA required via Conditional Access authentication strength.
• All other users: any MFA method is fine as a baseline. Migrate to phish-resistant over time.

# Verify which users have phishing-resistant methods registered
Get-MgUser -All | ForEach-Object {
    $methods = Get-MgUserAuthenticationMethod -UserId $_.Id
    [PSCustomObject]@{
        UPN     = $_.UserPrincipalName
        Methods = ($methods.AdditionalProperties.Values | Where-Object { $_ -match 'fido|windowsHello' }) -join ", "
    }
} | Where-Object { $_.Methods -ne "" }

PIM for Admin Roles

Standing Global Admin is the highest-risk configuration in any Microsoft tenant. A compromised account with standing GA can exfiltrate the entire directory, create new accounts, disable MFA for all users, and disable Conditional Access — all within minutes.

Privileged Identity Management eliminates standing privilege. Every admin role becomes eligible rather than active. To use the role, the admin must:

1. Navigate to the PIM portal or use the API
2. Request activation with a business justification
3. Satisfy an MFA challenge (phish-resistant if configured)
4. Receive time-limited activation (1–8 hours)

The justification and activation are logged. Alerts fire for activations outside business hours or without justification.

Priority roles for PIM:

• Global Administrator
• Privileged Role Administrator
• Privileged Authentication Administrator
• Exchange Administrator
• Security Administrator
• Intune Administrator

# List all users with active (non-PIM) Global Admin assignments
Get-MgDirectoryRoleMember -DirectoryRoleId (
    Get-MgDirectoryRole | Where-Object { $_.DisplayName -eq "Global Administrator" }
).Id | Select-Object Id, DisplayName, UserPrincipalName

Any user returned by that query has standing GA. That is the list you are working from.

Defender for Office 365: Presets Over Custom

Defender for Office 365 is configured via two mechanisms: preset security policies and custom policies. The guidance is simple — use presets.

Preset security policies (Standard and Strict) are Microsoft-managed, updated when the threat landscape changes, and tested against real-world attack campaigns. Custom policies require your team to maintain them. In practice, custom policies go stale, develop exceptions, and create coverage gaps.

Deploy Strict to priority accounts first:

# Apply Strict preset to a group of priority accounts
Set-ATPProtectionPolicyRule -Identity "Strict Preset Security Policy" `
    -SentTo @() `
    -SentToMemberOf @("sg-priority-accounts@contoso.com")

Verify Safe Links and Safe Attachments are active:

Get-SafeLinksPolicy | Select-Object Name, IsEnabled, ScanUrls, EnableForInternalSenders
Get-SafeAttachmentPolicy | Select-Object Name, Enable, Action

The output should show IsEnabled = True and Action = DynamicDelivery on all user-facing policies.

Secure Score: Target 85+, Ignore the Rest

Secure Score is a useful directional metric. It is not a target to optimise blindly. Some recommendations improve security materially. Others require significant operational change for minimal security benefit.

High value (implement immediately):

| Control | Secure Score Impact | |---|---| | Require MFA for all admins | 10–15 pts | | Block legacy authentication | 7–10 pts | | Enable Defender for Office 365 presets | 10–14 pts | | Enable PIM for privileged roles | 8–12 pts | | Configure DKIM and DMARC | 4–6 pts |

Low value or high disruption (evaluate carefully):

• "Restrict SharePoint external sharing" — assess business impact before enforcing
• Recommendations requiring E5 when tenant is on E3 — acknowledge as accepted risk
• "Enable MFA for all users" via Security Defaults — use Conditional Access instead

The target is a defensible configuration you can explain to an auditor, not a maximum score achieved by accepting every recommendation regardless of operational impact.

Legacy Authentication Eradication

Before blocking legacy authentication, you need to know what is using it. There are always surprises.

# Query sign-in logs for legacy authentication in the last 30 days
$startDate = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")

Get-MgAuditLogSignIn -Filter "createdDateTime ge $startDate and clientAppUsed ne 'Browser' and clientAppUsed ne 'Mobile Apps and Desktop clients'" `
    -All | Select-Object UserPrincipalName, ClientAppUsed, AppDisplayName, CreatedDateTime `
    | Group-Object UserPrincipalName | Sort-Object Count -Descending

Common legacy auth sources that require investigation before blocking:

• Line-of-business applications using Basic Auth to access Exchange
• Shared mailboxes monitored by scripts via IMAP
• Printers and MFPs scanning to email via SMTP Auth
• Legacy monitoring tools

Each dependency needs a migration path before the legacy auth block is enforced. Document every exception, assign an owner, set a deadline.

Evidence and Rollback

Every change in a hardened tenant engagement produces:

• Before screenshots — current configuration of every policy being changed
• After screenshots — post-change configuration with timestamp
• Sign-in log validation — 48h of sign-in logs reviewed after each policy enforcement
• PowerShell export — Export-Csv of all CA policies, auth methods, PIM assignments
• Rollback procedure — documented steps to revert every change, tested before enforcement

The evidence pack is not bureaucracy. It is the difference between a confident rollback and a 2am guesswork session during an incident.

Decision Priorities for a Defensible Security Baseline

A strong hardening programme does not implement every available control at once. It sequences controls by risk reduction, operational readiness, and licensing reality.

The order I recommend is:

1. Remove the easiest high-impact exposure: admin over-privilege and weak MFA.
2. Eliminate legacy authentication and unmanaged access paths.
3. Establish device trust and compliant access for corporate data.
4. Raise email and collaboration protections to a defined baseline.
5. Tune detection, evidence collection, and governance so the baseline can be sustained.

This matters because a tenant can look "advanced" on paper while still carrying basic exposure in admin roles, exceptions, and unmanaged devices.

Common Hardening Mistakes

The recurring problems are straightforward:

• Deploying controls without ownership. If no team owns CA exclusions, PIM reviews, Secure Score triage, and Defender policy drift, the baseline decays quickly.
• Trying to maximise Secure Score blindly. Some recommendations are valuable, others create disruption without proportionate benefit.
• Using exceptions as a substitute for remediation. A temporary SMTP Auth or sharing exception becomes permanent unless it is tracked like a risk item.
• Ignoring the operational evidence pack. Hardening work that cannot be evidenced is hard to defend to auditors and hard to troubleshoot under pressure.

The quality of the baseline is determined as much by review discipline as by the original implementation.

What to Validate Before You Call the Tenant Hardened

Before closing the engagement or declaring the baseline complete, confirm:

• privileged roles are eligible through PIM and reviewed regularly
• break-glass accounts are tested, monitored, and excluded correctly
• CA report-only results have been worked through and enforcement incidents are understood
• Defender for Office 365 presets, DKIM, and DMARC are aligned to the active mail flow design
• legacy authentication exceptions have owners, deadlines, and a retirement path

If those answers are weak, the tenant is improved but not yet hardened in a way an enterprise can rely on.

Recommended Baseline Position

If an organisation wants a credible Microsoft 365 security baseline without overengineering, the minimum defensible position is:

• no standing administrative privilege
• no unmanaged admin access
• no unexplained legacy authentication dependencies
• a defined email protection baseline using Microsoft-managed presets
• evidence, ownership, and review cadence for every meaningful exception

That position is achievable in most enterprise tenants and provides a far stronger foundation than chasing advanced controls while basic exposure remains open.

If your tenant hasn't been through a structured hardening engagement, your Secure Score is probably below 60 and your legacy auth block is still pending. Book a discovery call to find out.

Carlos AnnesSenior Microsoft 365 / Hybrid Architect10+ years designing and securing enterprise Microsoft infrastructure.