Technical Automation Blog | NudgeIT

The Governance Debt Hiding in Plain Sight

Written by Thomas Madsen | Apr 29, 2026 7:06:37 AM

Dormant accounts are not an IT hygiene issue. They are accumulated governance debt — unmanaged control points that quietly and predictably increase operational risk over time.

Dormant accounts are not an IT hygiene issue. They are governance debt — and unlike most technical debt, they don’t stay contained. They accumulate quietly until they show up in the worst possible moment: an audit, a breach, or a board-level question you can’t answer cleanly.

In Blog 1 Identity Entropy, we established that identity entropy is structural. Environments change constantly. Governance rarely keeps up. Dormant accounts are one of the clearest signals of that gap — and one of the easiest to ignore.

Every tenant older than a couple of years has them. Former employees are still present. Contractors who left months ago. Old project accounts. Migration leftovers. Everyone knows they exist. Almost nobody treats them as a governance problem - That’s the mistake.

What a dormant account actually represents

A dormant account is not simply someone who has not logged in recently. Operationally, it is an identity object that still exists in the tenant, still holds assigned permissions and potential group memberships, may still have an active mailbox and SharePoint access, and in some cases is still carrying a paid license. Most importantly, it often has no clear owner — no one responsible for validating whether it still needs to exist or what it should still be able to access.

That last point is the one that matters most. If no one is responsible for a given identity, it is an unmanaged space inside your control system. High-performing organisations do not tolerate unmanaged space in financial reporting, production systems, or contractual obligations. The same discipline should apply to digital identity — but in most SMEs, it does not.

 

Why dormancy accumulates


Dormant accounts are not the result of negligence. They are the result of how systems are set up. Each step may make sense in isolation. Together, they create drift.

If offboarding works 90% of the time, the remaining 10% doesn’t disappear. It stacks. Over time, that becomes dozens of accounts that nobody is actively thinking about — but that still exist in your environment.

 

The illusion of harmlessness

Dormant accounts feel harmless because nothing has happened yet. They are disabled. Nobody logs in. No incidents are linked to them. So they stay.

But they still exist with an access footprint — group memberships, permissions, data exposure. Until those are explicitly removed, they remain part of your environment. The issue is not whether a single dormant account is dangerous. It’s whether a growing set of unmanaged identities fits with a controlled, auditable environment - It doesn’t.

Ownership is the core issue

The defining question for a CIO is deceptively simple: who owns each identity in your tenant? Not administratively — operationally. For every user account, service account, shared mailbox, and external collaborator, someone should be able to answer the following questions:

Many SMEs default to the assumption that IT owns all accounts. But operational ownership is different from technical administration. A finance system user should be validated by finance leadership, not by IT. A service account supporting a production integration should have an accountable business owner who can confirm it is still needed. An external collaborator account should have an internal sponsor who confirms whether access should continue. Without that ownership model, lifecycle control becomes informal — and informal control degrades predictably.

The compliance dimension (when it goes wrong)

Imagine a post-incident review: Access to sensitive data was used. The account hadn’t been active for months. It belonged to a former contractor. It was never fully decommissioned.

Now you are explaining:


This is where dormant accounts stop being theoretical. Swiss regulation increasingly expects organisations to demonstrate control over identity and access. Not just policies — evidence. Clear ownership. Clear lifecycle. A list of dormant accounts with no ownership is difficult to defend in that situation.

Service accounts: the forgotten category

Service accounts are where this gets worse. 

They are created to solve a problem quickly. Then they stay. Over time, their purpose becomes unclear, their owner disappears, and their access remains.

From a governance perspective, they are harder to assess than user accounts and often less visible. This is not a separate problem. It is the same lifecycle issue — just with higher risk.


This point connects directly to Blog 4, which examines privileged access governance. Many service accounts carry access levels that qualify as privileged, making their lifecycle management a security question, not just a housekeeping one.

From cleanup to lifecycle discipline

Most organisations treat dormant accounts as a cleanup problem. Something to fix before an audit. Or when the licences look too high. That approach guarantees the problem comes back. The shift is simple:

 

 Lifecycle discipline means: 

  • defined offboarding triggers
  • clear ownership per identity
  • regular review of inactive accounts
  • expiry for external access
  • ownership for service accounts

This is not more work long-term. It is less repetitive work.

A practical test

Three questions are enough:

  • Can you produce a list of all inactive accounts older than 90–180 days within minutes?
  • For each account, is there a named owner?
  • Is there a defined, recurring process for reviewing and closing them?

If the answer is unclear on any of these, governance debt is already there.

Dormant accounts are one visible expression of the broader drift described in Blog 1, Identity EntropyTheir presence is not a failure — it is the predictable outcome of organisational change without structured lifecycle governance. The question is not whether they exist in your tenant. They almost certainly do.

In Blog 3: Role Drift Led to Security Gap, we turn to a less visible but equally significant pattern: role drift and the security capability gap—the gradual decoupling of license assignments from actual job responsibilities and the resulting control misalignment.