Security Settings Don't Stay Secure. Here's Why Your Microsoft 365 Environment Drifts

When the Microsoft 365 migration was completed, the business did the right things. MFA was enabled. Security settings were configured. Access was set up properly. An IT provider signed off on the implementation.

Then the business moved on.

And Microsoft 365 didn't stay still.

In the years since, the team has grown. Staff have joined, changed roles, and left. New Microsoft Teams have been created - some for specific projects, some that became permanent, some that nobody uses anymore. SharePoint sites have multiplied across departments and initiatives. External users were invited to collaborate. Third-party applications were connected to automate workflows. Somebody enabled broader sharing for a proposal deadline. Copilot licences were purchased because the productivity case looked compelling.

The business has changed significantly. The question worth sitting with is: does the Microsoft 365 environment still look like the environment that was originally secured?

The honest answer, for most businesses that have been running Microsoft 365 for three or more years, is: probably not.

You Didn't Leave Microsoft 365 Unsecured. It Changed.

There's an important distinction worth making at the start of this conversation.

Microsoft 365 Security Drift is not what happens when a business ignores security. It's what happens when security is configured correctly at a point in time, and then the environment changes around it.

This is well-documented across the Microsoft partner community. CoreView's 2026 guide to Microsoft 365 configuration drift tools put it plainly: "How do you know when a drift has happened? The answer is you don't, because Microsoft doesn't tell you." The reason is structural. Microsoft 365 isn't one product. It's a collection of more than 60 interconnected services - Entra ID, Exchange Online, SharePoint, Teams, OneDrive, Defender, Purview, Intune - each with its own settings and administrative interfaces. If an identity policy is weakened, an external sharing control is loosened, or a privileged pathway quietly expands, security controls can change without an obvious alert. Without an easy way to prove what changed, when, and why.

Senserva, a specialist in Microsoft 365 drift management, defines security drift precisely: "Configuration drift that weakens your security posture - for example an MFA requirement removed, a Conditional Access exclusion left in place, or a sharing control loosened."

D2NA's analysis from August 2026 captures why it happens: "Security controls are implemented correctly during a project, migration or security improvement programme, but over time those controls gradually change. New users are added, permissions are expanded, exceptions are created and settings are adjusted to solve operational challenges. Individually, these changes often seem harmless. Collectively, they can significantly weaken an organisation's security posture."

This isn't a story about IT failure. It's a story about business change. And businesses change faster than their security environments are reviewed.

What Microsoft 365 Security Drift Looks Like

The most useful way to understand security drift is through the ordinary decisions that create it - none of which seem significant at the time.

A project manager is given access to a SharePoint site for a major client engagement. The project ends. She moves into a new role. Her access remains. Two years later, the SharePoint site contains commercially sensitive pricing information and client financial data. Nobody has reviewed who can still access it, because nobody has a process for doing that review.

A business enables external sharing with a partner organisation for a specific integration project. The project is completed. The sharing configuration stays in place. Nobody at the business remembers why the external access was originally granted, and the partner organisation still has access to content that was never intended to be permanently accessible.

An employee connects a third-party application to Microsoft 365 to automate a workflow - a proposal tool, a scheduling application, a document signing service. The application is granted OAuth permissions to read email and access files. The employee leaves the company 18 months later. The application remains connected, still holding those permissions. Nobody reviews the list of third-party applications with access to the environment, because nobody knows where to look or that the review is needed.

A business configures MFA for all users when it first implements Microsoft 365. Over the following years: new users are added through a process that doesn't consistently enforce MFA. Exceptions are created for legacy systems. A Conditional Access policy that enforced MFA is modified to accommodate a specific use case and never reverted. The business believes MFA coverage is consistent. It no longer is.

These aren't edge cases. They're the ordinary accumulation of reasonable decisions made by people operating under time pressure in a growing business. The problem is that nobody has a consolidated view of what those decisions have added up to.

Seven Ways Security Drift Builds Up

Microsoft 365 security drift doesn't happen in one place. It accumulates across every layer of the environment.

Identity Drift

