What Is a CWPP? Cloud Workload Protection

A cryptominer running inside a Kubernetes pod does not show up in a configuration scan. Neither does a reverse shell spawned from a web server process, or a binary writing to a directory it has no business touching, or an attacker reading a container's environment variables to steal a cloud credential. These are runtime events. They happen inside a workload while it executes, and the only thing positioned to see them is something running close enough to that workload to watch its processes, its memory, and its network calls as they happen. That something is a Cloud Workload Protection Platform.

A CWPP secures the workload itself: the unit of compute that runs your code, whether that is a virtual machine, a container, or a serverless function, and wherever it runs, on-premises, in one public cloud, or across several. Gartner coined the term for this category, and the defining idea is in the name: the protection is workload-centric, not network-centric and not account-centric. This guide covers what a CWPP is, the core capabilities it provides, how it deploys through agents and agentless scanning, the workload types it covers, and where it sits inside the larger CNAPP picture alongside posture management and identity. For the head-to-head contrast with posture management, see the CWPP vs CSPM breakdown; this page is about what CWPP is and how it works.

What is a Cloud Workload Protection Platform (CWPP)?

A Cloud Workload Protection Platform is a security product that protects server workloads at runtime, wherever they run. Gartner defines CWPPs as "workload-centric security products that protect server workloads in hybrid, multicloud data center environments." Unpack that and three things matter. Workload-centric means the unit of protection is the running workload, not the network segment around it or the cloud account above it. Server workloads means the compute that runs application code: VMs, containers, and serverless functions, plus the operating system and libraries inside them. Hybrid and multicloud means a CWPP follows those workloads across on-premises hardware, virtual machines, and multiple public cloud providers, giving one consistent set of controls instead of a different tool per environment.

The reason the category exists is that the cloud broke the old perimeter model of workload security. When workloads were long-lived servers behind a firewall, you protected them by protecting the network they lived on. Cloud workloads are different: they are ephemeral, they autoscale, they span providers, and a container may live for minutes. A network appliance never sees inside them. A CWPP solves this by attaching protection to the workload itself, so the controls travel with the workload no matter where it is scheduled or how briefly it lives.

A CWPP is not the cloud provider's control plane and does not try to be. The control plane decides how the cloud is configured: which storage buckets are public, which IAM roles carry which permissions, which networks allow what. A CWPP looks the other direction, from inside the workload outward, at what the workload is actually doing while it runs. That distinction, configuration versus runtime, is the line between posture management and workload protection, and it is the reason the two are separate categories that a complete program runs together.

Core CWPP capabilities

Gartner describes CWPP capabilities as a layered set of controls, from foundational hygiene at the base up to advanced runtime detection. The base layers matter most because they remove the conditions an attack needs; the upper layers catch what gets through anyway. A real CWPP combines most of the following.

Vulnerability scanning. The CWPP inventories the operating system, packages, and libraries inside each workload and image, and flags known vulnerabilities and missing patches. Scanning the running workload, not just the registry image, is what catches a vulnerable package that is actually loaded and reachable rather than merely present.

System hardening and configuration. It checks each workload against secure-configuration baselines, the OS settings, services, and permissions that should be locked down, and reports drift. This is the workload-level equivalent of posture management, applied inside the host rather than at the account level.

System integrity monitoring. File integrity monitoring watches critical files, binaries, and registry or configuration paths for unexpected change. A modified system binary or a new file in a sensitive directory is a strong tamper signal, and integrity monitoring is what surfaces it.

Application control and allowlisting. The CWPP can enforce application whitelisting so only approved binaries execute on a workload. On a server that should run a fixed, known set of processes, an allowlist turns "anything can run unless blocked" into "nothing runs unless approved," which shuts down most commodity malware before it starts.

Host-based intrusion prevention. A host-based IPS inspects activity on the workload and blocks known attack patterns, exploit attempts, and malicious traffic at the host, independent of any network device.

