Service Account Hygiene at Scale
Service accounts are the silent risk in every IAM topology. They never quit; they never forget; they accumulate.
Why service accounts rot
Service accounts get created with broad permissions for ‘just to ship the feature.’ The permissions stay long after the feature ships, the engineer leaves, and the account is forgotten.
At 50+ engineers, untracked service accounts outnumber tracked ones within a year.
Four hygiene patterns
- 1. Workload identity over keys. AWS IAM Roles for EKS, GCP Workload Identity, Azure Managed Identities.
- 2. Time-bound credentials. Default expiry on tokens; renewal requires owner action.
- 3. Tag-based ownership. Every account tagged with owner, purpose, expiry.
- 4. Auto-disable on dormancy. Inactive 90+ days → disable; dispute resolution.
Tool-assisted audits
IAM Access Analyzer, GCP Recommender, Azure Identity Governance, all surface unused permissions.
Quarterly: run the report; remove or downscope what is not used.
Owner-of-record discipline
Every service account has a documented owner team. No owner = candidate for archive.
Catalog (Backstage, internal wiki) is the source of truth; without it, accounts orphan within a quarter.
Antipatterns
- Long-lived static keys. Use workload identity instead.
- Wildcard permissions for service accounts. Always tightenable.
- No quarterly review. Drift wins.
What to do this week
Three moves. (1) Pick one production system to apply this pattern to first. (2) Measure the security signal before/after. (3) Document the gap and write a follow-up ticket so the program stays alive between quarterly reviews.