A lot of Microsoft 365 “security” starts with an upsell: Defender for Office 365, Entra ID P1, P2, the Worksuite. But a large share of the highest-impact hardening is already included in the subscription you pay for — it’s just switched off by default. This post is a practical, no-extra-cost checklist: what’s free, what it actually does, and the commands to verify it.

Companion reading: PowerShell + Microsoft Graph — Connection & Command Reference covers the PowerShell/Graph setup used in the verification commands below.


What’s actually free

FeatureWhat it doesLicense required
Security DefaultsOne switch: MFA for everyone, legacy auth blocked, privileged ops protectedEntra ID Free
MFA / Smart MFAMultifactor sign-in, including phone-call verificationFree (all M365 tenants)
Self-service password reset (SSPR)Users reset their own passwords, with MFAFree
Exchange authentication policiesBlock Basic Auth per-protocol, per-mailbox or org-wideFree (Exchange Online)
Baseline security modeOne-stop toggle set in the M365 admin center covering auth, files, and Teams room devicesAll M365 subscriptions
Sign-in + admin audit logsSee who signed in, how, and what admins changedFree (Entra ID)
Named locationsIP/geo groups for policy conditionsFree
Baseline M365 security portalSecurity posture overview, some alertsFree tier of the security portal

What is not free (don’t plan around these without a license): Conditional Access policies (Entra ID P1 per current Microsoft docs), risk-based sign-in/user-risk policies (P2 / Entra ID Protection), Privileged Identity Management and Identity Governance (P1/P2), and the Defender for Office 365 family.


1. Enable Security Defaults (if you have no P1 license)

If your tenant has no Conditional Access policies, no P1/P2 licenses, and no active legacy-auth clients, the single highest-value action is turning on Security Defaults:

  • Entra admin center → Entra ID → Properties → Manage security defaults → Enable

It turns on, in one switch:

  • MFA registration for all users
  • MFA for administrators on every sign-in
  • Adaptive MFA for regular users (new location, new device, risky sign-in, sensitive action)
  • Blocking of legacy authentication protocols (IMAP, POP3, SMTP AUTH, Exchange ActiveSync basic auth)
  • Blocking of the device code flow
  • MFA for privileged activities (Azure portal, Entra admin center, Azure PowerShell/CLI)

Caveats: it’s all-or-nothing — you can’t tune individual policies. And if you later buy P1, Microsoft’s own guidance is to replace Security Defaults with proper Conditional Access policies (the two can’t run side by side — enabling CA policies requires Security Defaults to be off).

Verify it’s on:

Connect-MgGraph -Scopes "Directory.Read.All" -UseDeviceCode
Get-MgPolicyAuthorizationPolicy | Select-Object -ExpandProperty Properties
# "securityDefaultsEnabled": true

Recommended follow-up: revoke existing tokens so users are forced through MFA registration immediately, rather than riding out on old sessions:

# per user, or loop over users
Revoke-MgUserSignInSession -UserId "<upn>"

2. Enroll everyone in MFA (and know your options)

MFA is free for every M365 tenant. If you’re not on Security Defaults (e.g. you have P1), use per-user MFA or a Conditional Access “require MFA” policy.

  • Standard MFA — authenticator app, SMS, voice call. SMS is the weakest option; push the Microsoft Authenticator app.
  • Smart MFA — free, and the only phone-call method that works with non-AD FS setups: the user gets a call, hears their name, and presses 1. No license needed.
  • Passkeys (phishing-resistant) — the strongest free option, and increasingly the default one. Microsoft began rolling out passkeys as the default MFA experience on September 1, 2026: any user currently on SMS or voice is auto-enrolled and prompted to register a passkey at their next sign-in. Microsoft-provided SMS/voice delivery is being retired outright on February 1, 2027 — after that, tenants that still need SMS/voice have to bring their own telecom provider through the Microsoft Security Store. Given that timeline, it’s worth pushing passkey registration now rather than waiting to be forced into it.
  • FIDO2 security key — also phishing-resistant; the key hardware is the only real cost.

SSPR (self-service password reset) is also free and pairs with MFA — users who reset their password get an MFA check, which closes the classic “forgot password → attacker resets password” loop.