Every person who joins or leaves the organisation touches the identity layer of Microsoft 365. When someone joins, accounts are created. When someone leaves, accounts should be disabled - promptly, completely, and with all associated permissions removed. In practice, this doesn't always happen cleanly.

Departed employees' accounts remain active longer than they should. Former contractors retain guest access after their engagement ends. Staff who changed roles carry the permissions from their previous position alongside the permissions for their new one. Service accounts created for specific projects remain in the environment long after the project has closed. Privileged roles - Global Administrator, Security Administrator, Exchange Administrator - accumulate across accounts because it was easier at the time than scoping access precisely.

Microsoft's own research found that 99.9% of compromised accounts did not have MFA enabled. The accounts most likely to be missing MFA are exactly those at the edges of a growing environment: new accounts added in a hurry, legacy accounts for systems that haven't been updated, and exceptions created for specific circumstances that then became permanent.

The question that identity drift creates: do the right people still have the right level of access - and only that level of access?

Permission Drift

SharePoint, Teams, OneDrive, and Microsoft 365 Groups create a permission landscape that changes constantly. Sites are created, teams are formed, folders are shared, and content is given access permissions in the moment of need.

What changes less reliably is the other end of that process - removing access when it's no longer needed, reviewing who still has permissions to sites and folders that contain sensitive content, and auditing the inherited permissions that cascade automatically through folder hierarchies.

Broken permission inheritance - where the settings at a file or folder level don't align with the settings at the site level - is one of the most common patterns in mature Microsoft 365 environments. Content that should be restricted can be accessible to far more people than intended, simply because the inheritance relationship was changed for a legitimate purpose at some point and never reviewed.

The question that permission drift creates: how much information can employees access that they no longer need?

Application Drift

Every third-party application connected to Microsoft 365 holds OAuth permissions that give it access to organisational data. Those applications don't decommission themselves when they're no longer actively used. The permissions don't expire when the employee who connected the application leaves the company.

CoreView's analysis notes the structural problem: there is no consolidated Microsoft tool that spans all 60-plus M365 services and shows a complete picture of which third-party applications are connected, what permissions they hold, and whether those permissions are still appropriate. Individual service views exist. A complete, business-facing audit of the application access landscape does not appear automatically.

Shadow IT adds another layer. Employees connect applications they find useful - for scheduling, document signing, automation, AI tools - through personal OAuth grants that create application connections IT may not be aware of. Each connection is a potential access pathway into the environment.

The question that application drift creates: does your business know every application that currently has access to its Microsoft 365 environment?

Security Configuration Drift

MFA policies. Conditional Access rules. Anti-phishing controls. Legacy authentication settings. External sharing defaults. Defender configurations. Each of these can be changed - often for legitimate operational reasons - without those changes being tracked, reviewed, or connected to a security assurance process.

A Conditional Access policy that enforces MFA is modified to allow access from a specific location for a specific business need. The exception is never reviewed again. Legacy authentication protocols are left enabled for an older line-of-business application that hasn't been updated. A security setting is changed during troubleshooting and not reverted. Email forwarding rules - a consistent early indicator of business email compromise - are created on accounts that aren't actively monitored.

The distinction between a current security configuration and an intended security configuration can develop gradually, one small change at a time. Microsoft Secure Score provides a point-in-time view of certain security recommendations - but as Senserva observes, "a one-time audit is a snapshot. Drift happens after the snapshot, so a tenant can pass an audit and be out of baseline weeks later."

The question that security configuration drift creates: are your security policies still being applied consistently?

Device Drift

Intune and device management policies define which devices are considered compliant and can therefore access company information. Those policies are configured at a point in time based on the device landscape the business had then.

Since then, new devices have been added. Employees are using personal devices that weren't part of the original device management framework. Old devices are still registered in the management system but no longer actively used. BYOD arrangements have evolved without the device management policy being revisited.

Conditional Access policies that require device compliance are only as effective as the device management policies they rely on. If the device landscape has evolved beyond what those policies account for, the compliance check becomes unreliable.

The question that device drift creates: does your business know which devices are accessing company information?

Data Drift

