CNAPP adoption is shifting toward unified cloud risk control

At a glance

What this is: This is Orca Security’s take on Gartner’s 2025 CNAPP Market Guide, with the key finding that buyers are moving toward unified cloud risk control across the application lifecycle.

Why it matters: It matters because the same consolidation logic is now shaping how security teams govern cloud workloads, machine identities, and developer workflows, which directly affects IAM, NHI, and DevSecOps operating models.

By the numbers:

• By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Orca Security’s analysis of Gartner’s 2025 CNAPP market guide

Context

CNAPP is the cloud security category built to unify configuration, workload, identity, data, and application risk across development, deployment, and runtime. The problem it is trying to solve is not just more alerts, but fragmented control planes that leave teams unable to see how cloud-native risk actually composes across environments.

For IAM and NHI programmes, the important shift is that cloud risk is increasingly being judged through relationships, not isolated findings. That makes identity context, entitlement sprawl, and developer workflow integration part of the same governance problem, especially where service accounts, tokens, and workload permissions drive cloud exposure.

Orca Security’s summary of Gartner’s report reflects a market that is maturing around consolidation, context, and operational fit. The starting position is typical: most organisations already have too many tools and too little connected visibility across cloud and application layers.

Key questions

Q: How should security teams evaluate CNAPP tools for cloud identity governance?

A: Security teams should test whether a CNAPP can connect identities, workloads, data, and code into a single risk path, not just list separate findings. The real question is whether the platform can show reachability, ownership, and remediation priority in one view. If it cannot, it improves visibility but not governance.

Q: Why does CNAPP matter for NHI and workload identity programmes?

A: CNAPP matters because cloud-native exposure often depends on non-human identities such as service accounts, roles, and tokens. If those identities are over-privileged or poorly contextualised, the platform can see the symptom but not the blast radius. CNAPP becomes useful when it helps teams understand what an identity can actually reach.

Q: What do security teams get wrong about unified cloud security platforms?

A: Teams often assume consolidation alone solves cloud risk. In practice, a unified platform only helps if it preserves context across development, deployment, and runtime, and if it can map risk to the correct owner. Without that, the organisation just centralises noise in one console.

Q: How can organisations tell whether developer-friendly security is working?

A: Developer-friendly security is working when findings move into the tools engineers already use and are resolved faster without losing policy fidelity. Look for fewer handoffs, shorter remediation cycles, and better context at the point of fix. If alerts still sit outside the development flow, friction remains too high.

Technical breakdown

Why CNAPP is consolidating CSPM, CWPP, CIEM, and DSPM

CNAPP emerged because cloud-native environments broke the assumptions behind single-purpose tools. CSPM sees configuration drift, CWPP sees runtime behaviour, CIEM sees identity entitlements, and DSPM sees sensitive data exposure, but none of them alone explain how a toxic path forms from misconfiguration to privilege abuse to data access. CNAPP ties those signals together in one graph or data model so teams can prioritise by effective risk rather than by alert volume. That is why market demand is moving toward platforms that connect assets, identities, workloads, and code in one control view.

Practical implication: Practitioners should evaluate whether their current stack can correlate identity, workload, and data paths before they add another point tool.

How cloud-native lifecycle context changes risk prioritisation

Cloud-native risk is lifecycle risk. The same application may be safe in code review, exposed in deployment, and highly privileged at runtime, which means the meaning of a finding changes depending on where it appears. Gartner’s framing reflects a practical reality: prioritisation improves when security teams can connect IaC, containers, production telemetry, and identity permissions into one policy and workflow loop. Without that, teams waste time on findings that are technically real but operationally low value, while missing combinations that actually create blast radius.

Practical implication: Security teams should prioritise controls that preserve context from source code to runtime instead of treating each layer as a separate queue.

Why developer experience now sits inside the security model

CNAPP adoption is partly a workflow problem. If security findings are disconnected from the tools developers already use, the organisation pays for visibility but still loses remediation speed. The Gartner guidance Orca cites is consistent with modern DevSecOps practice: guardrails work better than gates when they are embedded into ticketing systems, IDEs, SCM platforms, and CI/CD feedback loops. This is not about lowering standards. It is about making the secure path the fastest path without losing policy enforcement.

Practical implication: Practitioners should measure whether their security workflow reduces handoffs and preserves developer context at the point of fix.

Threat narrative

Attacker objective: The objective is to convert scattered cloud weaknesses into a reachable path to high-value workloads, credentials, or data.

