The sales deck shows one box: a single, unified platform, one login, one view of the enterprise. The order form, by the time procurement is done negotiating, usually shows five to ten line items: a core SIEM license, a SOAR add-on, a user behavior analytics module, a threat intelligence feed subscription, an identity threat detection package, maybe an email security bolt-on and a separate cloud posture product layered on top. Each one billed separately. Each one renewed on its own schedule. Each one, in practice, its own product with its own console, its own data model, and its own support queue, all wearing the same platform’s logo.
This isn’t a story about any one vendor being dishonest. It’s a story about how “platform” pricing works across a large share of the market, and why the gap between the one-box pitch and the multi-SKU reality is one of the biggest, least-discussed drivers of both weak security efficacy and runaway security spend.
Quick answer: Many of the platforms marketed as unified security suites are, commercially, a base product plus several separately licensed modules required to reach the capability shown in the demo: user behavior analytics, SOAR, threat intelligence, identity threat detection, and cloud or email security are common candidates for a separate SKU. Each additional SKU adds its own renewal negotiation, its own integration project, and often its own pricing model, commonly billed by data volume rather than by asset, which is why total cost of ownership on a “platform” purchase routinely runs well past what the core license implied, while the fragmentation between SKUs recreates exactly the visibility gaps the platform pitch was supposed to solve.
Key takeaways:
- A “unified platform” in the sales deck often becomes five to ten separately licensed line items on the order form.
- Each extra SKU brings its own renewal, its own integration project, its own console, and often its own pricing model.
- Modules billed by data volume can grow the bill between pilot and production, and push teams to cut identity and cloud audit logs, the telemetry that matters most.
- Modules that share a vendor logo don’t automatically share a data model, so cross-module attacks still need an analyst to connect the dots.
- Unconfigured bundle modules become shelfware: licensed, paid for, and never producing a detection.
| In the sales demo | On the order form |
|---|---|
| One unified platform | A core SIEM license |
| Automated response | A separate SOAR add-on |
| Behavioral analytics | A user behavior analytics module |
| Threat intelligence context | A threat intelligence feed subscription |
| Identity attack detection | An identity threat detection package |
| Email and cloud coverage | An email security bolt-on and a separate cloud posture product |
| One console, one view | Several consoles, data models, renewal dates, and support queues |
The pattern is well documented in how major SIEM platforms are actually licensed once you look past the core product. A widely used enterprise SIEM’s Enterprise Security module covers correlation and case management, but SOAR, user behavior analytics, IT service intelligence, and threat intelligence platform capability are each a separate license on top of it. A leading cloud-native security suite’s core module covers baseline detection, but its extended detection and response capability, its threat intelligence add-on, and its broader endpoint protection suite each carry their own per-user fees layered on top of the core subscription. In both cases, the “platform” a prospect sees in a demo and the “platform” a security team ends up operating are commercially two different things, connected by a purchase order with several more lines on it than the pitch implied.
None of this means the individual modules are bad products. It means the total cost and the total integration effort of reaching the capability that was demonstrated is systematically larger than the number attached to the platform’s name, and that gap rarely surfaces until the deal is already well into procurement.
Two costs compound from this pattern, and they map directly onto the efficacy and efficiency question from Part 1 of this series.
On the efficiency side, integration is the most concrete cost. Stitching several separately built modules, often acquired by the vendor rather than built natively, into something that functions like one platform requires custom connectors, data normalization work, and professional services engagements that can run well into six figures for a large enterprise deployment, independent of the license cost itself. Every additional SKU is also an additional renewal negotiation, an additional support relationship, and, for many of these products, an additional pricing dimension: several of the modules involved in a typical multi-SKU SIEM stack bill by data volume rather than by asset count, which means the bill can grow substantially between the pilot and full production even with headcount and infrastructure held flat. This is the same per-gigabyte pricing dynamic discussed in earlier work on this topic, where organizations facing rising ingestion costs respond by turning down the highest-volume telemetry sources, which are frequently the identity and cloud audit logs that matter most for catching a real intrusion.
On the efficacy side, the cost is subtler but arguably worse: five to ten separately licensed products, each with its own data model and its own console, do not automatically correlate with each other just because they share a vendor logo. An identity anomaly surfaced by one module and a network anomaly surfaced by another still have to be manually connected by an analyst unless real engineering work has gone into a shared data layer underneath them, which is exactly the kind of cross-referencing that’s easy to skip under alert-volume pressure, and exactly the gap that lets a multi-stage intrusion move from module to module without ever producing one unified picture of the attack.
| The fragmentation tax | Efficiency cost | Efficacy cost |
|---|---|---|
| Separately built or acquired modules | Custom connectors, data normalization, six-figure professional services | No shared data model underneath the modules |
| Several renewals and support relationships | More negotiations, more vendor management | Ownership of cross-module gaps is unclear |
| Data-volume pricing on some modules | Bill grows between pilot and production | Teams cut identity and cloud audit logs to control cost |
| Several consoles | More analyst time per incident | Multi-stage attacks never appear as one picture |
The pricing model is worth isolating, because it changes behavior, not just budgets.
| Pricing model | What drives the bill | The behavior it tends to create |
|---|---|---|
| Per gigabyte or per event | How much telemetry you send | Pressure to turn down high-volume sources, often identity and cloud audit logs |
| Per asset or per user | How many devices and identities you protect | A cost that tracks headcount and infrastructure, with no penalty for monitoring more |
When the cheapest way to control a security bill is to see less, some teams will eventually see less. That’s not a failure of discipline; it’s a predictable response to how the product is priced.
Part 1 of this series cited research showing that organizations lose roughly 28% of security software spend to tools that are underutilized or unused entirely, with some organizations leaving as much as 60% of purchased capability sitting dark. SKU fragmentation is a direct contributor to that number. A module purchased as part of a bundle to unlock volume pricing, but never fully configured because the team ran out of implementation bandwidth before the next renewal cycle came around, is shelfware in the most literal sense: paid for, licensed, and never contributing a single detection. Research on tool sprawl backs up why that happens: teams running larger numbers of security tools report meaningfully higher burnout, and a large share of security engineers already report spending the majority of their time on maintenance rather than security work, which leaves very little slack to properly stand up the sixth or eighth module in a stack, however capable that module might be on its own.
The question this reframes: it isn’t “does the platform have this capability.” Almost every serious platform, eventually, can check that box somewhere in its portfolio. The question is whether that capability ships as part of one coherently engineered product, or as a separately billed, separately integrated module bolted onto the side, because the second version is where the efficiency cost and the efficacy gap both live.
None of this means every add-on SKU is a red flag, or that bundling is inherently dishonest: some capabilities genuinely are optional for most customers and reasonably sold that way. The distinction worth pressure-testing in any evaluation is which capabilities are core to the platform’s own data pipeline versus which are separately acquired products wearing the platform’s branding.
In Part 3 of this series, we turn this into a concrete framework: the specific questions to ask any vendor to find out whether you’re buying one engineered platform or a bundle of five to ten products, and how to price out the real, all-in cost of the coverage being pitched before it becomes a line-item surprise, including how the Seceon Open Threat Management (OTM) Platform answers those questions with one data pipeline and asset-based licensing.
Because many platforms are commercially structured as a core product plus several optional or required modules (user behavior analytics, SOAR, threat intelligence, identity threat detection, and cloud or email security are common examples), each licensed, renewed, and often priced separately, even when they're marketed together under one platform name.
Not automatically. Modules that share a vendor logo don't necessarily share an underlying data model or correlation engine: several major platforms assembled their broader suites partly through acquisition, which means genuine cross-module correlation requires real engineering investment behind the scenes, not just a common purchase order.
Beyond the license cost of each additional module, the main hidden costs are integration and professional services (custom connectors and data normalization work that can run into six figures for a large deployment), the operational burden of running multiple consoles and support relationships, and, for modules priced by data volume, a bill that can grow substantially between pilot and full production.
A module purchased as part of a bundle often requires its own configuration and tuning work to become useful. When implementation bandwidth runs out before that work is finished (a common outcome given how much time security teams already spend on maintenance), the module becomes shelfware: fully licensed, never fully deployed, and contributing nothing to actual detection.
SKU sprawl is when a security platform marketed as one product is actually sold as many separately licensed modules, each with its own price, renewal, integration work, and often its own console, so the full capability shown in the demo requires five to ten purchases.
Per-GB or per-event pricing charges by how much telemetry you send, which can push teams to turn off high-volume sources such as identity and cloud audit logs. Asset-based pricing charges by the number of devices and identities protected, so the cost tracks your environment rather than how much you choose to monitor.
This is Part 2 of a 3-part series on evaluating cybersecurity vendors by outcomes instead of marketing signals. Continue to Part 3: Evaluating Security Vendors: A Real Framework, or return to Part 1: Why Security Buyers Reward Theater.