SharePoint sites, Teams channels, and OneDrive folders are created continuously in an active Microsoft 365 environment. Not all of them are governed, labelled, or periodically reviewed. Over time, sensitive content ends up in locations with broader access than intended - because the sharing decision was made in a hurry, because the content was moved without the permissions being adjusted, or because nobody knows it's there.

External sharing settings configured for one purpose remain active for other purposes. Guest users retain access to content after the collaboration that required it has concluded. Shared mailboxes and shared drives carry content from years of business activity without anyone having assessed whether the access permissions still reflect the business's intentions.

The question that data drift creates: where has the business's information ended up over the last several years?

AI Drift

When Copilot or other AI tools are introduced into a Microsoft 365 environment, they interact with the data and permissions landscape as they find it - not as it was originally designed.

As we covered in our post on what Copilot can see in your Microsoft 365 environment, Microsoft is explicit: Copilot does not create new permissions. It makes existing access more discoverable. An environment affected by identity drift, permission drift, and data drift provides AI with a broader surface to operate on than an environment where permissions are actively maintained.

An employee whose role has changed but who still holds permissions from a previous position can ask Copilot questions that surface content from across their accumulated access landscape. Overshared SharePoint sites become trivially queryable. Content that was technically accessible but practically obscured by volume becomes immediately discoverable through natural language prompts.

AI adoption doesn't create the drift problem. It makes it more consequential.

The question that AI drift creates: have your security and data controls kept pace with your AI adoption?

Why Businesses Often Don't See It Happening

The nature of drift is that it's gradual. No single change in a Microsoft 365 environment is likely to be dramatic enough to trigger a review. The permissions added for a project, the application connected for a workflow, the exception created for a legacy system - each one is individually manageable. The accumulation is what creates the problem.

There's also a visibility gap that's structural rather than negligent. As CoreView observed, Microsoft 365 is a collection of services with separate administrative interfaces. Entra ID, SharePoint, Teams, Exchange, Intune, Defender - each can be reviewed in isolation, but there is no single pane of glass that shows a consolidated view of configuration changes, permission accumulation, and application access across the full environment. That consolidated view requires either specialist tooling or deliberate review effort, neither of which is typically built into the regular operations of a lean NZ IT team.

The responsibility question complicates this further. In many NZ businesses, Microsoft 365 security sits somewhere between IT operations, the managed services provider, and leadership - without any of those parties having clear ownership of the ongoing assurance question. Managed services providers handle helpdesk and infrastructure. Leadership is focused on operations. The question of whether the security configuration has drifted from its intended state doesn't clearly belong to anyone.

And there's the assumption. Businesses that engaged a provider to configure Microsoft 365 securely often assume that the provider is maintaining that configuration over time. That assumption isn't always accurate. Configuration and ongoing governance are different services, and providers who weren't engaged for the latter aren't necessarily delivering it.

The Risk Isn't One Bad Setting

This is the framing that matters most for business leaders: Microsoft 365 Security Drift is not typically one critical misconfiguration. It's the accumulation of small changes, small exceptions, and small omissions that collectively create a security posture that doesn't reflect the business's intentions.

Any one of the patterns described above - a former employee's account still active, an external sharing setting left open, a Conditional Access exception never reviewed - might be manageable on its own. The combination of identity drift, permission drift, application drift, and configuration drift across an environment that hasn't been reviewed in two years is a different proposition entirely.

This is what the Windows Forum's analysis of Microsoft 365 security characterises as "false confidence" - "yesterday's good design into today's false confidence, one reasonable exception at a time." The security investment was real. The configuration work was done properly. What isn't known is whether it still exists in the form it was intended.

For NZ businesses, there's a specific regulatory dimension. The NZ Privacy Act 2020 requires that organisations maintain reasonable security safeguards for personal information. Microsoft 365's default configurations - as OxygenIT's NZ-specific analysis confirmed in May 2026 - present compliance gaps from the outset, with external sharing enabled by default across SharePoint and OneDrive. In an environment that has drifted further from its intended configuration, the gap between actual practice and privacy obligation may be wider than the business realises.

The NCSC's Minimum Cyber Security Standards, published October 2025, set a baseline that requires controls to be documented, maintained, and repeatable. An environment affected by security drift may have controls that were documented at implementation and have since changed in ways that aren't tracked. That's not a documented, maintained security posture. It's a historical record of a posture that may no longer exist.

