Drift inside Microsoft 365 is a structural consequence of organisational change. Treating it as occasional cleanup work is operationally naive—and leaves CIOs managing an environment that reflects history rather than intent.
Most CIOs of Swiss SMEs believe their Microsoft 365 environment is under control. Licences are assigned. Security policies exist. Offboarding is documented, automated, and enforced. The invoice is stable. Nothing appears chaotic.
And yet, in almost any tenant that has been running for more than two or three years, the same patterns appear:
This is not incompetence. It is entropy. And entropy in digital systems is structural.
Organisations change continuously. Roles evolve. Department restructuring. Projects start and end. Vendors come and go. Security requirements increase. Pricing models shift.
Microsoft 365, however, does not automatically re-baseline itself when these changes occur. A licence assigned in 2022 will not re-evaluate itself in 2026. A Conditional Access policy will not redesign itself when the risk model changes. An access group created during a migration will not dissolve when the project ends.
The system accumulates decisions. Over time, the tenant becomes a historical record of organisational evolution rather than a clean reflection of current operational design. That accumulation is identity entropy.
Entropy inside Microsoft 365 is rarely dramatic. It is subtle and incremental. Consider a few examples that will be familiar to most Swiss SME environments.
A finance analyst moves into a regulatory reporting function but retains a Business Standard licence without the advanced Data Loss Prevention capabilities her new role requires. A project administrator becomes a frontline supervisor but keeps an E3 licence with broad SharePoint access he no longer needs. A security add-on is purchased after a board discussion, but enforcement remains partial because the rollout was technically complex and never fully completed. An account created for a temporary external consultant remains active in the tenant long after the engagement ended.
None of these events triggers an alert. Each one seems reasonable in isolation. Together, they create drift.
The system still functions. But it no longer reflects intentional design. That gap between function and design is where governance risk accumulates.
This is the uncomfortable part. Many SMEs assume drift happens because teams are understaffed or careless. In reality, even competent IT teams operate in conditions that make structural entropy inevitable.
The reason is straightforward: operational change velocity is higher than governance review cycles. Most SMEs run manual offboarding processes, conduct licence reviews annually or ad hoc, implement security improvements incrementally, and have no structured process for re-baselining role-to-access alignment. Meanwhile, people change roles quarterly, business priorities shift rapidly, regulatory pressure increases, and Microsoft itself changes licensing structures and feature boundaries.
The tenant evolves faster than the governance model. That is not a failure of people. It is a mismatch between system dynamics and control cadence. Recognising that distinction is the starting point for operational maturity.
One reason entropy goes unnoticed is conceptual. Licensing is typically viewed as a commercial construct — something managed between IT and procurement, a financial artefact reviewed when invoices change.
But in Microsoft 365, licences are not merely commercial instruments. They determine the availability of security features, Conditional Access capabilities, Data Loss Prevention coverage, the scope of Privileged Identity Management, and Defender protection levels. Licensing is the enforcement layer of your operating model.
When roles evolve, but licensing assignments do not, the enforcement layer lags behind organisational reality. From a governance perspective, that is not a billing issue. It is control misalignment. The distinction matters because billing issues get noticed when invoices change. Control misalignment can persist undetected for years.
This connection between licensing and security enforcement is developed further in Blog 3, where we examine role drift and the security capability gap in detail.
Entropy compounds quietly. At first, the impact appears minimal — a slightly oversized licence here, a dormant account there, a security feature licensed but unconfigured. But compounding matters. Over several years, cost inefficiency accumulates, governance debt increases, audit exposure widens, and security posture becomes inconsistent across similar roles.
Most importantly, visibility decreases. The longer the drift continues, the harder it becomes to distinguish intentional architecture from historical residue. For a CIO, this creates what might be called the illusion of apparent stability: invoices are stable, no major incidents have occurred, nothing looks obviously wrong. But operational systems can be deeply misaligned long before they fail visibly.
Dormant accounts — explored in detail in Blog 2 — are one of the most concrete expressions of this compounding effect. They are the unmanaged space that accumulates when offboarding lags behind organisational change, and they illustrate how individually harmless-looking gaps become collectively significant over time.
Here is the critical insight:
Any environment that experiences role mobility, organisational growth, incremental security improvements, and multi-year operation will drift. The question is not whether entropy exists. The question is whether it is acknowledged and managed as part of operational governance.
In other domains, Swiss SMEs accept this logic without question. Production systems require recalibration. Financial controls require periodic reconciliation. Quality management requires documented review cycles. Digital identity and licensing rarely receive the same structured discipline, yet they underpin every modern workflow and define who can access what in your organisation.
Most organisations respond to drift reactively. An invoice increase triggers a licence optimisation exercise. An audit triggers an access cleanup. A security incident triggers a configuration review. This is event-driven governance. It addresses symptoms after they surface rather than managing the underlying dynamic.
Operational excellence requires something different: structured re-baselining. That means validating licence assignments against actual usage patterns, confirming role definitions against access entitlements, reviewing dormant or low-activity identities on a defined cadence, and aligning security configuration with current threat assumptions. Not because something broke — but because drift is inevitable and correction is cheaper before it compounds.
This shift from reactive cleanup to structured re-baselining is the thread that runs through this entire series. Blog 4 examines a specific dimension where reactive governance carries the highest risk: external identities and privileged access. xBlog 5 brings the full picture together into a practical governance maturity model designed for the scale and resource constraints of Swiss SMEs.
For SME CIOs, addressing identity entropy is not a question of technical sophistication or team size. It is a question of mindset.
If Microsoft 365 is treated as a static infrastructure component — something that runs in the background and only demands attention when invoices or incidents force it — entropy will accumulate until it becomes visible as a cost spike, an audit finding, or a security event. If it is treated as a dynamic operational system that requires periodic re-baselining, corrections become the norm rather than the crisis.
Operational excellence does not mean perfection. It means accepting that systems degrade without structured attention, and building governance rhythms that reflect that reality.
Identity entropy is not dramatic. It does not announce itself. It does not generate urgent alerts. But it quietly reshapes the relationship between roles, access, and control — and in a digitally dependent SME, that relationship defines operational resilience.
The more useful question is not whether entropy exists in your tenant. It almost certainly does. The more useful question is this: do you treat Microsoft 365 as a living operational system that requires structured re-baselining, or as a toolset that only demands attention when invoices or incidents force it?
That distinction defines the maturity of your governance model. In dynamic environments, maturity is not measured by stability. It is measured by how intentionally you correct drift before it compounds.
In Blog2 to be released soon (Sign up to be notified here), we will look at one of the most common and underappreciated expressions of identity entropy: dormant accounts, and the governance debt they quietly accumulate over time.