Securing the cloud provider means protecting the underlying infrastructure, services, and platform availability. Securing customer identities means controlling authentication, authorization, credential lifecycle, and account hygiene for the data and workloads the customer uses. In a shared responsibility model, a vendor can run the service correctly while a customer still suffers a breach if stale credentials, weak MFA, or unmanaged access remain in place.
Shared responsibility splits the control plane from the customer trust boundary
In practice, the cloud provider is responsible for the platform itself, including infrastructure availability, service reliability, and the security of the managed service boundary. The customer is responsible for how their users, admins, service accounts, and applications authenticate and what they can reach. That means one side can be healthy while the other still creates an exposure path.
For readers mapping this distinction to cloud security controls, the provider side aligns with service hardening, platform resilience, and tenant isolation, while the customer side aligns with access control, authentication strength, and entitlement management. A useful way to think about it is that provider failure usually affects many tenants, whereas customer identity failure often starts as a local misconfiguration and then expands through access.
When the customer identity layer is weak, the cloud service may still be operating exactly as designed, which is why shared responsibility issues often show up as account misuse, token abuse, or overbroad permissions rather than as a platform outage. NHIMG’s Ultimate Guide to NHIs is useful here because the same governance problems apply to service accounts and API keys as well as human users.
That distinction also explains why cloud-provider assurance and identity assurance should be reviewed separately. A vendor may publish strong uptime and security commitments, but those commitments do not replace customer-side decisions about MFA, session controls, privileged access, or secret storage. If the customer identity stack fails, the breach can still be complete even when the provider did not fail operationally.
Identity failures usually create the real blast radius
The main difference is not abstract ownership, it is where compromise becomes actionable. Provider compromise usually affects the service foundation, but customer identity compromise gives an attacker a direct path to data, administrative functions, and workloads. In shared environments, that access path is often more valuable than a platform flaw because it inherits legitimate trust.
That is why identity issues often dominate cloud incidents: stolen credentials, weak MFA, stale tokens, excessive permissions, and poor offboarding can all turn ordinary access into unauthorized control. A vendor can keep the platform intact while a customer still loses data or availability because an attacker authenticated as a legitimate tenant principal.
NHIMG’s Okta Breach and JumpCloud Breach both illustrate the same practitioner lesson: downstream customer impact often comes from identity compromise, not from failure of the underlying cloud service. For cloud access design, that makes credential lifecycle and entitlement review first-class controls, not administrative detail.
One statistic from NHIMG’s Ultimate Guide to NHIs is especially relevant: 97% of NHIs carry excessive privileges. That matters in shared responsibility because excessive privilege does not need a provider failure to become exploitable, it only needs a valid identity in the wrong hands.
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 surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | Customer identities, MFA, and entitlement control are central to the tenant-side risk. |
| Recommendation — Enforce identity proofing, MFA, and access governance for all tenant principals. | ||
| CIS Controls v8 | 6 — Access Control Management | The question is fundamentally about who can access cloud resources and with what privilege. |
| 5 — Account Management | Account lifecycle and offboarding determine whether customer identities remain exploitable. | |
| Recommendation — Review and remove unused access, excessive permissions, and stale credentials regularly. Disable dormant accounts quickly and retire credentials on role change or exit. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control is the core customer-side control in the shared responsibility split. |
| A.8.5 — Secure authentication | Weak authentication is a primary failure mode for customer identity compromise. | |
| A.8.2 — Privileged access rights | Overprivileged tenant identities materially increase blast radius if compromised. | |
| Recommendation — Define and enforce access policies for tenant users, admins, and service identities. Require strong authentication for cloud access and administrative actions. Restrict privileged cloud access and review admin entitlements on a fixed cadence. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Customer-side cloud access often depends on API keys, tokens, and service credentials. |
| NHI-03 — Overprivileged Non-Human Identities | Excessive privilege is a common cause of tenant-side cloud compromise impact. | |
| Recommendation — Store and rotate cloud secrets centrally and remove hard-coded credentials. Minimize non-human identity permissions and scope them to the exact workload need. | ||
Practitioner Guidance
What to verify: Separate provider controls from customer controls in your assessment. If the provider scope is strong but the customer identity scope is weak, treat the environment as exposed even when the service itself is stable.
Decision rule: If an account, token, or service principal can reach production data or admin actions, prioritize MFA, rotation, offboarding, and privilege reduction before you investigate provider-side blame or infrastructure status.
What good looks like: The provider owns platform uptime and service integrity, while the customer can prove who has access, how that access is authenticated, when credentials expire, and which permissions are actually in use.
Common mistake: Teams often over-trust cloud certifications or service availability reports and under-invest in customer identity governance. That creates a false sense of safety because the service can be healthy while the tenant is still compromised.
Practitioner takeaway: In a shared responsibility model, the provider can secure the cloud service, but only the customer can secure the identities that decide what the service may reveal or do.
Related resources from NHI Mgmt Group
- What is the difference between shared responsibility in cloud security and provider-owned physical security?
- What is the difference between cloud provider security and customer responsibility in cloud security architecture?
- What is the difference between traditional IT ownership and shared security ownership in a cloud-first environment?
- What is the difference between managing human accounts and non-human identities?
