Notifications
Clear all
Topic starter
22/06/2026 4:56 pm
TL;DR: Long-lived service-account passwords, API keys, OAuth client secrets, and SSH keys remain the dominant cause of non-human identity breaches because they leak, persist for years, and can be replayed from anywhere, according to Scramble ID. The real fix is architectural replacement, not faster rotation: workload identity, sender-constrained tokens, and OIDC federation remove the standing secret that current controls assume will still exist.
NHIMG editorial — based on content published by Scramble ID: Service Account Replacement
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: What breaks when service accounts still depend on long-lived secrets?
A: The failure is replayability.
Q: When should organisations prioritise workload identity over another rotation effort?
A: Prioritise workload identity whenever the credential protects production workloads, CI/CD pipelines, or cross-tenant integrations.
Q: How do teams know a machine-identity migration is actually working?
A: Look for declining use of stored secrets, 100% named ownership, successful short-lived token issuance, and fewer credentials surviving in vaults, environment files, and repositories.
Practitioner guidance
- Inventory machine identities across every control plane Build a living list from Vault, cloud IAM, CI/CD runners, environment variables, and source control.
- Migrate in-cloud workloads to native workload identity Replace persistent service-account secrets with AWS IRSA, GCP Workload Identity, Azure Managed Identity, or SPIFFE/SPIRE where the runtime can attest itself.
- Bind cross-boundary credentials to proof of possession Use mTLS or DPoP so a stolen token cannot be replayed on its own.
What's in the full article
Scramble ID's full report covers the operational detail this post intentionally leaves for the source:
- A phased migration plan with week-by-week sequencing for inventory, classification, replacement, and decommissioning.
- Cloud-by-cloud implementation patterns for AWS, Google Cloud, Azure, and cross-cloud SPIFFE/SPIRE deployments.
- Concrete KPI targets for ownership coverage, token latency, replay detection, and migration progress.
- Failure cases for legacy systems and third-party integrations that still require exception handling.
👉 Read Scramble ID's analysis of service account replacement and NHI breach prevention →
Service account replacement: what IAM teams need to change now?
Explore further
22/06/2026 5:07 pm
Long-lived shared secrets are the wrong trust primitive for machine identity. They were designed for a world where access could be issued, stored, and rotated on a human-managed cadence. That assumption fails when workloads, pipelines, and integrations multiply faster than governance teams can inventory them. The implication is that service-account governance must shift from secret stewardship to runtime-issued identity.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to GitGuardian's State of Secrets Sprawl 2026.
- The same report found that 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase.
A question worth separating out:
Q: Who is accountable when a leaked service-account secret is reused in production?
A: Accountability sits with the identity owner, the platform team that allowed persistent credentials to remain in use, and the business owner that accepted the residual risk. Frameworks such as OWASP Non-Human Identity Top 10 and NIST CSF are relevant because they map the control failures to ownership, access management, and recovery.
👉 Read our full editorial: Service account replacement is now an identity security priority
