A Guide to Modern SASE Architecture
When you redesign the network around the end user, you route less, see more, and govern AI where it actually happens. Backhaul becomes the fallback, not the default. Explore Island’s Guide to Modern SASE Architecture and learn how to evaluate today’s SASE stack for modern work.
Identity-First Security Architecture
Treating users, devices and machine identity as the primary security perimeter, rather than the corporate network is the crux of Identity-First Security. It authenticates, permits and continuously examines every access request, ensuring a zero trust environment tailored to individual, context-aware risk profiles.
The traditional approach to IT security has arguably been almost entirely unchanged for decades. In fact we have deliberately used the term IT security here because we were doing it for many, many years before the term cybersecurity came into common use.
The approach has been based on location and device. If a device is inside our private network we have placed it in a position of trust – that is, although we would be sensible and not give excessive access to users, we designed our networks on the premise that if a connection came in from an adjacent system under the user ID of one of our trusted users it was assumed that the connection should be coming from the adjacent system and that the system and the user were what they claimed to be.
If we needed to get into the network from outside, we would apply controls at the perimeter. As long ago as the 1980s it was becoming fairly common to see point-to-point leased-line connections between sites and even between organisations, and one end’s trust of the other was based on the fact that we knew exactly where the other end of the circuit was connected. When dial-up remote access came in, we used usernames and passwords to identify the connecting users, and that was considered sufficient. Even when VPN came along it was considered as secure as dial-up, because it required a username and password in order to connect.
Pushing the Limits
As time went, remote working became more popular – not people working at home for days on end as we have known it since the COVID-19 pandemic of 2020, of course, but certainly people took advantage of remote access to have the occasional afternoon working from outside the building or connecting to the office at the weekend to finish off a vital piece of work. Illicit use of systems by attackers who had stolen (or guessed) credentials began to rise, as we would expect – if we increase the opportunity to misuse something by making it more accessible than before, we can expect more people to use that accessibility to break in. The number of systems increased, volumes and sensitivity of data increased, internet connectivity increased, more credentials were stolen and bad actors grew in number and voracity.
But the watershed that really prompted a need to change how we permit access to our systems was the advent of the cloud. This was because the perimeter of our systems was no longer the physical perimeter of the systems we owned, hosted and managed. The electronic border of our systems was exactly the same as the physical border: our remote access servers – dial-up, fixed link or VPN – literally gave us the ability to connect from a device outside the office or datacenter to a server or other service inside our physical premises. The cloud destroyed this concept almost overnight: a tangible portion of our infrastructure was no longer inside our physical premises, which meant that our perimeter became entirely meaningless.
Always Connected
Additionally, part of the nature of cloud services is that they are automatically connected to the internet – after all, this is how we then connect to them to manage and administer applications and data. The potential for attack is much greater than back in the day when systems were inside our own premises with little or no visibility to internet-based attackers. Of course, we could secure our cloud services with traditional approaches such as limiting the IP address ranges that were permitted to make incoming connections – such as the public ranges of our offices’ internet connections. But this would limit the flexibility of the cloud services – part of the attraction of the cloud is that we can enable our users to access applications on the move, or from home, or from an overseas hotel when away on business. And yes, we could still use our old VPN service to enable users to connect to the office and then bounce off from there into the cloud service, but the inefficiencies of routing all connectivity through the office VPN and internet connection made this an unattractive option: slowing down users excessively in the interests of security will usually be met with disapproval from colleagues who need to be productive and have swift access to the systems they need.
Changing the Approach
That key requirement was a watershed moment: the challenge of allowing only legitimate access to systems when we could not use traditional mechanisms of trust. The answer is to use identity as the primary means of making access decisions.
But how does this differ from the “old” way of doing things? Is a username not an identity? Does the IP address of a calling machine not identify where the caller is, or at least whose network they are on? In short: no. The use of a username and password provides no rigorous proof of who the user is – it just tells us that someone who knows that username and password is trying to access our system. Source IP addresses tell us no more than that someone with access to a device with that IP address is attempting to connect – there is no guarantee that they are using that system legitimately.
Hence the advent of multi-factor authentication (MFA) – rather than just using something you know (a username and password) to authenticate, we now insist adding something you are (such as a fingerprint or face scan) or at least something you have (a code from an MFA app on your phone). This “something you have” element often also depends on something you are, as the most common way of unlocking your phone is face recognition. Similarly the identification of the device the user is connecting from has become more complex and hence more robust: rather than it being enough just to be seen to have a “trustworthy” IP address, we now insist that devices themselves are known to and registered with the target system, so that it can be sure that connections are coming from systems with a high level of trust.
Advancing to Zero Trust
Even though we have a greater level of confidence, we generally go a step further. We adopt the approach of “never trust, always verify”, and re-authenticate users and source systems many times over the duration of a connection or an application session. We micro-segment our network so that if a bad actor does somehow manage to get past our defenses (usually by way of malware on the user’s system, which piggy-backs on the user’s legitimate connection) the blast radius is modest. Of course, we combine this micro-segmentation with the principle of least privilege.
There are also various areas that need a lot more work if we are to secure them confidently. Privileged logins are, by definition, considerably more troublesome if compromised and so we need to be particularly cautious to secure them properly and identify their users rigorously – but at least they have human users so we can use the techniques discussed already. We can do something similar with third-party logins too, because again they are used by human beings so we can enforce the same techniques.
In fact, the main problem with third-party logins was discovered by the likes of U.K. retailers the Co-op and M&S – high-privilege accounts with users who were duped into using them for illicit purposes. So, we now have to look at extra defenses such as adding more layers of security – perhaps introducing four-eye checks for security-related activities so that there is no reliance on any one individual avoiding being duped 100% of the time. Where things get really tricky is non-human identities: service accounts; automations; and, particularly topical in 2026, agentic AI. The latter is particularly worrying because in addition to doing bad things very, very quickly, the agent has the opportunity to learn how to try to bypass security constraints to make its job easier or even to widen the area that it can damage.
Now is therefore the time for us to be adopting security techniques that work in the 2020s. We need to inventory every login on every system and get as close to possible to a single, orchestrated authentication mechanism that uses one central authoritative source of user and machine data. MFA must be made phishing resistant (which basically means: never, ever use SMS text messages or email as they are startlingly easy to compromise). We should replace VPN-based security with identity-led security: a stolen laptop with compromised credentials is an automatic way around VPN defenses. We must have robust mechanisms for managing the lifecycle of everything we use for authenticating people trying to use our services.
Above all, though, it is essential that we focus on the gap that exists with non-human interactions. We can use techniques such as signed tokens (OAuth2, for example, potentially with OpenID Connect layered on top) but there is still a level of risk as authentication materials lie around on systems for a certain amount of time. The step-change that has taken place with AI holds promise in this area, though, since technology is becoming more capable of, for example, authenticating a non-human access request as rigorously as possible using current techniques but then layering on an AI layer that asks: does this connection look right, are the behaviors what we would expect and what is the risk of allowing it to execute the function it just asked to run.
The defenses we use for human-originated connections are sufficiently established that we should be able just to sit down and do it; we can then focus on adopting developments for the challenges of identity-first architecture for these non-human access requests.
