Notifications
Clear all
Topic starter
06/06/2026 2:04 am
TL;DR: Service accounts remain difficult to inventory, rotate, and govern because they are often created in a distributed way, used widely across applications, and left with long-lived credentials that outlive operational need, according to Oasis Security. The governance problem is not the account type itself but the lack of lifecycle visibility, ownership, and enforcement across legacy and cloud environments.
NHIMG editorial — based on content published by Oasis Security: What are Service Accounts and How Should You Secure Them?
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: What breaks when service accounts are not centrally governed?
A: When service accounts are created and maintained outside a central identity process, ownership, purpose, and retirement become unclear.
Q: Why do service accounts increase risk in cloud and legacy environments?
A: Service accounts increase risk because they often carry broad privileges, are embedded in applications, and are hard to rotate without breaking dependencies.
Q: How do security teams know if service account governance is actually working?
A: Governance is working when every service account has an owner, a workload, a retirement condition, and an auditable rotation path.
Practitioner guidance
- Build a service account inventory from live dependencies Identify every service account by querying applications, scripts, schedulers, and cloud workloads, then reconcile those findings against directory records and PAM vaults.
- Map credential rotation impact before changing secrets Document which systems consume each password or token, then test rotation in a controlled sequence so production jobs do not fail during credential updates.
- Tie each service account to a named owner and workload Require an accountable business or technical owner, the workload it supports, and the retirement condition that should trigger offboarding.
What's in the full article
Oasis Security's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step service account lifecycle workflows from creation to decommissioning.
- Contextual mapping examples showing how permissions, usage, and dependencies are assessed together.
- Operational detail on automated posture assessment for secret rotation, access permissions, and policy enforcement.
- Examples of how service account governance is applied across legacy AD, cloud, SaaS, and database environments.
👉 Read Oasis Security's analysis of service account governance and lifecycle controls →
Service account governance gap teams are still missing?
Explore further
06/06/2026 3:32 am
Distributed service account ownership is a governance failure, not an administrative inconvenience. When service accounts are created directly by developers or embedded into application stacks, the identity record and the operational reality diverge. That divergence is why many organisations cannot answer basic ownership questions or confirm whether an account still serves a live workload. The practical conclusion is that service account governance must be treated as a system of record problem, not a cleanup task.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
A question worth separating out:
Q: Should organisations treat service accounts as part of PAM or IGA first?
A: They should treat service accounts as both, because the identity lifecycle problem and the privilege problem are inseparable. IGA helps establish ownership, lifecycle, and review, while PAM helps constrain high-risk access and reduce standing privilege. In practice, the programme needs both control planes to keep machine identities from becoming unmanaged privileged assets.
👉 Read our full editorial: Service account governance is still broken by fragmented ownership
