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

At a glance

What this is: This is Orca Security's argument that CNAPP pricing complexity can mirror and reinforce security fragmentation across cloud, AppSec, and runtime coverage.

Why it matters: It matters because IAM, cloud, and security platform teams need pricing models that do not create hidden coverage gaps or block reallocation as environments change.

Context

CNAPP pricing can become a governance problem when buyers cannot easily tell which capabilities are included, which are metered separately, and which protections are effectively out of reach. In cloud security, packaging choices often shape how broadly teams can deploy controls across development, application security, and runtime.

Orca Security's argument is not really about sticker price alone. It is about whether tiering, add-ons, and SKU separation force teams to accept fragmented coverage, slower decisions, and awkward trade-offs between breadth and depth of protection.

Key questions

Q: How should teams evaluate CNAPP pricing without missing hidden coverage gaps?

A: Start by mapping the security controls you need across development, AppSec, posture, and runtime, then compare each vendor's entitlements against that map. If a pricing model forces you to split baseline controls across tiers or add-ons, the commercial model is already shaping the security architecture.

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 do security teams get wrong about single-SKU CNAPP offers?

A: They sometimes assume a single SKU automatically means full operational flexibility. The real test is whether the license lets teams move coverage as workloads shift, or whether the platform still creates hidden limits through scan caps, credit rules, or feature gating.

Q: How do cloud teams know whether a CNAPP pricing model is fragmenting control coverage?

A: Look for separate entitlements for posture, application security, runtime protection, or scan frequency that do not align with how your programme is governed. If the commercial boundary is different from the operational boundary, fragmentation is already influencing control coverage.

Technical breakdown

How tiered CNAPP pricing turns coverage into a procurement exercise

Tiered pricing changes the buying motion from capability selection to budget arbitration. When core functions such as DSPM, AppSec, and Cloud Detection and Response are split into separate SKUs, the control plane is no longer unified even if the platform marketing says otherwise. Buyers then have to map each workload, each feature, and each environment to a commercial entitlement before they can understand actual security coverage. That creates a practical gap between what the platform can do and what the organisation is allowed to use.

Practical implication: verify that the commercial model matches your intended control coverage before rollout begins.

Why workload-based pricing matters in dynamic cloud environments

Workload-based pricing is more than a billing preference when environments change quickly. It gives teams a way to move protection with demand, rather than freezing controls inside static license buckets. Orca Security's pitch is that flexible reallocation lets unused capacity shift between AppSec, sensors, and other protections as workloads move. The governance value is predictability: teams can scale protection without renegotiating every time the architecture shifts.

Practical implication: model pricing against cloud growth, workload churn, and control reallocation before committing to a vendor contract.

What fragmented CNAPP bundles often conceal

Fragmented bundles can hide the real scope of what is and is not covered. If scan frequency varies by tier, or if runtime protection and posture management sit behind different limits, security leaders may mistake partial coverage for full coverage. The operational risk is that gaps stay buried until an incident, audit, or expansion exposes them. In cloud security, commercial fragmentation often becomes technical fragmentation because teams deploy only what they can afford to keep turned on.

Practical implication: test whether the vendor's default entitlement leaves any critical cloud control throttled, siloed, or unavailable.

NHI Mgmt Group analysis

Pricing fragmentation is a governance signal, not just a commercial one. When a CNAPP vendor has to explain coverage through tiers, credits, and add-ons, it usually reflects a deeper problem in how security capabilities are packaged and consumed. That matters because cloud teams rarely experience security as isolated products; they experience it as one operating model across build, deploy, and runtime. Practitioners should treat pricing structure as evidence of control fragmentation, not merely sales design.

One SKU is only valuable if entitlement really follows operational need. A single commercial package can reduce procurement friction, but the more important question is whether it preserves coverage continuity as workloads move. The moment a team has to choose between AppSec, posture, or runtime protection because of entitlement boundaries, the platform has reintroduced governance friction through pricing. Practitioners should evaluate whether commercial simplicity actually maps to technical unity.