Why AI Makes This More Important

The relationship between Microsoft 365 security drift and AI adoption isn't complicated. It's direct.

A permissions landscape affected by drift - where employees hold access they no longer need, where SharePoint sites are overshared, where former employees' accounts remain in the environment - is the data environment that AI operates on. Copilot traverses content based on what each user can access. AI agents can potentially interact with data across connected systems. Shadow AI tools - ChatGPT and equivalents that staff are using independently - are processing business information through external systems that have no visibility into your permissions landscape at all.

The businesses that are deploying AI effectively understand that AI governance and Microsoft 365 security are not separate workstreams. The data governance, identity management, and permission hygiene that good Microsoft 365 security requires are also the foundation that makes AI adoption trustworthy.

Introducing AI into an environment affected by significant security drift doesn't create new permissions problems. It makes existing ones matter more.

How Do You Know If Your Microsoft 365 Environment Has Drifted?

These questions don't require technical answers. They require honest ones.

Can you name every person who currently has Global Administrator access in your Microsoft 365 environment? Can you confirm those accounts belong to people who should have that access today - not people who needed it during a migration or implementation three years ago?

Do you know what third-party applications are currently connected to your Microsoft 365 environment and what permissions they hold? Not what was connected when you last checked - what's connected right now, including applications employees connected themselves?

Can you confirm that MFA is consistently enforced across every user account in your environment? Not that MFA was enabled when you set it up - that it's currently applied consistently, including accounts created in the last 12 months and accounts that were created as exceptions to policies?

Do you know which SharePoint sites and OneDrive folders in your environment are accessible to everyone in the organisation? Can you identify which of those contain content that should be more restricted?

When did someone last review which guest accounts and external users have access to your Microsoft 365 environment? Are all of those access grants still appropriate?

Do you know what changed in your Microsoft 365 environment last month? Which settings were modified, which accounts were created or changed, which applications were connected?

If the honest answer to several of these is "I'm not sure" or "I'd have to ask someone to check" - the environment has likely drifted from its intended configuration in ways that aren't currently visible.

Microsoft 365 Security Needs Ongoing Assurance

The concept of configuration drift management is now well-established in the Microsoft security space. Senserva's definition is useful: "the ongoing practice of detecting drift from a secure baseline and closing it, rather than checking once and hoping nothing changes. It combines a known-good baseline, continuous detection, and a remediation path."

That's the framing that translates into a business requirement. Not a one-time project. Not an annual audit. A continuous practice - a known baseline, a way of detecting deviation from it, and a process for addressing deviations when they're found.

For NZ SMEs without large internal IT teams, this doesn't mean building a security operations centre. It means having someone actively watching the Microsoft 365 environment - identity activity, configuration changes, permission accumulation, application access, and security policy consistency - on a continuous basis, and surfacing the changes that matter.

Microsoft Secure Score is a starting point. It provides a point-in-time view of security recommendations across the Microsoft 365 environment, updated regularly. It's useful for identifying where a configuration doesn't meet Microsoft's recommended baseline. What it doesn't provide is a change log - a record of what has moved since the last review, what was deliberately changed versus what drifted without anyone noticing, and what the context was for changes that appear in the current configuration. That contextual, historical view of the environment requires more than a score.

The businesses that manage Microsoft 365 security well over time treat it as a continuous function, not a periodic project. They maintain a current picture of who has access to what. They track application connections and review them regularly. They monitor identity and access changes as they happen rather than discovering them in retrospect. And they have someone accountable for the question that drift undermines: does our Microsoft 365 environment today still reflect our security intentions?

Security Shouldn't Depend on Remembering to Check

The practical reality for most NZ SMEs is that ongoing Microsoft 365 security assurance doesn't happen - not because the business doesn't care, but because nobody has built a systematic process for it. The checks depend on someone having time to look, remembering that the review is due, and knowing where and what to look at across a platform of 60-plus interconnected services.

