From perimeter to cloud: my journey evaluating and implementing a Security Service Edge (SSE) solution

May 25, 2026

# From perimeter to cloud: my journey evaluating and implementing a Security Service Edge (SSE) solution

How a long-held vision for true zero trust endpoint management finally became reality — and the journey I had to navigate to get there.

diagram

Tags: Security architecture · SSE · Zero Trust · Cloud
Reading time: ~10 min

A note on scope: SSE is a broad subject — entire books exist on individual components within it. This post is intentionally an introduction: technically grounded, focusing mostly on a specifc goal, but not an exhaustive guide on any single topic. Some sections are deliberately high-level, or where i may simply raise considerations. Every organisation's requirements differ and prescribing specifics would require seperate dedicated blogs. If any area sparks an interest, I'm happy to go deeper in a follow-up post — just let me know.

Contents

The problem we knew we had

Several years ago, as a technical architect (with more than one foot in the security team), I had a clear strategic goal: move our endpoint platforms entirely to the cloud, managed through modern device management tooling, and secured through zero trust principles. The concept was compelling — no more dependency on corporate network proximity, no more implicit trust just because a device happened to be behind a firewall.

The opportunities were obvious:

  • Reduction of technical debt
  • Direct and indirect cost reductions
  • Simplification of operations
  • Improved user experience
  • Increased performance
  • Improved security?

But the elephant in the room was the question around security and how we could ensure that the security posture was equal or better than what we currently had.

So after a security analysis to honestly assess what cloud-native endpoint management would mean in practice, we quickly identified risks that we couldn't ignore, even though theoretically we were taking security improvements with the likes of conditional access and device compliance via Intune and MDE risk signals.

  1. Higher likelihood of a successful malware infection / Security monitoring is less efficient.
  2. Higher likelihood of data leakage
  3. Access to private applications

First: web threat protection. Devices living permanently on the open internet, without a corporate proxy or perimeter filtering, were inherently more exposed and we would no longer have as much visibility, protection or control on the sites users visited.

Second: data loss prevention. Without a network inspection layer, we had limited visibility into what data was leaving endpoints and where it was going.

Third: access to private apps, perhaps less obvious but more fundamental to our team and more importantly, the business. Many of our internal applications were not yet web-enabled. To achieve our goal we would need to ensure we could still access these critical business applications. If users were to use a VPN to reach them, we'd be recreating the very perimeter dependency we were trying to escape — and breaking the zero trust concept entirely in the process.

For the sake of illustrating the journey, here is a basic representation of where most organisations start off with their domain joined, SCCM managed infrastructure with remote access being accomplished via a traditional VPN solution.

diagram

Obviously with cloud native endpoints, this model no longer works as devices live on the internet.

As an interim measure and something I have experience with, was to implement the following controls to provide an effective solution with the tools available:

  • Conditional access policies to protect federated and SaaS applications
  • Microsoft Defender for Endpoint's (MDE) with Defender for cloud apps integrated for web threat protection, EDR and logging.
  • Azure App connector to give the ability for users to access internal web based applications.
  • Purview / Endpoint-DLP

This solution would somewhat look as follows:

diagram

Conditional access plays a key role in this implementation. Device, user, application, network and other signals would all have to meet your requirements before access would be granted. However it would only protect federated and SaaS services. If only we could have conditional access in front of everything…

So this is not quite the destination yet. What could we do…?

An early glimpse of the future

Before Gartner had even coined the term "security service edge" — that convergence of a Secure Web Gateway (SWG), ZTNA, and CASB into a single cloud-delivered service — I had an encounter that would shape the next several years of my working life.

In 2019/2020 I think it was, I happened to be a part of a discussion where Microsoft were describing a proof of concept for a new approach to zero trust private network access. In short, it would provide the ability to allow users to access internal applications or resources from the internet without exposing the corporate network. The concept would extend the Azure app proxy service to be protocol agnostic and using application micro-segmentation, delivered from the cloud and authorized through conditional access policies. It was early, experimental, and not yet productised. But the strategic fit with what we were building was immediately obvious.

Let me describe it with a simple example as it describes a ZTNA (Zero Trust Network Access) implementation.

