Mid-market SASE migration: where projects actually stall

Why SASE projects stall in the mid-market and how a phased SASE migration avoids it. The real stall points, and how to clear them.
IT manager and network engineer reviewing a phased SASE migration plan in a bright Brussels office.

Most mid-market SASE projects do not stall because the software falls short. They stall because teams treat the rollout as a hardware swap instead of a policy migration. The pattern is consistent: organisations with 50 to 400 users that try to move everything at once hit operational disruption, while those that phase the work by identity and policy keep production running.

This is not a list of mistakes or a step-by-step timeline. It is a look at where migrations actually get stuck, and why.

What are the main SASE migration challenges in the mid-market?

The main SASE migration challenges come from treating deployment as a hardware replacement rather than a policy integration project. The recurring blockers are manual tunnel configuration across multi-vendor edges, latency from centralised backhauling, and application breakage caused by certificate pinning and TLS 1.3. A phased SASE migration avoids them. Platforms like Jimber start with identity-first access for a pilot group, then layer in web filtering and agentless device isolation once the baseline holds.

Why do mid-market SASE projects fail?

Deployment reviews point to one root cause more than any other. Teams jump into product comparisons before defining what they actually need to connect. Requirements balloon, configurations try to satisfy everyone, and operations buckle after go-live. The other common failure modes are weak identity hygiene, underestimating exception handling, and never agreeing where logging and troubleshooting responsibility sits.

The cost of getting it wrong is rising. According to IBM’s 2025 Cost of a Data Breach Report, the global average breach now sits at USD 4.44 million, climbing to USD 10.22 million in the United States. IBM also found malicious insider attacks were the most expensive category at USD 4.92 million, with supply chain compromise close behind at USD 4.91 million. Recovery is slow: IBM reported that 86% of breached organisations saw operational disruption affecting sales or production.

The threat environment compounds the risk during a migration. The ENISA Threat Landscape 2025 analysed 4,875 incidents and found phishing remained the dominant intrusion vector at 60%, followed by vulnerability exploitation at 21.3%. ENISA also noted that AI-supported phishing made up more than 80% of observed social engineering activity worldwide by early 2025.

When an attacker breaches an edge device on a flat network, the absence of microsegmentation lets the threat spread sideways fast. Industry research cited by ENISA and IBM consistently ties lateral movement to a large share of successful breaches. Failing to restrict internal communication paths during a migration leaves the whole organisation exposed at exactly the moment things are in flux.

Metric Value Source
Global average cost of a data breach USD 4.44 million IBM Cost of a Data Breach Report 2025
US average cost of a data breach USD 10.22 million IBM Cost of a Data Breach Report 2025
Average cost of a malicious insider attack USD 4.92 million IBM Cost of a Data Breach Report 2025
Average cost of a supply chain compromise USD 4.91 million IBM Cost of a Data Breach Report 2025
Organisations reporting operational disruption after a breach 86% IBM Cost of a Data Breach Report 2025
Phishing share of recorded intrusions 60% ENISA Threat Landscape 2025
Vulnerability exploitation share of intrusions 21.3% ENISA Threat Landscape 2025
Incidents analysed 4,875 ENISA Threat Landscape 2025

How does tool sprawl exhaust lean IT teams?

Mid-market IT teams are buried under security tooling that does not talk to itself. The result is a fragmented stack of firewalls, VPN concentrators and web gateways that each need their own console and their own attention. That sprawl slows incident response, drains lean staff, and multiplies the chance of a misconfiguration.

Consolidation is now the priority for most European buyers. Gartner has estimated that 65% of enterprises will adopt single-vendor SASE by the end of 2026. The logic is straightforward: one cloud-managed console, one policy language, fewer places to make a mistake.

Single-vendor platforms like Jimber address the sprawl directly by bringing ZTNA, SWG, FWaaS, SD-WAN and WAF into one console. For a 50 to 400 user organisation, that means weeks to first value instead of a multi-quarter integration project, and one audit log instead of six. Because many mid-market teams lean on a service partner for capacity, Jimber’s multi-tenant console lets partners manage several client environments from shared templates without sharing credentials.

