Give Client Service Accounts an Owner Before Nobody Knows What Depends on Them

A service account is an operational identity, not a convenient extra employee account. It may run scheduled tasks, authenticate an integration, collect monitoring data or connect two business applications. The person who created it may have left years ago, and its display name may no longer describe its real use. An MSP that disables such an identity prematurely can interrupt live business work. An MSP that ignores it indefinitely may preserve excessive privilege and unowned credentials. A measured ownership review establishes identity, purpose, consumers, authority, security controls and a supported lifecycle decision.

The challenge is not solved by adding a contact name to a spreadsheet. The contact must be authorised to decide whether the service is needed, and the technical team must understand what actually depends on the identity. In smaller organisations, application owners, suppliers and outsourced engineers may share responsibility, but the boundary between them still needs to be explicit. This article provides a practical, evidence-led workflow for an existing client environment without presuming that every account is a Windows user or that every integration can use managed identities.

Start with an unambiguous technical identity

Capture the client tenant, environment, stable account or principal identifier, account type and observed configuration. A label such as svc-app, sync or automation can refer to several identities. Confirm whether the system uses a directory user, application principal, workload identity, local service identity, certificate or API credential. The supported controls differ, so a review that treats every entry as a conventional password-based user will miss important dependencies. Keep old aliases for traceability when a name changes, but use stable IDs for decisions.

Distinguish business accountability from administration

The business owner decides whether a process remains justified and what operational disruption is acceptable. The application or system owner understands technical dependencies. The MSP administrator implements approved changes and gathers evidence. One person may hold several roles, but permission to log in does not automatically grant authority to retire a business integration. Record the actual approval route, including exceptional or urgent decisions, and do not manufacture an owner merely to make the register look complete.

Map active and infrequent consumers

Inspect supported job configurations, service settings, vendor connectors, automation platforms and relevant logs. An account that has not authenticated recently might support a quarterly reconciliation or an emergency-only task. Conversely, an account with constant activity may perform an undocumented broad data export. Record confirmed consumers and unresolved suspects separately. Where tracing is incomplete, assign a specific investigation owner and observation checkpoint rather than declaring no dependencies.

Review permissions in business context

Compare actual roles and resources with the minimum authorised for the verified process. Elevated privilege may be appropriate for a narrow technical task but should not become unrestricted access without an explanation. Assess interactive sign-in, cross-tenant privileges and access to customer data where relevant. Avoid immediately removing a permission because it looks excessive; the application may require a different supported design. Prepare an approved change with impact, verification and recovery evidence.

Locate credentials without copying secret values

Identify the approved secret store, credential type, issuer, expiry model and persons permitted to rotate it. A ticket should include a secure reference rather than a password, token or private key. Shared screenshots and ordinary email are poor secret-management tools. Where no managed secret record exists, document the gap and agree a governed migration; do not place the live value into a convenient spreadsheet as a temporary fix that later becomes permanent.

Plan rotation around the actual provider

Some systems permit overlapping credentials, while others invalidate an old secret immediately. A staged cutover may require restarting workers or refreshing cached configuration. Identify each consumer, required supplier action, safe test and old-secret revocation checkpoint. Never promise rollback by re-enabling a revoked key unless the specific platform supports it. A saved secret version does not prove that the running business workflow has adopted it.

Investigate orphaned identities deliberately

When no valid owner can be established, classify the account as ownership-unverified, gather dependency evidence and seek a client decision. Neither immediate deletion nor indefinite unchecked operation is a satisfactory default. A temporary restriction may be possible but needs scope and a genuine recovery path. Preserve authorised business continuity while determining whether the identity should be assigned, redesigned or retired.

Check supplier and cross-client boundaries

Vendor-managed services can use identities owned by a different organisation, and a reseller might control a credential even when the client owns the data. Verify contractual authority before changing an external service. Never assume a multi-client integration can be disabled on behalf of one customer without affecting others. Record exact consumer and tenant boundaries, and escalate any ambiguity to the competent commercial and technical owners.

Review lifecycle triggers and named fallbacks

Supplier departure, application replacement, new hosting, staff changes and repeated authentication faults should trigger a targeted review. Define who can approve a change when the primary owner is unavailable. A fallback contact might be authorised to acknowledge an incident but not to grant additional system privileges. Keep those authority distinctions in the active runbook so a technician does not have to infer them under pressure.

Implement changes through supported controls

When authorisation is complete, identify exact account, applications, change window, expected state and validation criteria. Use named operator credentials and the approved platform workflow. If the operation times out, inspect the authoritative state before retrying. Do not bypass application controls by direct database edits or broad emergency privileges. Any separate permission, secret or account deletion deserves its own appropriate audit trail.

Verify business outcomes after the technical change

Check that relevant integrations authenticate, scheduled processes complete and intended access has the correct state. A directory screen showing disabled or a secrets store showing updated is not enough to prove every dependent service works. For monthly jobs, record verification as pending until an appropriate run occurs. Where a change unexpectedly interrupts a client, use the authorised recovery plan and document what actually happened.

Keep documentation useful for the next engineer

Record identity, purpose, business owner, technical custodian, major consumers, privilege scope, approved secrets reference, last verified state and next trigger. Restrict access appropriately. The goal is neither maximal paperwork nor a list of unowned names, but an actionable record that can guide safe incident resolution and future lifecycle decisions.

Measure what the review truly established

Separate identities with verified owners from those merely observed, and approved changes from changes actually implemented. Do not claim risk elimination because the spreadsheet has no blank cells. Examine recurring causes such as unmanaged supplier onboarding or incomplete project handover and improve those processes. Service account ownership is operational accountability tied to real dependencies, not a ceremonial name assigned to an identity.

Further reading: Microsoft managed identities guidance and OWASP Secrets Management Cheat Sheet. Provider-specific requirements and client authorisation govern implementation.