The M365 Quarterly Drift Check for 2026

Who this page is for

You finished a real M365 hardening pass three, six, maybe twelve months ago. Conditional Access is on. Defender is tuned. SharePoint sharing is locked down. The deployment was the hard part — but the worry now is different. Did anything slip? Did someone disable a policy "for an hour" and forget? Did a new admin get onboarded with too many roles? Did an OAuth app get consented to that nobody flagged?

This page is the operations companion to the M365 deployment guide for small business. The deployment guide is where setup lives. This page is what you run after setup is done — the four alerts that fire on day one, the PowerShell that catches drift, and the 90-minute quarterly review that keeps the baseline honest.

If you're still in deployment, this page won't help you yet. Finish the build, then come back in 90 days for the first drift check.

The spine of this page

1. The four day-one audit alerts — what you wire up the moment hardening is done so breach indicators surface within minutes, not weeks.
2. Verification stubs — short checks (not setup) for Conditional Access, Defender, and SharePoint sharing. If a check fails, the deployment guide has the fix.
3. PowerShell drift queries — the small set of one-shot scripts you run between quarterly reviews when something feels off.
4. The 90-minute quarterly review — five steps, in order, on the calendar.

Identity drift: the PowerShell that catches new accounts without MFA

Identity is the layer that drifts fastest. New users get added, contractors get onboarded, an admin clones a user without finishing the MFA registration step. The fastest way to catch it is a one-line query you can run any time someone says "wait, did we onboard that person properly?"

List every active user without an MFA method registered:

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","User.Read.All"

Get-MgUser -All -Property Id,UserPrincipalName,AccountEnabled |
  Where-Object { $_.AccountEnabled -eq $true } |
  ForEach-Object {
    $methods = Get-MgUserAuthenticationMethod -UserId $_.Id
    $hasMfa = $methods | Where-Object {
      $_.AdditionalProperties["@odata.type"] -ne "#microsoft.graph.passwordAuthenticationMethod"
    }
    if (-not $hasMfa) {
      [pscustomobject]@{ User = $_.UserPrincipalName; Status = "No MFA method registered" }
    }
  } | Export-Csv users-without-mfa.csv -NoTypeInformation

Run it monthly, or any time you onboard a batch of new users. If the file isn't empty, you have unfinished onboarding work — and an account without MFA is the most common drift finding in tenants that were buttoned up six months ago.

Verification: are the five Conditional Access policies still enforcing?

A hardened tenant should be running five named CA policies (legacy-auth block, MFA for all users, compliant device for admins, country block, sign-in risk MFA). Open Entra → Monitoring → Workbooks → Conditional Access Insights. Each of the five should show non-zero sign-ins evaluated in the last 30 days. A policy showing zero is almost always a scoping change that broke it. If a policy is missing or off, the setup is in the M365 deployment guide — this page is for verification, not setup.

Verification: is Defender still tuned the way you left it?

Three quick checks. (1) Defender portal → Threat policies → Safe Links — confirm the policy still applies to all recipients and the "do not rewrite" URL list is still empty. (2) Anti-phishing policy — phishing threshold should still be at 2 (Aggressive) or higher, and your CEO/CFO should still be listed as protected senders. (3) Outbound spam policy — automatic forwarding should still be set to Off.

If any of those have moved, that's drift. The original setup (including SPF/DKIM/DMARC, anti-phishing thresholds, and the forwarding trap that breaks legitimate ticketing aliases) lives in the M365 deployment guide and the companion Microsoft 365 email security checklist on EmailShield365.

Endpoint and Intune: getting devices into a known state

Conditional Access policy CA-003 above ("require compliant device for admins") only works if you have a compliance policy in Intune that defines what "compliant" means. Otherwise every device is technically non-compliant and your admins are locked out.

Minimum viable Intune compliance policy for Windows: BitLocker required, Secure Boot required, antivirus required, antispyware required, real-time protection required, OS minimum version pinned to the current N-1 build, password length 12+, password expiration off (NIST guidance: passphrases beat rotation), maximum minutes of inactivity before password 15. For macOS: FileVault required, system integrity protection on, OS minimum version pinned, gatekeeper on. For iOS and Android: encryption required, jailbreak/root blocked, OS minimum version pinned, six-digit PIN minimum.

