TL;DR: Cloud identity credentials stored in shared infrastructure can be exposed through host-jumping and cross-tenant abuse, with Axiad arguing that virtual private cloud separation reduces that risk while preserving cloud convenience. The security question is not whether cloud can be used, but whether identity data can be isolated without weakening governance.
NHIMG editorial — based on content published by Axiad: Virtual Private Cloud: The benefits of the cloud without the risk
By the numbers:
- Enterprise cloud spending increased by over 30% last year.
- Cloud spending is likely to double to around $500 billion by 2023.
Questions worth separating out
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.
Q: When is a virtual private cloud worth considering for IAM workloads?
A: A virtual private cloud is worth considering when identity data is sensitive, audit expectations are strict, or the organisation needs a clearer separation boundary than pooled cloud tenancy can provide.
Q: What do teams get wrong about cloud identity security?
A: Teams often assume that strong application security controls automatically neutralise the risk created by shared infrastructure.
Practitioner guidance
- Classify credential data by tenancy model Identify which identity stores, signing keys, and authentication services sit in shared cloud environments versus dedicated customer environments.
- Validate tenant isolation assumptions Test whether the provider's logical separation is sufficient for your risk model, including access paths, backend storage, and data-return behaviour on exit.
- Map audit requirements to deployment model Align cloud hosting choices with the audit, segregation, and residency demands that apply to your sector.
What's in the full article
Axiad's full blog post covers the operational detail this post intentionally leaves for the source:
- The shared-infrastructure example used to explain how host jumping can expose cloud-stored credentials.
- The VPC deployment model details, including dedicated tunnel behaviour and storage separation.
- The article's explanation of why some enterprises prefer isolated cloud environments for regulated identity data.
- The vendor's discussion of data return and deletion behaviour when a customer leaves the platform.
👉 Read Axiad's analysis of virtual private cloud controls for cloud identity credentials →
Virtual private cloud for credentials: is shared cloud the real risk?
Explore further
Shared cloud tenancy creates an identity trust problem, not just an infrastructure one. When credentials and authentication material live in pooled environments, the attacker does not need to defeat every control in the target organisation. They need only reach a weaker adjacent boundary and exploit the fact that identity data is now part of the shared attack surface. The practical conclusion is that identity teams must evaluate tenancy as a control variable, not a hosting detail.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means many teams cannot prove where sensitive identity data actually lives or who can reach it.
A question worth separating out:
Q: Who is accountable for credential protection in a cloud deployment?
A: Accountability should be shared but explicit. The provider is responsible for the platform and its isolation guarantees, while the customer remains responsible for governance decisions about which credentials belong in that environment, how they are classified, and how they are removed at offboarding. If neither side owns the lifecycle clearly, the risk remains unresolved.
👉 Read our full editorial: Virtual private cloud controls for cloud identity credentials