Multi-cloud security depends on unified secrets and identity control

At a glance

What this is: This is an analysis of why multi-cloud has become strategically necessary and why unified secrets and identity control is the practical enabler.

Why it matters: It matters because IAM, NHI, and security teams must govern credentials and access consistently across providers or accept growing operational and breach risk.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Infisical's analysis of multi-cloud security and secrets management

Context

Multi-cloud is the practice of using more than one cloud provider for production workloads, but the governance problem sits in the identity layer. Once credentials, service accounts, tokens, and certificates are distributed across multiple providers, security teams need consistent control over secrets, lifecycle, and auditability rather than provider-by-provider improvisation.

The article argues that most enterprises are already multi-cloud in practice, whether intentionally or not, because acquisitions, shadow IT, and best-of-breed tooling create cloud sprawl. That makes the real decision one of governance maturity: whether identity and secrets management can keep pace with the operational complexity that multi-cloud introduces.

For IAM and NHI programmes, the central issue is not portability alone. It is whether the organisation can maintain a coherent access model, rotation discipline, and monitoring posture when each cloud exposes different APIs, logging formats, and privilege semantics.

Key questions

Q: How should security teams manage secrets across multi-cloud environments?

A: They should treat secrets management as a shared control plane, not a per-cloud utility. That means standardising issuance, rotation, revocation, and auditing across providers, then tying those controls to workload ownership and lifecycle processes. If each cloud stores credentials differently, governance will drift and incident response will slow down.

Q: Why does multi-cloud increase identity and access risk?

A: Because every added provider creates another IAM model, another audit format, and another set of credentials that can drift out of policy. The risk is not just more systems. It is more opportunities for standing privilege, inconsistent rotation, and hidden trust relationships between workloads.

Q: What breaks when secrets are managed separately in each cloud?

A: Rotation, revocation, and auditability become inconsistent, which makes it hard to prove who can access what across environments. A compromise in one provider can also become a bridge into others if the same service identity or secret pattern is reused without central governance.

Q: How do organisations decide whether multi-cloud is worth the complexity?

A: They should compare the cost of operating multiple providers with the business cost of lock-in, outage concentration, and limited negotiating leverage. Multi-cloud is justified when resilience, compliance, or workload-specific advantages outweigh the governance overhead, and when identity controls are mature enough to manage the added surface.

Technical breakdown

Why multi-cloud makes secrets management the control plane

Multi-cloud environments multiply the number of credentials that must be issued, rotated, audited, and revoked. API keys, service account tokens, encryption certificates, and database passwords often live in separate vendor-native stores with different APIs and retention behaviours. That fragmentation is why secrets management becomes the control plane rather than a supporting utility. The governance challenge is to present one policy model across providers without pretending the providers are the same. This is especially important when teams need consistent rotation, consistent logging, and a consistent offboarding process for workloads that move between clouds.

Practical implication: centralise secrets policy before expanding cloud footprint so credential lifecycle decisions are made once, not per provider.

Infrastructure as code and Kubernetes reduce portability friction

Infrastructure as code defines infrastructure declaratively so the same intent can be deployed across environments, while Kubernetes gives applications a runtime that is less tied to any single provider. Together they reduce lock-in at the deployment layer, but they do not solve identity by themselves. If workloads still depend on cloud-native secret stores or provider-specific IAM constructs, portability becomes partial and fragile. The architectural lesson is that compute portability and identity portability must be designed together, or the application becomes movable only in theory.

Practical implication: align IaC and container strategy with workload identity design so portability is not broken by provider-specific credentials.

Credential sprawl is the hidden multi-cloud security tax

The article points to a familiar pattern: multi-cloud complexity is not only about operating more systems, but about multiplying trust edges. Each additional platform adds its own audit model, privilege model, and failure mode for exposed secrets. That is why credential sprawl often becomes the first security debt that teams feel after expansion. The technical failure is not simply too many tools. It is that each cloud can create a different governance surface for the same workload, making policy drift likely unless there is a unifying identity layer.

Practical implication: inventory and normalise all workload credentials across clouds before the sprawl becomes too large to reverse.

Threat narrative

Attacker objective: The attacker objective is to turn fragmented multi-cloud credential management into broad environment access and operational disruption.

1. Entry occurs when sensitive credentials, service accounts, or access tokens are spread across multiple clouds and supporting systems, widening the chance of exposure through code, configuration, or shadow IT.
2. Escalation follows when inconsistent IAM models and separate secret stores allow a compromised identity to be reused or over-scoped across environments.
3. Impact lands as cross-cloud access, service disruption, data exposure, or a failed failover posture when identity controls do not survive the move from one provider to another.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Multi-cloud only becomes resilient when identity becomes portable. The article is right to frame multi-cloud as a strategic capability, but the real governance boundary sits in workload identity and secrets lifecycle. If credentials are still managed as provider-specific artefacts, the organisation has not built multi-cloud resilience, only duplicated dependency. Practitioners should treat identity portability as the prerequisite control, not an afterthought.

