> ## Content Index
> Fetch the complete content index at: https://www.raedu.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# Inactive Microsoft 365 Accounts Need Ownership, Not Just Automation
- URL: https://www.raedu.co.uk/governing-inactive-microsoft-365-accounts/
- Published: 2026-10-02T12:33:42.000Z
- Updated: 2026-10-02T12:33:42.000Z
- Description: A practical approach to inactive Microsoft 365 accounts: clear ownership, reliable evidence, human approval and cautious automation from disablement through deletion.
- Author: Daniel Shire
- Tags: Microsoft 365, Microsoft Entra, Identity Governance, Security

Inactive Microsoft 365 accounts look like a technical housekeeping problem, but I treat them as an ownership problem first. A report can tell me that an account has not signed in recently. It cannot tell me whether the person is on long-term leave, whether a contractor is expected back, whether the account supports an application, or whether the business still needs access to its data.

Processes have to be kept practical. Removing an account too quickly can disrupt work. Leaving it enabled indefinitely creates uncertainty, wastes licences and makes support harder, not to mention any security or compliance implications. The answer is a controlled access management lifecycle with named owners, evidence and deliberate approval points.

## Inactivity is a signal, not a decision

I use inactivity to start a review, not to authorise deletion. Last successful sign-in information is useful evidence, but it is only one piece of evidence. Some legitimate accounts are used infrequently. Some users work through services that do not produce the activity pattern an administrator expects. A dormant account may also reflect a wider problem, such as an incorrect joiner, mover or leaver record.

Before changing an account, I want to understand:

- who or what the account represents;
- who is responsible for confirming its current purpose;
- whether HR records show an employment or leave status that explains the inactivity;
- whether a manager expects the user to return or still requires the account;
- which licences, groups, Teams, mailboxes, applications and devices depend on it; and
- whether retention, legal or operational requirements apply to its data.

This prevents a clean-up exercise from becoming an avoidable service incident. It also makes the outcome easier to explain later.

## Give each decision a clear owner

IT can provide the evidence and carry out the technical action, but it should not invent the employment decision. HR should confirm a person's status. The line manager should confirm the business need, handover requirements and likely return. The application or service owner should answer for non-human accounts. Where those answers conflict, the account should remain in review rather than moving automatically towards deletion.

> Automation should move evidence and approved actions through the process. It should not decide whether a person or service still matters to the business.

I would document a small number of accountable roles rather than create a committee. Someone raises or receives the inactivity case, someone confirms status, someone approves the next action, and an administrator executes or oversees it. If nobody will own an account, that is itself a governance finding which needs resolving.

## Separate people from service and shared accounts

A single inactivity rule should never cover every object in the directory. Human user accounts, service accounts, shared mailboxes, emergency access identities and test accounts have different purposes and risk profiles. A service identity may have no interactive sign-in by design. A shared mailbox may remain important even when its original owner has left. Emergency access accounts need their own monitoring and testing regime.

I prefer explicit classification and ownership. Non-human accounts should have a recorded purpose, a responsible owner, an expected usage pattern and a review date. If the purpose cannot be established, I investigate it rather than assuming that no recent sign-in means it is safe to remove. Exclusions from an automated workflow should also be visible and reviewed; an exclusion must not become permanent immunity from governance.

## Use a disable-before-delete lifecycle

My operational preference is reversible action before irreversible action. The exact waiting periods should follow the organisation's policy, contractual obligations and retention requirements, not an arbitrary number copied from another tenant.

1. **Detect and triage.** Identify accounts that meet the agreed inactivity condition, then check account type, ownership and known exceptions.
2. **Gather confirmation.** Ask HR, the manager or the service owner to confirm status and required access. Record the response, including a reason for keeping an account active.
3. **Approve the action.** Require a named human approver before disabling access. High-impact or unusual cases should receive additional scrutiny.
4. **Disable and observe.** Block sign-in first, preserve the account and monitor for a defined recovery window. This gives IT a safer route back if the evidence was incomplete.
5. **Protect data and dependencies.** Complete mailbox, OneDrive, group, application, device and ownership actions according to policy before removing the identity.
6. **Recover licences deliberately.** Remove licences when the dependent data and services have been considered. Licence recovery is valuable, but it should follow the lifecycle decision rather than drive it.
7. **Delete only after final approval.** Confirm that the recovery period has passed, required records are retained and no unresolved dependency remains.

This sequence reduces the chance that tidying the directory causes a user-facing problem. It also creates clear points where a case can pause, be corrected or be reversed.

## Keep an audit trail that answers sensible questions

For each reviewed account, I want a record of the evidence used, the rule that identified it, its classification, the people consulted, the approval given, each action taken and any exception or expiry date. I also want the administrator or workflow identity recorded. A future reviewer should be able to understand why the account was disabled, why a licence was removed and why deletion was eventually authorised.

The audit trail supports more than compliance. It helps the service desk respond accurately if somebody returns, a manager queries missing access or an application stops working. Good identity governance and good user experience are connected: both depend on predictable decisions and usable records.

### Controls I would expect before expanding automation

- separate scopes for human and non-human identities;
- named business owners and escalation routes;
- tested exclusions for service, shared and emergency access accounts;
- human approval before disablement and deletion;
- a recovery window between those actions;
- clear handling for licences, data and group ownership;
- workflow logs reviewed alongside the service desk process; and
- regular sampling to find false positives and stale exceptions.

The aim is not to automate the maximum number of clicks. It is to make the right action consistent, evidenced and recoverable. Once ownership and policy are clear, automation can remove delay and repetition. Without them, it simply makes an uncertain decision happen faster.