Orca’s CNAPP pricing pitch exposes the cost of fragmented security

At a glance

What this is: This is an Orca Security blog post arguing that CNAPP pricing complexity often reflects fragmented cloud security coverage and governance gaps.

Why it matters: It matters because IAM, NHI, and security architecture teams often inherit pricing-driven product fragmentation that obscures entitlement scope, weakens control consistency, and complicates programme design.

By the numbers:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.

👉 Read Orca Security's analysis of CNAPP pricing and cloud security packaging

Context

CNAPP pricing is not just a commercial choice. It often reveals how a vendor thinks about control boundaries, entitlement scope, and whether cloud security can stay coherent across development, workload, and runtime layers. When pricing is split into tiers and add-ons, practitioners usually inherit the same fragmentation in visibility and response.

For IAM and identity-security teams, the practical question is whether the platform model reinforces a consistent governance plane or encourages capability silos. That matters for non-human identities, workload identity, and any programme trying to align cloud security controls with least privilege, lifecycle management, and access review discipline.

Key questions

Q: How should teams evaluate CNAPP pricing when identity governance is a priority?

A: Teams should map pricing to governance outcomes, not feature names. The key test is whether posture, runtime, AppSec, and identity-relevant controls operate under one consistent policy model or become fragmented across tiers. If the contract forces separate decisions for core protection, the programme will usually inherit operational gaps and uneven enforcement.

Q: Why do tiered cloud security packages create governance risk?

A: Tiered packages create risk when they separate visibility, detection, and response into different commercial buckets. That can leave workloads partially covered, weaken least privilege enforcement, and make it harder to prove consistent control ownership. In practice, the commercial model becomes a proxy for how fragmented the security architecture really is.

Q: What should practitioners check before buying a unified CNAPP platform?

A: They should check whether the platform truly keeps policy, telemetry, and remediation aligned across development and runtime. If extra spend is needed to move protection between environments or enable key controls, the platform is not operationally unified even if the marketing says it is.

Q: When does pricing complexity become an identity management issue?

A: Pricing becomes an identity issue when it changes who gets visibility into workloads, which controls are enabled, and how consistently access is governed across environments. If packaging determines security scope, identity and access decisions stop being purely technical and become a procurement constraint.

Technical breakdown

One SKU versus control fragmentation in CNAPP

A single-SKU model is a packaging choice, but it also signals whether controls are meant to operate as one security system or as separable modules. In CNAPP, fragmentation usually appears when data security, AppSec, runtime protection, and detection are purchased or enabled independently. That can create inconsistent telemetry, uneven policy enforcement, and gaps between what is scanned and what is actually protected. From an identity perspective, this matters because entitlement decisions and runtime controls need a shared view of workload context. If the platform fragments that view, governance becomes harder to prove and harder to operationalise.

Practical implication: assess whether pricing structure mirrors a fragmented control plane before you standardise on the platform.

Workload credits, runtime protection, and access scope

Flexible credit reallocation sounds commercial, but technically it reflects whether security coverage can move with workload demand. In cloud environments, capacity shifts quickly across development, staging, and production, so static packaging can leave certain environments under-protected. The underlying issue is scope: teams need to know whether runtime protection, scanning, and posture checks can follow the asset as it changes. That is especially relevant when cloud workloads depend on non-human identities, because control effectiveness depends on where those identities operate, not just what was bought in a contract.

Practical implication: validate that the purchased controls can follow workload movement without forcing a new commercial decision.

Why pricing tiers often hide governance boundaries

Tiered pricing is frequently presented as flexibility, but it can hide the real governance boundary between features that are integrated in name and disconnected in practice. When core capabilities are split across SKUs, teams may have to choose between broader visibility and deeper protection, which is a poor trade-off for modern cloud programmes. This is less a procurement issue than a governance one: an incomplete control set encourages exceptions, manual workarounds, and inconsistent policy enforcement. Identity teams should treat pricing architecture as a proxy for how much operational consistency the platform can actually deliver.

Practical implication: map each pricing tier to the exact governance outcomes it can and cannot support.

NHI Mgmt Group analysis

