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.
- 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.
- 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.
It was the perfect combination of vendor sprawl and technical debt.
This isn’t an extreme case, either. 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.
Here are several factors compounding your costs:
- 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. In practice, this means engineers rotating between interfaces, one for the firewall, one for the SD-WAN, and another for remote access, with no shared view of what is happening across all three. Troubleshooting issues that span multiple systems is slow, friction-heavy, 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. Applications live in the cloud. Users are distributed. 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
Secure Access Service Edge (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 SASE 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. The engineering time previously spent on coordination between tools is redirected toward work that moves the organization forward.
What SASE looks like in practice
When the Log4j vulnerability was disclosed, organizations running a converged SASE platform like Cato had a materially different experience.
Cato’s 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 SASE 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 associated with 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, spanning points of presence across North America, EMEA, Asia, and Latin America, 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 a compound annual growth rate of 26%, reaching $28.5 billion by 2028. By that same year, Gartner expects 70% of SD-WAN purchases to be part of a single-vendor SASE platform, up from 25% in 2025. The direction is clear.
How organizations typically start
A common misconception about SASE adoption is that it 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.
Related Content: Comparing SD-WAN and SASE
Stage 1: Zero Trust Network Access
Remote access is the most common starting point and the most immediate pain point for most IT teams.
VPN performance complaints, contractor access management, and always-on security for distributed workforces are all problems that ZTNA addresses directly. A converged SASE platform can run alongside whatever network architecture is already in place, which means no changes to existing SD-WAN infrastructure are required to get started.
Momentum’s own internal environment uses Juniper SD-WAN at company locations and Cato’s ZTNA solution for remote access. Hybrid adoption is the norm, not the exception.
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. Instead of re-signing with a standalone SD-WAN vendor and maintaining a separate management interface, the organization extends its SASE deployment to cover branch connectivity. No new architecture required. The platform is already in place.
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. The capability is a switch that gets turned on.
Stage 4: Full convergence
At this point, networking, security, remote access, and threat prevention all run through a single platform with one policy engine, management interface, and data plane. The engineering time previously spent coordinating across tools is redirected toward work that moves the organization forward.
Organizations do not need to reach stage 4 to start realizing value. Each stage delivers measurable returns on its own. If you are evaluating whether the timing is right, here are seven signs your business is ready for SASE.
What to look for in a SASE 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. As the SASE model continues to evolve, that distinction is only becoming more important.
Here is what separates a genuinely converged platform from one that carries the SASE label without delivering on the architecture:
- Single data plane: All functions, including networking, security, and remote access, 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 policy configuration, no manual synchronization across tools.
- Unified management interface: The console reflects the actual state of the entire network, not separate views stitched together per product. Troubleshooting a remote user’s performance issue from device to application should happen in one place.
- Automatic updates: Firmware and policy updates are applied by the platform, universally and simultaneously. The customer is not responsible for patching individual appliances across sites.
- Zero-touch site deployment: New locations come online without sending a specialist to the site. Preconfigured hardware connects to the platform 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 IT teams have not solved yet
Alongside the established challenges of network fragmentation, a new and less-understood security surface has emerged rapidly over the past two years. Employees across virtually every organization are now using AI tools as part of their daily workflow.
Copilot, ChatGPT, and similar platforms have become productivity defaults for writing, analysis, and code generation.
Most IT teams have not yet established effective controls over what data flows into those platforms.
The scale of the problem is not theoretical. 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.
When an employee pastes a customer contract into an AI prompt to generate a summary, or includes internal financial data in a query, that information leaves the organization’s environment and enters a third-party system. Standard network security tools were not designed to inspect that kind of traffic at the content level. The common response has been to block AI platforms entirely, which addresses the security concern by eliminating the productivity benefit.
A converged network security platform changes what is possible here. Because all traffic routes through the platform before reaching its destination, the platform can sit between the user and the AI tool. It can inspect what the user enters in the prompt, identify content that matches defined sensitivity rules, including customer data, financial information, intellectual property, and personally identifiable information, and either redact that content before it reaches the model or block the request entirely. The AI platform receives a cleaned version of the prompt or nothing at all, and the user receives a notification that the input was restricted.
Two types of AI risk
Understanding AI risk in the enterprise means separating two distinct categories. Each creates different exposure, and each requires a different level of control.
Employee use of public AI tools
This is the more familiar risk. Employees access ChatGPT, Copilot, or similar tools through a browser and paste sensitive information into prompts, including customer contracts, financial data, internal documents.
The data leaves the organization’s environment and enters a third-party system. Most security tools have no visibility into what was shared or where it went.
AI agents acting autonomously
This risk is newer and harder to detect. Companies are beginning to deploy AI agents that autonomously reach out to other AI systems to execute tasks.
These agents can behave unpredictably if not properly scoped, and they create data flows that are often invisible to standard security tools. Unlike employee-driven usage, there is no human in the loop to catch a mistake before it happens.
A platform-level approach addresses both categories from the same interface.
The path forward is clear
For IT directors managing complex, multi-vendor environments, the question is not whether to move toward a more converged architecture. The operational and security advantages are well-documented, and the financial case is strong. 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. The entry point is low-friction, the ROI is immediate, and the path to broader consolidation opens naturally from there.
Momentum works with organizations at every stage of that journey. As one of Cato Networks’ most experienced global implementation partners, Momentum delivers managed SASE solutions from initial ZTNA deployment through full SASE consolidation across distributed and international environments.
The goal is to help IT teams spend less time managing infrastructure and more time using it. Explore all of Momentum’s secure networking solutions or connect with a Momentum network specialist to assess where SASE fits in your environment.
Assess your current network architecture. Book a meeting with a Momentum network specialist to build a practical SASE transition plan.