Where edge connectivity becomes the first bottleneck

The first stage of any SASE rollout is secure connectivity from the edge to the cloud, and it is where timelines slip. Teams hand-configure IPsec or GRE tunnels from branch appliances to multiple points of presence, test failover, and validate routing one site at a time. Coordinating those tunnels across mixed-vendor edges turns a planned few weeks into several months.

Legacy firewalls and MPLS circuits add friction because they cannot be ripped out overnight without dropping production traffic. Misconfigured tunnels flap, which means unpredictable connectivity, degraded application performance, and outages. Older SASE designs that backhaul every session through a central PoP for inspection introduce enough latency to make real-time collaboration tools painful. When failover hits, traffic shifts en masse, sessions reset, and latency spikes.

Decoupling security policy from the physical network removes most of this. Cloud-native connectivity that needs no inbound firewall ports lets a pilot group come online in days rather than waiting on hardware and routing changes. This is the model Jimber is built around: lightweight onboarding, policy defined once and enforced at distributed control points, no truck roll per site.

Connectivity aspect Legacy edge network Modern SASE connectivity
Tunnel configuration Manual IPsec/GRE setup across multi-vendor edges Lightweight cloud connectors, no inbound ports
Integration friction High; complex routing around active MPLS and firewalls Decoupled policy engine that bypasses the physical layer
Performance and latency High; all traffic backhauled through central PoPs Optimised routing through local controllers
Failover resilience Fragile; traffic shifts reset sessions and spike latency Resilient; localised inspection and cloud-native control plane
Lifecycle operations Heavy; manual hardware, route and certificate updates Single-console management with reusable policy templates

Why TLS 1.3 and certificate pinning break legacy inspection

Around 94% of web requests in 2026 run over HTTPS, so payload inspection requires TLS decryption. That is where pinned applications break. When a proxy intercepts the connection and presents a leaf certificate signed by the enterprise root CA, a standard browser accepts it, but a pinned app compares the public key against its hardcoded pin, sees a mismatch, and tears the connection down. Critical business apps stop working, and teams end up maintaining sprawling manual bypass lists.

TLS 1.3 and Encrypted ClientHello tighten the constraint further by encrypting the Server Name Indication inside the handshake, so the proxy cannot see the destination before decryption. Full decryption of everything is no longer a workable practice.

The realistic approach is selective decryption. Jimber combines protocol-aware decryption with category-based exclusions for privacy-sensitive traffic. Pinned services are exempted and covered by alternative controls instead, such as DNS-layer filtering, IP reputation and device posture checks. For unmanaged or high-risk sources, Jimber’s browser isolation runs the web content in a secure cloud container and streams only a visual representation to the endpoint, so nothing executes locally.

Traffic category Decryption action Alternative control
General web traffic Decrypt and inspect Inline antivirus, URL filtering, sandboxing
Cloud storage and file sharing Decrypt and inspect Inline DLP, file-type controls
Unmanaged or high-risk sources Do not decrypt Browser isolation with container streaming
Pinned or privacy-sensitive services Bypass decryption DNS-layer filtering, IP reputation, device posture

How does data sovereignty change vendor selection?

For European organisations, NIS2 turns vendor selection into a compliance decision. The directive requires firms to manage cybersecurity risk across their ICT supply chain and report significant incidents within 24 hours. The harder question sits underneath that: physical data residency and legal jurisdiction are not the same thing.

US-headquartered SASE vendors often host data in EU regions, but under the US CLOUD Act they can still be legally compelled to hand over decryption keys, telemetry and cleartext metadata to US authorities. Certification under the EU-US Data Privacy Framework does not block a CLOUD Act order, because the two operate on different legal planes.

European platforms like Jimber resolve the conflict by operating under EU jurisdiction by default, keeping decryption keys and user data outside the reach of foreign legal regimes. For a NIS2 supply chain audit, that is the difference between pointing at a data centre location and being able to answer who actually controls the infrastructure.