Pricing complexity is usually a symptom of control fragmentation, not just commercial design. When a CNAPP vendor splits core capabilities into tiers and add-ons, it is often exposing a deeper architectural reality: the security model is not fully unified. That matters because cloud security outcomes depend on consistent context across posture, runtime, and application layers. The implication is that practitioners should treat pricing structure as an indicator of governance coherence, not merely budget predictability.

One-SKU packaging can reduce procurement friction, but it also raises the bar for operational proof. If a platform claims unified coverage across CNAPP, AppSec, and runtime, the question is whether identity, telemetry, and policy decisions really share a common plane. This is where NHI governance becomes practical, because workload access and runtime protection must be visible in the same control model. Practitioners should demand evidence of control continuity, not just convenience in contracting.

Fragmented entitlement models create identity blind spots in cloud security programmes. When coverage is tied to separate features or credits, teams can end up with partial visibility into the very workloads whose identities need the tightest governance. That makes least privilege harder to enforce and lifecycle controls harder to verify across cloud environments. The practitioner conclusion is simple: if the commercial model is fragmented, the governance model usually is too.

Runtime security cannot be governed well when commercial boundaries dictate control boundaries. If teams can only extend protection by buying another tier, they are not managing security dynamically. They are managing exceptions through procurement. That pattern weakens programme maturity because policy scope, detection scope, and response scope stop moving together. Identity leaders should read packaging decisions as a signal of how much friction they will face when trying to operationalise unified cloud control.

From our research:

• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to the 2024 Non-Human Identity Security Report.
• 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which shows how quickly governance weakens when controls are fragmented.
• NHI Lifecycle Management Guide is the next resource to assess how provisioning, rotation, and offboarding behave when control scope is split across packages.

What this signals

Identity coverage often fails at the commercial boundary first. When platforms package core protections into separate tiers, practitioners should assume that operational consistency will need to be proven, not presumed. That is especially true for workload identity programmes, where the control objective is continuity across deployment stages and not just tool adoption.

Governance teams should treat packaging as an architectural signal. If a platform can only extend protection through extra SKUs or credits, the likely outcome is uneven policy enforcement across environments. Link this back to the Top 10 NHI Issues and the OWASP Non-Human Identity Top 10 when evaluating control completeness.

70% of organisations grant AI systems more access than they would give a human employee performing the exact same job. That figure, from the 2026 Infrastructure Identity Survey, shows why entitlement scope and packaging discipline are converging concerns for identity leaders.

For practitioners

• Map pricing tiers to control coverage List each CNAPP capability you need, then verify whether posture, AppSec, runtime, and data controls are governed under one operational model or split across separate packages.
• Test whether workload protection follows movement Confirm that new workloads, environment shifts, and runtime expansion do not require a separate commercial change before protection can be applied.
• Review identity visibility across bundled controls Check whether workload identity, telemetry, and remediation decisions remain consistent when you move from development to runtime coverage.
• Challenge tiered models that create exceptions Ask where the platform depends on add-ons, manual enablement, or separate SKUs that could leave parts of the environment outside the intended policy scope.

Key takeaways

• CNAPP pricing is not separate from governance, because packaging often reveals how fragmented the underlying control plane really is.
• When core protections are split across tiers or add-ons, teams risk inconsistent visibility, incomplete runtime protection, and weaker identity governance.
• Practitioners should evaluate pricing models by the security outcomes they preserve across development and runtime, not by commercial simplicity alone.

Key terms

• Cnapp: Cloud native application protection platform, a category that combines posture, workload, application, and runtime security into one operating model. In practice, the value depends on whether those capabilities share a common policy and identity view, or whether they behave like separate products bundled together.
• Workload Identity: A machine or service identity used by software workloads to authenticate and operate in cloud environments. It is the control point that determines what a workload can access, and it becomes harder to govern when visibility, runtime protection, and lifecycle processes are split across tools or commercial tiers.
• Identity Governance: The discipline of defining, reviewing, and enforcing who or what should have access, when, and for what purpose. In cloud security, it extends beyond human users to service accounts, workload identities, and autonomous systems, especially when commercial packaging affects control scope.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: the blog post on CNAPP pricing and simplified cloud security packaging. Read the original.