Enrollment restrictions. Intune → Devices → Enrollment → Enrollment device platform restrictions. Block personal Windows. Block personal Linux. Allow corporate iOS and Android, block personal versions for any group with access to sensitive data. Personal-device users get app protection policies instead.

App protection policies for BYOD. Intune → Apps → App protection policies. Build one for iOS, one for Android. Apply to all Microsoft mobile apps (Outlook, Teams, Word, Excel, OneDrive, SharePoint). Settings: prevent backups to iCloud/Google, prevent copy-paste to non-managed apps, require PIN on launch, block screen capture (Android), encrypt org data, wipe org data after 90 days offline. This protects company data on a personal phone without owning the phone.

Once these are in place and CA-003 enforces "require compliant device for admins," you've eliminated the "phished admin from random laptop" attack pattern entirely.

SharePoint sharing drift: what changed since last quarter

Sharing settings are where well-meaning users create the most drift. A site owner flips a toggle to share one file with a vendor, and now the whole site is set to ExternalUserAndGuestSharing. The PowerShell below pulls the current state of every site so you can diff it against last quarter:

Connect-SPOService -Url https://yourtenant-admin.sharepoint.com

Get-SPOSite -Limit All |
  Select-Object Url, SharingCapability, SharingDomainRestrictionMode, SharingAllowedDomainList |
  Where-Object { $_.SharingCapability -ne "Disabled" } |
  Sort-Object Url |
  Export-Csv sharepoint-external-sharing.csv -NoTypeInformation

Compare to the file from last quarter. Any new site at ExternalUserAndGuestSharing needs a documented reason or gets walked back. The tenant-default and anonymous-link policies that should be in place (and the Purview labels worth building) are in the M365 deployment guide.

The four day-one audit alerts that catch most real attacks

A hardened tenant with no logs is a black box during incident response. Get logging configured before you need it.

Unified Audit Log. Should already be on for tenants created after 2019, but verify. From Exchange Online PowerShell: Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled. The result must be True. If False, run Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true.

Retention. Default audit retention is 90 days for E3, 180 days for E5. Most ransomware investigations need 12 months because attackers sit in the tenant for an average of 6 to 9 months before pulling the trigger. License Audit (Premium) or push logs to a SIEM with longer retention. Microsoft Sentinel is the obvious choice if you're already in the Microsoft estate. An open-source alternative is Wazuh feeding from the Office 365 Management API.

The four alerts you set up on day one. Microsoft Purview compliance portal → Audit → Alert policies → New alert policy. These four catch the breach indicators that show up first, before the ransomware demand or the wire-fraud loss:

• User consented to OAuth application. Activity: Consent to application. Severity: High. This is how attackers persist after a phish — they get the user to grant a malicious app long-lived access. Single biggest indicator of post-phish compromise.
• Inbox rule created or modified that forwards or deletes. Activities: New-InboxRule, Set-InboxRule. Severity: High. Filter on rules that contain ForwardTo, RedirectTo, or DeleteMessage. Standard attacker move during BEC.
• Mailbox permission added. Activity: Add-MailboxPermission. Severity: Medium. Grants attacker persistent access to a mailbox even after the password is reset.
• Privileged role assigned. Activity: Add member to role. Severity: High. Catches privilege escalation. Should be near-zero false positives.

Route alerts to a shared inbox and a Teams channel. A single email destination is the fastest way for these to be ignored. The breach-response side of why these four matter is in the 25-step data breach response checklist.

Lazy admin trick: while you're in the audit panel, also build a saved search for Set-AuthenticationPolicy, Set-OrganizationConfig, and Set-ConditionalAccessPolicy. Anyone touching tenant-wide security primitives should be visible in your monthly review.

Microsoft 365 doesn't back you up — here's what that means

Microsoft replicates your data across data centers. Microsoft does not protect you from your own users (or attackers acting as your users) deleting things. Three controls get conflated and they protect against different things.

• Retention policies. Keep mailbox or SharePoint content for N years even if a user deletes it. Useful for compliance. Useless against ransomware that encrypts every file in place — the encrypted file is what gets retained.
• Litigation hold. Like retention, but legal-discovery-grade and immutable for the duration of the hold. Same weakness against ransomware as retention.
• Backup. A separate copy of your data outside the tenant, restorable to a point in time, on storage the attacker can't reach with stolen credentials. Microsoft 365 Backup (the Microsoft offering, GA in 2024) is one option. Veeam, Barracuda, AvePoint, and Datto are the established third parties.

