Topic starter
01/12/2025 3:00 pm
TL;DR: Service accounts now outnumber human users by 82 to 1 in CyberArk’s 2025 Identity Security Landscape, with 42% carrying privileged access, while Aembit argues that static credentials, broad permissions and missing ownership leave them outside traditional IAM governance. Machine identity governance has become an operational control problem, not a policy problem.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “The Real Risk Behind Service Accounts (And Why Nobody’s Watching Them)”.
By the numbers:
- Service accounts now outnumber human users by 82 to 1 in CyberArk’s 2025 Identity Security Landscape.
- 42 percent of machine identities carry privileged access, according to CyberArk’s 2025 Identity Security Landscape cited by Aembit.
- Only 5.7 percent of organizations in Osterman Research’s 2023 study could accurately inventory all their service accounts, according to Aembit.
Key questions
Q: What breaks when organisations manage service accounts like human users?
A: Service accounts do not behave like people, so human IAM controls miss the real risks.
Q: Why do service accounts and automation tokens increase breach impact when they are over-privileged?
A: Because they can move data and trigger actions at machine speed without the friction that often limits human accounts.
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
- Assign a named owner to every service account Create a mandatory ownership record for each machine identity, including purpose, environment, and retirement criteria.
- Replace static secrets with short-lived identity federation Move workload authentication away from stored keys and toward identity-based access that expires when the task ends.
- Scope permissions to the actual workload, not the template Review service account entitlements against the minimum actions the workload needs today, not what a prototype copied months ago.
Bottom line: Service account sprawl is a governance problem created by human IAM assumptions being applied to machine identities that do not have managers, review cycles, or predictable lifecycles.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 10 months ago by Aembit
This topic was modified 10 months ago by Abdelrahman
This topic was modified 6 days ago by NHI Mgmt Group
06/10/2026 9:28 pm
Service account sprawl is a governance failure, not just an inventory problem: The article shows that machine identities are being created at the edge of delivery workflows while oversight remains anchored to human IAM assumptions. That means the core issue is not merely that organisations have too many service accounts. It is that the lifecycle is being managed in the wrong operating model, with no stable ownership, review, or offboarding path. Practitioners should treat this as a lifecycle architecture issue, not a cleanup exercise.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should IAM teams do when service account access is broader than the workload needs?
A: IAM teams should reduce the entitlement to the minimum runtime function the workload requires and then revalidate the dependency with the technical owner. Broad service account access usually persists because teams optimise for deployment convenience, not governance. Tightening scope reduces blast radius and makes later audit and offboarding decisions far easier.
👉 Read our full editorial: Service account sprawl is outpacing traditional IAM governance