The Security Gaps Hiding in Fragmented SASE Architectures and How VersaONE Closes Them

SASE has become the blueprint for modern enterprise security, but many of the “SASE solutions” running in production today aren’t unified platforms. They’re proxy-chained, multi-console SSE stacks with bolted-on networking, assembled from separate products that were never designed to work as one. On paper they look like SASE. In practice, the seams between products open structural gaps that attackers are already exploiting.

Here are the five most overlooked gaps in fragmented SASE architectures, and why they tend to stay gaps.

Gap 1: Internet-exposed VPN appliances are vulnerable targets

Every VPN gateway is internet-facing by design. It has to be reachable from the public internet to do its job, which makes it a permanent, privileged target sitting directly in front of the network. Verizon’s 2026 Data Breach Investigations Report found that exploiting software vulnerabilities, such as those in VPNs, is now the most common way attackers break in, at 31% of breaches, overtaking stolen credentials for the first time in the report’s history. The shrinking patch window doesn’t help. AI-assisted vulnerability discovery lets attackers find and weaponize flaws faster than teams can patch, and exploitation of public-facing applications has climbed 44% year over year. Yet organizations fully remediated only about 54% of edge-device and VPN vulnerabilities in the past year.

The industry recommendation is to move internet-exposed VPN appliances behind brokered zero-trust access and patch edge-appliance vulnerabilities quickly. Simple in theory, but in practice the migration can mean rearchitecting whole networks, and keeping pace with patches ties up security teams indefinitely.

Gap 2: Encrypted traffic is an un-inspected blind spot

Almost all web traffic is now encrypted, with Google reporting roughly 98% of Chrome browsing in the U.S. runs over HTTPS. That protects privacy, but it also means a large portion of traffic isn’t inspected by an org’s security stack. And most organizations leave it that way: 76% still treat encrypted data as inherently secure. Attackers exploit that blind spot, with malware now accounting for 86% of encrypted attacks. The takeaway: if you’re not inspecting encrypted traffic, you’re not securing most of your traffic.

Security experts typically recommend reversing the default: inspect all traffic, then carve out narrow, deliberate exclusions. But full inspection is compute-intensive, and under heavy traffic, it can add latency that users notice.

Gap 3: Licensed security controls are unconfigured or misconfigured

Buying a security product is not the same as configuring it, and enterprises now run more tools than they can manage well. Gartner puts the average at 43 security tools in a product portfolio, with some organizations fielding well beyond that number. More tools should mean more protection, but Gartner also cited that 61% of security leaders suffered a breach in the past year because a control failed or was misconfigured. OWASP also elevated misconfiguration to the number two risk in its 2025 Top 10, where it turned up in every application tested. The capability was there. The configuration wasn’t.

The fix is low-cost: no new purchases, just turning on what’s already licensed. But the obstacle isn’t budget; it’s operational overhead. These controls typically live in separate consoles, licensed as separate modules, each requiring its own configuration project before it enforces anything.

Gap 4: Known-malicious traffic isn’t consistently blocked

Even when a control can stop a known threat, it often doesn’t, because blocking is off by default. Many products ship in monitoring or alert-only mode, flagging known-malicious traffic without stopping it until someone turns enforcement on. Microsoft’s Azure Firewall is a clear example. Its threat-intelligence filtering can alert on and deny traffic from known-malicious IP addresses and domains, but ships in alert-only mode by default and has to be manually switched to deny. Until someone makes that change, the firewall sees the threat and lets it pass.

This is another no-purchase fix: switch settings from “monitor” to “block.” But consistent enforcement means making that switch across separate consoles and modules, each with its own process, and a single console left in monitor mode leaves the gap open.

Gap 5: AI and MCP connections operate outside existing identity controls

AI tools and agents are multiplying inside enterprises, accessing resources with little oversight. Explicit verification is a core Zero Trust principle, but existing identity and access management (IAM) systems were built for human users and predictable service accounts. They weren’t built to handle authentication and authorization from thousands of agent-generated requests. A recent Cloud Security Alliance survey found that 92% of organizations were not confident their IAM tools can manage AI and non-human identity risks, and just 28% can trace an agent’s actions back to a human sponsor. The problem compounds with the AI tools employees adopt on their own: 43% of security incidents involved shadow AI, according to IBM’s 2026 Cost of a Data Breach report.

The solution is to gate all AI surfaces with identity-aware access, the same way ZTNA already gates human access to applications. The catch is that most current identity systems have no concept of a non-human identity to enforce against in the first place.

Why fragmented SASE architectures produce the same gaps

These gaps aren’t independent problems. They’re the predictable outcome of a specific architectural pattern: security functions delivered as a chain of separate proxies and appliances, each with its own console, its own policy object model, and its own licensing.

