The employee leaves but the service account stays

A service account can remain necessary after the person who sponsored it leaves. The departure should trigger a review of its continuing purpose, accountable owner and access arrangements. Removing the employee's login does not by itself settle what happens to the application's identity; disabling that identity without understanding its dependencies may also interrupt a legitimate service.

This is a governance analysis for Canadian application owners and identity teams. It uses Canadian Cyber Centre security guidance and Microsoft's on-premises service-account documentation. It is not a deployment runbook, a certification claim or a determination of a regulated organisation's legal duties.

A service account provides an identity used by an application or service. Record what it supports and the resources it can reach. Separately identify the people who can administer the account, retrieve its credentials where applicable, change its permissions or approve its continued use.

The Canadian Cyber Centre recommends regular review of user accounts and privileges, including provider-held access, and reassignment or removal according to business needs and security requirements. It does not prescribe one universal review interval. Cyber Centre administrative privilege guidance

Apply that lifecycle thinking to the account's associated human access. A departing administrator's authority should be resolved through the organisation's leaver process. The service's continuing identity needs its own decision about purpose, permissions and accountable ownership.

Avoid keeping a former employee as the nominal owner because an automated job still succeeds. Someone must be able to explain the account's role, request a change, respond to an unexpected use and decide when it should be retired.

Microsoft describes group managed service accounts, or gMSAs, as a way for Windows to manage account passwords for supported services. Its service-account guidance recommends confirming that the service can use a managed account and documenting purpose, owner, permission scope, risk and periodic attestation. Microsoft service-account guidance Microsoft gMSA overview

Automated password management addresses a credential-management problem. The business still needs to decide whether the service is required, whether its access is appropriate and who is accountable for it. A managed password is not approval of every resource the account can reach.

Keep the product distinction precise. A gMSA is a particular Microsoft mechanism, not a generic name for every automated identity in a cloud platform. Select the appropriate technology with qualified technical staff and current vendor documentation. This article does not supply configuration commands or assume that every application supports the same mechanism.

Consider an invented Canadian distributor whose overnight inventory export uses a service account. The application sponsor leaves; the export continues. This fictional example illustrates a decision problem, not an observed incident or client result.

The successor first establishes which application uses the account, who relies on the export, which systems it accesses and who can administer it. The technical team checks the recorded permissions and dependencies. The business owner decides whether the export remains required.

Three decisions are possible: retain the account with a confirmed owner and justified scope, change the arrangement under an approved migration, or retire it through a controlled process. Continued successful execution alone is insufficient evidence for choosing among them.

If nobody can explain the account, record an ownership gap and escalate it according to the organisation's risk process. Do not invent an owner or silently accept unrestricted access to make the review appear complete.

This is an original decision aid. Store references to evidence in the review record; do not place passwords, tokens or recovery secrets in a broadly shared register.

For a retained identity, set the next attestation point and the changes that require earlier review. Include provider access where it forms part of the arrangement. Link the accountable role to the service, so another personnel change can be detected without searching for an obsolete individual name.

For a change, approve the operating change before implementation. That linked article uses UAE operating examples; the relevant general principle is to define authority and acceptance evidence. Canadian duties and platform-specific requirements still need their own assessment.

For retirement, competent staff should confirm the dependencies and plan the removal. Record the observed outcome and any retained evidence. A disabled account, a removed credential and a decommissioned application are separate states; report the state actually verified.

Fictional completed record. An inventory export runs nightly under a managed identity. Its departing sponsor also belonged to the group able to administer that identity. The service must continue, but the person's access must end through the applicable leaver process.

These are three distinct approvals or checks, not one green ownership field. The handover remains incomplete if the replacement owner accepts responsibility but the former administrator can still control the account. Conversely, removing human access does not demonstrate that the export still runs correctly.

Use evidence references rather than secrets in this record. Technical staff must determine whether credential rotation, session revocation or further checks are needed for the actual identity type and access previously held. The example supplies no universal command sequence and does not claim that changing a directory owner removes every access path. Preserve the observed outcomes and escalate anything that could not be verified.

No. Credential automation does not decide business purpose, appropriate permissions or continuing accountability.

Do not use a blanket deletion rule for an application identity. Resolve the departing person's access and review the service account through a controlled, accountable decision.

It can point to the accountable owner and supporting records. A row marked approved does not replace current permission evidence, a justified purpose or the required verification.

Canadian Cyber Centre ITSM10.094 — Effective 19 July 2022; administrative privilege guidance checked 8 October 2026.

Microsoft securing on-premises service accounts — Vendor guidance checked 8 October 2026.

Microsoft gMSA overview — Updated 1 July 2025; checked 8 October 2026.

QSE Advisory is part of the QSE Advisory brand family. Research and drafting were AI assisted. The scenario is hypothetical; implementation needs competent technical review.

This article is general information. Verify current requirements and seek qualified advice for your specific circumstances.

Spotted an issue? Contact our editorial desk.