Who is accountable when a third party’s weak cloud controls expose the enterprise?

Why This Matters for Security Teams

When a third party’s weak cloud controls expose the enterprise, the issue is not just supplier hygiene. It is an identity and access decision that the enterprise accepted, scoped, and allowed to persist. Third-party access often arrives through OAuth apps, service accounts, API keys, or shared admin pathways, which makes the blast radius larger than most vendor questionnaires capture. NHIMG’s The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is exactly where accountability gaps become operational incidents.

That visibility gap matters because cloud exposure rarely stays inside the supplier boundary. Once a partner token, integration key, or delegated role is active, the enterprise inherits the risk of over-scoping, weak monitoring, and slow offboarding. The OWASP Non-Human Identity Top 10 treats unmanaged non-human access as a first-class attack surface, not a procurement footnote. In practice, many security teams encounter partner compromise only after logs show unusual API activity, rather than through intentional control testing.

How It Works in Practice

Accountability should be mapped to the control owner, the approver, and the system operator, not assigned after an incident based on who technically “owned” the cloud account. For third-party access, that usually means security defines the minimum control baseline, procurement verifies contractual obligations, and identity or platform teams enforce the access pattern in production. The enterprise remains accountable because it authorized the delegated trust relationship and failed to continuously verify it.

Practically, this means treating partner access like a managed NHI lifecycle:

• Issue access through named workflows with explicit purpose, scope, and expiry.
• Prefer short-lived tokens and just-in-time approvals over long-lived shared secrets.
• Bind access to workload identity and logged context, not only to vendor assurances.
• Review OAuth grants, service accounts, and API keys on a schedule tied to business criticality.
• Revoke access immediately when contracts end, scopes change, or monitoring signals degrade.

This approach aligns with the spirit of 52 NHI Breaches Analysis, where weak credential hygiene and poor visibility repeatedly turn delegated access into enterprise exposure. It also fits the monitoring emphasis in NIST’s Zero Trust guidance, which expects access decisions to be evaluated continuously rather than assumed safe after onboarding. Current guidance suggests that enterprises should make third-party trust revocable by design, with every grant tied to an owner, a purpose, and an expiry date. These controls tend to break down in multi-cloud environments with inherited IAM, because each platform exposes different ways to bypass central approval and leave stale access active.

Common Variations and Edge Cases

Tighter third-party controls often increase onboarding friction and operational overhead, so organisations have to balance faster partner integration against stronger assurance. That tradeoff becomes sharper when vendors need machine-to-machine access, because shared roles and static credentials are still common in older integrations.

There is no universal standard for this yet, but best practice is evolving toward layered accountability. A supplier may be contractually responsible for maintaining its own cloud hygiene, yet the enterprise is still accountable for granting overly broad access, failing to monitor it, or leaving it active after the business need ends. The same logic applies when an integration is subcontracted through another platform: the enterprise cannot outsource its duty to define scope, enforce MFA where feasible, and prove periodic review.

For high-risk cases, use the Ultimate Guide to Non-Human Identities as a governance baseline, then add contract clauses for incident notification, subprocessor disclosure, and rapid revocation. The remaining edge case is emergency access, where business pressure often overrides normal controls. In those situations, enterprise accountability is still intact, and post-incident review should ask why the exception was approved, not only who abused it.

Related resources from NHI Mgmt Group

• Who should be accountable for third-party identity exposure?
• Who is accountable when a third-party enterprise application is exploited through a zero-day?
• Who remains accountable when a managed cloud security provider misses an incident?
• Who is accountable when multi-cloud access reviews miss excessive permissions?