How long does a SASE implementation take?
A cloud-native SASE deployment for a mid-market organisation with 50 to 400 users follows six phases and takes 60 to 90 days from scoping to full rollout. The phases are assessment, identity and policy design, controlled pilot, phased expansion, legacy decommission, and ongoing optimisation. Platforms like Jimber that are designed for rapid onboarding can have a pilot group operational in days, not weeks, because there is no hardware to procure or rack.
Most IT teams assume SASE migration will feel like the firewall replacement projects they already dread. Twelve months of planning. Six months of parallel running. Three months of fixing things that broke. That expectation comes from hardware-centric projects where every site needs a truck roll, a rack mount, and a change window. Cloud-native SASE works differently. Policies are defined centrally and pushed instantly. Users connect through software, not site-specific appliances. The entire SASE implementation timeline compresses from quarters into weeks. This guide walks through each phase with concrete steps, team responsibilities, and the common blockers that slow deployments down.
| Phase | Timeline | Key activities | Outcome |
|---|---|---|---|
| Assessment and scoping | Week 1-2 | Audit current stack, map users to applications, define success criteria | Clear scope and priority list |
| Identity and policy design | Week 2-3 | IdP integration, access policies, device posture baselines | Authentication and policy framework ready |
| Controlled pilot | Week 3-5 | 10-20% of users, remote workers first, parallel VPN running | Validated configuration, user feedback collected |
| Phased rollout | Week 5-10 | Site-by-site, department-by-department expansion | 80%+ of users and applications migrated |
| Legacy decommission | Week 8-12 | VPN sunset, firewall retirement, contract wind-down | Single platform, no parallel systems |
| Optimise and monitor | Ongoing | Policy refinement, logging review, compliance evidence | Continuous improvement and audit readiness |
Phase 1: assessment and scoping (week 1-2)
Every SASE deployment starts with a clear picture of what you have and what needs to change first. Skip this step and you replicate old VPN access patterns in a new tool, which defeats the purpose.
Start by mapping your current security stack. List every appliance, subscription, and console your team manages. For most mid-market organisations, this exercise alone reveals the fragmentation: a VPN concentrator here, a standalone web filter there, branch firewalls with their own rule sets, and an endpoint tool that nobody checks anymore.
Next, map users to applications. Not “the sales team uses the network.” Specific applications. CRM, ERP, file shares, the invoicing portal, the production monitoring dashboard. This inventory becomes the basis for your ZTNA policies later. Most organisations discover that the average user needs access to three to five applications, not the entire network that VPN was granting.
Define your quick wins. Which user group experiences the most VPN friction? Usually remote workers and field engineers. Which application causes the most support tickets? Start there. Your SASE vendor comparison guide should inform which platform matches your scoping requirements.
Finally, agree on success criteria before you start. Measurable targets like “reduce VPN-related support tickets by 50%” or “achieve sub-30ms latency for remote users accessing cloud apps” give the project a clear finish line rather than an endless optimisation loop.
Phase 2: identity and policy design (week 2-3)
Identity is the foundation of SASE. Without a working identity provider integration, nothing else functions. This phase runs partly in parallel with the tail end of assessment.
Connect your identity provider first. Microsoft Entra ID, Okta, Google Workspace, or whichever IdP your organisation uses. Synchronise user groups and verify that role assignments align with business functions, not legacy AD groups that accumulated over years. Our guide on identity providers explained covers the integration patterns for SAML and OIDC in detail.
Then define your access policies. The principle is simple: each user gets access only to the applications their role requires. Nothing more. A finance team member reaches the invoicing system and the reporting portal. An engineer reaches the production monitoring tool and the code repository. Neither sees the other’s applications.
Set device posture baselines alongside access policies. Decide which signals matter for your organisation: OS version currency, disk encryption status, endpoint protection running, device registration. Jimber’s platform enforces these checks at the point of access, so non-compliant devices are blocked or given restricted scope automatically. For a step-by-step walkthrough, see our guide on device posture checks for NIS2.
Document your policy decisions. This documentation becomes compliance evidence later and prevents the “why was this configured this way?” conversations six months from now.
Phase 3: controlled pilot (week 3-5)
The pilot proves the platform works in your environment before you commit the rest of the organisation. Start small, measure everything, fix what breaks.
Select 10-20% of your users for the pilot. Remote workers are the ideal first group for two reasons. They experience the most VPN friction, so they notice improvement immediately. And they test the hardest access scenario: connecting from unpredictable networks through consumer ISPs.
Publish two to three applications through ZTNA. Pick applications that are high-usage but low-risk if something goes wrong. An internal wiki, a time registration system, or a project management tool. This lets your team learn how the platform behaves in practice while the stakes are manageable.
Cloud-native platforms like Jimber can onboard a pilot group in days, not weeks, because there is no hardware to ship or configure. The administrator creates the application definitions in the console, assigns them to the pilot group, and users connect through a lightweight agent or browser-based access.
Keep VPN running in parallel during the entire pilot. Users need a fallback if they hit an edge case the ZTNA configuration does not cover yet. Monitor three things closely: user experience (latency, connection stability), support ticket volume, and access logs showing policy hits and blocks. This data shapes the rollout plan for Phase 4.
Run the pilot for at least two weeks. One week is not enough to catch intermittent issues like certificate renewal problems or DNS resolution edge cases.
Phase 4: phased rollout (week 5-10)
With pilot data in hand, expand coverage methodically. The goal is to reach 80% or more of users and applications before touching legacy infrastructure.
Roll out site by site or department by department. Each wave follows the same pattern: sync the user group, publish their applications, enable device posture checks, monitor for two to three days, then move to the next wave. Jimber’s single console means policy changes propagate instantly across all sites. There is no per-site configuration drift to manage.
Add business-critical applications in this phase. ERP, CRM, financial systems, and any application that touches sensitive data. These require stricter posture rules and tighter access policies than the pilot applications. Define exception workflows for edge cases: a contractor who needs temporary access, a shared workstation in a warehouse, a legacy application that only speaks RDP.
For organisations with OT environments, this phase includes deploying NIAC hardware for agentless devices. Printers, cameras, industrial controllers, and IoT sensors cannot run a ZTNA agent. Jimber’s NIAC appliances sit inline between the device and the network, enforcing Zero Trust controls without requiring software on the device itself.
Service partners managing multiple customers benefit from the multi-tenant architecture during this phase. Each customer environment is isolated, but templates and baseline policies can be shared across tenants. Our post on how MSPs deliver managed SASE covers the operational model in detail.
Track your success criteria from Phase 1 throughout the rollout. If VPN support tickets are not dropping, something in the configuration needs attention before you expand further.
Phase 5: legacy decommission (week 8-12)
Once application coverage reaches 80% or more and the pilot data confirms stable performance, begin retiring legacy infrastructure. This is the phase where the cost savings materialise.
Start with VPN. Disable VPN access for applications that are fully published through ZTNA. Do this in stages: remove the application from VPN configuration, monitor for a week, then proceed to the next application. Keep documented fallback procedures available until you are confident the transition is complete.
Next, retire branch firewalls. Cloud-delivered FWaaS replaces the need for on-premise firewall hardware at each location. For most mid-market organisations, this eliminates the firmware update cycles, rule set management, and hardware refresh costs that consumed a disproportionate share of IT time.
Jimber’s single console means IT teams do not manage two dashboards during the transition period. Access policies, web security, SD-WAN connectivity, and logging all live in one interface from day one. The transition is about removing old infrastructure, not learning new tools.
Wind down contracts and licences for decommissioned products. VPN concentrator support agreements, standalone web filter subscriptions, and per-site firewall licences can represent significant annual costs. A Belgian wealth management firm reduced total security costs by 58% after completing this consolidation.
Phase 6: optimise and monitor (ongoing)
SASE is not a set-and-forget deployment. The ongoing phase is where you refine policies based on real usage data and build the compliance evidence that auditors expect.
Review access logs monthly. Look for users who have permissions they never exercise and tighten their scope. Look for applications that generate frequent policy blocks and investigate whether the policy is too restrictive or whether someone is trying to reach something they should not.
Run a quarterly policy audit. Verify that user groups still reflect actual roles, that device posture baselines are current (OS version thresholds need updating as vendors release new versions), and that exception policies have not accumulated into permanent workarounds.
For NIS2-regulated organisations, the logging and reporting capabilities of your SASE platform are your compliance engine. Jimber’s built-in logging and device posture checks cover several NIS2 requirements from day one: access control documentation, incident detection within 24 hours, and device compliance evidence. Our NIS2 compliance checklist maps these requirements to specific platform capabilities.
What slows SASE deployments down (and how to avoid it)
The 90-day timeline above assumes competent execution. In practice, four common blockers extend deployments unnecessarily.
No identity provider readiness. If your IdP is misconfigured, has stale user groups, or lacks MFA enforcement, SASE integration stalls at Phase 2. Clean up your directory before you start. Remove orphaned accounts, verify group memberships, and enable MFA. This preparation work pays for itself.
DNS misconfiguration. Split DNS environments, custom DNS resolvers, and applications that hardcode DNS servers all cause issues when traffic routing changes. Audit your DNS configuration during assessment. Document every internal DNS zone and custom resolver.
No executive sponsorship. SASE deployment touches every user in the organisation. Without visible executive support, individual departments push back on changes, pilots stall waiting for approvals, and legacy contracts get renewed “just in case.” Get a board-level sponsor before Phase 1.
No legacy sunset plan. Some teams deploy SASE perfectly but never decommission the old infrastructure. VPN stays running “for backup.” Branch firewalls keep getting patched. The organisation pays for both systems indefinitely. Set a sunset date during scoping and hold to it.
How NIS2 deadlines affect your SASE implementation timeline
Belgium’s CyberFundamentals (CyFun) verification deadline of April 2026 has passed. Organisations that needed to demonstrate Basic or Important level compliance should already have their technical controls in place. For those still working toward compliance, every week of delay is a week of exposure to enforcement action.
NIS2 Article 21 requires documented access controls, incident detection capabilities, and supply chain security measures. A SASE platform addresses approximately 90% of these technical requirements through identity-based access, centralised logging, and device posture enforcement. The NIS2 compliance overview covers the full regulatory context.
The practical implication for your SASE implementation timeline: do not treat the deployment as a multi-quarter project. The compliance clock is already running. A 90-day implementation that delivers working controls is worth more than a 12-month plan that produces a perfectly documented roadmap and no protection.
For organisations in the Netherlands, the Cyberbeveiligingswet activated in early 2026. The UK’s NIS regulations follow their own enforcement schedule. Regardless of jurisdiction, the direction is the same: demonstrable technical controls, not documented intentions.
Frequently asked questions
Can we run SASE alongside our existing firewall?
Yes, and you should during the transition. SASE platforms are designed for phased deployment. Keep your firewalls active while you migrate applications to ZTNA and shift web security to SWG. Once coverage reaches 80% or more, decommission firewalls at branch locations. Some organisations retain a perimeter firewall at the data centre for specific north-south traffic controls during the transition, but the long-term direction is full consolidation.
How many users should be in the pilot?
Aim for 10-20% of your user base, with a minimum of 15-20 users to generate meaningful data. Include remote workers, frequent travellers, and at least one department that accesses sensitive applications. Too few users and you will not catch edge cases. Too many and you lose the controlled environment that makes a pilot useful.
Do we need to replace our SD-WAN?
Not necessarily. If you already have a working SD-WAN deployment and only need cloud-delivered security, SSE (Security Service Edge) may be sufficient. If your SD-WAN contracts are expiring or you want a single management plane across both remote users and branch offices, unified SASE is the cleaner path. Our SASE architecture explained guide covers the distinction between SSE and full SASE.
What about devices that cannot run agents?
Printers, IoT sensors, cameras, and industrial equipment need inline isolation rather than agent-based protection. NIAC hardware places these devices behind identity-aware access controls that restrict communication to explicitly defined flows. The device connects only to its designated destination. Nothing else. This closes the blind spot that traditional security tools ignore.
How does SASE deployment work for organisations with multiple sites?
SD-WAN handles multi-site connectivity as part of the SASE platform. Branch locations connect through encrypted tunnels over standard internet links. Zero-touch provisioning means a device ships to the site, gets plugged in by non-technical staff, and automatically retrieves its configuration from the cloud. Deployment time per site drops from days to minutes.
What if we have a service partner managing our IT?
Service partners accelerate the timeline. They bring deployment experience from previous customers, and multi-tenant SASE platforms let them manage your environment from the same console they use for their other customers. Policy templates, standardised baselines, and repeatable onboarding processes mean the partner is not starting from scratch for each engagement.
Ready to map a SASE implementation timeline for your organisation? Book a demo and walk through a deployment plan tailored to your team size, site count, and compliance requirements. Jimber’s platform is built for mid-market organisations that need enterprise-grade security without the 12-month implementation project.