NSP's Microsoft 365 Drift Management service is built for exactly this. Rather than waiting for an annual review or a security incident to surface what's changed, we provide continuous visibility into your Microsoft 365 environment - monitoring identity and access changes, tracking configuration drift against a secure baseline, identifying permission accumulation, reviewing application access, and detecting shadow AI activity - so the environment is actively maintained rather than periodically checked.

The objective isn't to add more security tools to the environment. It's to give leadership confidence that the Microsoft 365 environment today reflects the security decisions made when it was originally configured - and that when something changes, it's visible, understood, and addressed.

That confidence matters more now than it did three years ago. Because the environment has changed more, because AI adoption has raised the stakes of getting permissions wrong, and because insurance underwriters, privacy regulators, and major clients are increasingly asking specific questions about whether security controls are not just present, but actively maintained.

The Environment You Have Now

Return to the question from the opening.

You migrated to Microsoft 365. You did the right things. Security was configured. MFA was enabled. An IT provider signed off.

That was then.

Since then: staff have joined and left. Teams have been created. SharePoint sites have grown. Applications have been connected. External access has been granted and never reviewed. Copilot licences have been purchased. Exceptions have been made and forgotten. Microsoft has updated its services and introduced new capabilities that the business hasn't assessed.

The question isn't whether your Microsoft 365 environment was secured.

The question is whether the environment you have now still looks like the one that was.

If you don't know the answer, that's the starting point.

Book a Microsoft 365 security review with NSP →

Or call us: 0508 010 101

Frequently Asked Questions About Microsoft 365 Security Drift

What is Microsoft 365 Security Drift?

Microsoft 365 Security Drift is the gradual movement of a Microsoft 365 environment away from its intended, secure, or recommended configuration as users, permissions, applications, settings, and business requirements change over time. It's a description of what happens when a security configuration is set correctly at a point in time, and then the business and environment change around it without the security controls being maintained in step.

Why doesn't Microsoft alert me when my security configuration has drifted?

Microsoft 365 is a collection of more than 60 interconnected services, each with its own settings and administrative interfaces. There is no consolidated Microsoft tool that spans all of these services and automatically alerts on configuration drift across the whole environment. Microsoft Secure Score provides a point-in-time assessment of certain security recommendations, but it doesn't track what changed, when, or why.

How quickly can a Microsoft 365 environment drift from its intended configuration?

Meaningfully, within weeks of a security review. Every new user added, role changed, application connected, sharing decision made, or exception created is a potential drift event. In a business with regular staff movement and active collaboration, changes that individually seem minor can accumulate into a materially different configuration within months.

What are the most common areas where Microsoft 365 security drift occurs?

Identity and access management - former employees, role changes, accumulated permissions - is consistently the highest-risk drift area. Permission oversharing across SharePoint, Teams, and OneDrive is the most common discovery when organisations do a proper review. Third-party application access - applications connected via OAuth and never decommissioned - is frequently broader than businesses realise. MFA policy gaps are the most consequential: Microsoft's research shows 99.9% of compromised accounts didn't have MFA enabled.

Does Microsoft Secure Score tell me if my environment has drifted?

Partially. Secure Score shows your current configuration against Microsoft's recommended baseline. What it doesn't show is the change log - what was deliberately changed versus what drifted without anyone noticing, and when those changes happened. A tenant can pass a Secure Score assessment and be out of baseline weeks later, because the score is a snapshot, not a continuous monitoring capability.

What does ongoing Microsoft 365 drift management actually involve?

It involves maintaining a known-good security baseline, detecting deviation from that baseline continuously rather than periodically, understanding what changed and whether it was intentional, and having a clear remediation path for changes that create security exposure. In practice: monitoring identity and access changes, tracking configuration modifications across key security controls, reviewing permission accumulation, auditing application access, and surfacing shadow AI activity - on a continuous basis rather than as periodic projects.

Is this just an IT problem?

No. Decisions about who should have access to what, which applications should be connected to company systems, and what information should be accessible to which parts of the organisation require business context that IT alone doesn't have. The technical implementation belongs to IT. The business decisions that determine what the security configuration should look like belong to leadership, with input from HR, Finance, Legal, and Operations. Microsoft 365 security drift is a business governance problem with a technical dimension, not purely a technical problem.