Behavioral runtime protection. This is the layer that catches active compromise. The CWPP models normal behavior for a workload and flags deviations: a web server process spawning a shell, an outbound connection to a known command-and-control host, a process reading credentials it never should. These signals only exist while the workload is alive, which is exactly why a runtime agent is needed to see them.

Network segmentation and microsegmentation. Host-based segmentation controls which workloads can talk to which, narrowing east-west traffic so a compromised workload cannot freely reach the rest of the environment. Tight segmentation is one of the most effective brakes on lateral movement.

Anti-malware and memory protection. Signature and behavioral anti-malware catches known malicious files, and memory protection guards against in-memory and fileless techniques that never write a malicious file to disk, the kind a file scanner alone would miss.

No single capability is the product. The value is the stack: hygiene controls shrink the attack surface inside each workload, and runtime controls detect and stop the compromise that slips past the hygiene. A CWPP that only scans for vulnerabilities is half a tool; a CWPP that only watches runtime behavior without hardening the workload first leaves more for the runtime layer to catch.

How a CWPP works: agent-based and agentless

A CWPP has to see inside the workload, and there are two ways to get that visibility. Most platforms use both, because each answers a question the other cannot.

Agent-based deployment installs a lightweight sensor on the host or inside the container or VM image. The agent runs alongside the workload and watches it from the inside: processes as they spawn, files as they change, network connections as they open, memory as it is accessed. This is the only way to get true runtime visibility, because runtime behavior exists only while the workload is executing and only the thing running next to it can observe it as it happens. The cost is operational: agents have to be deployed, kept current, and accounted for in performance, and an agent that is not installed on a workload protects nothing.

Agentless deployment skips the in-workload sensor and inspects the workload from outside, typically by analyzing a snapshot of the disk or the VM through the cloud provider's API. This is fast to roll out, covers workloads you cannot or did not install an agent on, and is well suited to vulnerability scanning, configuration assessment, and inventory: questions you can answer from a point-in-time picture of the workload's contents. What it cannot do is watch live behavior. A snapshot taken every few hours will never see a process that spawned and exited in between, which is why agentless alone is a posture view of the workload, not a runtime one.

The two are complementary, not competing. Agentless gives broad, low-friction coverage and finds the vulnerabilities and misconfigurations sitting in every workload. Agent-based gives the deep, continuous runtime detection that catches an attack in progress on the workloads that warrant it. The practical pattern is agentless everywhere for breadth, agents on the workloads where active-compromise detection is worth the operational cost: the long-lived hosts, the clusters handling sensitive data, the internet-facing services.

What workloads a CWPP covers

The "workload" in CWPP is deliberately broad, because cloud compute comes in several shapes and each has its own protection problem. A CWPP aims to cover all of them with one consistent set of controls.

Virtual machines. The most traditional cloud workload: a full OS running on virtualized hardware, often long-lived. VMs take the full CWPP stack, an agent for runtime visibility, vulnerability and configuration scanning, integrity monitoring, host IPS, and behavioral protection, because they look most like the servers workload security grew up protecting.

Containers. Short-lived, packaged, and orchestrated, usually by Kubernetes. Containers shift the protection problem: you scan the image before it ships, enforce that only approved images run, and monitor container runtime behavior for the same anomalies you watch for on a VM, but compressed into a much shorter and more dynamic lifecycle. Container coverage also extends to the orchestration layer, which has its own configuration and runtime concerns.

Serverless functions. The most ephemeral workload: code that runs on demand for seconds and then disappears, with no host you manage. There is nowhere to install a traditional agent, so CWPP coverage of serverless leans on scanning function code and dependencies for vulnerabilities, checking function permissions and configuration, and monitoring invocation behavior through the provider's instrumentation rather than a host sensor.

The common thread is that a CWPP is supposed to give you one place to protect compute regardless of its form, instead of one tool for VMs, another for containers, and a blind spot for serverless. The capabilities apply differently across the three, but the goal is consistent visibility and control wherever your code actually runs.

