Tenant Baseline Drift

What Tenant Baseline Drift Really Means

Tenant baseline drift is a configuration-state problem, not a product feature. It describes the widening gap between what teams believe Microsoft 365 is enforcing and what tenant settings, defaults, and exceptions are actually doing.

The important idea is that the “baseline” is often a living set of policies, admin choices, service defaults, and inherited exceptions. Over time, small one-off changes can accumulate into the effective control posture even when no one has formally approved that posture.

This makes the term especially useful in Microsoft 365 environments where configuration is spread across multiple admin surfaces, security controls, and workload-specific settings. The drift is real when the operational state diverges from the intended security standard, not merely when a document is outdated.

For organisations trying to keep a stable tenant posture, baseline drift is often the first sign that governance is weaker than the published configuration standard suggests. It is a measurement problem as much as a control problem.

How Baseline Drift Emerges in Microsoft 365

Drift usually begins with exceptions that were meant to be temporary. A setting is loosened for a migration, a workaround is added for a business team, or a default is left in place because it did not break anything during testing. Once those changes persist, they become part of the real operating environment.

Microsoft 365 is particularly prone to this because it combines tenant-wide defaults, service-specific controls, and identity-linked policy decisions. A change in one area can quietly alter the effective baseline elsewhere, especially when ownership is split across messaging, collaboration, identity, and endpoint teams.

That is why configuration baselines should be treated as continuously validated control states rather than static documents. A reference standard only helps if it is still aligned with what the tenant actually enforces.

For a broader baseline-hardening view, CIS Benchmarks remain a useful reference point for comparing intended configuration against a hardened standard, and CIS Benchmarks are especially relevant when tenant settings need a concrete control target.

What Tenant Baseline Drift Breaks

Drift weakens confidence in three things at once: the security control itself, the reporting around that control, and the organisation’s ability to explain its posture. If the tenant no longer matches the approved baseline, dashboards and policy statements can become misleading even when they still look current.

It also creates hidden inconsistency across user groups and workloads. Two teams may believe they are operating under the same tenant standard while one group is effectively exposed to looser controls, inherited exceptions, or older defaults that were never reconciled.

In practice, drift can also make enforcement uneven across identities, applications, and integrations. For example, a control weakness in one integration path can persist long enough to become the accepted state, which is why tenant posture review and change control need to stay tightly linked. NHI-focused work on Salesloft OAuth token breach is a useful reminder that configuration drift and token-related access paths can combine into real exposure.

When drift is ignored, the organisation stops managing a baseline and starts managing exceptions as if they were normal operations.

Why Drift Matters for Governance and Assurance

Tenant baseline drift is ultimately a governance issue because it obscures ownership. Someone may own the policy, someone else may own the tenant, and a third group may own the exceptions, but the control result is only as strong as the least-governed part of that chain.

It also affects assurance. Audit evidence, security attestations, and internal reporting all depend on a stable relationship between the documented baseline and the enforced configuration. When that relationship breaks, assurance becomes conditional rather than reliable.

That is why continuous configuration comparison matters more than one-time approval. The goal is not to create a perfect baseline once, but to keep the approved state, the enforced state, and the observed state aligned enough that the tenant remains trustworthy.

For security teams that already map hardening to formal control sets, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a structured way to think about configuration management, access control, auditability, and system integrity, while NIST Cybersecurity Framework 2.0 gives a higher-level way to organise governance, protect, detect, respond, and recover activities around a drifting baseline.

Risk and Threat Considerations

Tenant baseline drift creates security exposure because the organisation may be relying on controls that are no longer actually enforced. The danger is not just misconfiguration, but the false belief that the tenant is still operating under a stricter standard than reality.

Failure mechanism: Small exceptions, inherited defaults, and unreviewed changes accumulate into the true operating state, which can leave access, sharing, authentication, or policy settings looser than expected.

Impact: Attackers and insiders can exploit the gap between intended and actual posture, and defenders may miss the exposure because reporting still reflects the old baseline.

Practitioner Guidance

What to watch for: Treat drift as a continuous validation problem, not a periodic cleanup task. The key signal is any persistent difference between the tenant’s documented standard, the current configuration, and the exceptions that teams say are temporary.

Governance implication: Assign explicit ownership for the baseline itself, not just for individual settings. If nobody is accountable for reconciling defaults, exceptions, and approved deviations, the “baseline” will slowly become whatever happened last.

Practitioner takeaway: The best tenant baseline is the one you can actually prove is being enforced today, not the one that was approved last quarter.

Related resources from NHI Mgmt Group

• How should security teams use drift management alongside infrastructure as code in multi-tenant environments?
• How should security teams implement baseline configurations to reduce configuration drift across mixed infrastructure?
• Tenant Drift
• How should security teams think about a compromised integration like Drift?