Gartner projects that through 2026, 99% of cloud security failures will be the customer's fault — not the cloud provider's. The Cloud Security Alliance ranks misconfiguration as the single biggest threat to cloud computing, with identity and access management close behind. And 78% of organisations now run two or more cloud providers, up from 71% just a year earlier, with the average enterprise's cloud footprint built across roughly three providers. Put those three facts together and the picture is clear: the cloud isn't insecure because the provider failed. It's insecure because almost nobody can actually see everything they've built across it.

Post 4.2 covered SASE securing the network edge — the path traffic takes to get to its destination. This post covers what happens once it arrives: the workloads, containers, identities, and misconfigured storage buckets sitting inside multiple cloud environments that most security teams only see in fragments, one native console at a time.

What CNAPP Actually Replaces

Cloud security used to be assembled from separate point tools, each covering one slice of the problem: Cloud Security Posture Management (CSPM) scanning for misconfigurations, Cloud Workload Protection Platforms (CWPP) securing running workloads, Cloud Infrastructure Entitlement Management (CIEM) untangling who and what can actually access what, and increasingly, Infrastructure-as-Code scanning catching misconfigurations before they're ever deployed. Each tool did its own job reasonably well. None of them talked to each other, and none of them, on its own, could answer the question that actually matters during an incident: given this misconfigured bucket, this over-privileged service identity, and this vulnerable container, what's the realistic attack path an adversary could actually walk?

Cloud-Native Application Protection Platform (CNAPP) is the consolidation of those previously separate tools into one platform with shared context — the same convergence logic that drove SASE in the network layer, applied to what happens once workloads are actually running in the cloud. The CNAPP market reached roughly $10.9 billion in 2025 and continues growing at north of 20% annually, and cloud security overall is the single fastest-growing subsegment of the entire $244.2 billion 2026 global security market, expanding at 28.8%. That growth rate is the market's own admission that fragmented point tools stopped being sufficient.

The Core Components

Cloud Security Posture Management (CSPM). Continuously scans cloud configurations against best-practice and compliance baselines — the layer that catches the publicly exposed storage bucket or the security group left open to the internet before an attacker finds it first.

Cloud Workload Protection (CWPP). Runtime security for the actual compute — virtual machines, containers, and serverless functions — detecting malicious behaviour and vulnerabilities in workloads that are already running, not just how they were configured at deployment.

Cloud Infrastructure Entitlement Management (CIEM). Maps and right-sizes permissions across an environment where the number of identities — human and machine — routinely outnumbers the number of employees by an order of magnitude, and where over-provisioned access is the default state unless something actively corrects it.

Infrastructure-as-Code (IaC) scanning. Catches misconfigurations in Terraform, CloudFormation, and similar templates before they're ever deployed — shifting the same "left" instinct DevSecOps applies to application code into the infrastructure definitions that provision the cloud environment itself.

Kubernetes and container security. Purpose-built visibility into orchestration layers that traditional workload scanning was never designed for — image scanning, runtime container behaviour, and the orchestration control plane itself.

The point of consolidating these into one platform isn't tidiness. It's that an attack path in a modern cloud environment almost never involves just one of these layers — it's a misconfigured resource, reached via an over-permissioned identity, exploited through a running workload, and the only way to see that full chain is a platform that has visibility into all of it simultaneously.

Why "Protecting What You Can't See" Is the Right Framing

Three separate forces make cloud visibility harder than traditional infrastructure ever was. First, the shared responsibility model itself is where most of the Gartner 99% statistic actually originates — cloud providers secure the infrastructure underneath their services, but everything built on top of it, from IAM policy to storage permissions to network configuration, is the customer's job, and that division of responsibility is routinely misunderstood or simply not operationalised by the teams actually building in the cloud.

Second, cloud infrastructure is ephemeral in a way traditional infrastructure never was. A container can spin up, run for ninety seconds, and terminate — existing for exactly long enough to do damage and gone before any point-in-time scan would have caught it. Serverless functions have no persistent host to inventory at all. Security tooling built around periodic scanning of static infrastructure fundamentally cannot keep pace with infrastructure that no longer holds still.

Third, multi-cloud fragmentation compounds both problems. Each provider's native security tooling sees only its own environment — AWS's tools see AWS, Azure's tools see Azure — and with the average enterprise running roughly three providers, that means three separate, non-overlapping views of a security posture that attackers experience as one continuous environment, not three walled-off ones. An attacker moving from a compromised identity in one cloud to a resource in another doesn't respect the boundary your tooling was built around.

What This Means for Every IT Leader

1. If an attacker compromised one cloud identity today, could you trace the realistic blast radius across every cloud provider you run — or only within the one where it started? Native, single-provider tools cannot answer this question by design. It requires a platform with cross-cloud visibility, which is precisely the gap CNAPP is built to close.

2. How much of your cloud security posture is verified continuously versus checked at a point in time during the last audit? Given how briefly ephemeral infrastructure exists, a posture that was compliant during last quarter's scan tells you very little about what's actually running right now.

3. Do you know, with confidence, how many machine identities exist across your cloud environments and what each one can actually access? If the honest answer is no, this is very likely your largest unmanaged attack surface — CIEM exists specifically because most organisations have lost track of an identity population that dwarfs their human headcount.

The Bottom Line

The Gartner statistic that opened this post — 99% of cloud security failures being the customer's fault — is not an indictment of cloud computing. It's a precise description of where the actual work is: not in trusting the provider less, but in gaining continuous, cross-cloud visibility into the configurations, workloads, and identities the customer is entirely responsible for. CNAPP is the architectural answer to that problem the same way SASE was the architectural answer to the network edge — consolidation not for its own sake, but because the attack paths that actually matter cut across the boundaries separate point tools were never built to see past.

Sources: Gartner cloud security spending and failure forecasts, 2026, Cloud Security Alliance top threats research, Fortinet 2025 State of Cloud Security Report.