1. Entry occurs when attackers exploit a cloud misconfiguration, exposed workload permission, or weakly governed identity path that sits outside isolated tool coverage.
2. Escalation follows when identity and workload relationships are not correlated, allowing the attacker to move from a narrow issue to broader access through over-privileged cloud entitlements.
3. Impact is reached when fragmented visibility prevents teams from seeing toxic attack paths before sensitive workloads, data, or control planes are reached.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CNAPP is becoming an identity governance problem, not just a cloud security category. The article’s core message is that cloud risk now depends on how identities, workloads, code, and data relate to one another across the lifecycle. That moves CNAPP out of a narrow posture discussion and into a governance model where entitlement scope, workload context, and remediation workflow are all part of the same control surface. Practitioners should treat CNAPP as an identity-adjacent control plane, not a standalone cloud dashboard.

Unified risk visibility is the named concept this market is converging on. The market is rewarding platforms that can explain not just what is misconfigured, but what that misconfiguration enables in context. That matters because alert aggregation without relationship mapping still leaves the highest-risk paths hidden. The practical conclusion is that buyers should ask whether their current tooling can trace privilege, exposure, and reachability as a single chain.

Developer experience is now a security control because friction determines whether risk gets remediated. Gartner’s emphasis on low-friction integration shows that security programmes are being judged on operational fit as much as detection depth. When findings do not reach the developer where they work, remediation slows and risk persists. Practitioners should re-evaluate controls that create visibility but not actionability.

CNAPP maturity is increasingly defined by whether the platform can collapse silos without collapsing accountability. Consolidation only helps if teams still know which identity, workload, or code owner must act. Otherwise the organisation gets a larger console with the same governance gap. The field is moving toward contextual ownership, where remediation is assigned from the graph, not from a generic queue.

Cloud-native zero trust is converging on relationship-based control rather than static policy alone. Gartner’s zero-trust reference point aligns with a broader shift: cloud access decisions are only as strong as the context feeding them. That makes identity context, asset relationships, and runtime state more important than isolated control checks. Practitioners should expect future cloud governance to depend on connected evidence, not just policy declarations.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• For broader lifecycle context, NHI Lifecycle Management Guide explains how provisioning, rotation, and offboarding should be governed across machine identities.

What this signals

Unified risk visibility is becoming the practical test for cloud security maturity. The organisations that can trace identity, workload, and data relationships in one control view will be able to prioritise remediation more accurately than teams still operating from disconnected point findings.

The governance signal is that CNAPP is no longer just a runtime or posture conversation. As cloud estates grow more interconnected, security teams need a model that can explain reachability, not just exposure, and that requires discipline across identity, code, and operational workflows.

When cloud teams adopt relationship-based prioritisation, they should also tighten NHI lifecycle controls in parallel. The same environment that needs consolidated visibility usually has the same hidden exposure problem in service accounts, secrets, and workload credentials.

For practitioners

• Map cloud identity relationships into one governance view Inventory how service accounts, roles, workloads, and data stores connect across your cloud estate, then identify paths where one entitlement can reach multiple sensitive assets. Use the result to prioritise remediation by reachability instead of by alert count.
• Embed security findings into developer workflows Route cloud and application findings into ticketing, SCM, and IDE processes so remediation happens where developers already work. Preserve context about why a finding matters and what dependency it affects, instead of handing over a bare technical alert.
• Test whether your stack can explain toxic attack paths Validate that your current tools can show how a misconfiguration becomes an exposure path through identity, workload, and data relationships. If they cannot, your programme is still operating on siloed findings rather than connected risk.
• Separate consolidation from ownership When evaluating platform consolidation, require clear assignment of remediation responsibility for identities, workloads, and application findings. A single platform only improves governance if it preserves who must act on each risk.

Key takeaways

• CNAPP is maturing into a governance layer that connects cloud configuration, identity, code, and runtime risk.
• The strongest programmes will use relationship context to prioritise remediation instead of treating every finding as equal.
• Security teams should judge cloud platforms by whether they improve actionability for developers, owners, and identity governance together.

Key terms

• Cloud-Native Application Protection Platform: A CNAPP is a unified cloud security platform that brings together posture, workload, identity, and data risk into one control model. It is designed to help teams understand how cloud-native exposure forms across development, deployment, and runtime rather than treating each layer separately.
• Toxic Attack Path: A toxic attack path is a sequence of connected misconfigurations, entitlements, and exposures that lets an attacker move from a small weakness to a high-value target. In cloud environments, the path is often only visible when identity, workload, and asset relationships are analysed together.
• Non-Human Identity: A non-human identity is any machine or software credential used by services, workloads, scripts, APIs, or automation. These identities often operate at scale and with broad access, so lifecycle control, visibility, and entitlement scope become critical governance issues.
• Reachability Analysis: Reachability analysis determines whether a vulnerable or misconfigured asset can actually be accessed from an attacker’s starting point. In cloud governance, it helps separate theoretical exposure from paths that materially increase blast radius.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Orca Security: the 2025 Gartner CNAPP Market Guide analysis. Read the original.