Check registration status (Graph, free):

Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
    Select-Object UserDisplayName, IsMfaRegistered, MethodsRegistered, IsAdmin |
    Sort-Object IsAdmin -Descending |
    Format-Table -AutoSize

Chase the IsMfaRegistered = False rows first, admins before everyone else.


3. Block legacy authentication in Exchange Online

Microsoft has permanently removed Basic authentication for most legacy protocols — Exchange ActiveSync (EAS), POP, IMAP, Remote PowerShell (RPS), Exchange Web Services (EWS), Offline Address Book (OAB), and Autodiscover. For those, there’s nothing left to “disable” — the ability to re-enable Basic Auth was deleted tenant-side.

SMTP AUTH is the one exception, and it’s mid-transition right now. As of today it’s still usable with Basic Auth, but Microsoft has a firm, published retirement timeline:

  • Now → December 2026: SMTP AUTH Basic Auth behavior unchanged
  • End of December 2026: disabled by default for existing tenants (admins can still re-enable it if they have a documented business reason)
  • New tenants created after December 2026: unavailable by default, OAuth only
  • 2H 2027: Microsoft announces the final removal date

That’s only a few months out, so don’t wait for Microsoft to flip the switch — audit and lock it down yourself now:

Create and apply a Basic Auth block policy (free, Exchange Online PowerShell):

New-AuthenticationPolicy -Name "Block Legacy Auth"

Set-AuthenticationPolicy -Identity "Block Legacy Auth" `
  -AllowBasicAuthPop:$false `
  -AllowBasicAuthImap:$false `
  -AllowBasicAuthSmtp:$false `
  -AllowBasicAuthActiveSync:$false `
  -AllowBasicAuthRpc:$false `
  -AllowBasicAuthWebServices:$false `
  -AllowBasicAuthAutodiscover:$false `
  -AllowBasicAuthMapi:$false `
  -AllowBasicAuthOfflineAddressBook:$false `
  -AllowBasicAuthPowershell:$false `
  -AllowBasicAuthOutlookService:$false `
  -AllowBasicAuthReportingWebServices:$false

Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Legacy Auth"

Before you flip -AllowBasicAuthSmtp:$false org-wide, find out who’s actually still using it — the Exchange admin center’s SMTP AUTH Clients Submission Report shows which senders (scanners, line-of-business apps, relays, multifunction devices) are on Basic Auth vs. OAuth, so you can migrate them first instead of breaking them outright.

Verify per-mailbox protocol state:

Get-CASMailbox -ResultSize Unlimited |
    Where-Object { $_.Pop -or $_.Imap -or $_.SmtpAuth } |
    Select-Object DisplayName, PopEnabled, ImapEnabled, SmtpAuthEnabled

Anything that comes back should have a business reason — disable the protocol if it doesn’t.

Client-side readiness (so you don’t lock out your own users):

  • Outlook for Windows 2013+ / Outlook for Mac 2016+ (Modern auth)
  • Mobile: Outlook iOS/Android natively use Modern auth; third-party mail apps must support OAuth (Thunderbird does; most others don’t)
  • Scripts: Exchange Online PowerShell module (Modern auth, MFA-capable); certificate-based auth for unattended jobs
  • EWS consumers: migrate to Graph where possible; EWS itself is being deprecated

4. Turn on Baseline security mode

The M365 admin center’s baseline security mode is a one-stop toggle set available on all M365 subscriptions — no license. It covers three areas:

Authentication

  • Phishing-resistant auth for admin portal access
  • Block legacy authentication flows
  • Block Basic authentication
  • Block addition of new password credentials to apps
  • Restrict end-user consent to low-risk M365-certified/single-tenant apps
  • Block insecure file-open protocols (HTTP/FTP, FPRPC)
  • Block legacy SharePoint/OneDrive client auth (RPS, IDCRL)
  • Disable org-wide EWS access

Files (OneDrive/SharePoint)

  • Legacy file formats open in Protected View (block or allow editing)
  • Block ActiveX controls, OLE objects, DDE launches in Excel, Publisher

