Virtual private cloud controls for cloud identity credentials

At a glance

What this is: This is Axiad's analysis of why storing identity credentials in shared cloud infrastructure creates cross-tenant exposure risk and why virtual private cloud separation is presented as the control response.

Why it matters: For IAM and NHI teams, the issue is not cloud adoption itself but whether credential custody, tenant isolation, and data portability remain governable once identity systems move into shared environments.

Context

Cloud identity credentials are not just another workload asset, because they sit at the center of authentication, auditability, and offboarding. When those credentials live in shared cloud infrastructure, the governance question shifts from simple access control to whether tenant separation is strong enough to prevent lateral abuse across customers.

Axiad's article argues that multi-tenant cloud convenience creates a structural trust problem for identity data. The point is not that cloud is unsafe by default, but that credential stores and authentication platforms need isolation controls that match the sensitivity of the identity layer.

For IAM programmes, the practical concern is whether a shared service still allows a clean boundary around credentials, logs, and recovery paths. If it does not, then portability, audit response, and incident containment all become harder than the cloud economics first suggest.

Key questions

Q: How should security teams evaluate shared cloud risk for identity credentials?

A: Security teams should assess whether the deployment model creates an avoidable trust extension around credentials, keys, and authentication data. The main question is not only who can log in, but whether shared backend infrastructure allows a compromise in one tenant to affect another. If the answer is unclear, the identity boundary is too soft for high-value data.

Q: Why does cross-tenant exposure matter so much for IAM systems?

A: Because IAM systems hold the keys to downstream access. If an attacker can pivot through shared infrastructure into identity credentials, the resulting access can look trusted and legitimate, which makes detection and containment harder than a straightforward perimeter breach.

Q: What are the biggest failure modes in multi-tenant identity operations?

A: The main failures are policy drift, tenant-specific one-offs that bypass the baseline, and audit trails that do not preserve client context. Each of those weakens assurance even if the underlying tool works. Multi-tenant governance fails when convenience is allowed to outrun evidence.

Q: Should regulated organisations require dedicated identity isolation in the cloud?

A: When the identity platform stores sensitive credentials or supports strict audit obligations, dedicated isolation is often easier to justify than relying on shared infrastructure. The key decision is whether the service can prove custody, separation, and clean offboarding under regulatory scrutiny.

Technical breakdown

Why shared cloud infrastructure changes identity risk

Shared cloud infrastructure creates a different trust model from isolated hosting because tenants rely on platform separation instead of physical separation. For identity credentials, that matters because compromise in one tenant can become a stepping stone into another tenant's control plane or data path. The risk is not just exposure of a record set, but exposure of the authentication boundary itself. In an IAM context, the question is whether the custody model still preserves tenant-specific control over where secrets and authentication artefacts can be reached.

Practical implication: Map every cloud-hosted credential store to its tenant boundary and verify that compromise in one tenant cannot become a path into another.

Host-jumping and cross-tenant abuse as identity attack paths

Host-jumping describes an attacker using one compromised tenant or environment to reach another tenant sharing the same underlying service. In identity systems, that becomes dangerous when credentials, tokens, or authentication material are reachable through shared backend infrastructure. Once an attacker reaches those identity assets, they can authenticate as trusted systems or users rather than as an obvious outsider. That shifts the problem from perimeter defence to trust inheritance across tenants, which is why the identity layer needs stronger isolation than ordinary cloud convenience usually implies.

Practical implication: Treat shared backend reachability as an identity threat path and test whether one tenant's compromise can expose another tenant's credentials.

Virtual private cloud as an identity isolation pattern

A virtual private cloud in this context is a per-customer isolation model for identity services, not a generic cloud label. The intended effect is to keep traffic, storage, and administrative reach within a dedicated boundary so the provider's shared infrastructure no longer defines the customer's trust domain. For identity programmes, the architectural question is whether the isolation is strong enough to preserve auditability, portability, and revocation control while still fitting cloud operating models. That makes the VPC a governance pattern as much as a deployment pattern.

Practical implication: Require per-customer isolation controls for identity platforms where shared tenancy would otherwise blur custody, audit, and offboarding responsibilities.

Threat narrative

Attacker objective: The attacker wants to turn shared infrastructure into a credential bridge that gives access to protected identity assets and the systems those credentials control.

