For years, cybersecurity strategy followed a relatively predictable pattern.

A new risk emerged. A specialized vendor built a solution for it. Organizations identified a gap in their security program and purchased another tool. Then another. And another.

The result is an increasingly complicated security ecosystem. Research from IBM Institute for Business Value and Palo Alto Networks found that surveyed organizations manage an average of 83 security solutions from 29 vendors, while 52% of executives said fragmentation of security solutions was limiting their ability to deal with threats.

Now we're seeing the market begin to move in another direction.

Two related trends are emerging.

First, organizations are reconsidering incumbent platforms when licensing or packaging changes require them to purchase broader, and more expensive, bundles simply to retain capabilities they already depend on.

Second, organizations confronting a new cybersecurity requirement are increasingly asking whether functionality already exists somewhere within their current stack before purchasing another point solution.

Those trends create two very different strategic questions:

If a vendor asks us to spend significantly more to keep the capabilities we need, should we upgrade or reconsider the platform?

And:

If we need a new capability, do we actually need another tool, or have we already paid for the functionality needed that exists somewhere else within our stack and we just don't know it?

Both questions lead to the same conclusion.

Before buying, renewing, upgrading, or replacing cybersecurity technology, organizations need a much clearer understanding of what they own, what they use, what they need, and what business outcome the technology is supposed to produce.

Key Takeaways

• Cybersecurity tool consolidation is already widespread. IANS research found approximately 70% of surveyed CISOs had consolidated or were consolidating multiple security solutions into integrated platforms, with another 13% planning to do so.
• Organizations should not assume an incumbent vendor's new package is automatically the right choice simply because its existing product is deeply embedded in the environment.
• Evaluate functionality and total cost, not merely the cost of maintaining a single familiar feature.
• Before buying another specialized security product, determine whether existing platforms, hyperscalers, or enterprise tools already provide the required capability.
• Tool sprawl carries operational consequences. IBM research found organizations manage an average of 83 security solutions from 29 vendors.
• AI and non-human identities illustrate why capability reviews matter: Microsoft, AWS, and Google Cloud are already expanding identity and security capabilities for machine identities and AI agents.
• Native functionality is not automatically the right functionality. Capability, maturity, architecture, compliance, interoperability, and operating requirements still matter.
• The objective should not be consolidation for consolidation's sake. It should be the simplest, most cost-effective architecture that satisfies the organization's security and business requirements.
• Sometimes "good enough" is enough when it comes to inherent capabilites that may exist within a company's current stack.

The Security Tool Conversation Is Changing

One of the themes we're seeing across clients, prospects, and partners is a greater appetite to reconsider the platforms organizations use to support their IT and cybersecurity strategies.

At the same time, we're seeing something that may initially sound contradictory.

Organizations are also looking for ways to expand their use of existing platforms rather than buying additional point solutions.

Those trends aren't actually in conflict.

They are both symptoms of a larger shift:

Security leaders are becoming more deliberate about the economics and complexity of their technology stacks.

IANS and Artico Search surveyed 628 CISOs for their 2025 Security Software and Services Benchmark research and found approximately 70% were consolidating or had consolidated multiple software solutions into one or more integrated platforms. Another 13% planned to consolidate.

IBM's research illustrates one reason why. Organizations in its study were juggling an average of 83 security solutions from 29 vendors. More than half of surveyed executives said fragmentation was limiting their ability to deal with cyber threats.

This is no longer simply a procurement issue.

It's an IT strategy issue.

When Your Cybersecurity Platform Starts Looking Like a Car Trim Package

One way to describe what's happening is to think about buying a car.

There was a time when buyers could select individual options relatively easily. Maybe you wanted heated seats. Maybe adaptive cruise control. You selected the features you valued.

Increasingly, those features come packaged into trim levels. Want the heated seats? You may need to buy a premium package containing 19 other features you never asked for and may never use.

Software packaging can create a similar problem.

An organization may have used a particular cybersecurity capability for years. It is installed. The team understands it. Workflows depend on it. Integrations have been built around it.

Then the vendor's commercial model changes.

To continue accessing the capability the organization values, the customer may be encouraged, or required, depending on the vendor and contract, to move into a broader package containing additional functionality.

Suddenly the economic equation changes.

The question is no longer:

"Do we like this tool?"

It becomes:

"Is the broader package worth the total cost required to retain the capability we actually need?"

Those are very different questions.

Don't Let Switching Costs Eliminate Strategic Choice

A deeply embedded platform has an advantage.

• The organization already knows it.

• The technology is configured.

• Integrations exist.

• Employees are trained.

• Processes depend on it.

That creates legitimate switching costs.

But those costs should be quantified rather than used as a reason to automatically accept a substantially different commercial model.

Organizations should compare at least three scenarios:

• Option 1: Stay and upgrade.

  What does the new package cost, which capabilities will actually be used, and what additional value does it create?

• Option 2: Stay and optimize.

  Can the organization retain its current model while enabling additional functionality it already owns or changing how existing products are configured?

