Who is accountable when an authorised cloud identity service is misused?

The provider is accountable for the service’s authorized operating environment, but the customer remains accountable for its own configuration, access decisions, and oversight. In regulated environments, that split matters because authorization does not transfer operational responsibility for identity governance.

Why This Matters for Security Teams

When an authorised cloud identity service is misused, accountability does not disappear into the provider relationship. The provider is responsible for the service’s authorised operating environment, but the customer still owns configuration, access approvals, and ongoing oversight. That distinction is central in regulated environments because “authorised” only confirms the service boundary, not the safety of every tenant setting, role assignment, or delegated trust.

This is especially visible in identity-driven incidents where over-permissioned service accounts, exposed keys, or weak delegation controls turn a managed service into an attack path. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That is why NIST Cybersecurity Framework 2.0 treats identity governance as a shared operational discipline, not a vendor-only obligation.

In practice, many security teams encounter disputed accountability only after an access path has already been abused, rather than through intentional governance reviews.

How It Works in Practice

Operationally, the cleanest way to think about this split is to separate service assurance from customer responsibility. The cloud provider secures the platform layer, while the customer is accountable for what is created, granted, rotated, monitored, and revoked inside that service. If a cloud identity service is misused because a tenant over-shared a role, stored a token insecurely, or left a service principal active after a change, that is a customer-side control failure. If the provider fails to maintain the underlying service boundary, that is a provider-side failure.

The practical governance pattern is to map responsibility across three layers:

• Platform controls: provider hardening, isolation, logging, and resilience of the identity service itself.
• Tenant controls: role design, conditional access, key rotation, and approval workflows.
• Operational controls: monitoring, alerting, periodic review, and incident response ownership.

That is why NHIMG research on the Ultimate Guide to NHIs emphasises lifecycle governance, while breach analysis such as the 52 NHI Breaches Analysis shows how often misuse follows weak ownership rather than exotic exploitation. In cloud identity services, current guidance suggests using shared-responsibility matrices, explicit control ownership, and evidence-backed reviews aligned to NIST Cybersecurity Framework 2.0. The operational test is simple: if the customer can change the access decision, the customer owns the risk of that decision.

These controls tend to break down when identity administration is fragmented across platform, security, and application teams because no single group has end-to-end visibility into effective privilege.

Common Variations and Edge Cases

Tighter shared-responsibility mapping often increases review overhead, requiring organisations to balance governance certainty against operational speed. That tradeoff becomes sharper in delegated admin models, marketplace integrations, and federated identity setups where authority is distributed across multiple systems.

There is no universal standard for this yet, but best practice is evolving in three common edge cases. First, in fully managed identity services, the provider may own more of the technical control plane, but the customer still owns access design and misuse prevention. Second, in federated environments, the upstream identity provider and the consuming application may both influence the failure path, so responsibility needs to be contractually and technically documented. Third, in regulated sectors, auditors usually care less about who hosted the service and more about who could approve access, detect abuse, and prove remediation.

That is why issue analysis in the Top 10 NHI Issues is often paired with control objectives from NIST Cybersecurity Framework 2.0: the question is not only who runs the service, but who can prove that misuse was prevented, detected, and contained. In practice, accountability becomes contested when contracts describe the service, but nobody documents the customer’s last access review.

Related resources from NHI Mgmt Group

• Who is accountable when a cloud-hosted identity governance service cannot meet sovereignty requirements?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• When does a machine identity become a compliance problem?