Your AWS security hub is flagging 400 findings. Your Azure Defender console has 280 more. Your GCP Security Command Center is running independently on a separate dashboard your team checks when they remember. Three cloud providers. Three posture models. Three compliance reports assembled manually every quarter. And zero visibility into whether a misconfiguration in Azure and an over-permissioned service account in AWS together form an attack path that crosses cloud boundaries, because no individual cloud-native tool sees both.
This is the multi-cloud security problem that CNAPP was architecturally designed to solve. How CNAPP works in multi-cloud is not a feature question – it is an architecture question. A CNAPP platform unifies security telemetry, posture assessment, identity governance, and risk prioritization across cloud providers under a single normalized risk model, so a cross-cloud attack path is as visible as a single-cloud one.
For Indian GCCs managing hybrid infrastructure and BFSI organizations navigating RBI’s continuous monitoring requirements across multi-cloud environments, the architectural answer is no longer optional. The audit will ask for it before the attacker exploits it.
Multi-Cloud Is the Default. Unified Multi-Cloud Security Is Not.
Multi-cloud adoption was an architectural choice that became an operational inevitability. Enterprise teams chose AWS for compute, Azure for identity integration with Active Directory, GCP for data analytics. What began as a deliberate platform selection became an ecosystem of independent security surfaces, each requiring separate tooling, separate expertise, and separate reporting. The Verizon Data Breach Investigations Report 2023 found that 82% of breaches involved cloud data, and multi-cloud complexity is a primary contributor to the detection latency that lets those breaches persist.
The specific failure is normalization. Each cloud provider uses a different schema for security events, a different taxonomy for resource types, a different model for identity and access management. AWS IAM roles, Azure Managed Identities, and GCP Service Accounts are functionally equivalent concepts that appear in completely different forms in their respective security logs. A security analyst correlating a cross-cloud event manually is comparing incompatible data formats, which means most cross-cloud correlations simply do not happen. Indian GCCs, which routinely manage cloud infrastructure across parent-company standards and Indian regulatory requirements simultaneously, face this compounded by a 30,000-person cloud security talent gap that makes manual normalization even less viable.
Gartner research finds that organizations managing multi-cloud security using separate cloud-native tools spend 40% more on security operations overhead compared to those using a unified Cloud-Native Application Protection Platform (CNAPP). This cost increase occurs because normalization, correlation, and compliance mapping are handled manually by security analysts instead of being architecturally automated within a single platform.
The path from this fragmentation to genuine visibility runs through a single architectural question: how does CNAPP work in multi-cloud to unify what cloud providers deliberately keep separate?
Cloud-Native Security Tools Are Not a Multi-Cloud Security Strategy
Most multi-cloud security programs are built by deploying the native security service of each cloud provider — AWS Security Hub, Microsoft Defender for Cloud, Google Security Command Center — and connecting their outputs to a SIEM for aggregation. This approach feels comprehensive because it covers every cloud. It is not comprehensive, because coverage is not the same as correlation. Three tools that each see 80% of their cloud’s risk, with no shared context between them, do not produce 80% multi-cloud visibility. They produce three independent 80% views with blind spots at every boundary.
Most security teams believe deploying each cloud’s native security tool constitutes a multi-cloud security strategy. Here is the specific cost of that assumption: cross-cloud attack paths — where an attacker uses a compromised AWS credential to access Azure resources through a federated identity trust — are invisible to any single cloud-native tool. MITRE ATT&CK for Cloud documents cross-cloud lateral movement as an active and documented attack technique. No individual cloud provider’s security service detects it.
Table: Fragmented Multi-Cloud Security vs Unified CNAPP Architecture (Enterprise View)
| Fragmented Approach | CNAPP Unified Approach |
|---|---|
| AWS Security Hub, Azure Defender, and GCP Security Command Center generate independent findings with no shared schema or contextual risk correlation. | Single normalized risk model ingests telemetry from all cloud providers into one unified asset and attack path graph. |
| Cross-cloud identity relationships remain invisible, AWS IAM roles and Azure Managed Identities are not correlated, increasing blind spots and over-privileged access risk. | Unified identity graph maps permissions across cloud providers, detecting toxic combinations and cross-cloud over-privilege exposure. |
| Compliance reporting requires manual assembly of exports from multiple cloud consoles during every audit cycle. | Single continuous compliance posture mapped across CERT-In, RBI, and DPDP Act controls from unified telemetry. |
Unified CNAPP architectures reduce analyst overhead by eliminating manual normalization, correlation, and compliance stitching across multi-cloud environments.
“Three cloud security tools covering three clouds is not multi-cloud security.
It is single-cloud security repeated three times — with the most dangerous gaps at the boundaries.”
The 3-Layer CNAPP Multi-Cloud Security Model
Understanding how CNAPP works in multi-cloud requires a framework that distinguishes the three architectural layers a unified platform must operate across simultaneously. Each layer is a prerequisite for the next.
Layer 1: Telemetry Ingestion and Normalization
A CNAPP platform ingests security telemetry from all cloud providers; AWS CloudTrail, Azure Activity Logs, GCP Audit Logs, Kubernetes audit logs across all environments, and normalizes them into a single unified schema. This normalization is the architectural prerequisite for everything that follows: you cannot correlate what you cannot compare.
What good looks like: an IAM privilege escalation event in AWS and an Azure Managed Identity permission change are represented as the same event type in the same data model, searchable and correlatable in a single query without provider-specific translation.
Layer 2: Unified Multi-Cloud Risk Graph
With normalized telemetry, the CNAPP builds a real-time graph of cloud assets, identities, permissions, network relationships, and vulnerabilities across all providers. This graph enables cross-cloud attack path analysis, the ability to identify, for example, that an over-permissioned AWS Lambda function can access an Azure storage account through a federated trust, creating a cross-cloud attack path that neither AWS Security Hub nor Microsoft Defender would surface independently.
What good looks like: a single query surfaces all paths from any public-facing resource in any cloud to any resource tagged as containing PII, across all providers simultaneously.
Cy5’s ion Cloud Security platform builds this unified risk graph natively across AWS, Azure, and GCP, with event-driven ingestion that evaluates configuration changes within seconds across all three providers, the architectural requirement for CERT-In’s 6-hour breach reporting mandate in multi-cloud environments.
Layer 3: Action and Governance
The unified risk graph feeds a single governance layer: compliance posture mapped across CERT-In, DPDP Act, RBI IT Governance, ISO 27001, and SOC 2 from one data model; developer remediation tickets that reference the specific cross-cloud attack path the fix addresses; and executive dashboards that show multi-cloud risk as a unified trend, not three separate provider charts. What good looks like: a single CNAPP compliance report covers a BFSI organization’s RBI continuous monitoring obligation and its global parent’s ISO 27001 requirement, from the same normalized dataset.
Must Read: What Is CNAPP? The Complete Guide for Enterprise Security Teams
How Multi-Cloud CNAPP Coverage Changes Security Outcomes in Indian Enterprises
Scenario 1: The GCC Whose Cross-Cloud Attack Path Went Undetected for Eight Months
A Hyderabad-based GCC managing infrastructure across AWS and Azure for a European financial services parent ran AWS Security Hub and Microsoft Defender for Cloud as its multi-cloud security stack. Both tools were functioning correctly within their respective clouds. During a penetration test commissioned for RBI compliance evidence, the testing team identified a cross-cloud attack path: an AWS Lambda function with an over-permissioned execution role could authenticate to Azure Active Directory through a federated identity trust established during initial infrastructure setup, and from there, access Azure storage accounts containing transaction records.
Neither AWS Security Hub nor Microsoft Defender had visibility into the federated trust relationship that crossed cloud boundaries. The path had been open for eight months. A CNAPP platform operating Layer 2 of the Multi-Cloud Security Model, a unified identity graph across both providers, would have surfaced this relationship at the moment the federated trust was established. The GCC’s remediation cost: a four-month program involving both AWS and Azure remediation workstreams. The detection cost with unified CNAPP coverage: seconds.
Scenario 2: The Fintech Whose Three-Cloud Compliance Report Took Four Person-Weeks
A Mumbai-based Series C fintech running its payment processing on AWS, its analytics platform on GCP, and its Active Directory integration on Azure faced a DPDP Act compliance assessment requiring evidence of continuous monitoring across all environments where personal data was processed. With three separate cloud-native security tools, the compliance team spent four person-weeks manually exporting findings, normalizing formats, mapping controls, and assembling a unified report.
Midway through the assessment, the team discovered a GCP misconfiguration that had been flagged in GCP Security Command Center two months earlier, but had never been correlated with the AWS finding that together with it formed a complete attack path to payment records. The DPDP Act assessment required a supplementary breach risk disclosure. A unified CNAPP compliance layer would have produced the cross-cloud report automatically, and would have correlated the two findings into a single attack path on the day both were detected.
Also Give it a Read: Event-Driven Cloud Security Architecture: Implementation Guide from Cloud Security Experts
Four Recommendations for Security Leaders Building Multi-Cloud CNAPP Coverage
1. Inventory Your Cross-Cloud Identity Relationships First
Before evaluating CNAPP platforms, map every federated identity trust, cross-account role assumption, and workload identity configuration that spans cloud providers. These relationships are the most commonly exploited multi-cloud attack vectors and the least visible to cloud-native security tools. This inventory takes a week with the right cloud architecture team involvement and produces the most honest picture of your actual multi-cloud attack surface, independent of any vendor conversation.
You have done this correctly when: you can name every AWS role that can assume an identity in Azure or GCP, and vice versa, with the business justification for each trust relationship.
2. Test Cross-Cloud Attack Path Detection Before Any POC Ends
The definitive test of multi-cloud CNAPP capability is whether the platform can identify an attack path that crosses cloud provider boundaries without human correlation. In your POC, deliberately create a federated trust between a misconfigured AWS resource and an Azure resource, and measure whether the platform surfaces a single cross-cloud attack path or two independent findings. This test takes two hours and eliminates platforms that aggregate without correlating.
3. Treat Unified Compliance Reporting as a Procurement Requirement, Not a Feature
For Indian enterprises subject to CERT-In, DPDP Act, and RBI obligations, multi-cloud compliance reporting assembled from three separate provider exports is not compliant with continuous monitoring requirements, it is periodic snapshot evidence. Unified CNAPP compliance reporting that tracks control posture continuously across all cloud providers is the architecture that satisfies India’s regulatory standard. Make this a go/no-go criterion in every CNAPP evaluation, not a bonus capability.
4. Consolidate Before Expanding Cloud Coverage
Organizations planning to add a third or fourth cloud provider should deploy unified CNAPP coverage before expanding, not after. Security debt compounds in multi-cloud environments faster than in single-cloud ones because each new provider multiplies the number of cross-cloud relationships that require monitoring. The organizations that implement unified CNAPP coverage before their third cloud deployment have materially fewer remediation programs than those that implement it after discovering the accumulated cross-cloud exposure.
Where to Start: 3 Steps
- Step 1 (This Week)
Map every cross-cloud identity trust relationship in your environment. This is your actual multi-cloud attack surface.
- Step 2 (This Month)
Run the cross-cloud attack path test on your current security stack. If it cannot detect a manufactured cross-cloud path, you have your gap analysis.
- Step 3 (This Quarter)
Evaluate unified CNAPP platforms with cross-cloud attack path detection as a mandatory POC criterion.
What Independent Research Validates About Multi-Cloud CNAPP Architecture
Gartner’s 2023 CNAPP research identifies cross-cloud risk correlation as the primary technical differentiator among CNAPP platforms, and the capability most frequently absent from platforms that present as multi-cloud capable but operate as cloud-specific tools with a unified dashboard. The MITRE ATT&CK for Cloud matrix explicitly documents cross-cloud lateral movement techniques, validating that cross-cloud attack paths are active threat vectors, not theoretical edge cases, in enterprise multi-cloud environments.
NIST CSF 2.0’s updated cloud guidance requires integrated detection across all cloud environments an organization operates, a direct mandate for the unified telemetry architecture that Layer 1 of the Multi-Cloud Security Model provides. CIS Controls v8 IG2 and IG3 both include continuous asset discovery and vulnerability management requirements that extend to multi-cloud assets.
Cy5 has deployed ion across multi-cloud enterprise environments in India, UK, Germany, and Southeast Asia with documented 97% MTTD reduction.
Multi-Cloud Is Where You Operate. Unified Coverage Is Where Your Security Must Reach.
Your cloud providers will not build the unified security view you need. That is not a criticism, it is a business model observation. AWS is optimized for AWS security. Azure is optimized for Azure security. The architecture that connects them is yours to build, and CNAPP is the platform category designed to do it.
The cross-cloud attack paths in your environment exist whether or not you can see them. The federated identity trusts, the cross-account role assumptions, the workload permissions that span cloud boundaries, these relationships were created by your architecture team solving operational problems. A CNAPP platform working across Layer 1, 2, and 3 of the Multi-Cloud Security Model surfaces what those relationships enable before an attacker maps them first.
Start with the cross-cloud identity inventory. Everything else in your multi-cloud security architecture builds from that foundation. If you want a structured second opinion on what you find, the conversation is available.
See Your Multi-Cloud Attack Surface as
One Unified Risk Model
Cy5’s team works with Indian enterprise security leaders to map cross-cloud exposure across AWS, Azure, and GCP, identifying the federated identity relationships, attack paths, and compliance gaps your current tools are missing. Structured assessment. No sales process.
Questions Security and DevSecOps Leaders Ask About How CNAPP Works in Multi-Cloud
CNAPP works in multi-cloud by ingesting security telemetry from all cloud providers; AWS, Azure, GCP, normalizing it into a unified schema, building a single risk graph of cross-cloud asset relationships, and surfacing attack paths that span cloud boundaries. This three-layer architecture, telemetry normalization, unified risk graph, and governance action, replaces the fragmented model of cloud-native tools operating independently with no shared context between provider environments.
Cloud-native tools fail in multi-cloud because each is designed for its provider’s data model and attack surface. AWS Security Hub does not understand Azure Managed Identities. Microsoft Defender does not model GCP IAM relationships. No individual cloud-native tool has visibility into the federated identity trusts and cross-account role assumptions that connect cloud environments, which is precisely where cross-cloud attack paths, the most dangerous class of multi-cloud risk, originate and propagate.
A cross-cloud attack path is a sequence of exploitable conditions spanning multiple cloud providers, for example, a compromised AWS IAM role that can authenticate to Azure Active Directory through a federated trust, then access Azure storage containing sensitive data. CNAPP detects cross-cloud attack paths by maintaining a unified identity and asset graph across all providers, enabling graph traversal queries that find dangerous chains even when each individual step appears benign to a single-provider security tool.
CERT-In’s 6-hour breach reporting mandate requires real-time detection across all cloud environments, including multi-cloud deployments. A unified CNAPP platform with event-driven ingestion from all cloud providers evaluates configuration changes within seconds across AWS, Azure, and GCP simultaneously, eliminating the per-provider scan delays that create detection gaps. For Indian enterprises with multi-cloud infrastructure, this event-driven multi-cloud architecture is the only approach structurally compatible with CERT-In’s 6-hour window.
The best CNAPP platform for Indian multi-cloud environments must satisfy four criteria: native ingestion from AWS, Azure, and GCP with event-driven architecture for CERT-In compliance; unified identity graph covering federated trusts across providers; prebuilt compliance packs for CERT-In, DPDP Act, RBI IT Governance, and SEBI frameworks; and India-specific deployment experience.
Cy5’s ion platform was built with Indian regulatory requirements as first-class capabilities and has documented multi-cloud deployments across BFSI and GCC enterprises in India.
CNAPP handles multi-cloud IAM by building a unified identity graph that maps AWS IAM roles, Azure Managed Identities, GCP Service Accounts, and federated identity trusts into a single model. This graph reveals cross-cloud permission relationships that each provider’s native IAM tooling cannot see, including which AWS principals can assume Azure identities, which GCP service accounts have permissions in AWS through workload identity federation, and which identities hold over-privilege across multiple cloud environments simultaneously.
Indian GCCs typically manage cloud infrastructure across parent-company cloud standards and Indian regulatory requirements simultaneously, often running different cloud providers for different workload types. The most effective implementation approach is deploying CNAPP coverage across all cloud environments before adding providers, rather than retrofitting security after multi-cloud complexity accumulates. GCCs that deploy unified CNAPP from their second cloud deployment onward avoid the cross-cloud security debt that makes later remediation programs significantly more expensive.
Multi-cloud risk visibility is the ability to see security posture, attack paths, and compliance status across all cloud environments from a single interface, without requiring per-provider analysis or manual data normalization. CNAPP provides multi-cloud risk visibility through a normalized asset graph that represents resources, identities, configurations, and vulnerabilities from AWS, Azure, and GCP in a common data model, enabling unified risk prioritization that ranks findings by actual business impact regardless of which cloud provider they originate from.
CNAPP supports multi-cloud DevSecOps by integrating security into the development pipeline across all cloud providers, scanning Terraform, CloudFormation, and Deployment Manager templates for misconfigurations before deployment; evaluating whether pipeline changes create or extend cross-cloud attack paths; and generating developer tickets with specific remediation guidance that references the cross-cloud context of the finding. DevSecOps teams operating across multiple clouds need a single security integration, not separate pipeline plugins per provider.
CNAPP reduces multi-cloud alert noise through cross-cloud correlation: instead of generating independent alerts from three cloud provider security services, potentially tripling the noise for the same underlying risk, the CNAPP correlation engine identifies whether findings across providers are steps in the same attack path and surfaces them as a single correlated finding. Multi-cloud CNAPP deployments consistently produce 85–96% reductions in actionable alert volume compared to running cloud-native security tools independently across each provider environment.
Key Takeaways
- How CNAPP works in multi-cloud is an architecture question, not a feature question, three cloud-native tools covering three clouds is not multi-cloud security.
- The 3-Layer CNAPP Multi-Cloud Security Model, Telemetry Normalization, Unified Risk Graph, Action and Governance, is the architectural template for evaluating genuine multi-cloud CNAPP capability.
- Cross-cloud attack paths, where exploitable conditions span cloud provider boundaries, are invisible to cloud-native security tools and are actively documented attack techniques in MITRE ATT&CK for Cloud.
- CERT-In’s 6-hour reporting mandate requires event-driven multi-cloud telemetry ingestion, scheduled scanning across multiple providers creates compounding detection gaps.
- Indian enterprises should deploy unified CNAPP coverage before adding cloud providers, not after, to prevent cross-cloud security debt that compounds with each additional environment.
About the Author
Kumar Shantanu specializes in translating complex cloud security architecture, CNAPP strategy, and multi-cloud risk management concepts into executive-ready insights for CISOs, DevSecOps leaders, and enterprise security teams. At Cy5.io, he develops research-driven thought leadership content focused on attack path analysis, cloud identity risk, compliance automation, and modern cloud security transformation.
