Skip to content

Field note

Defender Office 365 Baseline

Most email security debates drag on because people talk about settings in the abstract. The better question is simpler: which users need more protection, what will it interrupt, and who will own the fallout when something legitimate gets caught.

Published19 Jan 2026

Updated4 months ago

Read time5 min · 895 words

AuthorGyorgy Bolyki

The Standard vs Strict discussion gets treated like a maturity test far too often. This baseline comparison is a scoping decision, not a ranking.

Microsoft gives you preset security policies in Defender for Office 365 so you do not have to hand-build every anti-phishing, Safe Links and Safe Attachments choice from scratch. That is useful. Where teams get into trouble is assuming there must be one answer for the whole tenant. In real life, risk is uneven. Finance, leadership, admins, procurement and anyone exposed to supplier payments usually need a tighter posture than the rest of the business.

That means most tenants should start with a simple rule:

  • put normal users on Standard
  • put high-risk users on Strict
  • keep exceptions rare, named and reviewed

That is less glamorous than a giant custom policy stack, but it is easier to explain and much easier to keep tidy six months later.

What Standard is good at

Standard is where most SMEs should begin because it gives you a strong baseline without immediately forcing a culture war with the helpdesk.

If you are cleaning up a tenant that has grown unevenly, Standard is often the fastest way to stop obvious gaps:

Where Standard helpsWhy it works
General user populationSensible protection without the highest level of friction
Early-stage cleanupLets you stabilise detection and reporting before tightening more
Teams with poor exception hygieneAvoids a flood of allow requests on day one
Mixed operational maturityGives you a baseline that support staff can actually live with

That last point matters. A control no one understands will get bypassed the moment it blocks a sales quote, supplier invoice or client introduction.

Where Strict earns its keep

Strict is not there to make the dashboard look serious. It is there for the people most likely to be impersonated, socially engineered or targeted because they can approve money, change access or unblock other people.

I usually care about these groups first:

  1. Finance and payroll.
  2. Directors and executive assistants.
  3. Global admins and other privileged roles.
  4. Procurement and supplier-facing staff.
  5. Shared high-visibility mailboxes that attract external contact.

If one of those users gets a convincing fraudulent invoice, bogus MFA prompt or malicious document share, the business impact is not theoretical. That is where tighter phishing and link controls tend to justify themselves quickly.

The mistake people make

The most common mistake is rolling out Strict broadly before anyone has cleaned up the noisy basics:

  • missing user reporting
  • unclear quarantine handling
  • old allow entries
  • broken sender authentication on legitimate partner mail
  • no agreed path for false positives

On paper, Strict looks like the "safer" answer. In practice, if the surrounding process is weak, users and support staff start fighting the tool rather than learning from it. Once that happens, pressure builds for blanket exceptions, and those exceptions usually stay around much longer than the original problem.

That is why I prefer a staggered rollout. Standard for broad coverage. Strict for the people who genuinely carry more business risk. Then review the data and expand if it is earning its place.

A deployment model that stays sane

This is the version that tends to survive contact with normal business operations:

User groupSuggested presetNotes
Most staffStandardGood baseline while keeping support overhead reasonable
Finance, payroll, directorsStrictHigher impersonation and payment fraud exposure
Admin accountsStrictHigh-impact identities deserve tighter filtering
Shared mailboxesCase by caseDepends on workflow, automation and message volume
VIPs with noisy external commsStrict plus careful reviewOften worth it, but watch false positive patterns

The point is not to build five policy families. The point is to make a small number of deliberate choices and document why they exist.

What to check before calling it done

A preset policy rollout is not finished because the toggle is on. I would want quick answers to these:

  1. Are the preset policies actually assigned to the right users?
  2. Are Safe Links and Safe Attachments in scope where expected?
  3. Are impersonation protections covering the people and domains that matter?
  4. Is the Report Message or Report Phishing workflow live and reaching the right review queue?
  5. Can someone explain how quarantine release works?
  6. Are there old allow entries with no named owner?
  7. Are external forwarding controls aligned with the email risk posture?
  8. Is there a monthly review point for exceptions and false positives?

If the answer to half of those is "probably", the policy is not operational yet.

What success looks like

Success is not "everyone is on Strict".

Success is more boring than that:

  • suspicious mail gets filtered consistently
  • high-risk users are protected more aggressively
  • legitimate mail problems get resolved without panic
  • exceptions stay small and reviewable
  • user reports help the system instead of disappearing into a black hole

That is a decent outcome. It is also the kind of setup a small internal team can keep running without needing to redesign it every quarter.

References

Related notes

Need help mapping this to your own tenant, controls, or assessment timeline?