Service accounts can become some of the least visible identities in a supported environment. They may run scheduled tasks, connect applications, access shared resources or support integrations, yet their original creator may have left years ago. Disabling an unfamiliar account can break a live service; leaving every old account untouched creates a different kind of uncertainty. An MSP needs a review process that establishes purpose, ownership and dependency before any access decision is made.
Start with identity and observed purpose
Build the review from the recognised account record and the systems where it is configured or observed. A name such as “service” or “sync” is not enough evidence of purpose. Record what the account is understood to support and mark uncertain uses for investigation rather than filling the gap with an assumption.
Separate business ownership from technical administration
The MSP may administer the credential while the client owns the business process that depends on it. Record both responsibilities. That distinction matters when somebody requests a password change, permission increase or retirement: technical ability to make the change is not automatically authority to approve the operational consequence.
Map dependencies before changing anything
Identify applications, scheduled jobs, services or integrations known to use the account. Where the environment does not provide a complete dependency map, treat that limitation as part of the risk. A quiet account may still support a monthly process or an exception workflow that has not run during the review window.
Check whether the access still matches the purpose
Once the purpose is established, compare the account's current access with what that function needs under the client's approved access model. Avoid expanding the review into speculative permission redesign. If a material discrepancy is found, route it through the normal access-change and approval process.
Clarify credential custody and rotation responsibility
Document where the credential is held through the approved secret-management process, who can rotate it and which dependent systems must be updated together. Do not copy passwords or keys into tickets simply to make the review record convenient. The operational record should explain the route to the controlled secret, not reproduce it.
Handle orphaned accounts as an investigation
If nobody can identify an owner, do not immediately disable the account. Escalate the unresolved identity to the appropriate client and technical roles, gather available dependency evidence and agree the next action. Retirement may be correct, but it should be a controlled decision with a rollback or recovery path appropriate to the supported service.
Update documentation after ownership is confirmed
Record the accountable owner, technical administrator, purpose and relevant dependency context in the recognised support documentation. The value of the review is lost if the next technician still has to rediscover the same information during an incident or credential-expiry event.
Use lifecycle events to trigger another review
Application replacement, supplier change, major integration work and client organisational changes can all invalidate old ownership assumptions. This topic is distinct from security-group ownership: a group governs access membership, while a service account is an operational identity whose credential, permissions and live system dependencies must remain traceable.