The service account hygiene playbook

Service accounts are the unglamorous backbone of every enterprise estate — and the long tail that consumes most of the cleanup effort in any privileged-access program. They authenticate applications, run scheduled jobs, drive integrations, and connect legacy systems. They also outlive the engineers who created them, accrete excessive permissions over years, and almost never get reviewed.

This piece covers the playbook we use on engagements where service-account hygiene is the keystone problem. The pattern is platform-independent — the controls land the same on CyberArk, BeyondTrust, Vault, and on the cloud-native equivalents.

The four-phase pattern

Phase 1 — Discovery (weeks 1-4)

You cannot manage what you cannot enumerate. Most enterprises have an order-of-magnitude undercount of their service accounts. The discovery phase produces a single authoritative inventory:

• Active Directory service-account groups and individual accounts
• Database service accounts (Oracle, MS SQL, MySQL, PostgreSQL — each has its own model)
• Cloud IAM service accounts (AWS IAM users, GCP service accounts, Azure managed identities)
• API keys and tokens issued to service principals
• Shared mailbox identities used as integration accounts (yes, this is still common)

The output is a single registry. We typically find 3-5x the count of service accounts the customer estimated.

Phase 2 — Triage (weeks 5-8)

The registry is too long to address all at once. We triage by three dimensions:

• Privilege: Domain admin and equivalent first; high-privilege application accounts second; long-tail accounts last.
• Visibility: Accounts with explicit ownership are easier to address than accounts where ownership is unclear. We address the unclear ones first because they are typically the most stale.
• Reach: An account that authenticates to 50 systems is a higher priority than one that authenticates to a single legacy app.

The output is a prioritized work list with named owners.

Phase 3 — Vaulting + rotation (weeks 9-16)

For accounts that should remain as service accounts (not all of them should — see Phase 4), the next step is bringing them into a vault with rotation enabled:

• Credentials moved from configuration files, secrets managers, and engineer-memorized passwords into the vault
• Rotation cadence engineered — typically 90 days for human-administered accounts, 60 days for application-administered, dynamically per-session for the highest-stakes ones
• Application access pattern updated so the application retrieves the credential from the vault at runtime — never holds it long-term

For organizations with mature PAM platforms (CyberArk Privilege Cloud, BeyondTrust Password Safe, Delinea Secret Server), this phase is execution against a known pattern. For organizations starting from scratch, we deploy the platform alongside the vaulting work.

Phase 4 — Replace with dynamic secrets where possible (weeks 17-24+)

For new applications and any application that can be updated, the right pattern is not vaulting a long-lived service account — it is eliminating the long-lived credential entirely.

Dynamic-secret patterns:

• HashiCorp Vault dynamic database credentials (Vault generates a short-lived database user per session)
• AWS IAM Roles Anywhere for on-prem applications (X.509 certificate identity, short-lived AWS credentials per session)
• Workload identity federation (AWS IRSA, GCP workload identity, Azure managed identities) — eliminates the long-lived credential entirely
• OIDC federation between CI / CD systems and cloud platforms — short-lived tokens per pipeline run

For each application that can adopt dynamic secrets, the long-lived service account goes away entirely. This is the strategic direction for any engineering organization with a real cloud-native posture.

The four anti-patterns to call out

We see the same four anti-patterns on almost every engagement:

1. The service account that runs as domain admin. "It's just easier" is the explanation. The fix is hard — the application has to be updated to run with scoped permissions, sometimes requiring engineering work the customer has been deferring for years. We engage on this when leadership is willing to back the engineering investment.

2. The credential checked into the repository. Discovered via gitleaks-equivalent tooling and grep. The credential needs to be rotated and the repository history typically needs to be expunged. The audit-evidence implication is real — the credential should be considered compromised from the date it was committed.

3. The "temporary" service account that has lived for five years. Created during a project, never decommissioned. Discovery surfaces these; the fix is rotation followed by close observation followed by retirement.

4. The shared service account used by multiple applications. "It worked" is the explanation. The audit-trail implication is fatal — it is impossible to attribute actions to a specific application. The fix is per-application service accounts with the credential vaulted.

The operating model after cleanup

The post-cleanup operating model has three properties:

1. Every service account has a named owner, with quarterly attestation.
2. Every credential lives in the vault, with rotation cadence engineered.
3. New applications default to dynamic secrets, with long-lived service accounts requiring an exception.

Reaching that state is the work of two to three quarters for most enterprises. Maintaining it is a discipline — the next-generation engineers will create the next-generation of stale service accounts unless the operating model holds.

The bottom line

Service-account hygiene is unglamorous, expensive, and necessary. The discovery is harder than expected; the cleanup is more political than technical; the operating model after cleanup has to be defended every quarter. The fix is a sustained program — not a one-quarter cleanup project.