Service account replacement is now an identity security priority

At a glance

What this is: This is an analysis of replacing long-lived service-account secrets with workload identity, sender-constrained tokens, and OIDC federation, with the key finding that secret-based machine identity is structurally brittle.

Why it matters: It matters because IAM, PAM, and NHI teams cannot govern what they cannot reliably inventory, rotate, or revoke, and the same patterns also reshape how autonomous and human programmes think about trust boundaries.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Scramble ID's analysis of service account replacement and NHI breach prevention

Context

Long-lived service-account secrets create a machine identity problem, not just a secrets hygiene problem. When passwords, API keys, OAuth client secrets, and SSH keys sit in repositories, vaults, environment files, and developer laptops, they create an exposure surface that outlives the workload they were meant to protect.

The article argues that the correct response is to replace shared secrets with workload identity inside cloud platforms, sender-constrained tokens across boundaries, and OIDC federation in CI/CD. That is a governance shift for NHI programmes, because the control point moves from storing and rotating secrets to issuing and attesting identity at runtime.

Key questions

Q: What breaks when service accounts still depend on long-lived secrets?

A: The failure is replayability. A copied secret can be used from anywhere, often for months or years, because it is not tied to a workload or session. That creates persistent blast radius, weakens revocation, and makes incident response depend on finding every place the credential was copied instead of removing the trust primitive itself.

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. Those paths have the largest blast radius and the highest replay value. Rotation still has a place for legacy exceptions, but it should not be the main programme when the platform can issue short-lived identity instead.

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. If the programme still depends on manual rotations or exception handling for most workflows, the architecture has not changed enough.

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.

Technical breakdown

Why long-lived service-account secrets fail at scale

A service-account secret is a bearer credential, which means possession is enough to use it. Once copied, it is not tied to a specific device, session, or network path, so the blast radius is defined only by how long the credential remains valid. That makes inventory, rotation, and revocation necessary but insufficient. In mature environments, the problem is not one stolen key. It is the structural accumulation of thousands of credentials across cloud, CI/CD, partner integrations, and legacy systems, any one of which can become the compromise path.

Practical implication: classify every machine identity by exposure and lifetime before deciding which secrets can be retired first.

How workload identity replaces shared secrets in cloud platforms

Cloud-native workload identity lets the runtime prove who it is to the IAM layer and receive a short-lived credential in return. AWS IRSA, GCP Workload Identity, Azure Managed Identity, and SPIFFE/SPIRE all follow that model in different implementations. The key change is that the workload no longer carries a reusable credential in source control or a vault. Instead, the platform issues time-bounded access based on attested runtime identity, which sharply reduces replay value if something is discovered later.

Practical implication: move in-cloud workloads to native workload identity before spending effort on another rotation campaign.

Why sender-constrained tokens and OIDC federation matter for CI/CD and cross-boundary paths

Not every integration can be rewritten as pure workload identity, so cross-boundary service-to-service calls need proof-of-possession controls and CI/CD needs federated issuance. Sender-constrained tokens bind access to mTLS or DPoP material, while OIDC federation lets pipelines request credentials only at job execution. That closes the gap where a leaked token or pipeline secret can be replayed from elsewhere. It also narrows the trust window to the moment of action, which is the right model for ephemeral automation paths.

Practical implication: reserve shared secrets for exceptions and move pipelines and partner links onto federated, proof-bound credentials.

Threat narrative

Attacker objective: The attacker wants durable machine-level access that can be reused across systems, not just a one-time foothold.

1. Entry occurs when a long-lived service-account secret is exposed in code, CI/CD configuration, a vault export, or an environment file.
2. Escalation follows when the same bearer credential is replayed from outside the original runtime because it is not bound to a workload, device, or session.
3. Impact is sustained access to cloud APIs, admin functions, data stores, or production workflows until the secret is revoked or expires.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Credential replay is the real failure mode, not just secret exposure. A leaked machine secret remains valid long after detection in many environments, which means the breach surface persists even when the original leak is found. That is why detection without revocation discipline produces false confidence. Practitioners should treat replayable bearer credentials as a design defect, not an operational inconvenience.

