The Cleanup CampaignThat Never Ends

Walk into most M365 tenants that have been running for three or more years and you'll find the same thing: a cleanup effort in progress, or recently completed, or just about to be scoped. Teams workspaces nobody remembers creating. SharePoint sites from projects that closed before half the current team was hired. Guest accounts from vendors, contractors, and partners who finished their work and moved on. Their access didn't.

The cleanup gets funded, it gets done, and six months later the tenant is roughly back to where it was. Not because the work was poor. Because a cleanup is a one-time correction applied to a system that never stopped accumulating. You cleared the backlog. The backlog started over.

The only way to change that math is lifecycle: treating every workspace, group, and automation as something with a defined end, not an indefinite default. Not a better cleanup process. A model where resources have to prove they're still needed, or they don't stay active.

M365 tenants don't fall apart randomly. They fall apart in ways that are entirely predictable once you've seen enough of them. The same failure patterns show up across organizations of different sizes, industries, and maturity levels. They're not caused by admin mistakes. They're caused by how the platform is built. Creation is fast and easy. Retirement is slow and manual. The gaps that result are structural, not accidental.

These five don't stay separate. Sprawl creates more locations for sharing drift to accumulate. Sharing drift makes the overpermission surface larger. Ownerless resources mean nobody cleans any of it up. And when Copilot arrives, it queries everything that drift and sprawl left accessible, surfaces it instantly, and exposes in seconds what manual discovery would have taken weeks to find, if anyone was even looking.

The conversation about Teams sprawl almost always goes the same direction: someone says users are creating too many workspaces and the fix is restricting creation. That's the wrong diagnosis. The problem isn't that people create workspaces. It's that the platform never asks whether they still need them.

When someone creates a Team, they're not just creating a chat window. The underlying Microsoft 365 group brings a SharePoint site, a mailbox, a Planner board, a OneNote notebook, and increasingly an AI surface. Each of those inherits the same membership and permission state. When the project ends and nobody archives the workspace, all of those surfaces stay live. Files stay accessible. Guests stay in the membership. Sharing links keep resolving. The workspace gets quiet. The access doesn't.

Restricting Team creation in the Teams admin center doesn't close that loop. Users create M365 groups through Outlook, Planner, Viva Engage, and a half-dozen app integrations that all provision the same underlying primitives. The creation surface is too broad for any single restriction to contain. The answer isn't to lock the front door more aggressively. It's to build in an end state so the accumulation can't continue indefinitely.

Lifecycle governance treats workspaces, groups, and automations like assets, not indefinite resources. Every asset has a start state, an active use phase, a review trigger, and an end-of-life event. The model doesn't rely on humans remembering. It operates on time and on event triggers. The only human decision required is re-attestation: confirm the asset is still needed, or it transitions to the next state automatically.

This is the assumption that kills more M365 governance programs than any other: if nobody is posting, nothing bad can happen. The UI gets quiet. The risk doesn't.

The guest problem from Part 1 of the Identity series and the lifecycle problem here are the same problem expressed at different layers. A guest account lifecycle and a group lifecycle both need to be managed, and they're not the same event. Removing someone from a group and disabling their account are two separate steps that do not automatically trigger each other.

Closing this loop requires two parallel tracks: group lifecycle (does the resource still need to exist, and who is responsible for it?) and guest account lifecycle (does this external identity still have a legitimate reason to authenticate to your tenant?). Access reviews handle membership. Expiration policies handle accounts. Both need to run. Both need enforced outcomes on non-response.

Lifecycle works where cleanup campaigns don't because it doesn't depend on anyone remembering to schedule the work. Time passes, a review window fires, someone confirms the resource is still needed or it moves toward archive. The accumulation can't continue unchecked because the model doesn't allow indefinite defaults. That's the difference. Not effort, not intent, just whether the system has a defined end or not.

Sprawl, sharing drift, exfiltration pathways, ownerless resources, and AI exposure. None of these require anything to go wrong. They're the natural output of a platform that creates easily and retires reluctantly. Lifecycle governance doesn't eliminate them. It removes the conditions that let them stack up quietly for years before anyone has to deal with them.

The next post takes the AI exposure pattern and examines it directly: what Copilot readiness actually requires, why it's a governance audit most organizations haven't completed, and why the organizations that have already cleaned up their authorization model are significantly better positioned than the ones that are trying to do it after deployment.