The hidden cost of a fragmented network: a practical path to SASE

Most enterprise networks were not designed, they accumulated over years and decades.

Maybe it was a firewall here, an SD-WAN appliance there, a remote access solution added under pressure, or a cloud security tool layered on top. Each decision made sense at the time. Together, they created something that is increasingly difficult to secure, manage, and scale.

For IT directors managing multi-site environments, the consequences are familiar. Engineers spend most of their time on maintenance rather than on strategy. Security gaps open in the space between tools that were never designed to work together. And total cost of ownership that looks reasonable on individual line items adds up to something very different in practice.

The result is a network that costs more than it should, takes longer to troubleshoot than it needs to, and creates security gaps that grow with every tool you add. But there is a practical path to consolidation, and most organizations start without replacing a single piece of existing infrastructure.

How enterprise networks got this way

The layered network did not happen by accident or negligence, but rather because the industry sold solutions one at a time, each addressing a specific problem at a specific moment.

• MPLS circuits were the right answer when workloads lived in data centers and users sat in offices.
• Perimeter firewalls made sense when the network had a clear edge.
• SD-WAN arrived to address the cost and rigidity of MPLS as branch offices multiplied.
• Remote access scaled up fast during 2020, and cloud security tools followed the migration of workloads out of on-premise environments.

Each layer solved a real problem. The issue is that none of these products were built to share data, context, or be managed from a single point of control. Organizations ended up with security teams working in one interface, network teams in another, remote access managed separately, and no single source of truth when something went wrong. For most IT teams, this is the reality of managing networks built across five or more years of independent purchasing decisions.

The compounding cost nobody budgets for

The visible costs of a fragmented network are the vendor contracts. The less visible costs are where the real damage accumulates.

Patching

Every device-based solution carries a firmware maintenance cycle. In multi-site environments with mixed versions and upgrade dependencies between vendors, patching becomes a significant engineering project in its own right, recurring indefinitely.

Visibility

When security, networking, and remote access tools do not share data, your visibility ends at each product’s boundary. A remote user with a performance issue could be affected by the device, the last-mile provider, the network path, or the application. Without end-to-end visibility, diagnosis is guesswork.

Consistency

Applying a uniform security policy across multiple sites, remote users, and cloud environments with separate tools requires manual coordination and ongoing verification. Policy drift is almost inevitable at scale, and it is usually invisible until an incident surfaces it.

Staff overhead

Siloed tools require siloed expertise. Engineers rotate between interfaces, one for the firewall, one for the SD-WAN, another for remote access, with no shared view across all three. Troubleshooting issues that span multiple systems is slow and dependent on individuals rather than process.

MPLS cost

Legacy circuit costs continue to climb while the underlying infrastructure becomes less suited to modern traffic patterns. Routing everything through a central hub to apply security before sending it back out adds latency and cost simultaneously.

When these costs are totaled, including contracts, engineering hours, incident response time, patching cycles, and the organizational overhead of managing disparate systems, the true cost of a fragmented network is substantially higher than any individual line item suggests.

What SASE actually means in practice

SASE has become one of the most used and most misunderstood terms in enterprise networking. The market’s appetite for the acronym has led to a wide range of products being marketed under the same label, which has generated reasonable skepticism among IT professionals who have seen too many rebrands to take vendor positioning at face value.

The architectural concept behind it is straightforward: converge SD-WAN, security, and remote access onto a single cloud-native platform so that they share the same data, the same policy engine, and the same management interface. When that convergence is genuine, built from the ground up rather than assembled through acquisitions, it changes what an IT team is operationally capable of.

A single policy applied through a converged platform applies uniformly to every site, remote user, and cloud environment. Firmware updates are managed by the platform, not the customer. When a threat is identified, a response is deployed across the entire estate simultaneously.

When the Log4j vulnerability was disclosed, organizations running a converged platform had a materially different experience. The security team identified the threat, built a detection signature, and deployed it across every connected customer environment within days, before most teams had finished assessing which servers were exposed. The patch still needed to happen, but the window of active exposure closed fast. That is the difference between a security product and a security platform.

The business case beyond the line-item comparison

The most common point of friction when evaluating consolidation is an apples-to-oranges cost comparison. A converged platform evaluated against a single incumbent vendor will often appear more expensive. Evaluated against the full stack it replaces, the calculation looks different.

According to a 2026 Forrester Consulting Total Economic Impact study commissioned by Cato Networks, organizations using the Cato SASE Platform realized a 235% ROI over three years, with a net present value of $13.2 million and payback in less than six months.

