Multi-cloud security assessment: where automated pipelines break and attackers benefit
Geert WarmenbolApril 29, 2026
Key takeaways
Multi-cloud environments are not assessed correctly by running separate per-provider security tools against each cloud — cross-cloud attack paths require an assessment that treats all providers as a single attack surface with shared trust relationships.
In Vulnox multi-cloud assessments, the gap between the asset inventory the security team provides and the inventory produced by active discovery averages three to five undocumented cloud accounts per engagement for organizations with more than 200 employees.
OIDC federation trust policies that allow any token from a federated provider — rather than specific workload audiences — are the single most common cross-cloud privilege escalation enabler, and they pass every per-provider compliance check.
CSPM tools are scoped to enrolled accounts and produce zero visibility into shadow accounts, unenrolled workloads, or configurations that are compliant per-provider but exploitable in combination across providers.
Cross-cloud log correlation requires detection logic written specifically for cross-provider authentication sequences — most organizations ingest the logs but have not written the rules.
A GCP service account key exported and stored as a static credential in AWS Secrets Manager is a finding that appears in neither provider's compliance report, because each provider sees only its own side of the configuration.
TL;DR
Multi-cloud security assessment is not the sum of three single-cloud audits. The risk that matters in a multi-cloud environment is the attack surface that exists between providers — the federated trust configurations, the identities that span clouds, the monitoring gaps that appear at provider boundaries. Most organizations assess each cloud reasonably well in isolation and have almost no visibility into what an attacker can do by starting in one cloud and moving through another. That is the gap this article addresses.
The attack path that three separate audits all missed
A 300-person SaaS company ran annual cloud security audits across their AWS, Azure, and GCP environments. Each was assessed by the same firm, each produced a report, each report showed a manageable finding count. AWS was the primary production environment. Azure hosted the identity provider and Microsoft 365 integration. GCP hosted the data analytics pipeline. The security team tracked findings across three separate remediation queues. No one was responsible for the space between them.
In a Vulnox multi-cloud assessment, the first two hours of work produced a finding that none of the three prior audits had identified. An AWS Lambda function in the data processing environment used OIDC federation to authenticate to GCP for BigQuery access. The federation trust policy on the GCP side was configured with audience: any — meaning any valid AWS identity token, not just the specific Lambda function the policy was intended to cover. Any Lambda function in the AWS account, across all environments including development, could authenticate to GCP using that trust relationship and inherit the GCP service account permissions, which included BigQuery dataset admin on the analytics environment. Development environment Lambda functions had far weaker IAM controls than production. The cross-cloud path turned a development environment compromise into a data analytics environment compromise. The finding existed in the configuration of the trust relationship between two clouds — visible to neither provider's compliance tooling because each tool could see only its own side.
Why per-provider security tools cannot see the cross-cloud attack surface
Cloud Security Posture Management tools work by querying provider APIs for resource configurations and comparing them against benchmarks — CIS controls, provider-specific security baselines, compliance framework mappings. They are accurate and useful within their scope. Their scope is a single provider. An OIDC federation trust policy in GCP defines what external identities can assume a GCP service account. The GCP CSPM tool sees the trust policy. It checks whether the policy follows GCP security recommendations. It does not know what those trusted external identities can do in their home environment, because that information lives in AWS or Azure IAM, not in GCP. The cross-cloud attack path requires correlating the outbound capability of the source identity (what can that Lambda function do?) with the inbound trust of the destination (what does this federation policy grant?). No per-provider tool makes that correlation. It requires a human or a purpose-built assessment methodology that models the environment as a connected system rather than a set of independent cloud accounts.
Example
Static credential cross-cloud storage is the clearest single-finding illustration. A GCP service account key is exported as a JSON file — a common operational practice when a workload in another cloud needs GCP access and OIDC federation has not been configured. That key is stored in AWS Secrets Manager with an appropriate rotation policy from the AWS side. The GCP CSPM flags the service account as having an exportable key and notes that key age exceeds the recommended rotation period. The AWS CSPM does not know what the secret in Secrets Manager contains — it sees a secret with rotation configured and marks it compliant. The actual risk — a static GCP credential living in AWS, accessible to anything in the AWS account that can read that secret — appears in neither report. Both tools see a compliant side of the configuration.
Workload identity federation, where properly configured with specific audience conditions and subject conditions, eliminates the static credential problem by allowing cloud-to-cloud authentication using short-lived tokens. The security of the federation depends entirely on the specificity of the trust conditions. An audience condition of sts.amazonaws.com covers all AWS identities. An audience condition of arn:aws:iam::123456789012:role/specific-lambda-role covers one. The difference between those two configurations is the blast radius of a development environment compromise — in one case, contained to the development environment; in the other, extending to every cloud that trusts that audience.
What multi-cloud assessments consistently find
Assessment base: Vulnox multi-cloud and cross-provider security assessments, 2023-2024
Overpermissive OIDC federation trust policies enabling cross-cloud privilege escalation
In multi-cloud assessments, OIDC federation trust policies configured with broad audience conditions — covering entire AWS accounts, all Azure tenants, or all GCP projects rather than specific workloads — appear across all cloud provider combinations. The pattern is consistent: federation was configured by a developer who needed cross-cloud access for a specific workload and copied example configurations from provider documentation. Provider documentation examples use broad conditions for simplicity. The specific workload the developer intended to cover is one identity among many that can use the resulting trust relationship. Production workloads inherit the trust. Development workloads inherit the trust. Any compromise of any identity in the source environment that meets the broad condition inherits the trust.
This finding does not surface in per-provider compliance checks because each provider's tool sees only its side of the trust relationship as described above. It requires cross-provider analysis — mapping all federation trust relationships, identifying the source identity set each trust policy covers, and assessing the permissions each trusted identity would receive. In environments where this finding exists, it typically represents the shortest path from a development environment compromise to a production data environment, crossing provider boundaries in the process.
Undiscovered cloud accounts carrying production-adjacent workloads
Asset inventory in multi-cloud environments is chronically incomplete. Development teams create AWS accounts, Azure subscriptions, and GCP projects outside the central procurement process for prototype projects, client demonstrations, cost-allocation experiments, and tools that were supposed to be temporary. These accounts are not enrolled in CSPM tooling, not included in audit scope, and not connected to the central identity provider in most cases. They carry whatever IAM configuration the creating developer applied. In a meaningful fraction of Vulnox multi-cloud engagements, undiscovered accounts contain data from production systems — database exports, API keys for production services, or direct VPC peering with production networks that was established during a migration and never removed.
The security program covers what it knows about. The accounts it does not know about are not edge cases — they are the environments where the most relaxed security practices were applied because the creator assumed the account was temporary and low-risk. Discovery must precede assessment. An assessment scoped to a provided asset list has a false ceiling that corresponds exactly to the gaps in the organization's own knowledge of its cloud footprint.
Log centralization without cross-cloud correlation rules
Most multi-cloud environments ingest logs from all providers into a central SIEM. The logs arrive. They are stored. They generate alerts against per-provider detection rules. AWS CloudTrail detections fire on AWS events. Azure Monitor detections fire on Azure events. The sequence of events that constitutes cross-cloud lateral movement — a specific identity authenticating to one cloud, using that session to obtain credentials or tokens, then authenticating to a second cloud — is a detection pattern that requires correlating events across both log streams. Those correlation rules almost never exist in the SIEM deployments Vulnox examines, because writing them requires understanding the normal cross-cloud authentication patterns for the environment, which requires knowing what cross-cloud connections exist, which requires the discovery and mapping work that precedes assessment.
An attacker who moves from AWS to GCP via a federated trust relationship generates an AWS authentication event and a GCP authentication event. Each event individually looks like normal service-to-service authentication. The anomaly is the sequence and the identity — this specific AWS identity should not be authenticating to this GCP service account from this IP range at this time. That detection requires the correlation rule and the baseline. Both require knowing the cross-cloud architecture well enough to define what normal looks like.
More cloud providers does not mean more redundancy — it means a wider attack surface with fewer people who understand all of it
Common belief
The operational argument for multi-cloud is resilience: if one provider has an outage or a security incident, workloads continue in other environments. The implicit security assumption is that spreading risk across providers spreads the attack surface in a way that limits blast radius.
What we found
In multi-cloud environments assessed by Vulnox, the identities most likely to have high cross-cloud reach are not the privileged accounts monitored by the security team — those accounts are reviewed, audited, and subject to just-in-time access policies. The identities with the most unreviewed cross-cloud reach are service accounts and workload identities created for specific integrations, granted the permissions needed to complete the integration, and never reviewed again because they were categorized as non-human accounts and excluded from the privileged access management program.
An attacker does not need to compromise all three clouds to cause significant damage. They need to compromise one identity that has reach into the others. In a multi-cloud environment with cross-provider federation, the blast radius of a single identity compromise is potentially larger than in a single-cloud environment with equivalent IAM controls, because the compromised identity might have federated access to services in clouds where that identity was not the primary security concern. The organization's IAM team thinks carefully about what each identity can do within its home cloud. They think less carefully about what that identity can reach in other clouds through federation, because the cross-cloud permissions were configured by a different team, at a different time, for a specific use case that has since expanded.
What multi-cloud assessments consistently leave out of scope
Data plane cross-cloud trust — not just control plane
IAM federation analysis covers the control plane: who can authenticate, what API calls they can make, what resources they can manage. Multi-cloud environments frequently have data plane cross-cloud trust as well: S3 buckets with bucket policies allowing access from GCP service accounts, Azure Blob Storage with SAS tokens generated programmatically by AWS Lambda functions, BigQuery datasets accessible by AWS Glue jobs. These data plane connections are not IAM relationships from the perspective of either cloud's CSPM tool — they are storage configurations that happen to involve cross-provider access. They carry the same escalation risk as federated IAM trust and are almost never included in multi-cloud assessment scope.
Developer tooling and CI/CD cross-cloud credential exposure
CI/CD pipelines in multi-cloud environments typically need credentials for all providers they deploy to. Those credentials live in the CI/CD platform — GitHub Actions secrets, GitLab CI/CD variables, Jenkins credential stores. A compromise of the CI/CD platform produces credentials for all clouds simultaneously. The CI/CD platform is often not included in the multi-cloud security assessment scope because it is developer infrastructure rather than cloud infrastructure. It is also the single point of failure that holds the keys to the entire multi-cloud environment.
Provider-specific metadata service attack paths
Every major cloud provider exposes an instance metadata service (IMDS) to workloads running on their compute infrastructure. The IMDS provides temporary credentials for the workload's cloud identity. SSRF vulnerabilities in applications running on cloud compute — where an attacker can make the application issue an HTTP request to the metadata endpoint — can retrieve those temporary credentials. In a multi-cloud environment, an SSRF in an application running on AWS EC2 retrieves AWS credentials. If that EC2 instance also has GCP service account keys stored in the instance's environment variables or in a mounted secrets file, the SSRF produces multi-cloud credential access. The attack path starts with an application vulnerability, passes through the cloud metadata service, and ends with credentials for multiple providers. It requires security testing that covers application SSRF, cloud metadata service exposure, and the credential storage practices on cloud compute instances — usually three separate assessment domains.
Where multi-cloud security is heading in the next two years
A publicly disclosed breach will be traced to cross-cloud lateral movement through a misconfigured OIDC federation trust relationship, and the post-incident analysis will show that the misconfiguration was present in CSPM compliance reports as an informational finding that was triaged below the remediation threshold because it appeared compliant within each provider individually.
The technical precondition — overpermissive federation trust policies — is common in environments Vulnox assesses. The organizational precondition — findings that appear informational in per-provider CSPM tools because each tool sees a compliant side of the configuration — is equally common. The combination produces a misconfiguration that passes compliance checks and is never prioritized for remediation. A breach through this vector will clarify to the industry that per-provider compliance scores are not a sufficient assessment of cross-cloud risk.
Confidence: mediumA publicly attributed breach by end of 2027 where the attack chain is documented to cross at least two cloud providers via federated identity and post-incident review identifies CSPM coverage as a detection gap.Within 18 months, at least two major CSPM vendors will introduce cross-cloud trust relationship analysis as a product feature, framed as a response to customer demand rather than a gap acknowledgment, and the feature will be priced as an enterprise add-on rather than included in base tiers.
The cross-cloud attack surface gap is understood within the security research community and is beginning to appear in enterprise security assessments. CSPM vendors track what assessors find that their tools miss. The feature exists in concept — it requires querying IAM and federation configurations from multiple provider APIs and correlating them. The incentive to build it exists. The incentive to price it at the enterprise tier rather than include it broadly also exists, because it addresses a problem that enterprise multi-cloud buyers experience and that SMB buyers are less likely to have.
Confidence: highCheck CSPM vendor feature announcements from major providers (Wiz, Orca, Prisma Cloud) by end of 2026. If none have released cross-provider federation trust analysis, the prediction was premature.
The multi-cloud security problem is an organizational problem that tooling cannot solve
Every conversation about multi-cloud security eventually reaches tooling: which CSPM covers all three clouds, which SIEM ingests all the logs, which identity platform federates all the identities. The tooling conversation is easier than the organizational conversation, which is: who is responsible for the security of the space between the clouds? In most multi-cloud organizations, AWS security is owned by the cloud infrastructure team. Azure security is owned by the identity team or the Microsoft 365 team. GCP security is owned by the data engineering team. The cross-cloud attack surface is owned by nobody, because it requires understanding all three environments simultaneously and the organizational structure separates them. Tooling that covers all three providers does not fix the ownership gap. It produces findings in a unified dashboard that are still routed to the team responsible for the individual provider, not the team responsible for the cross-cloud relationship — because that team does not exist.
Counterargument
The counterargument is that mature organizations have a cloud security team or a CISO function that owns security horizontally across providers, and that the organizational gap is a symptom of immaturity that organizations grow out of as their cloud programs mature. This is correct in principle. In practice, the organizational structure solidifies around the tooling and operational responsibilities before the security ownership question is resolved, and the cross-cloud responsibility gap persists in organizations that are otherwise reasonably mature in their per-provider security programs.
The first thing to do before the next multi-cloud assessment is scoped
Before scoping the next multi-cloud security assessment, run a cloud account discovery exercise independent of the asset inventory the security team maintains. Use billing API access across all providers, OAuth application registrations in the identity provider, and DNS enumeration for cloud provider naming patterns. Compare the result to the provided inventory. The gap is the first finding of the assessment and sets the correct scope for everything that follows. Then pull all OIDC and SAML federation trust relationships across all providers — AWS trusted identity providers, Azure app registrations with federated credentials, GCP workload identity pools — and map what each trust policy covers. If any trust policy uses audience conditions broader than a specific workload, flag it before the assessment begins. Those two steps take less than a day and define the highest-priority scope for the work that follows.
Further Reading
Vulnerability Assessment
vulnerability assessment servicesDigital Footprint
digital footprint analysisNIST Vulnerability Assessment Definition
NIST vulnerability assessment definitionNational Vulnerability Database NIST
NIST National Vulnerability DatabaseWhat is Attack Surface Management Cymulate
attack surface management overview
Frequently Asked Questions
What does a multi-cloud security assessment find that single-provider CSPM tools miss?
Cloud Security Posture Management tools are built around provider-specific APIs and control frameworks. They find misconfigurations within a single cloud well. They do not model the attack paths that cross provider boundaries — an AWS IAM role that can assume an Azure service principal via federated trust, a GCP service account key stored in an AWS Secrets Manager instance, or a workload identity that has excessive permissions in the second cloud it was not designed for. Cross-cloud attack paths require an assessment methodology that treats the multi-cloud environment as a single attack surface, not a collection of individual cloud audits.
What are the most common IAM misconfigurations in multi-cloud environments?
Across Vulnox multi-cloud assessments, the three most consistently exploitable IAM patterns are: overly permissive OIDC federation trust policies that allow any token from a federated provider to assume a role rather than specific workloads, service account keys exported from GCP and stored as static credentials in AWS or Azure without rotation policies, and blast radius miscalculation where a developer role in a non-production account has trust relationships that allow it to reach production resources in a different cloud. None of these appear in standard per-provider compliance checks.
How do you discover shadow cloud accounts and workloads in a multi-cloud environment?
Shadow cloud accounts — AWS accounts, Azure subscriptions, GCP projects created outside the central procurement process — are discovered through billing data analysis, DNS enumeration looking for cloud provider naming patterns, and OAuth application registrations in identity providers. In Vulnox assessments, the gap between the asset inventory the security team provides and the inventory produced by discovery tooling averages three to five undocumented cloud accounts per engagement for organizations with more than 200 employees. These accounts carry whatever security configuration the creator applied at setup.
Why does CSPM tooling produce false confidence in multi-cloud environments?
CSPM tools are scoped to enrolled accounts. They produce findings within those accounts against provider-specific benchmarks. They have no visibility into accounts that are not enrolled, workloads running in clouds the organization does not know it is using, or configurations that are compliant within one provider but create exploitable conditions when combined with configurations in another. A multi-cloud environment assessed account-by-account with per-provider tools produces a set of clean-ish provider reports and zero visibility into the cross-cloud attack surface.
What is a cross-cloud privilege escalation path and how do you test for one?
A cross-cloud privilege escalation path is an attack sequence where compromising a low-privilege identity in one cloud provider produces elevated access in another. Example: an AWS Lambda function execution role with sts:AssumeRoleWithWebIdentity can use its AWS identity token to authenticate to Azure via a federated trust configuration, then call Azure RBAC APIs using that Azure identity. Testing requires mapping the federated trust relationships between providers, identifying what permissions each trusted identity receives in the target cloud, and tracing whether those permissions enable further escalation. This is manual work — no automated scanner models cross-cloud trust chains.
How should multi-cloud security assessment be scoped to cover the real attack surface?
Scope must start with discovery, not with a provided asset list. Before assessing any configuration, enumerate all cloud accounts across all providers the organization might be using — billing APIs, identity provider OAuth registrations, DNS patterns, and developer tool configurations. Then map the federated trust relationships between providers. Then assess IAM configurations with cross-cloud attack paths in mind, not just within-provider compliance. The assessment produces a different set of findings than a per-provider compliance audit because it models what an attacker can reach, not just what violates a benchmark.
What monitoring gaps are most dangerous in multi-cloud environments?
The highest-risk monitoring gap is cross-cloud event correlation. An attacker who compromises an identity in one cloud and uses it to access a second cloud generates events in both providers' logs — but those events are correlated only if both log streams flow into the same SIEM with correlation rules that model cross-cloud lateral movement. Most organizations ingest cloud logs into a SIEM but have not written detection logic for cross-cloud authentication sequences. The second gap is federated authentication anomalies — a workload identity authenticating from an unexpected cloud region or at an unexpected time is an anomaly that requires understanding the baseline behavior across providers, not just within one.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.