Microsoft 365 has become the backbone of modern business. Identity, email, collaboration, file storage, and increasingly security controls themselves all live within a single tenant. For many organisations, it is now the most business-critical platform they operate.
Yet despite this centrality, a large proportion of Microsoft 365 tenants remain insecure — not because organisations are negligent, but because security is often assumed, misunderstood, or allowed to drift.
This article explains why insecurity in Microsoft 365 is the norm rather than the exception, and what “secure” actually looks like in practice.
For many organisations, this insecurity does not feel obvious day to day. Systems work, users authenticate, data flows, and incidents are rare or invisible. From the outside, everything appears functional. The problem is that security failure in Microsoft 365 is often latent rather than immediate — risk accumulates quietly until a single event exposes how fragile the environment has become.
This is article is part of a series on M365 security that can be read in any order:
Why Most Microsoft 365 Tenants Are Insecure by Default – Preparing for a Microsoft 365 Audit: What Actually Gets Scrutinised – What Good Looks Like: Microsoft 365 Governance in Practice – Rethinking Microsoft Secure Score: Why a Percentage Is Not a Security Posture. – Is Microsoft 365 Enough for ISO 27001? – External Sharing in Microsoft 365: Convenience vs Risk – The Most Common Microsoft 365 Misconfigurations We See – Why Defender Doesn’t Mean You’re Protected – Identity Is the New Perimeter: How Attackers Exploit Microsoft 365
Microsoft is very clear about the shared responsibility model: they secure the platform, customers secure how it is used.
In theory, this is well understood. In practice, it breaks down quickly.
In practice, the shared responsibility model fails not because it is unclear, but because it is uncomfortable. Accepting responsibility for configuration, access decisions, and monitoring means accepting accountability for outcomes. In many organisations, that accountability is diffused across IT, security, and cloud teams, creating gaps where critical decisions are made implicitly rather than owned explicitly.
Most organisations assume that because Microsoft 365 is a managed cloud service:
None of these assumptions are true.
Microsoft provides capability, not secure configuration. The tenant owner decides:
When those decisions are implicit rather than deliberate, risk accumulates silently.
Security defaults are designed to reduce friction and encourage adoption across millions of tenants with vastly different risk profiles. That design goal is entirely reasonable from a platform perspective. The problem arises when those defaults are mistaken for a completed security posture, rather than a baseline from which tenant-specific risk decisions should begin.
However, defaults are designed to be:
Microsoft has improved its defaults significantly in recent years. Security Defaults, baseline policies, and template-driven controls are all steps in the right direction.
Attackers do not operate at this level.
Real-world Microsoft 365 attacks target:
Security Defaults are not designed to withstand targeted attacks against a specific organisation. They are a starting point, not a security posture.
Targeted attacks are, by definition, informed. Attackers study common Microsoft 365 configurations, understand how tenants are typically deployed, and probe for predictable weaknesses. Defaults, no matter how sensible, are visible to anyone who understands the platform. Treating them as sufficient against a motivated adversary misunderstands both attacker behaviour and intent.
When Microsoft 365 tenants are compromised, identity is almost always the entry point.
Common identity-related weaknesses include:
Attackers no longer “break in” — they log in.
Identity misconfiguration persists because it often emerges gradually rather than through a single poor decision. Exceptions are added for convenience, legacy protocols are left enabled to avoid disruption, and privileged access expands organically as responsibilities grow. Individually, these changes seem reasonable; collectively, they create an identity layer that is permissive, opaque, and difficult to defend.
Once a valid token is obtained, many tenants provide little resistance to:
This is not a tooling problem. It is a configuration and governance problem.
Tooling failures are easy to diagnose and fix. Governance failures are not. They require organisations to confront how decisions are made, how access is justified, and how risk is accepted. In Microsoft 365, where identity sits at the centre of everything, weak governance magnifies the impact of even small configuration mistakes.
Another recurring issue is over-reliance on tooling.
Organisations invest heavily in:
Yet struggle to answer basic questions such as:
When these questions cannot be answered confidently, security teams are forced into a reactive posture. Decisions are made under pressure, investigations stall due to missing context, and confidence erodes over time. The organisation may still appear well-tooled, but beneath the surface, security becomes fragile and dependent on individual knowledge rather than repeatable process.
Security tooling without operational governance creates false confidence. Controls exist, but no one knows whether they are effective.
This gap is rarely visible until an incident occurs — or an assessment forces uncomfortable questions.
Even tenants that start securely rarely stay that way.
Drift occurs due to:
Drift is particularly dangerous because it rarely triggers alarms. Each change appears minor, justified, and isolated. Only when viewed over time does the cumulative effect become clear — by which point reversing decisions is complex, politically difficult, or operationally risky. Without deliberate review, drift becomes the default state.
Because Microsoft 365 is constantly evolving, yesterday’s “secure” configuration may no longer be sufficient today.
Without periodic, independent review, risk accumulates invisibly.
A secure Microsoft 365 tenant is not defined by:
“Good” security in Microsoft 365 is less about perfection and more about intent. It reflects conscious choices about risk, visibility into how the tenant is actually used, and a willingness to revisit decisions as conditions change. Secure tenants are not static — they are actively maintained.
It is defined by:
This is why independent Microsoft 365 security assessments remain essential — even for mature organisations.
The common thread across insecure tenants is not ignorance or negligence, but assumption. Assumptions about responsibility, about coverage, and about how attackers operate. These assumptions persist precisely because they are rarely challenged until something goes wrong.
Microsoft 365 insecurity is rarely the result of a single bad decision. More often, it is the accumulation of reasonable assumptions, inherited configurations, and well-intentioned compromises made over time.
The platform itself is not the problem. Microsoft provides powerful security capabilities, but those capabilities require deliberate design, ongoing attention, and periodic validation. Without that, even well-resourced organisations drift into insecure states without realising it.
The most mature organisations recognise that Microsoft 365 security is not something you “finish”. It is a state that must be understood, measured, and revisited as the environment evolves.
Independent assessment plays a critical role here — not because internal teams lack competence, but because security blind spots are often structural, not technical. Fresh perspective is what turns assumption into evidence.
Trusted Microsoft Cloud Security Advisor with 27 years experience | Empowering Businesses to Embrace Cloud Innovation with Confidence
