They often stop at the provider boundary and underinvest in the controls they still own. Customer teams are responsible for identities, configurations, logs, encryption choices, and application permissions. If those controls are broad or poorly monitored, the cloud remains exposed even when the provider’s core platform is secure.
Why Shared Responsibility Gets Misread in Cloud Security
Teams often treat shared responsibility as a clean boundary that ends at the provider’s platform, but that is only true for a narrow slice of the stack. In practice, cloud providers secure the underlying infrastructure, while customers still own identities, network exposure, data handling, application permissions, and configuration hygiene. NIST’s NIST Cybersecurity Framework 2.0 reinforces that security outcomes depend on governance and control execution, not just platform assurances.
The common mistake is assuming the provider’s certifications, shared control language, or managed-service defaults automatically cover tenant-side risk. That mindset leaves gaps in IAM, logging, key management, and workload permissions, which are exactly the areas attackers exploit after they get a foothold. NHIMG’s research on the 230M AWS environment compromise shows how quickly misconfigurations and identity weaknesses can turn a secure cloud platform into an exposed tenant environment. In practice, many teams discover shared responsibility failures only after an exposed permission, leaked secret, or overbroad role has already been abused.
What Security Teams Still Own and How It Fails in Practice
Shared responsibility becomes operational when teams map each control to the right owner, then verify that ownership with monitoring and testing. The provider may secure the hypervisor, storage service, or regional control plane, but the customer still decides who can access what, how secrets are issued, whether logs are retained, and which services can talk to each other. This is why cloud risk often persists even when the provider is technically sound.
Current guidance suggests starting with the controls that most frequently fail under tenant ownership:
- Identity and access management, including least privilege, role design, and access review cadence
- Secrets and key lifecycle, including rotation, storage, and blast-radius reduction
- Logging and alerting, especially for privileged actions and cross-account activity
- Configuration control for storage, networking, and public exposure
- Application permissions for SaaS, APIs, and automation workloads
The issue is not just missing controls, but misplaced confidence. NHIMG research in The State of Non-Human Identity Security found that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which matters because cloud workloads increasingly rely on non-human identities, service principals, and automated access paths. That concern aligns with NIST’s control-based view and with operational reality: if a workload can call an API, assume a role, or read a secret, it must be governed like any other privileged identity.
These controls tend to break down in fast-moving multi-account environments where teams reuse roles, skip logging for convenience, and let automation accumulate permissions across projects.
Where the Shared-Responsibility Model Breaks Down
Tighter cloud control ownership often increases operational overhead, requiring organisations to balance speed of delivery against the discipline needed to keep tenant-side risk contained. The hardest edge case is platform abstraction: managed databases, serverless functions, and SaaS integrations can blur the line between provider-managed and customer-managed security.
That ambiguity is why teams need written responsibility matrices, not verbal assumptions. Best practice is evolving toward explicit mapping for each service layer, with separate treatment for identity, configuration, data, and monitoring. It also helps to distinguish between provider assurance and tenant evidence. A compliant provider does not guarantee safe tenant configurations, and a secure landing zone does not stay secure if developers can bypass policy with ad hoc permissions.
Two real-world patterns deserve special attention. First, over-permissioned automation often looks efficient until it becomes the shortest path to data exposure, as seen in incidents like the Snowflake breach. Second, secret sprawl in cloud platforms can create escalation paths that the provider cannot see, including key vault abuse and role chaining, as highlighted in Azure Key Vault privilege escalation exposure. There is no universal standard for exactly how every shared control should be tested, but the operational principle is clear: if the customer can configure it, the customer must secure it.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Shared responsibility depends on knowing what the organisation owns. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Overprivileged cloud identities are a core tenant-side failure mode. |
| NIST AI RMF | AI and automation increase shared-responsibility risk through dynamic access. |
Document cloud ownership boundaries for identities, configs, logs, and data in your governance model.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