CWPP within CNAPP, alongside CSPM and CIEM

A CWPP does not work alone, because runtime protection of a workload is only one slice of cloud security. In 2021 Gartner introduced the Cloud-Native Application Protection Platform (CNAPP), a category that combines several cloud security functions into one platform. CWPP is the workload-runtime pillar of CNAPP. The other core pillars are Cloud Security Posture Management (CSPM), which finds misconfigurations in the cloud control plane, and Cloud Infrastructure Entitlement Management (CIEM), which governs identities and permissions. CNAPP typically folds in adjacent capabilities too, such as Kubernetes security posture management and infrastructure-as-code scanning.

The reason these were unified is that a real cloud incident crosses all of their boundaries. A misconfiguration exposes a workload (a CSPM concern). An over-permissioned role gives an attacker reach once they land (a CIEM concern). The actual compromise, the malicious process, the credential theft, the lateral movement, happens inside the running workload (a CWPP concern). Treated as three separate tools in three separate consoles, the connection between these findings is left for a human to reconstruct. Unified under CNAPP, they can be correlated: this internet-exposed workload, running with this over-permissioned role, has this unpatched critical vulnerability and is showing this suspicious runtime behavior, so investigate it first.

Inside a CNAPP, the CWPP engine still does what it always did, runtime protection of the workload, but now shares context with posture and identity instead of living in isolation. This is also where CWPP overlaps with cloud detection and response, which focuses on the runtime detection and investigation half of the problem. Understanding that CWPP is the workload-runtime layer, separate from the posture layer and the identity layer, is what lets a defender read a CNAPP's findings correctly and tell a workload compromise from a configuration exposure even when one screen shows both.

How CWPP fits for cloud defenders

For a SOC or DFIR practitioner, the value of a CWPP is the telemetry it produces and the detections it makes possible. Posture tooling tells you a workload was exposed; a CWPP tells you what happened on it. When an investigation reaches a cloud workload, the questions are concrete: what processes ran, what files changed, what network connections opened, was a known vulnerability exploited, did anything touch credentials or sensitive memory. Those are the questions a CWPP agent's runtime data answers, and without that data the answer to "what did the attacker actually do inside this workload?" is guesswork.

A CWPP also shifts work earlier. Vulnerability and configuration scanning at the workload and image level catches exploitable conditions before an attacker does, and application allowlisting and segmentation remove whole classes of attack from the table rather than waiting to detect them. The defender's leverage is that hardening a workload is cheaper than catching the intrusion that exploits a soft one, and a CWPP is where that hardening and that catching live in the same tool.

The honest framing is that a CWPP is necessary but not sufficient. It protects the workload, which is one layer of the cloud. It does not see the misconfigured account around the workload, and it does not govern the identities that reach it. That is the case for running it alongside posture and identity management, increasingly together under CNAPP, so the runtime view a CWPP provides is correlated with the exposure and the access that made the compromise possible. The workload is where the attack lands; the CWPP is what watches the landing.

The bottom line

A CWPP secures the running workload: the VMs, containers, and serverless functions where your code actually executes, across on-premises and multiple clouds. Gartner coined the category around that workload-centric idea, and its controls run from foundational hygiene, vulnerability scanning, hardening, integrity monitoring, application allowlisting, up to runtime detection, behavioral protection, memory protection, and host-based segmentation and IPS. It deploys through agents for deep runtime visibility and agentless scanning for fast, broad coverage, and most real deployments use both.

What makes a CWPP matter to a defender is that it is the only layer positioned to see what happens inside a workload while it runs, the malicious process, the credential theft, the lateral movement, that no configuration scan and no network device will ever catch. It is one pillar of the larger cloud picture, sitting under CNAPP next to posture management and identity governance, and it is necessary but not sufficient on its own. The workload is where the attack lands. The CWPP is what watches the landing, and the runtime evidence it produces is what turns a cloud investigation from guesswork into a record of what actually happened.