Last quarter I did an inventory I'd been putting off. I listed every security tool touching our Amazon Web Services (AWS), Google Cloud Platform (GCP), and Azure footprints, and I put a dollar figure next to each one. Three cloud security posture management (CSPM) consoles because two clouds came with their own, a standalone cloud infrastructure entitlement management (CIEM) nobody had opened in two months, a data security posture management (DSPM) tool we bought in a panic after an audit finding, and a cloud-native application protection platform (CNAPP) that was supposed to retire half of those and retired none. By the time I got to the bottom of the list, I realized something I hadn't wanted to say out loud: the stack itself had become the operational risk. The thing I bought to manage cloud risk was now a source of it.
Multi-cloud security needs fewer, better-placed tools. I now start with provider-native controls where they're genuinely good, then use one unified platform layer for cross-cloud posture and correlation. Agentless scanning supplies breadth. Those deliberate bets replaced eleven reluctant renewals; everything else on my list was a renewal I'd been talked into to close a gap the last purchase opened.
In brief
- Security teams need unified, end-to-end visibility and centralized cloud monitoring, backed by tools that correlate signals across providers.
- CSPM, cloud workload protection platform (CWPP), CIEM, DSPM, and CNAPP form the acronym mountain, and it is the industry's confession. Every category exists because the last purchase didn't close the gap.
- The platforms that promise consolidation were themselves built by acquiring the point-tool categories they now bundle. That's the strongest possible signal those categories needed unifying.
- A lean stack covers more than a tall one, but agentless scanning has a hard limit at runtime. It tells you a vulnerability exists; live exploitation requires runtime telemetry.
Multi-cloud security as a visibility problem
Teams often secure each cloud first, then the connections between them. The advice is true and operationally useless, because it implies the answer is more controls per cloud, which is exactly how you end up with my inventory. A per-cloud view can miss the moment when a credential stolen in Azure gets used against a correctly configured resource in AWS.
Security teams need end-to-end visibility, and the standards bodies land there without selling anything. NIST calls for complete end-to-end visibility between the access endpoint and the IT resource endpoint, including when the resource sits inside a cloud provider's network. NIST frames visibility as an architectural requirement that drives the security design. Across cloud environments, CISA's SCuBA guidance emphasizes standardized logging, telemetry, and centralized monitoring. NIST and CISA point toward consistent posture and unified telemetry over more category purchases.
Every coverage gap got answered with another acronym
The category map tells the same story I saw in operations. Several of the categories that now sit inside cloud and multi-cloud security programs are defined in CISA's cloud use case guidance. CSPM is the box for control-plane configuration the perimeter tools couldn't see; CWPP is the box for runtime workload behavior; CIEM is the box for cloud identity and permissions; DSPM is the box for the data layer. Then CNAPP emerged to bundle the first four back together. In practice, every acronym is a receipt for a gap teams were still trying to close.
The market voted with its wallet too. Buyers can consolidate vendors to cut complexity and reduce duplicative point-solution costs as contracts renew across workload, posture, entitlement, and container security offerings. Wiz acquired Gem Security for roughly $350 million, and CEO Assaf Rappaport framed the deal as part of a broader push toward security consolidation. The dissent matters too: Forrester analysts Andras Cser and Sandy Carielli argue that a CNAPP bundle can make useful cloud workload, posture, API, serverless, IaC, and container capabilities unnecessary or misleading under the CNAPP label. Both can be true: the categories needed unifying, and a bad bundle is still a bad bundle.
The tooling mountain creates the gaps it was bought to close
Every tool you add generates its own alert stream that nobody correlates with the others. Over 70% of teams struggle with alert fatigue, with Sumo Logic also finding many teams field more than 10,000 alerts a day. Modern organizations deploy an average of 28 security monitoring tools, each generating its own alert stream. [Stat needs approved-source replacement] And 69% of organizations report tool sprawl and visibility gaps as the biggest barriers to security effectiveness, because platform dashboards remain disconnected. [Stat needs approved-source replacement] Those gaps create exactly the blind spots the tools were bought to remove.
Attackers live in that blind spot. For 34% of 2024 intrusions, the initial infection vector could not be determined, a proportion tied to potential deficiencies in enterprise logging and detection capabilities. Cloud identity attacks can bypass multifactor authentication and allow long-term access and data exfiltration without triggering alerts. The trap is straightforward: you buy eleven tools to see more, and the seams between them are precisely where the credential abuse, measured at 35% of cloud incidents, walks through untriaged.
A lean stack covers more than a tall one: native controls, one platform, agentless breadth
I start with provider-native controls where they're genuinely good. AWS GuardDuty's Extended Threat Detection correlates multi-stage attack sequences across CloudTrail, Amazon Elastic Kubernetes Service (EKS) audit logs, and runtime behaviors within an account, with MITRE ATT&CK mapping. A useful comparison of cloud-native vs. third-party security tools makes the same point: cloud-native tools may offer deeper coverage within their own cloud environments because the vendor has detailed knowledge of how its own services work. That depth is real, and it's free or cheap; the limit is in the phrase: within their own cloud.
Above the native controls, one unified platform layer handles the cross-cloud correlation I don't want to bet on any single provider console to handle cleanly. Agentless scanning supplies breadth by connecting to cloud APIs to inventory and assess posture across every account in minutes, including ephemeral resources, without a fleet rollout. Deliberately placed, those bets cover more than my eleven-tool inventory did. I gave up depth for it: a best-of-breed CIEM may reason about entitlements more deeply than a platform's CIEM module, and I traded that depth on purpose because I was running a CIEM nobody opened.
What agentless scanning buys you and where it stops
Agentless is the right default for breadth because it deploys via API integration, imposes zero in-guest overhead, and covers workloads where agent installation is unavailable. For vulnerability discovery and posture, it's a common approach. It can tell you what you have and how it's configured across multiple clouds from a single platform. I bought it for that breadth.
Agentless scanning stops at runtime, and overclaiming here gets people breached. The trade-off is fundamental: agentless scanning can tell you a vulnerability exists; live exploitation requires runtime telemetry. Scans typically run on a scheduled interval and capture snapshots instead of live process or network behavior. If you need live defense, put a runtime agent on your business-critical workloads. An agentless dashboard cannot do that job for you.
When consolidation is the wrong call
A taller stack can be right when a team has deep staffing or hard resilience and regulatory constraints. Large enterprises may have the operational capacity to run deeper stacks: platformization is especially useful for smaller teams with limited specialized skills, while larger enterprises with hundreds of security professionals and deeper specialization are better positioned to make best-of-breed work. If you have the SecEng bench to operate ten tools well, depth can beat unification.
Operational resilience and regulatory pressure are the other clear exceptions. The consolidation argument weakens when operational resilience and regulatory frameworks such as NIS2 enter the picture, as BeyondTrust's Morey Haber notes. Healthcare HIPAA/HITRUST work and financial services' highest regulatory bars of any industry can push teams toward depth that a mainstream platform may not carry. And when a genuinely novel threat vector emerges, a platform may lag until the problem is understood, so the startup point tool may be the least-bad option.
The honest version of my argument names these exceptions, even though most teams I talk to aren't in any of them and are still buying like they are.
The question I now ask before adding any cloud security tool
The tool I killed at renewal was a standalone DSPM product I bought for multi-cloud coverage after an audit finding spooked me. It scanned data stores across all three clouds, produced beautiful maps, and overlapped almost entirely with posture functions I already had in the platform layer. Nobody triaged its findings. I'd bought a category to close a gap that two of my other tools already covered, badly, in parallel. At renewal I cut it and folded the requirement into the platform.
I now open every platform demo with the same question, the one I started asking after that inventory: which of my existing tools does this retire? I don't ask what it adds, because everything adds something. If a vendor can't name the line items their product lets me cancel, they're selling me the next acronym, and I've already got a mountain of those.
My buying principle is one sentence: every category on the stack has to either go deep where I genuinely need depth, or earn its place by killing two other line items. I would renew the native controls, the one correlation platform, and the agentless scanner tomorrow. Everything else has to survive that question.
Frequently asked questions about multi-cloud security
How should I define multi-cloud security for a SecOps program?
Multi-cloud security is the practice of maintaining consistent posture, visibility, and threat detection across two or more cloud providers like AWS, GCP, and Azure. Teams have to correlate signals across them so an attack that pivots from one provider's identity plane to another's resources doesn't slip through the seams. The requirement is common operational visibility and control across multiple cloud providers, with complete visibility into the enterprise network environment rather than isolated per-cloud management.
Do I need different security tools for each cloud provider?
Use provider-native controls where they are strong, then cover cross-cloud correlation separately. Provider-native controls like AWS GuardDuty, Microsoft Defender for Cloud, and Google Security Command Center are genuinely strong within their own cloud, because the providers have proprietary knowledge of their own services. They all leave the same gap: cross-cloud correlation. A leaner architecture uses native controls per cloud where they're good, plus one unified platform layer above them for posture and correlation that sits outside any single provider's console.
When should I use agentless cloud security scanning?
Use agentless scanning when you need broad inventory and posture coverage without installing software inside workloads. It connects to cloud provider APIs to assess ephemeral and unsupported workloads, making it useful for vulnerability discovery and posture assessment. Its hard limit is runtime: it captures snapshots on an interval, so it can tell you a vulnerability exists while live exploitation still requires runtime telemetry.
Is a CNAPP enough for multi-cloud security?
For most teams it covers the majority of the posture and correlation requirement, which is why the major platforms were built by acquiring the underlying point categories. A CNAPP by itself still leaves runtime work on business-critical workloads where live process and network visibility matter. It also trades best-of-breed depth, which can be the wrong call for large specialized teams or heavily regulated industries.
How do I justify cutting cloud security tools at renewal?
Lead with the inventory and argue with the invoice. Count what each category costs in renewals, agents deployed, consoles checked, and findings nobody triages, then ask of every tool whether it goes genuinely deep or duplicates something you already run. The strongest justification is that tool sprawl creates blind spots: fragmented, uncorrelated tools force teams to manually correlate alerts across siloed telemetry, which is exactly the seam attackers move through.