Service accounts and delegated grants often have broad, persistent access that survives long after the original business purpose changes. That gives attackers a stable route to sensitive data and administrative actions once a credential or token is stolen. The risk is amplified when review cycles do not cover cloud grants and third-party consent.
Why This Matters for Security Teams
Service accounts and delegated cloud access are attractive to extortion crews because they often outlive the business task they were created for. Once a token, app consent, or API credential is exposed, attackers can quietly access mailboxes, storage, CI/CD systems, and cloud administration paths without triggering the same friction as a human login. That makes these identities a durable leverage point for data theft, sabotage, and double extortion.
The problem is not just exposure, but persistence. Many organisations still treat non-human access as an implementation detail rather than a governed identity class, even though NHIMG research shows 88.5% of organisations acknowledge their non-human IAM practices lag behind or match their human IAM maturity. The OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both reinforce the same operational reality: if standing access is broad and long-lived, it becomes an extortion asset the moment it is compromised. In practice, many security teams discover this only after an attacker has already turned a forgotten grant into a repeatable foothold rather than through intentional review.
How It Works in Practice
In extortion cases, attackers prefer identities that can be reused quietly and at scale. A service account with broad cloud permissions, or a delegated grant that can persist across application updates, gives them exactly that. Unlike a stolen user password, these credentials often bypass MFA, are less visible in access reviews, and may be embedded in automation that nobody wants to break.
Operationally, the risk rises when teams confuse ownership with control. An account may belong to a workload team, but if it can read storage, modify IAM policy, export data, or act through third-party consent, it becomes a business-wide exposure. This is why practitioners increasingly align with the NIST Cybersecurity Framework 2.0 focus on continuous governance, and why NHIMG’s Top 10 NHI Issues emphasizes inventory, ownership, and rotation discipline.
- Inventory every service account, workload identity, and delegated cloud grant.
- Map each one to a named business purpose and an accountable owner.
- Remove standing privilege where a just-in-time alternative is possible.
- Use short-lived tokens and rotate secrets aggressively, especially for automation.
- Review third-party consent and cloud app grants on a fixed cadence, not only during user offboarding.
Where this breaks down is in large hybrid environments with unmanaged legacy automation, because hidden dependencies make it hard to reduce access without interrupting production workflows.
Common Variations and Edge Cases
Tighter control often increases operational overhead, requiring organisations to balance extortion resistance against uptime and release velocity. That tradeoff is especially sharp in multi-cloud estates, vendor-managed integrations, and platform engineering pipelines where service accounts are deeply embedded.
One common edge case is delegated access created by business users through app consent. These grants can look harmless until they are chained into mailbox access, file exfiltration, or lateral movement through SaaS-to-cloud trust relationships. Another is “break glass” service accounts that were meant to be rare but gradually became routine automation credentials. Guidance here is evolving, but current best practice is to treat these as high-risk exceptions, not normal operating access.
NHIMG research on the Ultimate Guide to NHIs and the GitLocker GitHub extortion campaign shows how attackers use persistent identity paths to turn access into leverage. The defensive implication is straightforward: if the identity can read something valuable, change something critical, or impersonate an application, it should be reviewed like a privileged human account, not a background dependency. In environments with heavy third-party integration and weak consent governance, these controls tend to break down because ownership is diffuse and revocation risk is treated as higher than compromise risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Service accounts and delegated grants are non-human identities needing inventory and ownership. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Persistent credentials and tokens drive extortion risk when rotation is weak. |
| NIST CSF 2.0 | PR.AA-01 | Delegated cloud access must be authenticated and governed as a distinct identity class. |
Treat workload and delegated identities as governed assets with explicit authentication and accountability.
Related resources from NHI Mgmt Group
- Why do service accounts and secrets with standing access increase risk in cloud environments?
- Why do service accounts with persistent access increase risk in cloud environments?
- Why do service accounts increase risk in cloud and legacy environments?
- Why do mergers and acquisitions increase access risk for service accounts and privileged users?