Fragmented licensing can mask incomplete security programmes. When features are sold separately, teams may postpone capabilities that should have been baseline controls, especially when budgets are tight. That creates a false sense of maturity because the platform appears broad on paper while deployment remains selective in practice. The right practitioner response is to measure commercial fragmentation against real control coverage, not against vendor feature lists.

CNAPP buyers should read pricing models as control models. The article's strongest message is that pricing and architecture are linked: if the vendor cannot describe flexible protection without tier gymnastics, the buyer should assume the control estate will be harder to govern too. This is especially relevant for cloud programmes that need consistent coverage from development through runtime. Practitioners should insist on commercial terms that do not distort security design decisions.

Feature bundling is becoming part of cloud security differentiation. The market is moving toward platform narratives that promise breadth, but breadth only matters if teams can actually activate the controls they need when they need them. That means security leaders should now compare not just detection quality or posture depth, but also whether the pricing model allows the programme to evolve without renegotiating the architecture. The implication for practitioners is simple: pricing now influences security architecture.

From our research library:

• Valid account abuse was responsible for 35% of cloud-related incidents, according to CrowdStrike's 2025 Global Threat Report.

What this signals

Pricing is now part of cloud security governance. Teams that separate commercial design from technical design often discover too late that entitlement rules shaped what they could deploy. A pricing model that limits scan frequency or splits controls across SKUs can become the hidden constraint on the programme.

Control continuity should be the buying test. The important question is not whether a platform has many features, but whether those features remain available as cloud workloads move, scale, and change. If licensing prevents that continuity, the organisation inherits fragmentation before any incident occurs.

For practitioners

• Define coverage before comparing price Map the cloud controls you consider baseline, such as posture, AppSec, and runtime visibility, before looking at license terms. If the commercial model forces you to exclude a control from day one, the purchase is already shaping your architecture.
• Test whether credits are actually portable Ask whether unused entitlement can move between workload protection, application security, and runtime monitoring without a new contract motion. Non-transferable credits usually mean the platform will not keep pace with cloud change.
• Challenge scan throttles as a coverage risk Treat restricted scan frequency as a security gap, not a pricing detail. If the vendor meters visibility by tier, you may be buying partial assurance while assuming full monitoring.
• Compare entitlement boundaries to operating model Check whether feature separation aligns with how your team runs cloud security across build and runtime. If the SKU map does not match the control map, fragmentation will surface in deployment decisions.
• Build procurement questions around control continuity Ask vendors how they preserve coverage as workloads scale, move, or mature. The answer should show how protection stays continuous when the environment changes, not just how the price stays predictable.

Key takeaways

• CNAPP pricing can hide fragmentation when teams have to buy posture, AppSec, and runtime capabilities through separate commercial gates.
• The practical risk is not only higher cost, but partial coverage that looks unified until deployment and audit questions expose the gaps.
• Buyers should test whether entitlement, scan frequency, and workload reallocation preserve control continuity across the cloud lifecycle.

Key terms

• CNAPP Fragmentation: The splitting of cloud-native application protection capabilities across separate tiers, add-ons, or SKUs. In practice, fragmentation makes it harder for buyers to understand what is actually covered across posture, application security, runtime, and data controls, and can leave critical capabilities partially deployed.
• Workload-Based Pricing: A pricing model that charges according to the number of cloud workloads protected rather than by isolated feature bundles. When implemented well, it can preserve commercial flexibility as environments change, but only if entitlement rules do not reintroduce feature gating or scan limits.
• Coverage Continuity: Coverage continuity is the ability to keep testing aligned with ongoing application change rather than relying on isolated assessments. It matters when APIs, workflows and authentication paths evolve quickly, because point-in-time testing leaves assurance gaps between releases.
• Feature Gating: The practice of limiting access to capabilities based on license tier, plan level, or purchased add-ons. In cloud security, feature gating can create hidden control gaps when essential protections are treated as premium options rather than baseline governance requirements.

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 building or maturing an IAM programme, it is worth exploring.