Assume users only require access to an HR system, let's say it's called hr.company.com and runs on port 5015.

  • A policy rule is defined in the solution for this particular FQDN/IP and port combination aka Application
  • When users attempt to access this application the agent running on the endpoint would find a match based on the communication attempt and the policy defined above.
  • The attempt would then need to pass conditional access authorization policies
  • A tunnel is setup and traffic securely tunneled to an agent running on-premise.
  • The traffic is extracted and forwarded to the final destination – hr.company.com.

Transparent, fast, secure and limited to a single application where each attempt is scrutinized by conditional access policies.

Something like this abstract illustration:

diagram

This would obviously meet our business requirement to provide secure zero trust access to legacy applications.

Over the years that followed, I stayed closely involved — providing feedback, testing capabilities, watching the product evolve. What would eventually become Microsoft's Global Secure Access was something I had been tracking from its earliest days.

The positioning of conditional access (policy enforcement point) in this solution can't be overstated as it extended the enforcement conditional access had to include any HTTP and NON HTTP based private applications. Later in the evolution of this product it introduced an SWG into the equation as well. So everything!

The strategic path was set and we only had to wait…and…wait.

What is an SSE solution, and why did we need one?

In 2021 Gartner defined the term SSE, a security service edge solution as the convergence of three historically separate security technologies into a single cloud-delivered platform:

diagram

  • Secure Web Gateway (SWG) — internet traffic inspection, threat prevention, URL filtering, and DNS protection
  • Cloud Access Security Broker (CASB) — visibility and control over SaaS application usage, shadow IT discovery, and inline session controls
  • Zero Trust Network Access (ZTNA) — secure, least-privilege access to private applications based on identity, device posture, and context; the modern replacement for VPN

Why this matters for modern device management: Cloud-managed devices live outside the corporate network permanently. Without an SSE layer, there is no consistent policy enforcement point for internet traffic, no inspection of SaaS usage, and no secure path to legacy on-premises applications that doesn't rely on VPN. SSE brings network security to the endpoint as a cloud service — rather than trying to bring the endpoint back inside a perimeter.

Actually most vendors offer a lot more than this: Cloud Firewall, Sandboxing, Browser Isolation, to name but a few.

From my perspective, an SSE was the missing piece for our strategic goal. It would close the risks identified years earlier, enable the decommissioning of our proxy and VPN infrastructure, and enable us to extend zero trust controls from identity and device all the way to the network layer — covering not just M365 and Azure-integrated services, but all traffic, from all users, to any destination.

The three core tenets of zero trust we satisfied were:

  • Verify explicitly — authenticate all identities and validate access requests based on real-time signals
  • Least privilege access — limit connectivity to specific applications, not broad network segments
  • Assume breach — monitor all traffic continuously, correlate with threat intelligence, and react dynamically

The concept can be illustrated as follows:

diagram

This diagram attempts to illustrate that with such a solution any user on any device in any location can have their communications secured. This is typically achieved by an agent running on the device creating a tunnel to the nearest SSE PoP (Point Of Presence) over which traffic passes. Depending on the direction that traffic needs to take (private or public), and after authorization the SSE provider will route the traffic either privately or to the internet. All traffic can be inspected and monitored with the ability to react quickly if a state changes.

Diving into each individual request, the request would be scrutinized as follows:

diagram

Evaluation of market leaders

So far the discussion has been somewhat Microsoft focused.

In 2024 I was privileged to work as a technical lead and representative of the workplace team in the RFP for an SSE solution. This consisted of several vendors across the Gartner Magic Quadrant. I was able to take the knowledge from the previous years and compare it to other market leaders. It was a great experience.

My primary objective was to meet the requirements for migrating our endpoints to the cloud but that's not something that can happen overnight so the requirements were to support all platforms and workstyles. Moving to modern device management and modernizing the legacy where possible.

After over 12 months of discussions, evaluations and pilots I have learnt a lot about the different vendors offerings and their different implementation approaches.