Credential sprawl is the real operational cost of multi-cloud. The visible complexity is deployment tooling, but the deeper cost is governance fragmentation across secret stores, access models, and audit trails. That fragmentation turns routine tasks such as rotation, revocation, and exception review into provider-by-provider workarounds. The implication is that multi-cloud programmes must be measured by how well they compress identity variance, not by how many clouds they can reach.

Unified secrets management becomes the deciding control when cloud choice is strategic. Multi-cloud creates flexibility only when teams can move workloads without rebuilding trust relationships from scratch. Without a common secrets layer, portability is constrained by hidden identity coupling even if compute and storage are abstracted. The practitioner takeaway is that the control plane for secrets is now part of architecture design, not just security operations.

Identity governance has to span human, NHI, and platform automation together. Shadow IT, acquisitions, and best-of-breed adoption usually introduce the same pattern through different actor types. Human teams choose new services, non-human workloads need new credentials, and automated deployment pipelines amplify both. Multi-cloud governance therefore fails when it is split into separate human IAM and machine identity conversations instead of one lifecycle model.

Multi-cloud strategy changes the centre of gravity from vendor management to privilege management. Once an organisation can move workloads, the next question is whether it can control who and what may move with them. That makes least privilege, segmentation, and offboarding the durable governance issues. Practitioners should expect identity controls to become the measure of architectural maturity, not cloud count.

From our research:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, which shows how quickly governance is lagging capability.
• For a broader frame on identity governance under new actor types, see Ultimate Guide to NHIs - 2025 Outlook and Predictions for how the category is evolving.

What this signals

Credential portability will become a board-level architecture issue. As multi-cloud adoption spreads, security leaders will be expected to show not only where workloads run but how their identities move, rotate, and offboard across providers. Programmes that cannot prove this will struggle to defend resilience claims during outages or audits.

Identity lifecycle discipline is now a multi-cloud enabler. The organisations that win here will be the ones that connect workload onboarding, access review, and offboarding to the same control model across clouds. That shift matters because multi-cloud does not reduce governance demand, it concentrates it into the identity layer.

With 88.5% of organisations acknowledging that their non-human IAM practices lag behind or are merely on par with human identity and access management efforts, the control gap is already structural, not theoretical. Multi-cloud expansion will expose that gap faster unless teams align secrets, service identities, and policy enforcement around one operating model.

For practitioners

• Build a unified secrets control plane Standardise how API keys, tokens, certificates, and service account credentials are issued and rotated across every cloud before adding more workloads.
• Map workload identity to every deployment target Document which service identities each application uses in AWS, GCP, Azure, and on-premises systems, then tie ownership to lifecycle reviews and offboarding.
• Reduce provider-specific dependency in application design Prefer portable runtime patterns such as containers, IaC, and abstracted secret retrieval so workloads are not pinned to a single vendor's identity model.
• Centralise audit and rotation evidence Aggregate logs, rotation status, and exception records into one reviewable process so security teams can spot drift across clouds quickly.
• Tie multi-cloud expansion to governance gates Require identity architecture review before new cloud services are approved, especially when teams want to adopt new platforms outside central oversight.

Key takeaways

• Multi-cloud resilience depends on controlling identity, not just distributing workloads.
• The biggest operational risk is credential sprawl across cloud-native secret stores and audit systems.
• Teams should standardise secrets, workload identity, and lifecycle governance before scaling provider count.

Key terms

• Multi-cloud identity governance: The discipline of managing access, credentials, and lifecycle controls consistently across more than one cloud provider. It matters because each provider introduces a different identity model, so governance has to normalise policy, audit, and offboarding across environments rather than relying on native tools alone.
• Unified secrets management: A shared control plane for issuing, storing, rotating, and revoking credentials across applications and cloud platforms. In multi-cloud environments, it reduces drift by replacing separate secret stores with one policy model for lifecycle and auditability.
• Workload identity portability: The ability for an application or service to authenticate and operate across multiple environments without being tied to a single cloud provider's credential format. It is a design goal, not an automatic property, and it depends on abstracting secrets and trust relationships together.
• Credential sprawl: The uncontrolled spread of secrets, tokens, certificates, and service accounts across teams, tools, and cloud providers. It creates governance blind spots because no single owner can easily explain where each credential lives, how it is rotated, or when it should be removed.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance on building a unified secrets workflow across AWS, GCP, Azure, and on-premises environments.
• Practical patterns for using infrastructure as code and Kubernetes without hard-coding provider-specific identity dependencies.
• Implementation detail on rotation, audit logging, and how a central secrets layer supports multi-cloud operations.
• A rollout sequence for moving from single-cloud dependence to deliberate multi-cloud adoption without breaking production systems.

👉 Infisical's full post covers the architecture patterns, rollout sequence, and control trade-offs behind multi-cloud adoption.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.