Recovery time objective is the question to ask before you pick a vendor. Microsoft 365 Backup restores fast (hours, sometimes minutes for individual mailboxes). Some third parties take days for a full tenant restore because the data sits in their cloud and has to come back through Graph. Test the restore at least once a year. Restore-not-tested-is-restore-broken applies in M365 just like it always did.

The 90-minute quarterly review (the centerpiece)

The most common failure mode of an M365 baseline is drift. Someone makes a "temporary" exception, a new admin gets onboarded with too many roles, an OAuth consent gets granted to a "useful" app and never reviewed. Drift is invisible until it isn't.

Once a quarter, run through this short list:

1. Re-run Secure Score. Note any control that dropped from green to amber. Read the change log on the dropped control — usually you'll see "policy modified" and an admin name.
2. Audit Conditional Access policy effectiveness. Entra → Monitoring → Workbooks → Conditional Access Insights. Are CA-001 through CA-005 still firing on real sign-ins? A policy that "blocks 0 sign-ins" usually means a scoping change broke it.
3. Review who has admin roles. Entra → Roles and administrators. Anyone who shouldn't be there gets removed. Anyone who should be there permanently gets converted to PIM-eligible (Privileged Identity Management) instead of permanent.
4. Audit consented apps. Entra → Enterprise applications. Sort by date added. Anything in the last quarter that you don't recognize, revoke. Pay particular attention to apps with Mail.ReadWrite or Files.ReadWrite.All — those are the high-risk grants.
5. Drift-check the baseline. Pull a config dump of CA policies, anti-spam outbound policy, sharing settings, and the Exchange auth policy. Diff it against last quarter. Any line that changed needs a documented reason. Our CIS M365 Benchmark checklist for small business includes a config-export script you can use as the baseline of comparison.

Block out 90 minutes on the calendar, do all five back-to-back. Done in an evening, costs nothing, catches problems while they're still cheap to fix.

Common questions

Should I run Security Defaults or build Conditional Access policies?

If you have under ten users, no Entra ID P1 license, and no admin who's comfortable in CA, run Security Defaults. It enforces the right things and you don't have to maintain it. Above that scale, switch to Conditional Access. The five policies above replace what Security Defaults does and add the controls Security Defaults can't (country blocks, compliant-device-for-admins, sign-in risk). Don't try to run both. They conflict, and Security Defaults wins, which means your CA work doesn't take effect.

My users hate MFA prompts. How often should they actually see one?

In a properly configured tenant, a user signing in from a known device they've used for the last 30 days should see roughly one MFA prompt every two weeks. If they're seeing prompts daily, your sign-in frequency is misconfigured (check Entra → Authentication methods → Sign-in frequency — default of "every time" is too aggressive for non-admin users). If they never see one, something's wrong, probably a sign-in frequency policy of 90 days plus a token theft window you don't want.

Is Microsoft 365 Backup good enough, or do I need a third party?

Microsoft 365 Backup (the first-party product, GA April 2024) is good for fast in-tenant restore: ransomware encrypts your SharePoint, you roll back to a point-in-time. It's not good if the threat scenario includes "the tenant itself is compromised and the attacker disabled backup." For that scenario you want an out-of-tenant copy with separate credentials. The two-vendor pattern (Microsoft 365 Backup for fast restore plus a third-party for true off-tenant copy) is what we see in regulated industries.

Do I need Microsoft Sentinel or can I get by with the built-in alerts?

A 30-person business with the four alert policies above wired into a Teams channel is in fine shape for nine of ten threat scenarios. Sentinel adds value when you have multiple data sources to correlate (firewall + endpoint + identity + email), longer retention requirements (a year-plus), or a compliance regime that requires SIEM. If you're licensing E5 already, the Defender XDR portal correlates the four alert types above for you and that's often sufficient.

How do I know I'm done?

When you can answer four questions in under a minute each. (1) Which CA policies are enforcing MFA, on whom, with what exclusions. (2) What your DMARC policy is and where the aggregate reports go. (3) What your three highest-severity audit alerts have fired on in the last 30 days. (4) When your last successful tenant backup restore test was. If any of those takes longer than a minute, that's where the next round of work is.