Secret rotation is an exception control, not the operating model. Rotation reduces exposure windows, but it does not remove the structural problem that the same secret can exist in many places at once. Cloud-native workload identity, federated issuance, and proof-bound tokens are the controls that change the identity model itself. The practitioner takeaway is to redesign the path that creates the secret, not to optimise the leak window.

Service-account governance now overlaps with CI/CD, cloud IAM, and NHI lifecycle controls. The article shows that the highest-risk paths are production admin, cross-boundary integrations, and pipelines with write or admin scope. That means ownership, attestation, and decommissioning must be enforced at registration, not discovered after incident response. The implication is that lifecycle governance is now a machine-identity control plane, not a back-office process.

Identity blast radius should become the primary prioritisation metric. The article’s migration sequence is correct because it starts with the credentials that can do the most damage if abused. That is a more useful lens than counting total secrets, because one production admin credential can outweigh hundreds of low-impact tokens. Practitioners should rank replacement work by blast radius, not by where the secret is easiest to find.

From our research:

• 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.
• For the control-side response, see Guide to the Secret Sprawl Challenge for lifecycle and remediation patterns that move secrets out of the default path.

What this signals

Identity blast radius: the more a machine credential can do, the more urgently it should be removed from bearer-secret dependence. Teams that still classify service accounts by system name rather than by reachable privilege are managing inventory, not risk.

As workload identity and federated issuance become the default for cloud and CI/CD, the remaining exceptions will be the real governance test. That means platform teams need attestation, ownership, and decommissioning workflows that work across cloud IAM, pipelines, and legacy integrations.

The broader signal is that NHI programmes are converging with IAM and PAM governance. If a credential can be replayed from anywhere, then lifecycle control, proof of possession, and rapid revocation become the core operating model, not add-on hygiene.

For practitioners

• Inventory machine identities across every control plane Build a living list from Vault, cloud IAM, CI/CD runners, environment variables, and source control. Tag each identity by owner, environment, privilege level, and last-used date so you can separate active production risk from dormant clutter.
• 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. Use the legacy secret only as a temporary bridge, then remove it from source, vault, and environment.
• Bind cross-boundary credentials to proof of possession Use mTLS or DPoP so a stolen token cannot be replayed on its own. Pair that with short token lifetimes and resource-server validation that rejects credentials missing the matching certificate or key material.
• Federate CI/CD identity at job execution Move GitHub Actions, GitLab CI, and similar pipelines away from stored cloud admin keys. Issue credentials only when the job starts, scope them to the repository or workflow, and revoke the old key after each migration wave.
• Treat the vault as an exception store Keep the vault for the cases that truly cannot yet use modern auth, such as legacy systems and certain third-party integrations. Everything else should be measured against the target of removing persistent secrets from the default path.

Key takeaways

• Long-lived service-account secrets are a structural identity weakness because they are replayable, difficult to inventory, and slow to retire.
• The scale of secret exposure is already large enough that detection alone does not solve the problem, especially when valid leaked secrets remain usable.
• The practical response is architectural replacement: workload identity, proof-bound tokens, and federated issuance with ownership and decommissioning built in.

Key terms

• Workload Identity: Workload identity is a way for a service or application to prove who it is without carrying a reusable secret. The platform or identity provider issues a short-lived credential after runtime attestation, which reduces replay risk and removes persistent secrets from the default path.
• Sender-Constrained Token: A sender-constrained token is an access token that only works when presented with the proof material it was bound to at issuance, such as a certificate or key. This prevents a stolen token from being reused independently and is central to high-assurance machine-to-machine authentication.
• OIDC Federation: OIDC federation is a trust model where one system, such as a CI/CD provider, exchanges its own assertion for short-lived credentials in another system. It lets pipelines authenticate at job execution time instead of storing long-lived cloud secrets, which reduces exposure and simplifies revocation.
• Identity Blast Radius: Identity blast radius is the amount of damage a credential can do if it is misused or leaked. In NHI governance, it is a better prioritisation lens than count alone because it captures privilege scope, reach across systems, and whether the credential can be replayed from anywhere.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Scramble ID: Service Account Replacement. Read the original.