In practice, this is what lets a public-sector body move citizen-facing applications behind identity-based policies and shorten audit preparation from a multi-week documentation exercise to a few days of evidence demonstration.

How do you bridge IT and OT without software agents?

Industrial sites, utilities and retail locations run plenty of devices that cannot take a software agent, including PLCs, printers, building management systems and IP cameras. Standard SASE struggles to secure them, so they sit as an exposed attack surface where an intruder can gain a foothold and move laterally across a flat network.

Rather than bolting on separate point solutions, platforms like Jimber establish a secure integration bridge between IT and OT. Jimber’s NIAC hardware sits inline between unmanaged devices and the wider network and enforces identity-aware allow rules. An IP camera talks only to its designated video management system, a PLC talks only to its specific historian, and everything else upstream is blocked. The appliance secures these assets without disrupting production workflows.

For a manufacturer connecting factory-floor PLCs to corporate IT, this means maintenance engineers reach specific machines only through recorded, time-limited sessions, while the production network stays isolated and the audit trail stays complete.

Jimber offers three network isolation appliances sized for mid-market infrastructure.

Device model Gigabit Ethernet ports SFP interfaces Capacity Use case
Network Controller N1100 (UTP) 6 None Up to 350 isolated devices Standard mid-market branch, WAN throughput up to 1 Gbps
Network Controller N2100 (Fiber) 6 2x SFP Gigabit Up to 500 isolated devices Faster fibre uplink for multi-site offices
Network Controller N5100 (10G) 6 2x SFP+ 10 Gigabit High capacity High-speed data centre and core network integration

What does a phased SASE migration actually look like?

Trying to migrate the whole network in one move is the single biggest reason these projects fail. Experienced teams transition in policy segments, which keeps risk contained and uptime steady. The pattern that works is eight steps.

  1. Define scope and success metrics by picking one business process and its supporting applications.
  2. Compile a lightweight, version-controlled inventory of users, admin roles, managed devices and unmanaged devices.
  3. Map the minimal communication paths required, separating human traffic from machine-to-machine traffic, and include supporting services like DNS, NTP and identity.
  4. Choose enforcement points: a Zero Trust access layer for users, inline isolation for agentless devices.
  5. Deploy policies in monitor mode for one or two change cycles, cross-reference logs against the inventory, and close gaps before you block anything.
  6. Switch to active enforcement and stand up a Just-In-Time exception process with named owners and expiry dates, so exceptions do not sprawl.
  7. Validate compliance by documenting evidence of least privilege and incident containment for NIS2 audits.
  8. Automate the recurring work through APIs or policy-as-code for version control and posture checks.

One mistake shows up again and again: writing rules around IP addresses instead of identities. Dynamic addressing and remote workers make IP-centric rules go stale faster than anyone can maintain them. This phased approach is especially useful coming off legacy firewalls. A SonicWall-based team, for example, can follow a practical SonicWall to SASE migration guide and run parallel environments to avoid downtime. For the full process view, the 90-day SASE implementation timeline maps each phase, and the three deployment mistakes we see every quarter covers the organisational traps.

How do device posture checks support compliance?

Device posture checks verify the security state of an endpoint, things like OS patch level, an active firewall and disk encryption, before granting access. Under NIS2 and Belgium’s CyberFundamentals framework, which set its verification window in April 2026, these checks give documented proof that access decisions account for device health.

A common error is setting the bar too high on day one, which locks out a large share of users and floods the helpdesk. Start with three simple signals, set a baseline, then raise the threshold gradually. Posture also has to be evaluated continuously, not just at first connection, because a device can fall out of compliance mid-session.

For personal devices, Jimber pairs restricted profiles with secure browser-based access. Browser isolation runs web content in a cloud container and streams only the visual output to the endpoint, so malicious code never reaches the device. That continuous enforcement is what lets a team show auditors real, ongoing risk management rather than a point-in-time snapshot. In a clinical setting, for example, it is what keeps electronic health records reachable only from compliant, managed devices across clinics and remote staff.

How do mid-market SASE architectures compare?

