Learn the right order to lock down identity, email, data, devices, and monitoring in Microsoft 365 – and how to keep it secure with ongoing governance.
|
TL;DR |
If you’ve ever stared at Microsoft 365 security settings and thought ‘Where do I even start?’, this checklist is for you. We’ll detail five major areas in order of importance:
Each control pairs three things – what abuse pattern it stops, which switches to flip, and how to confirm it’s actually working in your tenant. Most of these protections are not enabled by default, so admin rights and a basic understanding of Conditional Access and audit logs will be needed.
Download your prioritized M365 security checklist
Identity goes first because once someone steals a valid account, they walk straight into everything – email, files, Teams, admin portals, and any connected apps in one move.
Strong identity controls split into three layers – authentication strength with Multi-Factor Authentication (MFA), tight limits on who holds admin roles, and protocol hardening by blocking legacy authentication that bypasses modern protections. Conditional Access then ties it all together as your central policy engine, combining identity, device state, and risk signals into one set of enforceable rules.
MFA should be enforced with Conditional Access policies, not via Security Defaults, which are a helpful baseline but too blunt for a mature tenant.
Conditional Access lets you target specific user groups, apps, locations, and device conditions instead of flipping one tenant-wide setting and hoping for the best. For admin hygiene, use dedicated cloud-only admin accounts that are not synced from on-premises AD, and keep your number of Global Admins low – the CIS Azure Foundations Benchmark recommends fewer than five for a tenant of any size.
Maintain at least two break-glass emergency access accounts. Exclude them from Conditional Access, and protect them with passwordless authentication like Passkeys, FIDO2, digital certificates, and Windows Hello so you can still sign in if Conditional Access misfires.
On top of that, enable Privileged Identity Management (PIM) so admin roles are activated just-in-time and for a limited duration instead of being assigned permanently. Without PIM, a stolen admin token stays useful for the life of its refresh window – often weeks – which is enough time for an attacker to establish persistence, exfiltrate data, and create alternative access paths before anyone investigates the original sign-in. With PIM, that window collapses to the activation duration you set (typically one to four hours), so even a successful credential theft expires before most attackers can establish a foothold.
To verify all of this, review Conditional Access sign-in and authentication reports to find users authenticating without MFA, then tighten policy scope until those cases disappear. When you roll out a new Conditional Access policy, start in report-only mode so you can see who would be blocked or prompted before you actually enforce it. Then switch to enforce once the impact looks acceptable.
Legacy authentication is still one of the easiest ways around your hard‑won MFA rollout. Older legacy protocols such as IMAP, POP3, and SMTP AUTH using Basic authentication simply do not understand MFA – a stolen username and password is enough to sign in as the user with zero extra prompts.
SMTP AUTH with Basic authentication is the last major holdout and remains available for existing tenants only until December 2026. This gives you a limited window to remove your dependencies instead of waiting for a hard cut‑off surprise.
To roll this out safely, start by creating a Conditional Access policy that targets legacy authentication client apps and blocks access, but keep it in report-only mode first. Let that run for one to two weeks so you can see which service accounts, applications, scanners, or line‑of‑business systems still rely on legacy protocols.
Document the legitimate use cases, plan replacements or exceptions, and only then switch the policy from report‑only to enforced with a tight list of documented exclusions instead of a broad ‘ignore legacy auth for everyone in this OU’.
Remember that MFA stops most automated credential stuffing, but it does not stop Adversary‑in‑the‑Middle (AiTM) phishing that steals session tokens after the user completes MFA. That’s why legacy auth blocking is a baseline control, not your final defense.
To verify it is working as intended, regularly filter your sign‑in logs by legacy authentication client apps and confirm that successful sign‑ins from those protocols drop to zero, with any remaining entries tied to explicitly approved exceptions.
Email is your second priority after identity because most attacks still arrive through someone’s inbox. Basic spam filtering catches obvious junk but often misses zero‑day malware, freshly weaponized URLs, and convincing impersonation attempts.
The stronger defenses live in Microsoft Defender for Office 365, and many of them are either off by default or running in less aggressive modes, especially in older tenants.
To harden email properly, you need to turn those features on, tune them, and confirm that they’re actually catching live threats.
The highest‑leverage single change is to apply Microsoft’s preset security policies for Exchange Online Protection and Defender for Office 365, such as the Standard and Strict presets for your riskiest users. These bundles pull in Microsoft’s own recommended configurations for malware, phishing, and spam rather than leaving you to guess at every slider and threshold.
Once presets are in place, Safe Links rewrites URLs in messages and Office documents so that when a user clicks, the link is checked again in real time against current intelligence, not just the reputation it had at delivery.
Safe Attachments runs suspicious files in a sandbox before they reach the mailbox, which helps catch malware that traditional signature‑based scanning misses. Zero-Hour Auto Purge (ZAP) then gives you a safety net by removing messages after delivery if later analysis flags them as malicious, cleaning them out of inboxes and folders without manual hunting.
Finally, dedicated anti‑phishing policies with mailbox intelligence and impersonation detection let you target CEO/CFO spoofing and similar business email compromise attempts, so users are less exposed to those ‘urgent wire transfer’ messages that still slip past generic filters.
Email authentication is your front door sign that tells the world ‘this message really came from us’. SPF, DKIM, and DMARC work together here – SPF lists which servers can send mail for your domain, DKIM cryptographically signs messages, and DMARC tells receiving servers what to do when something fails. Your long‑term goal is a DMARC policy of p=reject, which instructs receivers to drop spoofed messages outright instead of simply flagging them.
This is no longer a ‘nice to have’ for bulk senders. As of May 5, 2025, Microsoft requires domains that send 5,000 or more messages per day to Outlook.com, Hotmail, and Live addresses to meet stricter SPF/DKIM/DMARC requirements, or risk their mail being throttled or rejected.
That pressure usually forces organizations to clean up their DNS records, align their sending services, and move gradually from p=none to p=quarantine and finally p=reject once they trust the reports.
On the inbound side, automatic forwarding to external addresses remains a classic data exfiltration path. After a successful AiTM phishing attack, attackers typically create inbox forwarding or transport rules within the first hour of token capture – usually rules that route messages containing terms like "invoice," "payment," "wire," or "password reset" to an external Gmail address or to a hidden RSS Feeds folder where the legitimate user won't see them. Tighten your outbound spam policies so that automatic external forwarding is blocked by default, with explicit exceptions only for known business workflows.
Next, audit mailbox-level forwarding rules – especially any created in the last 90 days, any routing to personal domains, and any filtering by finance or credential terms.
Once identity and email are under control, the next challenge concerns data access. You’re usually juggling five related worries at once:
Native admin tools can show each of these, but only if you hop between multiple portals and utilize PowerShell.
“A cleaner alternative is to use tools that provide a single view of all externally shared files across Teams, OneDrive, and SharePoint. Using a centralized dashboard like Syskit Point lets you revoke risky access across the tenant in a few clicks instead of digging through individual site settings.”
– Danijel Čižek, Product Manager Team Lead at Syskit
Once you start tightening data access, external sharing defaults are the first place to look. Change SharePoint and OneDrive from ‘Anyone with the link’ to ‘Specific people’ so every new link has a clear audience.
The default "Anyone" link is effectively an unauthenticated public URL – it can be forwarded, screenshotted, and crawled if it ends up on a public page, and it survives even after the original recipient leaves the company. "Specific people" ties access to identity, so the link breaks the moment that the user is offboarded or removed from the workspace.
Next, use Conditional Access policies paired with SharePoint session controls to block downloads from unmanaged devices to keep files off personal laptops and phones. Note that this requires configuring App-enforced restrictions to limit access to web-only viewing. Pair that with guest user expiration policies so external accounts don’t linger forever after a project ends.
From there, build DLP policies that look for sensitive info types (payment cards, IDs, health data) across Exchange, SharePoint, OneDrive, and Teams. They should catch risky sharing attempts and either block, warn, or encrypt based on context. You get far better results when DLP rules work hand‑in‑hand with sensitivity labels, so a ‘Highly Confidential’ file triggers stricter behavior than something marked ‘Internal’.
The trick is to define a simple classification taxonomy before you create labels. Start with four tiers like Public, Internal, Confidential, and Highly Confidential, then teach teams what belongs where.
“Native guest expiration features help, but they’re still admin‑driven. By contrast, Syskit Point’s automated lifecycle management flips that around by asking workspace owners to confirm whether guests still need access, and revoking it when they don’t respond.”
– Danijel Čižek, Product Manager Team Lead at Syskit
Copilot is great at finding things users technically have access to, which is exactly why oversharing is a bigger problem than it used to be. Permissions that used to sit quietly in the background – ‘Everyone except external users’, old project guests, broad SharePoint links – suddenly become promptable.
A native way to reduce this is to combine clear sensitivity labels with the right protection settings. Highly confidential content is then restricted to tightly‑scoped groups, blocked from broad links, and excluded from risky sharing patterns that Copilot might surface. When labels are applied consistently, Copilot is far less likely to pull sensitive material into everyday prompts.
“Syskit Point’s Copilot Readiness Dashboard tightens security further by pulling oversharing signals into one place. You see which workspaces expose content too broadly, how sensitivity labels are used (or not used), and where external users can see more than they should. That makes it much easier to tune permissions before Copilot shines a light on every forgotten link.”
– Danijel Čižek, Product Manager Team Lead at Syskit
When users consent to third‑party apps, those apps can obtain long‑lived token‑based access to email, files, and directory data, often with broad read/write scopes. After the initial OAuth consent (which may involve MFA), the app can keep accessing data via tokens without prompting the user again – and without generating normal interactive sign‑in events for each access in your logs.
This is the exact pattern behind some of the most damaging cloud breaches of the last two years: Midnight Blizzard (APT29) used an over-permissioned OAuth application to pivot from a legacy test tenant into senior leadership mailboxes at Microsoft itself in early 2024, and the 2025 Salesloft Drift incident gave attackers persistent access to connected Salesforce environments through stolen integration tokens – no re-authentication required.
As of July 16, 2025, Microsoft tightened defaults so users cannot grant tenant‑wide permissions to apps without admin approval, but that doesn’t clean up older consents or lower‑scope apps that still see plenty of data.
A healthy governance workflow has four steps:
“Syskit Point complements those tenant‑level controls by giving you workspace‑level visibility into what third‑party apps and sharing patterns actually expose. You see which teams, groups, and sites are affected and what data they make available.”
– Danijel Čižek, Product Manager Team Lead at Syskit
When anyone can create a team, site, or group whenever they feel like it, you end up with a lot of abandoned workspaces. Each one carries its own sharing links, private channels, and guest accounts that no one remembers to clean up. Six months after a project finishes, the external consultant you intended to add for a few weeks may still have full read‑write access to chat history, files, and dashboards.
The worst offenders are orphaned workspaces. When an owner leaves the company or changes roles and no replacement is assigned, there’s no one clearly responsible for reviewing who’s in the workspace or what they can see. Permissions drift, guests stay, and IT only finds out when an audit or incident finally shines a light on that corner of the tenant.
A common discovery during M&A due diligence: legal teams find Teams sites containing two-year-old deal documents that still have external advisors, departed employees, and guest accounts with full read access – because the original owner left during a reorg and no one inherited the workspace.
“With Syskit Point, automated reviews go out to workspace owners on a schedule you define. Owners receive an email, open a guided view of members, guests, and permissions, and confirm who should stay or go. Inactive users, suspicious entries, and orphaned teams, groups, and sites are highlighted as soon as they lose a valid owner.”
– Danijel Čižek, Product Manager Team Lead at Syskit
Identity controls get you to the door, while device compliance decides whether the door actually opens. If Conditional Access only checks who the user is and whether they passed MFA, a compromised or unmanaged device can still walk straight into SharePoint, OneDrive, and Teams with full access. Tying access to device state closes that gap.
In practice, you treat device compliance as a grant condition in Conditional Access. Intune compliance policies then define what ‘compliant’ means – OS versions, disk encryption, antivirus, jailbreak status, and other minimum standards. Non‑compliant or unregistered devices are blocked from sensitive apps or pushed into a more restricted experience.
For Bring-Your-Own-Device (BYOD), app protection policies let you protect work data without owning the entire device. They enforce things like PIN requirements, copy/paste controls, and selective wipe within the Microsoft 365 apps themselves, so corporate data can be removed without touching personal photos or apps.
Attack Surface Reduction rules add another filter on the endpoint. They block common malware behaviors such as executable content launched directly from email clients, Office macros spawning suspicious processes, or unclear scripts. Combined with Conditional Access and compliance checks, they make it much harder for a compromised endpoint to turn into a full‑tenant breach.
Think about verification in three layers: Secure Score to quantify your posture; audit and sign‑in logs to catch active abuse and misconfigurations; and a way to back up and monitor tenant configuration so you can spot and roll back drift after changes, projects, or incidents.
Microsoft Secure Score gives you a points‑based view of how hardened your tenant is inside the Defender portal.
You earn points as you implement recommendations, and a score somewhere in the 60-80% range is usually a good sign that the basics are covered without chasing every last niche control. Start with the highest‑impact items it highlights – MFA for all users, blocking legacy authentication, and stronger anti‑phishing and anti‑malware policies.
The catch is that Secure Score mainly checks whether something exists. It won’t tell you if your Conditional Access scope is too narrow, your DLP rules are ineffective, or your access reviews never run. That’s why you still need logging, alerting, and configuration oversight on top of the scorecard.
Many practitioners pair Secure Score with open-source assessment tooling for deeper configuration checks (see practitioner discussions on Reddit) before declaring a tenant hardened:
Once controls are in place, your audit trail becomes the early‑warning system. In most E3/E5 tenants, unified audit logging is already on, but it’s worth confirming in the Purview portal – some other license mixes still require a one‑time activation.
From there, watch for a handful of high‑signal events – impossible travel sign‑ins, new inbox forwarding rules created by non‑owners, admin role elevation, mass file downloads from SharePoint or OneDrive, and new high‑privilege OAuth app consents or changes to outbound forwarding in Exchange.
Natively, many organizations still live with 180‑day retention. With Purview Audit (Premium), key workloads like Exchange, SharePoint, OneDrive, and Microsoft Entra are retained for one year by default, but only for users with E5-level licensing. Audit records from other services, or generated by non-E5 and guest users, still follow the 180-day limit unless you configure custom retention policies. A separate add-on is available if you need to retain logs for up to 10 years.
“Syskit Point strengthens this layer by extending how long you can see back in time and how quickly you can react. Cloud plans retain audit logs for a full year instead of the 180‑day window. Configurable alerts and the Security & Compliance Dashboard surface suspicious activity and policy violations in one place, so you’re not pivoting between portals trying to piece together what happened.”
– Danijel Čižek, Product Manager Team Lead at Syskit
Tenant configuration is another challenge, as Microsoft backs up your data, but not your security settings. If a misconfigured script, rushed project, or attacker changes Conditional Access, DLP, or sharing policies, there’s no native ‘undo’ button that restores yesterday’s configuration. Recovery usually means trawling documentation and old screenshots, then rebuilding every control by hand.
A healthier pattern is to treat configuration like code. Define a known‑good baseline for your tenant, export and back it up automatically with version history, and turn on drift detection so you know when something meaningful changes. Then test restoration on a schedule, the same way you would test a data backup, so you’re confident you can roll back to a safe state instead of discovering the gaps during an audit or incident.
A checklist is a great way to get your tenant out of the danger zone, but it’s still just a snapshot in time. Users keep creating workspaces, inviting guests, installing apps, and asking Copilot questions, which means your risk profile moves every day whether you touch a toggle or not.
Here are three immediate next actions to take:
In environments with 1,000+ users, manual quarterly reviews simply don’t scale. Ongoing governance is calmer, more accurate, and much less work than trying to do a major cleanup every year.
Syskit Point tracks how users behave, how workspaces grow, and where access quietly sprawls. Managing everything from a centralized dashboard enables you to turn a security checklist into a steady way of running Microsoft 365.