I purposely havent mentioned any vendors as this blog is not intended to plug any particular vendor as they were all more than capable. Each had their own strengths. Our decision really came down to the vendors needing to meet our stringent requirements with what the products could offer at that point in time. Requirements are the key to what is the best for any given organisation. This sounds obvious, but what can be challenging is understanding and defining your requirements and the scenarios that must work. I listed many scenarios that might be interesting in the section below.

Scenarios to consider

I want to share some considerations and scenarios that can be used when analyzing such solutions that might otherwise be overlooked. Mostly from a workplace perspective. I think a lot of organisations see this solution as a security or network driven topic so the workplace team might not get the amount of involvement they need and they should. I hope it helps.

Generally most vendors offer everything so how can we differentiate?

The devil's always in the detail so let me share some of my thoughts on how scenarios/use cases can be used to ensure you choose the right solution.

Endpoint & Agent functionality

OS and platform support

What platofrms do you need to support?
Windows, Mac, iOS, Android, persistent and non-persistent VDI, meeting room devices, IoTs, Terminal servers.
What about other workloads?

Agent vs agentless

Where agents cannot be deployed, can and how can communication still be secured?
Examples are meeting room devices/IoTs or perhaps non-persistent VDI.

Agent health, and compliance

The SSE agent is now a critical component on the endpoint, along with AV, disk encryption, EDR and Firewall etc.
It is important to have visibility on the installation status and health of the agents to ensure this fundamental security control is working and protecting.
Failures must be promptly detected and backup controls in place to mitigate any risk when endpoints are in this state.

Tamper protection

Do you need tamper protection and controls to mitigate the agent being bypassed, uninstalled or disabled?

Device provisioning support

Should endpoints be handed over to end users with security control installed and running?
During device provisioning there is usually no user logged in so the SSE solution should be able to apply protection before the first use but allow the device provisioning process to complete.

Local Firewall considerations

How does the solution interact with the windows host firewall? or any other local firewall?
Do you still need to maintain the local firewall?
Does the solution doesnt prevent inbound connections on the physical adapter? or do you still need to rely on the local firewall?
Do you need to configure rules to allow SSE to work?
What about mitigations when the SSE Agent isn't working? A local FW will then be one of the last layers of defence.
SSE solutions typically implement a cloud firewall but that is only providing filtering once the traffic has reached the SSE.

Virtual adapter vs filter driver

Some vendor solutions use virtual network adapters (like a VPN client) with their own IP address issued from a pool provided by the SSE provider. This brings with it some other considerations as the client now has a physical adapter and a virtual adapter, one connected to the SSE and the other the local network. These solutions act as routed connections.

  • How is traffic routed correctly? routing table management?
  • Are connections to the physical adapter a concern and can it be protected?
  • How are bypasses managed?

Other vendors implement their solution as a filter driver that is injected into the existing network adapter stack. It intercepts all communication and passes the communication through a policy algorithm to determine what to do with it. Instead of routing traffic, these solutions tend to encapsulate data for that particular session into micro-tunnels and forward it to the provider. Traffic is separated into different traffic streams so that different logic and policies can be applied differently.

This latter moves a lot if not all of the traffic forwarding logic to the client and is an example of why the workplace may play such a critical role.

Connectivity & Networking

Always connected and always secured vs on-demand or auto connect when remote

Does your organisation require enforcing endpoints to have persistent connections to the SSE backbone? i.e traffic should never be allowed on the public internet unless specifically authorized?

In such scenarios, all communication must be explicitly authorized unless agreed to be bypassed (see later for examples).
The solution should then probably also protect traffic no matter whether a user is logged in or not. The agent should start early and provide some type of machine based authN/authZ before the user logs in or after the user logs out. Akin to a machine tunnel on a VPN solution. Tamper protection is also critical in such cases (discussed earlier).

