A SASE proof-of-concept succeeds when it is tightly scoped and measured, not when you try to migrate everything at once. Pick one high-risk use case, usually replacing a remote-access VPN with ZTNA, run a 30-day pilot against a week-one baseline with clear KPIs, and let the numbers make the decision. This playbook gives you the plan, the success criteria and the test scenarios. The criteria that separate the platforms, one real console, instant policy changes, agentless OT coverage and EU data sovereignty, are exactly where a ground-up single-platform like Jimber pulls ahead of an acquisition-stitched enterprise stack.
Key takeaways
- Scope one or two critical use cases; trying to pilot the whole estate is the fastest way to fail.
- Take a baseline in week one (latency, throughput, weekly ticket volume) or you cannot prove improvement afterwards.
- Keep the pilot to 30 days: shorter misses failover edge cases, longer drifts into an unlicensed production environment.
- Test what marketing hides: time a global policy change, check whether the console is really one platform, and try to secure an agentless device.
- Weight your scorecard toward single-console management, instant policy propagation, agentless OT and EU sovereignty, which is where a single-codebase sovereign platform wins.
Scope it before you deploy it
Gartner and Forrester both stress that a SASE evaluation lives or dies on a tight scope. The most common mistake is trying to move the whole architecture to the new model in one step, which leads to analysis paralysis and business resistance. Start with a representative, high-risk use case instead: replacing legacy SSL or IPsec VPN for remote workers and contractors with ZTNA, or securing internet and SaaS traffic for one mobile business unit.
For the pilot group, begin with a core of 5 to 10 technical users (your IT and security team) in week one, then expand to 20 to 50 non-technical users from departments like sales or HR to test productivity and usability honestly. Keep the window to 30 days, up to 60 at most: a shorter run does not surface rare failover scenarios, while a longer one breeds project fatigue and risks the test environment quietly becoming unlicensed production. A single-vendor SASE, where network and security run from one codebase and console, shortens the whole exercise compared with stitching multiple vendors together.
The 30-day plan
| Week | Goals | Checklist |
|---|---|---|
| Week 1 | Design, baseline, identity | Map key on-premises and SaaS apps and document critical data flows; select the pilot group (IT plus one business unit); connect the SASE console to your IdP via SAML/OIDC; baseline current latency, throughput and weekly helpdesk tickets. |
| Week 2 | Agent rollout and ZTNA policy | Deploy the endpoint client to the IT pilot group via Intune; configure fine-grained ZTNA rules for a set of internal web and SSH apps; activate the SWG with basic filtering and test SSL/TLS decryption; verify connection stability while roaming between Wi-Fi and 4G/5G. |
| Week 3 | Scale and advanced scenarios | Expand to non-technical users; test conditional access on device posture and malware blocking; run failover tests by dropping active lines and PoPs; evaluate isolation of agentless devices (IoT, printers, OT) via inline isolation hardware. |
| Week 4 | Measurement, audit, decision | Export and verify audit logs against NIS2 and CyFun reporting needs; collect qualitative user feedback; compare performance KPIs to the week-one baseline; calculate the full TCO and write the final report. |
Success criteria and KPI matrix
Define these before you start so the evaluation is objective and the business case writes itself.
| Domain | KPI | Target | How to verify |
|---|---|---|---|
| Security posture | Least-privilege enforcement | 100% of unauthorised access blocked; no port publicly exposed | Port-scan and pentest the application gateways to confirm they are invisible (dark cloud) |
| Threat prevention | Inline malware and URL blocking | 100% of known malware payloads and phishing test domains blocked | Download the EICAR test file over HTTP and HTTPS and confirm the SWG ends and logs the session |
| Network performance | Cloud-layer proxy latency | Measurably lower than the incumbent VPN at the nearest PoP | Continuous ping and HTTP probes through the SASE tunnel |
| Throughput | File-transfer speed | Improvement over the old VPN architecture | Standardised 500 MB uploads and downloads to cloud storage |
| User experience | Connectivity helpdesk tickets | Reduction versus baseline | Compare ITSM ticket volume during the PoC to historical data |
| Management overhead | Time to push a global policy change | Near-instant propagation | Add a block rule in the console and time when it takes effect on a live session |
For context on the performance line, the WireGuard protocol over UDP delivers roughly 15% higher throughput and 20% lower latency than IPsec on comparable hardware, which is part of why a modern SASE feels faster than a legacy VPN. Fold the cost side into week four using our SASE pricing models guide.
The test-scenario script
Run these standardised scenarios in weeks 2 and 3 to put the platform under realistic conditions:
- Onboarding. Add a test user to the directory, confirm sync to the SASE console, push the client via Intune, and sign in with SSO. Expect a productive user within 15 minutes and no manual network config on the endpoint.
- Per-application ZTNA. Grant a user access only to the internal HR app on port 443, confirm it works, then try SSH to a database on port 22 on the same segment. The SSH attempt should be blocked and the database invisible to a scanner.
- MFA and conditional access. Deny a finance app unless the device meets posture (BitLocker on, OS patched). A managed device passes after MFA; a non-compliant one is refused with a clear reason.
- Blocking risky destinations. With SSL/TLS decryption on, visit a risky-category site (blocked with a warning page) and download the EICAR file over HTTPS (aborted mid-session and logged at high priority).
- SD-WAN failover. On a branch with two internet lines, start a Teams call, then pull the primary line. The call should hold over the backup without a noticeable drop.
- Offboarding. While a test user is logged into a ZTNA app, deactivate the account in the IdP and confirm the session is forcibly terminated within about five minutes.
- Reporting and audit. Simulate port scans and unauthorised transfers, then generate a 24-hour audit report and confirm it includes user identity, device ID, source IP, destination and the policy applied, in an exportable, immutable form a CyFun auditor can use.
Four pitfalls to plan around
- Over-broad scope. Limit the pilot to one or two critical use cases, such as remote access for the dev team or internet security for one branch.
- No baseline. Document latency, transfer speeds and weekly ticket volume for the current setup in week one, or you cannot prove the gain.
- Ignoring user feedback. Add non-technical users in week three and collect their experience through a short standard survey, so usability problems surface before rollout.
- No rollback plan. Make sure every change (DNS, routing, client installs) can be fully reverted within 15 minutes.
What the market and the forums are really telling you
Three recurring objections should shape your scorecard. First, the single-pane-of-glass illusion: larger vendors like Palo Alto and Zscaler advertise one console, but administrators report a patchwork of acquired technologies that forces constant switching between separate portals for internet access and private access, with inconsistent policy. That is the case for evaluating platforms built from the ground up as one codebase, such as Jimber, where one policy engine runs every component. Second, configuration-push delay: on some enterprise platforms every rule change needs a formal push that takes 3 to 5 minutes, which is why you should time propagation explicitly during the PoC. Third, post-acquisition support decline: reviews of established SASE and SD-WAN products show support quality dropping after acquisitions, and for a mid-market team without a 24/7 SOC, direct access to local, expert European support is close to essential.
Weigh these into the decision and the profile of the winning platform becomes clear: a genuinely converged, single-codebase console; instant policy changes; agentless coverage for OT via inline isolation such as the NIAC; local EU support; and EU data sovereignty so that inspection of your traffic does not fall under foreign-surveillance law. That is the shape of Jimber, and it is a straightforward one to prove out in 30 days. Our notes on where mid-market SASE migrations stall and the pilot-to-rollout timeline carry the project beyond the PoC.
Frequently asked questions
Why is a traditional VPN no longer enough under NIS2?
After authentication, a VPN grants Layer 3 access to a whole network segment, so stolen credentials or a compromised endpoint let an attacker move laterally to reach critical databases or ERP systems. NIS2 and CyFun require strict segmentation and least privilege. ZTNA replaces broad access with fine-grained, identity- and device-based connections to only the specific applications a user needs.
Is a SASE platform too complex and expensive for a small IT team?
It depends heavily on the vendor. Traditional US enterprise platforms are complex and often need several specialists to run separate portals, with opaque bandwidth-based pricing. European mid-market platforms such as Jimber are built for simplicity: ZTNA, SWG, FWaaS and SD-WAN in one console with one policy engine and transparent per-user pricing, which a two-person IT team can run efficiently.
What is the difference between single-vendor and multi-vendor SASE?
Single-vendor SASE delivers networking and security from one integrated cloud platform, giving one console, consistent logs and lower operational complexity. Multi-vendor SASE links one vendor’s network gear to another’s cloud security through API integrations and service chaining, which tends to fragment policy management, add latency and slow troubleshooting because vendors can point at each other.
How does SASE secure devices that cannot run an agent?
Standard ZTNA depends on an endpoint agent, which printers, VoIP phones, IP cameras and industrial PLCs cannot run. During the PoC, look for a vendor with native hardware-based network isolation, such as Jimber’s Network Isolation Access Controller, an inline device that places a zero-trust barrier in front of the agentless asset so it can only reach pre-approved upstream systems.
How does the CyberFundamentals framework help with NIS2 compliance?
The CCB built CyFun as the practical translation of NIS2 into concrete controls, across four levels (Small, Basic, Important, Essential). For an SME in or adjacent to NIS2 scope, reaching verified CyFun Basic or Important gives an official presumption of conformity, so you can show an auditor you meet the legal requirements.
Why does EU data sovereignty matter when choosing a SASE vendor?
A US SASE platform decrypts and inspects your network and internet traffic in its cloud PoPs, and under the US CLOUD Act those US companies can be compelled to hand data to US agencies even if it sits on European servers. That conflicts with GDPR and can create non-compliance in a DORA or NIS2 audit. A fully European, sovereign provider such as Jimber, based in Belgium with EU-only processing, removes that legal risk.
Prove it in 30 days, then decide
Scope one high-risk use case, baseline it, run the scenarios above, and score the platforms on the criteria that actually differentiate them. If you want a converged, EU-sovereign platform that is quick to stand up in a pilot and covers managed users, unmanaged contractors and agentless OT, book a Jimber demo to scope your PoC, or review flat-rate pricing for the TCO step.
