A cloud identity is any account, role, token, or credential used to access cloud services and resources. In practice, it includes both human and non-human identities that can authorize actions in infrastructure, applications, or automation pipelines. Governance depends on knowing which identity type is active and what it can do.
Expanded Definition
Cloud identity is the runtime identity used to authenticate and authorize access in cloud environments, including IAM users, roles, service principals, workload identities, API keys, certificates, and tokens. In NHI security, the term matters because cloud access is often granted to both people and software, and the two must be governed differently. Definitions vary across vendors, but the operational question is consistent: what identity is acting, what trust it has, and what it can change. That is why cloud identity governance sits alongside federation, lifecycle control, and privilege management, not just login security. For a broader NHI model, see the Ultimate Guide to NHIs and the identity assurance guidance in NIST Cybersecurity Framework 2.0.
The most common misapplication is treating cloud identity as synonymous with a human user account, which occurs when service accounts, workload credentials, and delegated roles are left outside the IAM review process.
Examples and Use Cases
Implementing cloud identity rigorously often introduces operational friction, because tighter controls can slow automation and require more ownership discipline across platform, security, and engineering teams.
- An application in AWS assumes a role to read from storage and publish events. The role should be treated as a cloud identity with scoped permissions, expiration logic, and monitoring, not as a reusable credential left in code.
- A CI/CD pipeline uses a token to deploy infrastructure. When that token is over-privileged, it becomes a high-value NHI and should be governed with the same discipline discussed in the Top 10 NHI Issues.
- A federated workforce signs into a cloud console through an identity provider, then assumes a temporary admin role. This is where cloud identity overlaps with NIST Cybersecurity Framework 2.0 access control outcomes and auditability requirements.
- An AI agent receives tool access to provision resources or query secrets. That agent is an identity with execution authority, which should be governed like any other privileged workload identity, as shown in NHIMG coverage of the 52 NHI Breaches Analysis.
- A third-party integration uses an API key to call cloud services. The key needs rotation, ownership, and revocation controls, especially when cloud identity spans external supply chain access.
Why It Matters in NHI Security
Cloud identity is where privilege becomes real. If teams cannot inventory which identities exist, which are human, and which are machine-driven, they cannot enforce least privilege, rotation, or offboarding. In practice, the risk often appears through static credentials, stale roles, and delegated access that outlives the workload that created it. That is why cloud identity is a core NHI control surface in Ultimate Guide to NHIs — What are Non-Human Identities and a recurring factor in incidents such as the Cisco DevHub NHI breach. NHI Mgmt Group research also shows that only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, which underscores how quickly cloud identity can outgrow manual oversight. The same pattern shows up in broader secret management failures, where credentials drift into code, pipelines, and shared services.
Organisations typically encounter cloud identity risk only after a token is abused, a role is escalated, or an automated system makes an unexpected change, at which point cloud identity becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Cloud identities are the non-human access surface OWASP NHI expects teams to inventory and govern. |
| NIST CSF 2.0 | PR.AC-4 | Cloud identity maps to access management, least privilege, and entitlement review under CSF. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust requires continuous verification of every cloud identity, human or machine. |
Restrict cloud identity permissions, review access routinely, and remove standing privilege where possible.
Related resources from NHI Mgmt Group
- How should security teams unify identity across cloud and data center environments?
- How should security teams balance agility with identity control in cloud and AI environments?
- Why does identity strategy matter more as organisations scale cloud and AI adoption?
- How should regulated teams evaluate cloud-private identity governance platforms?