Machine authenticated tunnels may need to support not only internet traffic but private traffic as well. (e.g SSPR needs LoS to DC's).

Ability to bypass SSE for certain applications

P2P traffic, audio and video streaming applications that are latency sensitive may be some examples of such traffic.
Does the solution have the ability to define networks or ports/protocols where traffic should go direct?.
Obvious examples are DHCP and DNS and whether you want to implement a "Trusted Network" concept. The best example is if ever a device is connected directly to the corporate network (e.g Domain joined devices) maybe you don't require them to tunnel private traffic through an SSE? Maybe just internet traffic?

Support for inbound connectivity

Is there a requirement to connect to the endpoint? via Remote shell or remote desktop or is there another application specific requirement?

ZTNA implementations typically only allow traffic from client to server. Do they offer the ability to define exceptions?.

Must the inbound connection traverse the SSE solution or is it possible to connect via the physical adapter/IP address?
Depending on the vendors implementation this may raise other considerations particularly for support scenarios.

Host name resolution

Devices need to be resolvable in some way.
Cloud managed devices do not register hostnames in DNS so if we need hostname resolution to them (e.g remote support reasons), how can we?

Domain joined devices on the other hand will.
IF IP addresses will be obtained from the SSE provider they may need to be registered with DNS or via an IPAM solution for hostname resolution to work. Is access from a 3rd party company to internal DNS servers a concern?

Location awareness

Domain controllers, SCCM and DFS rely on location detection algorithms to refer endpoints to the nearest replica/instance. The SSE solution should be able to work with this logic to prevent accidental cross-regional traffic.

Need for a dedicated egress IP

Are your clients and/or partners expecting you to come from a specific IP or range of IP's?
Do you use a trusted IP concept in conditional access?

China

Does the provider have a presence in China?
Chinese firewall considerations? Can corporate traffic be routed intelligently around the firewall and with good performance?

Captive browser detection and support

This may require special considerations. Depending on the implementation it may require a temporary bypass once detected.
Does the agent include a captive portal browser?

Developer specific requirements

Do Developers run WSL and/or containers? Will traffic still work and be protected?
Seamless access to private cloud networks & resources / secure landing zones?

Identity & Access

Seamless SSO

Should the connection be transparent with seamless SSO? or is it ok for users to be prompted? or do they need to manually connect?.

Integration with Microsoft Eco-System

Should it use Entra as its Idp? Okta? Something else? or a combination?
Do you need seamless SSO?

Is the solution complementary to conditional access or does it use Conditional Access as its policy enforcement point?
Can risk signals from Entra and the Defender suite be used by the SSE in any way?

Will CAE (Continuous Access Evaluation) work as expected? particularly with token replay protection when IP addresses change.

Does the solution understand Purview document classifications? as well as understand other types of data to prevent data exfiltration?

Is Integration with Defender for Cloud Apps a requirement?

Support for Microsoft Tenant restrictions v2

This provides controls for organisations to control foreign identity usage accessing foreign tenants.
https://learn.microsoft.com/en-us/entra/external-id/tenant-restrictions-v2

The Microsoft GSA solution can make use of universal tenant restrictions but 3rd parties can also support tenant restrictions in a more limited fashion using header injection. Tthis requires ssl termination&inspection on authentication traffic as an additional header needs to be injected.

Passwordless or phishing resistant authentication support

Maybe your organisation has stricter authN requirements such as passwordless. Does the service support this built-in? or relies on Entra or another idp to enforce such requirements?

Private access to Kerberos based applications

Access to Kerberos based applications requires access to domain controllers for obtaining tickets.
Does the solution offer the ability to securely access domain controllers? This is a good example where having more stringent private access policies for sensitive or critical applications is ideal.

Application support

You may need to think about ensuring that the vendors private access solution can work with complex applications running any protocol.

By definition if the SSE provider offers private access via a ZTNA type service, traffic is normally only allowed from client to server and not the other way around. This may break some protocols that work like passive FTP.

Some vendors implement a secure private connection over a bi-directional tunnel like a standard routed VPN connection so they don't have this limitation but it may be considered riskier depending on your security departments point of view (server and client abstraction and uni-directional authorized traffic)

Policy, Resilience, Support and Operations

RBAC and separation of duties

Does the solution offer an RBAC model or a dedicated portal where relevant operational activities can be easily delegated?

Policy targeting

User and user group targeting is clear

Given the number of platforms and workstyles you support, it may be important that policies can be targeted to groups of devices as well as users/user groups. For example, putting aside the different OS types you may need to differentiate your policies based on whether you are targeting business users, developers, Privilege Access Workstation (PAW) devices, shared devices, Kiosks, VMs etc.

Device posture checks

Should the solution support equivalent device posture checks such as what conditional access and Intune can offer?. Examples include: AV installed/up-to-date, Firewall enabled, OS Patch version, custom checks for registry values etc.
Or does the solution rely on conditional access?

Can different checks be applied differently to different applications?

If they provide their own device posture options, what do they offer and how reactive are they to state changes?

Support and troubleshooting

Agent manageability options? updates, rollbacks etc. Or will you rely on your MDM system to handle this?

Logs and dashboards should be adequate for quickly identifying status, issues or investigating endpoint communication problems.

Should Support staff have the ability to connect to endpoint devices for remote-control and troubleshooting? Does this require an inbound connection?

As this solution is network centric, is it possible out-of-the-box or via an API to correlate this data with endpoint centric telemetry, i.e Intune Endpoint Analytics or another DXA solution.

Ideally support should have visibility on what is wrong as well so tickets don't go in random directions.

Logging

Logging is critical for troubleshooting.
Do the logs provide information on user and device information?
What about process information?
Is bypassed traffic logged? i.e traffic that is allowed to be sent direct?

DR and break-glass

What if the SSE service is down or uncontactable via either full or partial service outage? Or perhaps caused by an agent issue or other computer issue interfering with the agent? (crowdstrike anyone?) How can we fix them? and ensure that devices are still visible, secure and manageable? Intune, CMG, MDE and Entra-ID authN endpoints are examples of endpoints may need to be contactable no matter what?

API for change control and CI/CD pipeline

Should changes to client policies be managed via an API? Then you need to ensure the API supports all required methods.

User Experience

Performance

Bandwidth and latency should be adequate and hopefully superior.
This relies on the providers presence in various regions and the strength and resilience of their backbone network.

End user Notifications

User experience should ideally be informative when necessary. e.g when there is a posture change or security incident resulting in loss of connection. No "Catastrophic error in Unknown" please…

From concept to reality

So here we are in 2026…

Regarding our cloud managed devices, we can now provision endpoints on the public internet with autopilot during which they are autpmatically enrolled and connected to the SSE service where all communications are secured.
Access is still possible to private applications. Users don't notice a difference. The business blocker to wait for the application landscape to be cloudified is over.
With a cloud Kerberos trust and Kerberos support in Entra-ID joined devices we can have full access to any Kerberos authenticated services with additional zero trust controls to ensure user, device and risk are acceptable first.
This could include network drives and really only has a limitation on services which require machine based authentication (RDP with device authentication enabled (there are workarounds btw), WinRM with Kerberos, to name a few)

Users don't know that they are working exclusively on the internet or that they are being managed cloud native. They do ask what we did to make things so fast (probably organisation specific).

So secure, fast, lean, easier to manage/support and with about 100kg of technical debt removed.

Consider automation possibilities as well. You want endpoints to connect to cloud services to do some automation magic?, to report something or start a process?. Something like we used to do with SCCM status messages and status message filters or with webservices (I miss those days). With an SSE solution we don't need to expose these endpoints publicly any more.

Goal met.

Looking back

This journey took longer than I expected when I first sketched out what a truly cloud-native workplace could look like. The identified and residual risks with interim solutions gave me a clearer path on what was needed to move forward. Then the patient involvement in a Microsoft preview programme — all of it was the slow, necessary work of building toward something that actually holds up under scrutiny.

The SSE/SASE market has matured enormously, and it continues to do so rapidly. If you're an architect facing similar decisions today, the honest advice is:

  • Be clear on your specific requirements before you evaluate — the differences between vendors matter most at the edges of their capabilities
  • Don't underestimate the value of deep ecosystem integration — whichever ecosystem you're already invested in
  • With flexibilty comes complexity. Many solutions are very flexible and are able to do complex traffic policing and forwarding. With this flexibility comes potential complexity and a requirement to understand software logic instead of traditional routing and firewall concepts. So there is a skill upgrade requirement.

The perimeter isn't coming back. The question is just which cloud-delivered enforcement layer you trust to replace it.

Written from personal experience as a digital workplace architect. Views are my own.

Glossary

Term Description
SSE Gartner describe a Security Service Edge (SSE) solution as including the following controls at a minimum: forward proxy including malware protection, threat prevention and URL filtering; both in-line (proxy) and out-of-band (API) detection and protection of in-use SaaS apps; granular access (controlled by identity and context) to private applications by agent or agentless; support for managed and unmanaged devices; support for Windows, macOS, iOS and Android; integration with SIEM, XDR, SD-WAN and other adjacent technologies; integration with identity providers; and SSL/TLS decryption and re-encryption.
SASE Secure Access Service Edge. Delivers converged network and security as a service capabilities, including SD-WAN, SWG, CASB, and ZTNA. SASE supports branch office, remote worker and on-premises secure access use cases. Primarily delivered as a service, it enables zero trust access based on the identity of the device or entity, combined with real-time context and security and compliance policies.
Zero Trust Instead of believing everything behind the corporate firewall is safe, the Zero Trust model assumes breach and verifies each request as though it originated from an uncontrolled network. It is designed to adapt to the complexities of the modern environment that embraces the mobile workforce, protecting people, devices, applications, and data wherever they are located.
SWG Secure Web Gateway. Solutions that protect web-surfing PCs from infection and enforce company policies by filtering unwanted software/malware from user-initiated web/internet traffic. At a minimum, SWGs include URL filtering, malicious-code detection and filtering, and application controls. Native or integrated data leak prevention is also increasingly included.
CASB Cloud Access Security Broker. Security policy enforcement points placed between cloud service consumers and cloud service providers to combine and interject enterprise security policies as cloud-based resources are accessed. CASBs consolidate multiple types of security policy enforcement including authentication, SSO, authorisation, credential mapping, device profiling, encryption, tokenisation, logging, alerting, and malware detection/prevention.
ZTNA Zero Trust Network Access. A product or service that creates an identity- and context-based, logical access boundary around an application or set of applications. Applications are hidden from discovery, and access is restricted via a trust broker to a set of named entities. The broker verifies identity, context and policy adherence before allowing access and prohibits lateral movement elsewhere in the network. Considered a replacement for VPN solutions.
PAW Privileged Access Workstation. A dedicated, highly secured and hardened computing device (usually a physical laptop or desktop) used exclusively for performing sensitive administrative and privileged tasks.
DFCA Microsoft Defender for Cloud Apps. Microsoft's CASB solution.
DLP Data Loss Prevention. A set of tools and processes used to ensure that sensitive data is not lost, misused, or accessed by unauthorised users.
CDN Content Delivery Network (or Content Distribution Network). A network of interconnected servers that speeds up webpage loading for data-heavy applications.
PoP Point of Presence. An artificial demarcation point or network interface point between communicating entities. In SSE context, these are the vendor's cloud nodes through which traffic is routed and inspected.
MVP Minimum Viable Product. A version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.
PoC Proof of Concept. A demonstration of a product in which work is focused on determining whether an idea can be turned into a reality.
SIEM Security Information and Event Management. Technology that supports threat detection, compliance and security incident management through the collection and analysis (both near real-time and historical) of security events, as well as a wide variety of other event and contextual data sources.
MDE Microsoft Defender for Endpoint. An advanced Endpoint Detection and Response (EDR) solution embedded into Windows operating systems, or installed as a service on other OS platforms, to collect and process behavioural signals. Signals are translated into insights, detections and recommended responses to advanced threats. See Microsoft Defender for Endpoint | Microsoft Learn.
Cloud / Modern managed devices Devices that are Azure Active Directory joined and managed by Microsoft Intune, with no reliance on on-premises services or infrastructure.
Micro-segmentation A method that divides a network into multiple isolated segments or "microsegments." Each microsegment hosts and secures only specific parts of the network resources. The aim is to limit lateral communication and movement within the network, thereby reducing the attack surface and minimising the potential impact of a breach.
GSA Microsoft Global Secure Access. Microsoft's SSE solution, integrating SWG, CASB and ZTNA capabilities delivered from the Microsoft cloud.