Security and Compliance in Microsoft 365: What Microsoft Protects, and What You Must Do Yourself

Microsoft 365 is the single most-used application for most companies and therefore an attractive target. Rising ransomware and phishing waves, tightening compliance requirements (GDPR, NIS2) and access from anywhere on any device make M365 security and compliance an ongoing task. The key insight: Microsoft protects the platform. You protect your data and your configuration.

That sentence reads like small print. It is the root cause of most M365 security incidents we see.

What Microsoft handles

Microsoft secures the platform on three levels:

Physical: biometric access controls, 24/7 security and video surveillance in the data centres
Logical: automated server management, personnel vetting, controlled administrator access, anti-malware
Data: tenant isolation via independent “containers” and Entra ID separation

That’s the foundation, but it’s the security of the platform, not the security of your usage.

Where the responsibility boundary actually runs

Concretely: Microsoft guarantees the service runs, that your data is separated from other tenants’, and that the infrastructure beneath is maintained.

Microsoft does not guarantee:

that your permissions are set sensibly,
that a compromised account gets noticed,
that a file accidentally shared with the world is detected,
that after a ransomware event or an accidental mass deletion you can reach a usable restore point.

The last point routinely surprises people. The built-in retention and recycle bin mechanisms are not a backup in the operational sense: they hold data for a limited period and don’t cover every failure mode. Anyone who needs a specific recovery capability (particularly across longer periods or with granular restore) has to establish it separately and test it regularly. A restore that was never rehearsed is an assumption, not a capability.

What you must configure yourself

Data protection:

Rights Management Service: encryption and identity-based policies
Sensitivity labels: classification that travels with the document, even when it leaves the tenant
S/MIME and Message Encryption for email
Built-in anti-malware and spam filters

Access management:

Single sign-on via Entra ID
Multi-factor authentication: the single most effective measure, but no longer sufficient on its own
Conditional Access: the actual control plane
Mobile Device Management with remote wipe

Compliance:

Data Loss Prevention (DLP): detect and block sensitive data
Auditing and retention policies
eDiscovery: evidence preservation for legal requirements

The gaps in a default configuration

A freshly deployed tenant and one grown over years typically share the same weaknesses. These five are worth checking before any product gets bought:

Legacy authentication protocols. Older protocols know nothing of a second factor. As long as they remain active anywhere, a path around MFA exists and attackers look for exactly that.

MFA not universal. “We have MFA” often means, in practice: for the administrators. What’s left over are service accounts, external guests, mailboxes without a personal user, and the one area where “it didn’t work”.

Too many privileged accounts. Global administrator rights get granted and rarely revoked. Every one of those identities is full access to the entire tenant.

Uncontrolled external sharing. Defaults often permit more than intended. The difference between “people in my organisation” and “anyone with the link” is one click and a data protection incident.

Mailbox rules. Automatic external forwarding is a classic step after an account takeover: inconspicuous, persistent, and it even survives a password change if nobody removes the rule.

Why MFA alone no longer suffices

MFA remains the single most effective measure. It just isn’t an end state anymore.

Attackers adapted. MFA fatigue relies on repetition: whoever gets the twelfth push notification at two in the morning eventually approves it for peace and quiet. Adversary-in-the-middle phishing goes further and bypasses the second factor entirely: the fake sign-in page relays input to the real service in real time, the user correctly confirms their second factor and the attacker captures the resulting session token. They are now signed in without knowing the password and without possessing the second factor.

What helps against this:

Phishing-resistant methods: FIDO2 security keys or certificate-based sign-in bind authentication to the genuine domain. A fake page cannot intercept them.
Number matching instead of simple approval: makes reflexive dismissal impossible.
Conditional Access: tie access not only to “who” but to device state, location, application and risk assessment.
Session anomaly monitoring: a session that suddenly continues from a different country or with a different client fingerprint is a finding.

Conditional Access is the actual control plane

MFA answers “is this the right person?”. Conditional Access answers the question that decides more in day-to-day operations: “under what circumstances may this person access this application?”

Useful starting points:

Access to sensitive applications only from managed, compliant devices
Blocking legacy authentication protocols through a policy without exceptions
Stricter conditions for privileged roles than for regular users
Risk-based conditions: force additional verification on anomalous sign-ins
Document and time-limit exceptions, otherwise interim solutions become permanent holes

Compliance: what M365 can do and where it stops

The built-in compliance tools are capable. Three notes from practice:

DLP only works with clean classification. Rules reacting to patterns like credit card or ID numbers work reliably. The real value only appears with sensitivity labels that fit your business and that somebody has to maintain.

Audit logs need deliberate configuration. Check which events are logged at all and how long they are retained. An investigation starting three months after the incident either fails against a 90-day retention or doesn’t. Why retention weighs so heavily on detection and evidentiary obligations is covered in Which Log Sources Does a SIEM Actually Need.

A lot depends on licensing. A substantial share of the advanced capabilities (risk-based access control, extended DLP, longer audit retention) is tied to higher plans or add-on licences. Check what your licences actually provide before planning, rather than discovering it after the design is done.

Why a CASB makes the difference

The native tools are good, but they stop at the edge of Microsoft 365. A Cloud Access Security Broker (CASB) extends your internal security policies to all the cloud applications in use and makes shadow IT visible.

That isn’t an academic addition. Data leaves M365 constantly in daily work: into file transfer services, project tools, AI assistants, personal storage accounts. A policy that only applies inside M365 ends exactly where the risk begins.

What that looks like concretely with Zscaler, from local internet breakout through tenant restriction, is covered in Zscaler Internet Access & Microsoft 365.

That’s exactly the move from “secure M365” to an end-to-end Zero Trust architecture, where identity and context decide access, not location.

A sequence that works

Disable legacy authentication protocols
Roll out MFA without gaps, including service and guest accounts
Reduce and time-limit privileged roles
Conditional Access for sensitive applications and privileged roles
Review external sharing and automatic forwarding
Align audit logging and retention with investigation needs
Align classification and DLP with the data actually worth protecting
Verify recovery capability and actually restore something once

The first five cost configuration effort and no budget. They close the gaps real attacks run through.

How Cloud Cape helps

Clean tenant configuration is mandatory; extending it into an end-to-end access architecture is where the real value sits. Our Managed Security Service Edge brings CASB, DLP and identity-based access together: from Core through Plus to Elite, operated by Cloud Cape and integrated with our SOC. That way Microsoft 365 isn’t just configured correctly but becomes part of a resilient Zero Trust strategy.

Talk to us about Managed SSE. We bring Microsoft 365 and Zero Trust together.