European mid-market teams have to weigh features against operational complexity and jurisdiction risk. Jimber is built for 50 to 400 user organisations, combining ZTNA, SWG, FWaaS, SD-WAN and a Web Application Firewall in one console, with transparent per-user pricing and EU-only data hosting. The mainstream alternatives carry structural trade-offs at this scale.

Zscaler Internet Access splits functions across tiers, limiting ZTNA to a fraction of users in its entry bundle and capping browser isolation per user per month. Check Point Harmony SASE runs a hybrid control plane that routes agent communication through legacy Perimeter 81 AWS endpoints. Cato Networks targets larger global enterprises, with limited unmanaged-device support and no native WAF. Palo Alto Prisma Access sets a minimum user count that forces smaller organisations to pay for capacity they do not use. Twingate is limited to inbound ZTNA with DNS-level filtering only, and no cloud firewall or unmanaged-device support.

Criterion Jimber SASE Zscaler Internet Access Check Point Harmony SASE Cato Networks Palo Alto Prisma Access Twingate ZTNA
Architecture and hosting Cloud-native single codebase, EU-hosted by default Cloud-native multi-tenant Hybrid control plane on AWS Perimeter 81 base Cloud-native single platform PAN-OS firewall-first in cloud PoPs ZTNA-first cloud proxy
OT and agentless devices Native inline isolation via NIAC hardware Separate add-on required Routed through separate gateways Limited, site-level socket Separate hardware or add-on Not supported
Browser isolation Native container streaming Add-on with usage caps Available Not native Add-on or separate module Not supported
Web Application Firewall Included natively In advanced suites Not native Not native In advanced bundles Not supported
Data sovereignty EU jurisdiction by default US parent, CLOUD Act exposure US parent / AWS, CLOUD Act exposure Foreign-jurisdiction exposure US parent, CLOUD Act exposure US control plane
Pricing model Transparent per-user, no surcharges Tiered with add-on modules Split across multiple SKUs Bandwidth or contract negotiation Credit-based, high minimum commit Public per-user tiers

Moving to a consolidated, European-hosted SASE platform lets a mid-market team sidestep both the complexity and the security gaps of a legacy stack. You protect remote workers, secure agentless devices, and produce the evidence NIS2 auditors actually ask for, from one console. If you want to see what that looks like against your own environment, the SASE business case for less complexity and more control lays out the cost and operational picture, and a demo with the Jimber team turns it into a concrete migration path for your sites.

Frequently asked questions about SASE migrations

How long does a mid-market SASE migration take?

A phased migration for 50 to 400 users usually runs between six weeks and ninety days. Tightly structured rollouts can move core ZTNA and web security inside four to six weeks by using identity-centric configuration rather than per-site hardware work.

Can unmanaged OT and IoT devices be brought into SASE?

Yes. Agentless devices can be secured with inline hardware such as Jimber’s NIAC appliances. They sit between the device and the wider network, enforcing identity-aware policies without installing any software on the device itself.

How does SASE handle European data sovereignty under the CLOUD Act?

US-headquartered vendors stay subject to the CLOUD Act regardless of where data is stored. European organisations resolve this by choosing an EU-native platform like Jimber, which operates entirely under EU jurisdiction and processes data within EU borders.

Is full decryption of all web traffic required for compliance?

No. Best practice in 2026 is selective decryption: protocol-aware inspection of higher-risk traffic, with privacy exclusions for sensitive categories, backed by alternative controls such as DNS-layer filtering and device posture checks.

What is the core difference between ZTNA and a traditional VPN?

A VPN grants broad network access once connected, which enables lateral movement. ZTNA verifies continuously and restricts each user to specific authorised applications, keeping access least-privilege and containing the blast radius of a compromised account.

Find out how we can protect your business

In our demo call we’ll show you how our technology works and how it can help you secure your data from cyber threats.

Cybersecurity
Are you an integrator or distributor?

Need an affordable cybersecurity solution for your customers?

We’d love to help you get your customers on board.

checkmark

White glove onboarding

checkmark

Team trainings

checkmark

Dedicated customer service rep

checkmark

Invoices for each client

checkmark

Security and Privacy guaranteed