• Option 3: Switch.

  Can another platform satisfy the required use cases at a lower total cost or with a better strategic fit?

That comparison needs to include more than licensing.

Migration has costs. So does implementation, integration, data migration, training, process redesign, configuration, potential downtime, ongoing administration, and eventually, another migration if the replacement no longer fits.

This is why a cheaper license isn't necessarily a cheaper solution.

The appropriate comparison is total cost of ownership against required business outcomes.

Consolidation Can Create Value But It Isn't Automatically Better

There is meaningful evidence supporting security consolidation.

IBM's research found organizations with greater security platformization reported substantially better operational outcomes. The study found incident identification was 72 days faster and containment 84 days faster among more platformized organizations. It also found seven in ten organizations with high platformization reported cybersecurity investments supporting outcomes such as operational efficiency and revenue generation.

But that doesn't mean every organization should put every security function on one platform.

Best-of-breed tools continue to exist for a reason. Some environments require deeper functionality. Some regulatory or government environments introduce specific requirements.

Multicloud organizations may need broader interoperability. A particular risk may justify specialized capability. And some bundled features simply may not be mature enough to replace an established specialist.

The strategic objective therefore isn't:

Consolidate everything.

It's:

Eliminate unnecessary complexity without eliminating necessary capability.

The Other Side of the Trend: Before You Buy, Look at What You Already Have

The second trend we're seeing may represent an even bigger opportunity.

Organizations identify a new risk and immediately begin evaluating a new product.

That behavior has accelerated with AI.

• AI governance.

• Shadow AI.

• AI security.

• Non-human identities.

• Agent security.

• Data protection.

Every emerging issue quickly generates a new category of specialized technology.

Some of those solutions provide significant value.

But the first question should not automatically be:

"Which new vendor should we evaluate?"

Start with:

"What functionality already exists within the platforms we're paying for today?"

This is especially important because major enterprise and cloud platforms are evolving rapidly.

Capabilities that weren't available when you selected a platform three years ago may exist today. Capabilities that previously required a separate product may now be integrated into a cloud or identity platform. And functionality you assumed required another license may already be available under an existing agreement.

The Cost of Tool Sprawl Is More Than Licensing

Every new security product creates more than an invoice.

It may also create:

• Another implementation
• Another integration
• Another configuration baseline
• Another dashboard
• Another data source
• Another set of alerts
• Another API
• Another vendor relationship and third party risk
• Another renewal
• Another employee training requirement
• Another product that must be patched or maintained
• Another potential point of failure

Thales' 2025 Cloud Security Study provides a good example of the complexity organizations are already managing. Nearly two-thirds, 61%, of respondents reported using five or more tools for data discovery, monitoring, or classification, while 57% used five or more enterprise key managers for encryption.

ISACA has similarly warned that tool sprawl can create fragmented reporting, inconsistent detection and operational complexity.

So the true cost of adding a tool is:

License + Implementation + Integration + Configuration + Operations + People + Maintenance + Governance

That's the number organizations should compare against the cost of expanding an existing platform.

AI and Non-Human Identities Are a Perfect Test Case

AI governance and non-human identities illustrate this decision particularly well.

Organizations are deploying:

• AI agents
• Service accounts
• APIs
• Automation
• Applications
• Containers
• CI/CD pipelines
• Machine identities
• Autonomous workloads

Those entities need identities and permissions just like people do, although the security model can be very different.

Microsoft defines workload identities as identities assigned to software workloads such as applications, services, scripts, and containers. Microsoft also identifies AI agents as a distinct category of machine identity with unique governance requirements.

The risks are legitimate.

Organizations need to understand:

1. Who owns the identity?

2. What can it access?

3. Does it still need access?

4. Is it overprivileged?

5. How are credentials managed?

6. Can its actions be traced?

7. What happens when the workload or agent is retired?

But that does not automatically mean the organization needs to procure a dedicated NHI platform before evaluating its existing environment.

Look at What the Hyperscalers and Identity Platforms Already Provide

The major cloud and identity providers have expanded capabilities in this area.

Microsoft provides Microsoft Entra Workload ID for applications, service principals, and managed identities, including capabilities around conditional access, lifecycle management, risk, and privileged access reviews. Microsoft has also introduced dedicated agent identities for AI workloads, with governance designed around the dynamic lifecycle of AI agents.

AWS explicitly distinguishes between human and machine identities in its Well-Architected security guidance and recommends practices including temporary credentials, centralized identity management, credential auditing, and secure secrets management. AWS's AI Security Framework further recommends giving AI agents their own identities and using temporary, scoped credentials rather than persistent access.

Google Cloud provides service accounts, Workload Identity Federation, managed workload identities, and agent identities. Google describes agent identities as Google-managed identities tied to the lifecycle of agentic workloads, providing an alternative to simply treating an AI agent like another traditional service account.

The point isn't that native hyperscaler capabilities eliminate the need for specialized products.

They don't.

The point is:

You should know what your existing platforms can do before deciding what they cannot do.