Notifications
Clear all
Topic starter
25/06/2026 1:04 am
TL;DR: Service accounts often persist after ownership changes, carry long-lived secrets, and accumulate standing access that attackers can exploit, according to Defakto Security. The governance failure is not hygiene alone, but using human lifecycle controls for machine identities that change faster than directories can manage.
NHIMG editorial — based on content published by Defakto Security: Identity Service Accounts Were a Shortcut. Now They’re a Liability. It’s time to go Accountless
Questions worth separating out
Q: What breaks when service accounts are managed like human identities?
A: Lifecycle drift becomes the main failure mode.
Q: Why do service accounts with standing privilege increase lateral movement risk?
A: Because a stolen secret is not just an authentication token, it is a ready-made access path.
Q: How do teams know if machine identity governance is actually working?
A: Look for evidence that each service account has a current owner, a narrow purpose, a short credential lifetime, and a clear retirement path.
Practitioner guidance
- Separate workload lifecycle from human lifecycle Map service accounts, their owners, and their runtime dependencies separately from employee joiner-mover-leaver processes.
- Inventory standing privilege on every service account Identify accounts that retain broad permissions even when they are rarely used.
- Rotate or eliminate long-lived secrets Replace persistent credentials with short-lived, workload-bound authentication wherever possible.
What's in the full article
Defakto Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Specific examples of how service accounts persist after ownership changes and decommissioning events.
- The mechanics of accountless, attestable identities and how runtime proof replaces stored secrets.
- Practical considerations for moving workloads away from directory-centric identity patterns.
- The article's own examples of high-profile cloud breaches involving forgotten service accounts.
👉 Read Defakto Security's analysis of why service accounts are becoming a liability →
Service accounts and accountless identity: what IAM teams need to know?
Explore further
25/06/2026 10:14 am
Human lifecycle controls were never designed for machine identities. Service accounts persist because the governance model assumes onboarding, job change, and termination events, but workloads do not follow those rhythms. Their context changes through deployment, reconfiguration, and retirement, which means ownership and access drift long before a human-style review catches it. The practitioner conclusion is straightforward: if the lifecycle model is wrong, the access model will drift too.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Nearly 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to the same report.
A question worth separating out:
Q: Who is accountable when an orphaned service account is abused?
A: Accountability should sit with the business or engineering owner of the workload, not only the directory team. If no one can explain why the account still exists, who depends on it, and when it will be retired, the governance model has already failed before the incident occurs.
👉 Read our full editorial: Service accounts are becoming a liability for NHI governance