The full-stack comparison accounts for the firewall vendor, the SD-WAN vendor, the remote access solution, the threat prevention layer, and the engineering overhead of running all of them. It also accounts for incident response costs in environments where poor visibility extends the time to detect and contain threats.

For organizations with international locations, the formula shifts further. A platform with global infrastructure delivers the same experience in Singapore or Frankfurt that it delivers in Chicago, from the same interface, under the same policy. Gartner projects the SASE market will grow at 26% CAGR, reaching $28.5 billion by 2028, and expects 70% of SD-WAN purchases to be part of a single-vendor SASE platform by that year, up from 25% in 2025.

How organizations typically start

A common misconception is that adoption requires a full network replacement from day one. In practice, most organizations begin with a single use case and expand from there as value is demonstrated and contracts with incumbent vendors expire.

Stage 1: Zero Trust Network Access

Remote access is the most common starting point and the most immediate pain point. VPN performance complaints, contractor access management, and always-on security for distributed workforces are all problems ZTNA addresses directly. A converged platform can run alongside whatever architecture is already in place. Momentum’s own environment uses Juniper SD-WAN at company locations and Cato’s ZTNA for remote access.

Stage 2: SD-WAN refresh

When existing SD-WAN contracts come up for renewal, the opportunity opens to consolidate networking onto the same platform already handling remote access. No new architecture required.

Stage 3: Firewall and threat prevention consolidation

Hardware lifecycle events create a natural opening to retire on-premise firewalls and move threat prevention into the platform. Each addition is a configuration change, not an infrastructure project.

Stage 4: Full convergence

Networking, security, remote access, and threat prevention all run through a single platform with one policy engine, management interface, and data plane.

Organizations do not need to reach stage 4 to start realizing value. Each stage delivers measurable returns on its own.

What to look for in a platform

Not all SASE offerings are architecturally equivalent. The distinction that matters most is whether the platform was built as a converged system from inception or assembled by stitching together acquired products under a common brand.

Single data plane

All functions share the same underlying data layer. Platforms built through acquisition often integrate at the management layer only, which means visibility and policy consistency are partial rather than complete.

One policy engine

Security rules written once apply to every edge: sites, remote users, cloud environments. No per-product configuration, no manual synchronization.

Unified management interface

The console reflects the actual state of the entire network, not separate views stitched together per product.

Automatic updates

Firmware and policy updates are applied by the platform, universally and simultaneously.

Zero-touch site deployment

New locations come online without sending a specialist to the site. Preconfigured hardware connects and inherits policies automatically.

The practical test is straightforward. Can your team write one security rule and know it applies everywhere? Can they trace a performance issue end-to-end in a single interface? Can they bring a new site online remotely? If the answer to any of those is no, the architecture has not actually converged.

The AI security problem most teams have not solved

Alongside the established challenges of fragmentation, a new security surface has emerged rapidly over the past two years. Employees across virtually every organization now use AI tools as part of their daily workflow, and most IT teams have not yet established effective controls over what data flows into those platforms.

According to Cyberhaven’s 2026 AI Adoption and Risk Report, nearly 40% of AI interactions in the enterprise involve sensitive data, with most employees using personal accounts that bypass corporate security controls entirely. Standard DLP tools were not designed to catch this kind of activity.

A converged platform changes what is possible. Because all traffic routes through the platform before reaching its destination, it can sit between the user and the AI tool, inspect what the user enters in the prompt, identify content that matches defined sensitivity rules, and either redact that content before it reaches the model or block the request entirely.

Employee use of public AI tools

Employees paste customer contracts, financial data, or internal documents into prompts. The data leaves the organization and enters a third-party system, and most security tools have no visibility into what was shared.

AI agents acting autonomously

Companies are beginning to deploy agents that reach out to other AI systems to execute tasks. They can behave unpredictably if not properly scoped, and there is no human in the loop to catch a mistake.

The path forward

For IT directors managing complex, multi-vendor environments, the question is not whether to move toward a more converged architecture. The question is where to start and how to sequence the transition without disrupting a network the business depends on. The answer is almost always to start with the use case where the pain is sharpest. For most organizations, that is remote access.

Momentum works with organizations at every stage of that journey. As one of Cato Networks’ most experienced global implementation partners, Momentum delivers managed SASE from initial ZTNA deployment through full consolidation across distributed and international environments.