1. Entry occurs when an attacker compromises a weaker tenant or adjacent environment that shares the same cloud backend as the target identity service.
2. Credential access follows when shared infrastructure exposes identity data, tokens, or authentication material through the common backend path.
3. Impact occurs when those credentials are used to reach the target's protected systems through trusted identity channels rather than noisy perimeter attacks.

Breaches seen in the wild

• Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared-cloud identity custody creates an identity blast radius problem: Once credentials move into multi-tenant infrastructure, the question is no longer only who can log in, but what happens when one tenant becomes the pivot into another. The identity layer is especially sensitive because it is the control plane for everything else. For practitioners, this means the trust boundary must be evaluated at the tenant level, not just at the application layer.

Virtual private cloud is really a governance boundary, not a branding term: The article's core claim is about separating custody and reachability, not about adding another cloud feature. A per-customer boundary matters because identity systems are judged by revocation, recovery, and audit containment as much as by uptime. That makes VPC-style isolation relevant wherever shared services weaken accountability for credentials.

Portability risk becomes an identity governance issue when cloud backends are mutualised: If a provider cannot cleanly return or delete identity data, offboarding and vendor exit become incomplete. That is not just a service-management nuisance, it is a governance failure because credentials must be recoverable, revocable, and disposable on customer terms. Practitioners should treat data return and deletion guarantees as part of identity control design.

Credential isolation should be evaluated as an access control property, not an infrastructure preference: The right comparison is between shared tenancy with residual cross-tenant trust and dedicated tenancy with narrower exposure. That distinction matters for regulated environments because audit outcomes depend on proving separation, not assuming it. Teams should ask whether the identity architecture can sustain evidence of isolation under real operational pressure.

Identity programme maturity now includes cloud boundary design: Modern IAM is no longer satisfied by moving credentials into a managed service. The question is whether the service's architecture preserves the same control expectations that on-prem teams relied on for secrets custody, offboarding, and audit response. For identity leaders, that changes cloud adoption from a convenience decision into a governance design decision.

What this signals

Identity blast radius is now a cloud architecture question: The more an organisation centralises credentials into managed cloud identity services, the more it has to prove that one tenant's weakness cannot become another tenant's problem. That changes cloud design reviews from availability checks to boundary validation.

Shared identity services can reduce operational friction while still expanding the consequences of compromise if tenant separation is weak. For practitioners, the issue is whether the identity platform can sustain segregation, audit evidence, and offboarding integrity under real attack pressure.

For practitioners

• Map credential custody boundaries Document exactly where cloud identity credentials are stored, who can reach the backend, and which tenant boundaries are meant to prevent cross-customer exposure.
• Test cross-tenant isolation assumptions Run architecture reviews and threat models that specifically test whether compromise in one tenant could expose another tenant's identity data or authentication paths.
• Require verifiable data return and deletion Define offboarding requirements for identity records, including complete return of customer data and deletion from provider-managed systems.
• Review regulated deployment requirements Confirm that the identity platform's isolation model satisfies sector obligations for audit evidence, custody, and controlled access in regulated environments.

Key takeaways

• Shared cloud hosting changes identity risk because credentials are only as isolated as the tenant boundary protecting them.
• The article's central concern is cross-tenant exposure through host-jumping and shared backend trust, not cloud adoption itself.
• Practitioners should treat per-customer identity isolation, data return, and deletion guarantees as core governance requirements.

Key terms

• Virtual Private Cloud: A virtual private cloud is a logically isolated cloud environment reserved for one customer. In identity governance, its value depends on whether it reduces the reachable impact of credential compromise and preserves clear ownership, revocation, and data-return controls across the full lifecycle.
• Cross-Tenant Exposure: A failure where one user or organisation can reach data belonging to another tenant. In agentic systems, this often appears when boundaries are assumed in the application layer but not enforced tightly enough in the tool, identity, or retrieval layer.
• Key Custody: Key custody is the ownership and control of cryptographic keys across their lifecycle, including storage, rotation, emergency use, and retirement. Poor custody turns encryption into a weak barrier because any identity with key access can recover data that should have remained protected.
• Tenant boundary: The administrative and technical separation that defines where customer data, logs, and controls live in a cloud environment. In identity governance, it matters because auditors and security teams often need to prove that access decisions and identity records are isolated from other tenants.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.