The cloud provider is responsible for the underlying infrastructure, but the customer remains responsible for workload identities, permissions, runtime behaviour, and exposure. That division matters because the most common workload risks arise from customer-controlled identity and configuration decisions, not from the provider’s managed layer.
What cloud responsibility actually means when workload security fails
Cloud responsibility is split by control plane, not by who owns the incident headline. The provider secures the underlying infrastructure, while the customer secures the workload itself, including identities, permissions, configurations, secrets, and runtime decisions. That is why many failures are not “cloud provider breaches” at all, but customer-side control failures inside the shared-responsibility boundary.
The practical test is simple: if the control is about the service fabric, the provider usually owns it; if the control determines who can act, what can be reached, or what the workload can do at runtime, the customer usually owns it. Workload security breaks most often in the latter category, because mis-scoped access and exposed credentials create direct paths to compromise.
Which workload controls usually stay with the customer?
Customer responsibility usually covers the workload identity layer, authorization model, secret handling, and exposure of the application or service. That includes service accounts, managed identities, federation, API credentials, role assignments, network exposure choices, and runtime entitlements. The point is not that the provider is uninvolved, but that the customer decides the trust relationships that determine blast radius.
This is easiest to see in modern workload identity designs. A workload that authenticates through short-lived federation, rather than long-lived static keys, shifts risk from secret theft toward trust policy quality and permission scoping. Guidance such as the SPIFFE workload identity specification, Cloud Workload Identity Guide, and NHI Authentication Guide all point to the same operational reality: workload security depends on how identity is issued, trusted, and constrained.
It also means customer-controlled access paths remain in scope even when the provider offers strong infrastructure isolation. For example, a workload can still be overprivileged, reuse credentials across environments, or expose data through an unnecessarily open interface. The provider may keep the platform reliable, but it does not determine whether the workload can be abused once access is granted.
Why customer-side mistakes dominate most cloud workload failures
Most serious workload failures come from configuration and identity decisions the customer makes, not from defects in the provider’s managed layer. Common examples include excessive permissions, long-lived secrets, weak trust policies, exposed tokens, and poor offboarding of automation accounts. Those are customer decisions because they define what the workload can reach and how compromise propagates.
That is why cloud workload security is closely tied to least privilege and short-lived authentication. If a workload can authenticate with durable secrets or broad roles, compromise tends to become persistent rather than local. The exposure is often visible only after misuse begins, which is why identity-centric controls matter as much as infrastructure controls in the cloud.
For Kubernetes and service-to-service environments, the same pattern shows up in pod identities, service account tokens, and east-west access. Kubernetes NHI Security Guide, Service Account Security Guide, and Ultimate Guide to NHIs, Key Challenges and Risks are useful references because they show how identity sprawl, overprivilege, and unmanaged credentials become customer-owned failure points in cloud environments.
Risk and Threat Considerations
Cloud workload failures are dangerous because the attack path often starts with customer-managed identity or configuration, then expands into privilege abuse, lateral movement, or data exposure. A provider outage is visible immediately, but a mis-scoped workload identity can stay hidden until an attacker uses it to act as the workload itself.
Failure mechanism: A workload receives more authority than it needs, or a durable secret is exposed, and the attacker inherits that trust relationship rather than breaking the cloud platform itself.
Impact: The result can be unauthorized API calls, data access, cross-environment movement, or service disruption that looks operational but is actually an access-control failure.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Organizational Users) | Cloud workloads authenticate as services, not people, so this governs workload identity trust. |
| AC-6 — Least Privilege | Workload failures often stem from permissions that exceed the workload’s operational need. | |
| IA-5 — Authenticator Management | Static keys and long-lived tokens are a common customer-owned failure point in cloud workloads. | |
| Recommendation — Apply IA-9 to authenticate workload identities with short-lived, verifiable credentials. Limit workload permissions to the minimum set required for each runtime action. Manage workload authenticators with rotation, expiry, and revocation controls. | ||
| NIST Zero Trust (SP 800-207) | ZT.NA — Never trust, always verify | Cloud workload access should be continuously verified rather than assumed from network location. |
| Recommendation — Require explicit verification for each workload access request and dependency. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Workload identities in cloud fail often because they are granted more access than needed. |
| NHI-07 — Long-Lived Secrets | Static cloud workload secrets extend compromise windows and make misuse harder to contain. | |
| NHI-02 — Secret Leakage | Cloud workload compromise commonly begins with exposed API keys, tokens, or certificates. | |
| Recommendation — Reduce workload permissions to the smallest role set that still supports the task. Replace long-lived workload secrets with short-lived, federated credentials. Detect and revoke exposed workload secrets before they can be reused. | ||
| CIS Controls v8 | CIS-5 — Account Management | Workload accounts and service identities need explicit lifecycle ownership and review. |
| Recommendation — Inventory workload accounts and review their access on a recurring schedule. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity management, authentication, and access enforcement | Cloud workload security depends on enforcing authenticated access and access decisions. |
| GV.SC-01 — Supply Chain Risk Management Strategy | Cloud responsibility depends on knowing which provider controls are inherited versus customer-owned. | |
| Recommendation — Enforce authenticated workload access and authorization for every protected resource. Document provider and customer control boundaries in the cloud risk strategy. | ||
Practitioner Guidance
What to prioritise: Start with the controls that define workload authority, not the controls that only harden the hosting layer. If the workload can reach production data or deploy infrastructure, treat its identity, secrets, and permissions as the first-order risk.
What to verify: Confirm who owns each workload identity, what it can access, whether the credential is short-lived, and whether the trust path is explicit and revocable. If you cannot show that chain clearly, the workload is not well governed.
Common mistake: Teams often assume the cloud provider “secures the workload” because the service is managed. In practice, managed infrastructure reduces platform burden, but it does not remove customer responsibility for the workload’s access model.
Practitioner takeaway: When a cloud workload fails, the right question is usually not “who owns the cloud?”, but “who granted the workload its authority, and was that authority still appropriate at the moment of failure?”
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities in cloud environments?
- Why is single-provider AI agent governance not enough for enterprise security?
- How should security teams design resilience when a cloud provider's control plane fails?