In that model, only a small fraction of encrypted traffic is inspected, because inspecting all of it carries a compute and latency cost at every proxy hop. So inspection is opt-in by default. Teams have to explicitly designate traffic for it, and coverage gets dialed back further under load. IPS and malicious-IP blocking stay in monitoring mode because flipping them to full enforcement is a separate change-management exercise in a separate console, carrying its own risk of breaking traffic nobody has time to validate. Security platforms sit unconfigured because extending coverage means a new integration project layered onto an already-fragmented stack. And AI/MCP endpoints have no identity plane in front of them for a more fundamental reason: none of these platforms were built with a non-human identity model in the first place. They were designed to broker human user sessions to SaaS applications, years before agentic AI and MCP existed. Extending “zero trust” to an AI agent means bolting a new identity system onto an architecture that was never built to hold one. None of this is a training gap. It’s what happens when every additional control is a separate system to activate, and activation keeps losing to more urgent work.

Closing the gaps with a Pervasive Security approach

Taken together, these gaps argue for something more than another control. Exposed VPN front doors, uninspected encrypted traffic, dormant licensed controls, unenforced malicious-IP blocking, and ungoverned AI and MCP endpoints are the same failure surfacing in five places: a control that exists somewhere in the stack but isn’t applied everywhere the traffic is. Fixing them one at a time, console by console, is slow, unwieldy, and doesn’t ensure consistent enforcement across an enterprise. As AI further accelerates attacks and expands the attack surface across identities, applications, clouds, and network connections, organizations can no longer rely on a patchwork of disconnected tools.

This reflects a broader cybersecurity shift Versa calls Pervasive Security.

Gaps in disparate SASE architectures point to the need for a different model: a small set of best-in-class platforms spanning endpoint, identity, cloud, security operations, application security, and network and SASE that share visibility and context and coordinate enforcement in real time. This approach lets teams prevent threats and contain those that get through before they spread, rather than responding after the damage is done. Inspection, enforcement, and identity become properties of the platform every packet and every session already traverses. They’re also applied uniformly across branch, data center, cloud, remote user, and now AI agent. Closing the five gaps stops being five separate activation projects and becomes one policy posture.

How VersaONE delivers Pervasive Security

VersaONE puts the Pervasive Security model into practice. Instead of separate appliances and functions, it runs one operating system, one single-pass parallel processing engine, one policy engine, and one console spanning SD-WAN, SSE, NGFW, and ZTNA. That converged design changes the economics behind each gap above.

Here’s how VersaONE addresses each gap:

Replace exposed VPN with native ZTNA

Since ZTNA, SD-WAN, and firewall enforcement run on the same platform rather than layered on top of a separate VPN concentrator, migrating an exposed VPN appliance behind zero-trust access is a policy change inside one console, not a second platform migration with its own project timeline.

Inspect encrypted traffic by default

Versa’s single-pass architecture processes each packet once, running DPI, NGFW, IPS, URL filtering, CASB, and SWG in parallel against a single decode rather than hairpinning traffic through a chain of discrete proxies. TLS inspection lives inside that same pass instead of being bolted on as a separate, latency-costly hop. Now full inspection is viable as the default architecturally, rather than something administrators quietly opt traffic out of to protect performance.

Activate dormant controls in seconds

With Versa’s single console and unified policy engine, IPS, malicious-IP blocking, and threat prevention are native, inline capabilities evaluated in the same pass as every other function, not separately licensed modules that need their own change window to switch from monitor to enforce. Metadata extracted once, by DPI for instance, is shared across every service in that same pass, so nothing stands between “licensed” and “enforcing.”

Block known-malicious traffic inline

IPS (30,000+ signatures), DPI-based application identification (3,800+ applications), and URL filtering (83+ categories) all execute inline in the same single pass, not in a bypassable, separately licensed layer. Every packet that traverses the platform is evaluated against the full control set by default. Moving a control from detection to enforcement is a policy setting, not a re-architecture.

Authenticate AI and MCP endpoints natively

As the newest attack surface, securing AI is where Versa’s unified architecture matters most. Versa’s zero-trust MCP architecture, delivered through the Versa Verbo operations layer and integrated into VersaONE, treats AI agents as a distinct identity class rather than an unauthenticated afterthought. Every agent action is checked against user identity, role-based access control, system policy, action-risk classification, and live system state before it executes, not after the fact. This applies whether the action is triggered by a human prompt or by autonomous agent-to-agent orchestration over MCP. Administrators define which actions run automatically, which require human approval, and which are blocked outright, with full attribution logging on every approved action. That’s identity-based authentication in front of an AI/agent surface, as a native extension of the same zero-trust engine already enforcing human ZTNA policy, not a parallel system bolted on afterward.

Mapping gaps and recommendations to VersaONE

Key takeaway

Architecture narrows the gap; it doesn’t eliminate the operational work. A converged platform can’t force a team to activate what it owns, but it reduces the number of separate integration projects standing between “licensed” and “enforcing.” What a single-pass, single-console architecture buys a security team is fewer places for that discipline to stall: fewer consoles to reconcile, and inspection that runs as the platform’s default rather than a setting someone has to remember to turn back on.

To learn more, explore the VersaONE platform.