SASE Deployment
We plan and implement SASE and ZTNA on Fortinet and Microsoft, bringing identity, application access, network traffic and security enforcement into one design.
The work runs from identity and application discovery through policy, testing and migration to running the service, across your existing VPN, private applications, branch networks and cloud services.
When a SASE deployment needs planning
The platform may already be chosen. The rollout still depends on the applications, identities and network paths you have today.
Replacing remote-access VPN
Work out which applications and user groups can move to ZTNA, and which still need network-level connectivity.
Adding cloud security across your sites
Work through existing firewalls, SD-WAN, internet breakout, traffic forwarding and where inspection happens.
Deploying Entra Private Access or Internet Access
Set the identity and device conditions, application publishing, licensing and forwarding before access policies go live.
Extending a Fortinet environment
Review FortiGate, FortiOS, FortiSASE, ZTNA, policy management and logging, and how they'll work together.
Meeting new information protection requirements
Identify the traffic and data that need inspection, the DLP controls available and the business processes enforcement will touch.
Moving users without losing essential systems
Document application dependencies, test the new access methods and set cutover and rollback steps before existing connections go.
Start with what you have today
We assess the environment before deciding which services to introduce and in what order: identity, applications, network, existing security controls and who owns what.
| Area | What we assess | What it tells us |
|---|---|---|
| Identity | Entra ID, Active Directory, MFA, Conditional Access, groups and privileged access | Accounts, policies and exceptions that need attention |
| Devices | Device management, compliance, endpoint security and unmanaged access | Which device conditions we can enforce |
| Applications | Owners, authentication, protocols and internal dependencies | Which applications suit ZTNA and which need other connectivity |
| Network | WAN, SD-WAN, VPN, routing, DNS, internet breakout and firewalls | Traffic paths and forwarding requirements |
| Security | Secure Web Gateway, CASB, DLP, firewall policy, inspection and logging | Controls to keep, integrate or change |
| Operations | Platform administration, support responsibilities and change processes | Who owns policies, connectors, incidents and reviews |
Tick what is already true in your environment.
Ready for a first ZTNA group A pilot can start soon Preparation first, then a pilot Start with discovery and identity Where would you start?
The foundations are in place. We would confirm them in the assessment, then pick a pilot group with well-documented applications. The essentials for access decisions are there. The remaining items can run alongside the pilot. Some groundwork is in place. Closing the gaps below keeps the pilot from carrying today’s exceptions into the new platform. Most deployments at this point begin with the application inventory and an identity review. That work is useful whichever platform you choose. Tick what is already true and we’ll show the likely first step.
- Map the applications behind the VPN
- Clean up identities and groups
- Close MFA and Conditional Access gaps
- Bring devices under management
- Settle the platform and scope
- Name owners for access policy
A business can be ready for a first ZTNA group while branch integration or internet security still needs preparation. The assessment sets the scope and the order of work.
Map the applications before changing access
Existing VPN connections usually carry more than the applications anyone documented. File shares, authentication services, printers, remote administration tools and older protocols can depend on routes or permissions that are rarely visible day to day.
If VPN goes before those dependencies are known, business processes stop, even with ZTNA working as designed.
What we record for each application
Owner and users
Who is responsible for the application, which groups need access, and whether external users or service accounts are involved.
Authentication
The current sign-in method, federation support, certificates, Kerberos dependencies and any legacy sign-in requirements.
Network dependencies
Required hosts, ports, protocols, DNS resolution, file services, domain controllers and connections to other internal systems.
Device and access requirements
Whether access needs a managed device, an installed client, browser support, privileged permissions or network-level connectivity.
Business dependencies
How the application is used, what an outage would cost and how its owner will test it.
Take a mid-size business and step through what its VPN is documented to carry, what discovery finds, and where each item ends up.
An internal web application with modern sign-in. It is published through a ZTNA connector to the finance group only, so nobody else can see it. A standard internal website with no unusual protocols, which makes it a good first application to prove the design. Already a SaaS service. It only ran over the VPN because of how routing was set up, so it moves to direct access with identity and web controls applied. File access works through supported ZTNA platforms, but large files and offline sync are tested with the project teams before they move. Found in discovery. Sign-in to the file shares and finance system depends on them, so they are published for authentication before anything else moves. Found in discovery. People were printing to the office from home, and nobody had written it down. It is tested in the pilot before that group moves. Found in discovery. RDP and SSH for the IT team move to ZTNA with privileged access policy and stronger MFA than everyday users. Found in discovery. A desktop client using an older protocol the platform doesn’t support. It stays on a restricted VPN, with a named owner, until the vendor’s web version is adopted. Found in discovery. It relies on dynamic ports and network-level reachability, so it keeps a controlled network connection that is documented and reviewed. Found in discovery. This is a connection between networks, so it stays as a site-to-site link with its own owner.
This is what most VPN inventories show: four applications, all reached through one tunnel. Discovery finds what the VPN was quietly carrying. If the VPN goes before these are known, sign-in, printing and a supplier connection stop on the same day. Each item gets an access method and a wave. Most move to ZTNA, one goes direct to the cloud, and three keep a controlled network connection with a named owner.
The classification feeds the migration and validation plan, and we revisit it whenever testing turns up a dependency discovery missed.
Prepare the identity policies that access depends on
ZTNA and cloud security policies work from the identities, groups and device signals they're given. Wrong group membership, MFA exceptions or unmanaged endpoints either block legitimate users or grant more access than intended. The deployment includes the identity work the chosen controls need.
Accounts and entitlements
We review inactive users, duplicate identities, shared accounts, stale contractors, service accounts and groups that no longer match application access.
Application owners confirm the permissions their users need. Privileged and emergency accounts are handled separately.
MFA and Conditional Access
We review MFA coverage, authentication methods, exclusions, device requirements and risk-based access policies.
SMS codes and phishing-resistant authentication give different levels of assurance. Where stronger authentication is needed, the design sets the supported methods, user enrolment and exception handling.
Break-glass accounts are planned and governed as emergency access, separate from ordinary user exceptions.
Device compliance
We confirm the device signals available from Intune or your management platform: registration, compliance and endpoint security status.
We define how managed employees, unmanaged contractors and specialist devices reach applications. Some groups need agent-based access; others suit browser-based access.
Identity provider dependencies
Authentication availability becomes part of the access service's availability.
We document what happens to new access requests if the identity provider is down, how established sessions behave on your platform, and which emergency procedures still work. The emergency account in the design can still sign in during the outage it's meant for.
How we configure each platform
Fortinet and Microsoft bring different capabilities, management tools and enforcement points. We configure them as separate engineering arrangements, with clear boundaries where they meet.
FortiGate ZTNA, FortiSASE and Fortinet SD-WAN
We assess your FortiGate and FortiOS estate, supported features, licensing and FortiSASE integration requirements. FortiSASE and FortiGate do different jobs, so we design the integration and policy boundaries between them explicitly.
What we configure- ✓ ZTNA application access and enforcement policies
- ✓ Identity provider and endpoint integration
- ✓ Branch traffic forwarding and internet security
- ✓ FortiSASE policy configuration
- ✓ FortiManager configuration and change management
- ✓ FortiAnalyzer logging and operational review
- ✓ Monitoring, administrative access and support responsibilities
Entra Internet Access and Entra Private Access
Microsoft's Global Secure Access provides secure internet and private application access. We build it around your supported operating systems, application protocols, device requirements and Microsoft licensing.
What we configure- ✓ Entra ID and Conditional Access integration
- ✓ Private application discovery and publishing
- ✓ Global Secure Access client and traffic forwarding
- ✓ Browser access to web apps through Entra application proxy
- ✓ Connector deployment and configuration
- ✓ Application assignment and access policies
- ✓ Internet access controls within your licences
- ✓ Diagnostic logging and operational administration
Microsoft for identity and access, Fortinet at the edge
Many businesses use Microsoft for identity and private application access and keep Fortinet networking and security. A combined design protects existing investment, and it adds integration and operating responsibilities we settle before deployment.
What we configure- ✓ Which service makes each access decision
- ✓ Where each type of traffic is inspected
- ✓ How routes are selected between the platforms
- ✓ Where each event is recorded
- ✓ Who owns policy changes on each side
Choose the scope first. Security Service Edge covers ZTNA, Secure Web Gateway and CASB without the networking layer. Many deployments start there and bring in SD-WAN integration later.
Read the Fortinet Secure SD-WAN guideDesign private application access for production use
Most private access platforms connect users to applications through a connector or gateway near the protected resources. Connectors make outbound connections to the access service, so applications can be published without opening an inbound firewall port to them.
The connectors still need their own engineering.
- ✓ Connection to the access service outbound
- ✓ Inbound firewall port not needed
- ✓ Capacity and redundancy sized
- ✓ DNS, certificates and paths documented
- ✓ Health and access errors monitored
Capacity
Expected users, application traffic, connection volumes and the vendor's sizing guidance.
Resilience
Connector redundancy, placement and application availability. Redundant connectors don't cover network, identity or application failures underneath them.
Network dependencies
DNS resolution, outbound destinations, firewall allowances, certificates and the paths from connector to application.
Maintenance and updates
Who looks after connector software, the operating system underneath, certificates, configuration and platform updates.
Monitoring
Connector health, connectivity, authentication failures, access errors and resource use.
An undersized or badly placed connector becomes the new bottleneck. We validate the design under expected load before expanding the rollout.
Make sure traffic reaches the intended controls
SASE changes how internet, SaaS and private application traffic moves between users, branches and cloud services. We design traffic steering together with security policy, so users reach their applications through the inspection points meant for them.
Forwarding and routing
How endpoints, branches and SD-WAN forward traffic: clients, tunnels, routing policy, forwarding profiles or proxy settings. We check split tunnelling, local breakout, DNS behaviour and overlapping routes.
Internet and SaaS traffic
Which traffic goes through Secure Web Gateway, cloud firewall, CASB or other controls, with cloud service requirements, inspection exclusions, certificates and application compatibility settled before broad enforcement.
TLS inspection
Certificate trust, supported applications, privacy and exemptions for traffic that shouldn't or can't be decrypted. Testing confirms both the security controls and the behaviour of affected applications.
DLP and application policy
The information and activities you want to control, such as uploads, downloads, sharing or access to specific cloud and AI services. We start in monitoring mode to find legitimate exceptions, then enforce.
Application performance
Connection quality, routing, latency, jitter, packet loss and application response. A more direct path helps where backhaul was adding delay, and we measure the result.
From assessment to an operating service
The order follows what discovery finds, so it can vary by application, user group and platform. Select a stage to see what it delivers.
Discover
Document applications, identities, device conditions, network paths, existing controls and operational requirements.
What you have at the end- Application and dependency inventory
- Current access and traffic paths
- Identity and policy findings
- Proposed implementation scope
- Initial risk and dependency register
Prepare
Fix the identity, application and infrastructure issues that would affect the access design.
What you have at the end- Confirmed access groups and application ownership
- MFA and Conditional Access changes
- Device compliance requirements
- Connector and forwarding design
- Agreed exception handling
Build
Configure the Fortinet or Microsoft components, integrate identity services and set application access and inspection policies.
What you have at the end- Platform configuration
- Application connectors and assignments
- Traffic forwarding and security policies
- Administrative access and logging
- Configuration documentation
Pilot and validate
Introduce the services to a controlled group with representative applications, devices and locations.
What you have at the end- Application and authentication test results
- Performance and user acceptance findings
- Security policy validation
- Support and incident procedure checks
- Agreed actions before wider rollout
Migrate
Expand by application and user group, keeping existing access in place until each replacement passes validation.
What you have at the end- Approved migration groups
- Cutover and rollback arrangements
- Updated access permissions
- Documented retained VPN requirements
- Completed operational handover
Operate
Run the environment through agreed policies, monitoring, maintenance and support responsibilities.
What you have at the end- Operational responsibility map
- Access and exception review process
- Connector and platform maintenance procedures
- Logging and incident escalation
- Change and support documentation
Validate application access before changing production traffic
A successful sign-in or connection doesn't prove an application works through the new architecture. The pilot tests the application, the access policy and the network conditions around it.
Functional testing
Authentication, authorisation, application launch and the business functions users need, including file access, printing, background services, authentication delegation and integrations with other systems.
Security testing
Approved and denied access paths, MFA conditions, device compliance, contractor restrictions, privileged permissions and policy exceptions. Permitted users reach what they should, and nothing outside the approved scope.
Performance testing
Application response, bandwidth, path quality, DNS resolution and the effect of inspection or forwarding, compared with the agreed requirements and your current baseline.
Operational testing
Logging, alerts, connector monitoring, service desk procedures, and whether support can tell an identity fault from a network, application or security platform fault.
Acceptance and cutover. Each migration group has agreed acceptance criteria and a named business or application owner. Anything that stops essential work, breaks a required security control or leaves a critical dependency open is fixed before that group moves.
Introduce ZTNA while keeping required access available
Applications and users don't have to move at the same time. A phased migration validates the suitable applications first and handles older systems, administrative access and specialist connectivity separately.
Suitable early groups
Users with well-documented applications, supported authentication, managed devices and few legacy dependencies.
Applications needing more work
Systems with complex authentication, legacy protocols, network discovery or undocumented dependencies get more investigation and testing.
Contractor access
Agent-based access supports more protocols and device checks. Browser-based, agentless access suits contractors and unmanaged devices on compatible applications, with narrower protocol and posture options. We choose the method per application.
Legacy and specialist systems
Some systems stay on VPN or another network access method while their dependencies are worked through.
VPN can stay alongside ZTNA wherever there's a continuing technical or operational need. For each case we document:
- ✓ The systems and user groups allowed to use VPN
- ✓ The network resources and routes it exposes
- ✓ Authentication, device and segmentation controls
- ✓ Who approves access and exceptions
- ✓ Who maintains the VPN and reviews its use
- ✓ Whether future application changes could shrink the requirement
The retained VPN has a defined purpose and a named owner. Access that ZTNA governs can't be reached through it.
Decommissioning VPN access. VPN is removed for a user group or application once its replacement meets the agreed acceptance criteria and the dependencies are dealt with. A target date helps coordination, but it doesn't make access safe to remove.
Plan for the conditions that could interrupt access
SASE adds dependencies on identity services, cloud security platforms, internet connections, connectors and your applications. The migration plan sets how failures are detected, who decides the response and which recovery paths stay available.
Pick a failure. See what breaks, what keeps working and the runbook that follows.
Working Affected Recovery path
New sign-ins and policy checks can’t complete. Whether sessions already open keep working depends on the platform. Applications published through connector A lose that path. Internet and SaaS access are unaffected. Internet, SaaS and AI traffic through the inspection path is interrupted or degraded. Private application access may continue. One user or group is denied something they should reach. Everyone else is unaffected. A migration group finds an application function that doesn’t work through the new path.
- Detect
Sign-in failures and identity provider health alerts, separated from network or application faults. Connector health monitoring flags the failure before most users notice. Forwarding and inspection alerts, plus users reporting web or SaaS issues from one location. The service desk takes the call and looks up the access decision behind the block. Acceptance testing with the application owner fails a criterion that was agreed in advance.
- Decide
The named owner confirms an identity outage and starts the documented procedure. No decision needed for supported apps: the redundant connector is already serving them. Any fallback, such as an alternate point of presence or bypassing inspection, needs the named security owner’s approval. The log shows which rule or device condition caused the block. The rollback trigger is met, so the named decision-maker calls it.
- Recover
Administrators use break-glass accounts that don’t depend on the failed path to reach critical consoles. Connector B carries the traffic while A is repaired or replaced. The permitted fallback in the design is applied, and nothing beyond it. The entitlement or condition is corrected through change control, with no broad exception added. Approved VPN access is re-enabled for that group only, as the rollback plan defines.
- Verify
Sign-ins recover, break-glass use is reviewed and the accounts are secured again. Capacity on B is checked under load, and A rejoins once healthy. Inspection is restored and any bypass is reversed and logged. The user confirms access, and the fix is checked against the rest of the group. The group works normally while the dependency is fixed, then the cutover is repeated.
Break-glass access is designed for this exact failure and tested against it, so the emergency path doesn’t rely on the service that’s down. Redundant connectors only help if they’re sized for the full load and don’t share the failure underneath, so both are tested in the pilot. The design decides in advance what happens here, because switching inspection off under pressure is the decision most likely to be regretted. Support can see why a request was denied, which is what keeps one wrong entitlement from turning into a permanent exception. VPN stays in place until each group passes validation, so rolling back is a planned, rehearsed step.
Behaviour during an outage depends on the platform, and each recovery step is tested before production cutover.
Where your data is processed and recorded
Cloud-delivered access and security services can process different information in different places. An Australian point of presence or locally hosted management component doesn't mean traffic, access records and administration stay in Australia. Where residency or regulatory requirements apply, we record the service arrangements:
Traffic processing
Where internet and application traffic is forwarded, inspected or processed.
Logging and retention
Which identity, access, security and diagnostic events are recorded, where they're stored and for how long.
Management information
Where configuration and administrative information is processed and kept.
Administrative access
Who can manage the service, including vendor support and any third-party administration.
Cross-border information
Which information may be transferred or accessed outside Australia, and the contractual or organisational requirements that apply.
Control responsibilities
Which settings the service provider, your business and our engineers each control.
The Australian Privacy Principles, including APP 8 where it applies, are part of the legal picture. We check region and contractual commitments for the selected service before you rely on them.
Running SASE after deployment
The access architecture keeps changing as applications, users and devices change. Without clear ownership, exceptions and unused entitlements pile up and connector maintenance slips.
Access and identity changes
Joiner, mover and leaver processes, application assignments, contractor expiry, privileged permissions, Conditional Access exceptions and regular group reviews.
Connectors and platform maintenance
Connector software, supporting systems, certificates, platform configuration and vendor updates, with redundancy and monitoring reviewed as applications change.
Security policies and incidents
Secure Web Gateway, CASB, DLP and firewall policy reviews, alerts and events, plus agreed ownership of investigations, exceptions and vendor escalation.
Emergency procedures
Administrative recovery and break-glass procedures documented and tested against identity provider, application, connector and network failures.
Change management and reporting
Application onboarding, policy changes, platform updates and the evidence needed for operational and security reviews.
Our engineers can manage the agreed components or work alongside your internal IT team, with responsibilities set as part of the service.
Explore Managed SD-WANWhere SASE deployments go wrong
Identity and application dependencies
Stale accounts, broad groups and MFA exclusions carry into the new platform, and an application launches through ZTNA but fails on a function that relies on an undocumented file share or authentication service.
What we do: We clean up identity and map dependencies with application owners before the first pilot.
Platform and traffic integration
The platform is bought before the design, then routing, DNS, certificates or inspection interrupt SaaS or private application access.
What we do: We confirm application support and forwarding in the design, and test traffic paths before broad enforcement.
Connector resilience
Connector capacity, placement or redundancy falls short of the real workload, and the connector becomes the bottleneck.
What we do: We size and place connectors for expected load and validate them in the pilot.
Testing and recovery
Users move or VPN is removed before owners confirm their applications work, and the emergency access path depends on the very service that failed.
What we do: We agree acceptance criteria for each migration group, and test rollback and break-glass access against real failure scenarios.
Ongoing policy ownership
Retained VPN and access policies have no owner, so exceptions, entitlements and alerts pile up after go-live.
What we do: We name owners for VPN scope, access policy, connectors and security events as part of handover.
How we deliver a SASE deployment
We bring network, identity and security work into one delivery plan, with engineers responsible for each part of the environment.
Network engineering
WAN and SD-WAN integration, routing, DNS, traffic forwarding, branch connectivity and access paths.
Microsoft identity and access
Entra ID, Conditional Access, device policy, Entra Internet Access and Entra Private Access.
Fortinet security and networking
FortiGate, FortiSASE, ZTNA, Fortinet SD-WAN, FortiManager and FortiAnalyzer.
Application migration
Dependency mapping, access policy configuration, user testing, cutover and rollback planning.
Operations
Documented policy ownership, monitoring, platform maintenance, access changes and incident escalation after deployment.
We deliver it as a project, as a project followed by a managed service, or alongside the responsibilities your IT team keeps.
Explore SASE & Zero TrustCommon questions about SASE deployment
What needs to be assessed before a SASE deployment?
Your identity provider, MFA, Conditional Access, device management, applications and their dependencies, WAN and VPN arrangements, security controls and operational responsibilities. The findings set the scope and order of the deployment.
Can Microsoft Entra Private Access replace all our VPN connections?
It replaces user-facing VPN for supported applications. Legacy protocols, specialist administration and site-to-site connectivity can stay on other access methods.
What happens to older applications that can't use ZTNA?
We map their dependencies and check whether changes would make ZTNA suitable. Where that isn't practical, a controlled VPN or another connection stays in place, with a defined scope and owner.
How do private applications connect to a ZTNA service?
Through application connectors or gateways. Many make outbound connections to the access service, so applications are published without an inbound firewall opening. We design and test each connector's protocols, network access and capacity.
How do we manage DLP policies during deployment?
We identify the supported traffic, sensitive information types and enforcement actions, then test policies against real business processes in monitoring mode before switching on restrictions. Exceptions and monitoring responsibilities are documented.
Does SASE provide Australian data residency?
That depends on the provider, the service components, region settings and contractual terms. We review traffic processing, logs, management data and support access against your requirements and record the result.
Will SASE deployment interrupt users?
Pilots, testing, staged migration and rollback planning keep disruption low. Some changes still need a scheduled cutover or a short change to access, depending on the applications and network design.
How long does implementation take?
It depends on your identity environment, the number and complexity of applications, integrations, testing and migration scope. We set the delivery sequence and timetable after the assessment.
Who maintains the platform after cutover?
We agree who owns identity and application access, connectors, traffic forwarding, security policies, logs, maintenance and incident response. We can run the agreed components or work alongside your IT team.
Talk to us before your next remote-access change
Tell us about your VPN, identity platform, branch network or the SASE project you're planning. We'll work through the technical requirements, application dependencies and implementation options with you.