Teams room devices

  • Block unmanaged device and resource-account sign-ins to M365 apps
  • Only endpoint-managed, compliant devices can sign in

Enable what fits your environment — for a typical small business, the auth section plus “block new password credentials to apps” is the biggest win.

Heads-up: turning on Baseline Security Mode can silently create a couple of disabled draft Conditional Access policies in your tenant tied to its settings. They won’t do anything while disabled, but don’t be surprised finding them later thinking someone else touched your CA config.


5. Find the legacy traffic (free audit logs)

Entra’s sign-in and admin audit logs are free. The classic legacy-auth marker in Graph sign-in logs is clientAppUsed eq 'Other clients':

Get-MgAuditLogSignIn -Filter "clientAppUsed eq 'Other clients'" -Top 100 |
    Select-Object CreatedDateTime, UserPrincipalName, ClientAppUsed, AppDisplayName |
    Format-Table -AutoSize

Empty result = no legacy auth traffic. Anything that shows up is a device or app that needs migrating (see the client-side list in section 3).

Admin audit log review — what changed, who did it:

# Entra admin center: Entra ID → Sign-in logs / Audit logs (free)
# or Graph:
Get-MgAuditLogDirectoryAudit -Top 50 |
    Select-Object ActivityDisplayName, InitiatedBy, CreationTime |
    Sort-Object CreationTime -Descending |
    Format-Table -AutoSize

6. Shrink the attack surface (all free)

  • End-user consent — restrict to M365-certified / single-tenant low-risk apps (baseline security mode does this in one toggle). Unguided user consent to third-party apps is a top data-exfil vector.
  • App passwords / client secrets — block new password credentials on app registrations; move scripts to certificate-based auth (app registration + cert, no interactive sign-in — see post 6 section 6).
  • Admin sprawl — review who actually holds Global Admin / other privileged roles; remove anyone who doesn’t need it. Free: Entra admin center → Roles and administrators.
  • Mailbox forwarding rules — check for external auto-forwarding (a common persistence mechanism):
Get-Mailbox -ResultSize Unlimited | Get-MailboxAutoForwarding |
    Where-Object { $_.ForwardingAddress -and $_.ForwardingAddress -notlike "@yourdomain.com" } |
    Select-Object Mailbox, ForwardingAddress
  • Service principals — list app registrations, flag ones with password credentials and broad permissions; you don’t need P1 to see them.

What you can’t do without a license (honest limits)

  • Conditional Access policies — current Microsoft docs list Entra ID P1 as required. If you’re license-free, Security Defaults is your substitute; it’s coarser but covers the big risks.
  • Risk-based policies (sign-in risk, user risk step-up) — P2 / Entra ID Protection.
  • PIM / access reviews / entitlement management — P1/P2 (Identity Governance).
  • Email security (anti-phishing, anti-spam tuning, quarantine) — Defender for Office 365. The free tier gives you basic mail flow rules and the security portal overview, not ATP.
  • Leaked-password checks in SSPR — P1.

The pattern: the identity hardening (MFA, legacy auth, consent, audit) is mostly free; the continuous detection layer (risk engines, PIM, email security) is where the licenses buy you things.


Gotchas

  • Security Defaults is all-or-nothing — if you need exceptions (a kiosk, an old app), you’ll outgrow it and need P1 + Conditional Access. Plan the migration path before enabling it.
  • Most legacy protocols are already gone, but SMTP AUTH isn’t yet — EAS, POP, IMAP, RPS, EWS, OAB and Autodiscover Basic Auth are permanently removed. SMTP AUTH Basic Auth is still active today and won’t be disabled by default until end of December 2026 — audit your senders now instead of waiting for Microsoft to do it for you.
  • MFA registration takes time to propagate — after enabling, give users a day or two; chase non-registrants with the registration report (section 2).
  • Revoke tokens after enabling MFA — otherwise users ride old sessions and MFA “doesn’t seem to work”.
  • clientAppUsed eq 'Other clients' is a marker, not a verdict — some legitimate older apps report this way; verify before you break something.
  • Baseline security mode “block new password credentials to apps” can break scripts that still use client secrets — audit your app registrations before flipping it.

Sources