A finance manager opens her laptop at a café on a Tuesday morning. She checks email in a cloud inbox, updates a spreadsheet stored with a cloud provider, joins a video call, and approves a supplier payment through a web-based banking portal. At no point does her traffic pass anywhere near the company’s office.
That office still has a firewall. It is well configured, regularly updated, and protecting a building that, on most days, is half empty.
This is the quiet mismatch inside many businesses. Security was designed around a place, and work no longer happens in one.
The Perimeter Model Stopped Fitting
For a long time, protecting a business meant drawing a boundary around it. Staff worked inside the office network, applications ran on servers in a back room, and security equipment stood at the edge, inspecting everything that came in or went out.
It was a sensible design for its time. Anything inside the boundary was treated as broadly trustworthy, and anything outside was treated with suspicion.
Three changes broke that model. Applications moved to the cloud, so the tools people rely on no longer sit inside the building. Staff began working from homes, client sites, trains, and hotels, so the people no longer sit inside it either. And the number of devices connecting to company systems multiplied, including personal phones and tablets the business does not fully control.
The boundary still exists on paper. In practice, most of the activity it was meant to protect now happens outside it.
Patching The Gaps Created New Ones
Businesses responded in sensible, incremental ways. Virtual private networks let remote staff connect back to the office. Separate tools were added to filter web browsing, control access to cloud applications, and protect laptops individually.
Each addition solved a real problem. Together, they often created a complicated patchwork.
Sending remote traffic back through the office to reach cloud services adds delay, which staff notice on every video call. Separate security tools each have their own dashboards, policies, and alerts, and keeping them consistent takes time small teams rarely have. Gaps appear where one tool’s coverage ends and another’s has not been set up, and those gaps are exactly where problems slip through.
The result is a system that is harder to manage, slower for users, and not necessarily safer.
Bringing Network And Security Together
Secure access service edge, usually shortened to SASE, approaches the problem from a different direction. Rather than building security around a location, it builds security around users and the resources they access, wherever either happens to be.
The idea combines networking and security into a single service delivered from the cloud. Traffic from a laptop in a café, a branch office, or a home connection goes to a nearby point in the provider’s network, where it is inspected and protected before heading to its destination. The same rules apply regardless of where the person is sitting.
Several functions are typically brought together under this approach. Intelligent routing chooses the best path for traffic across available connections. Web filtering blocks malicious sites and downloads. Controls on cloud applications govern what data can be shared and with whom. Firewall protection is delivered as a service rather than through a box on site. And access to internal systems is granted based on identity and device health rather than simple network location.
That last element, often described as zero trust, is a meaningful shift. Instead of assuming anyone inside the network is safe, every request is checked, and people get access only to what they actually need.
What Changes For The Business
For staff, the most noticeable improvement is often speed. Traffic no longer has to make a detour through head office before reaching a cloud application, so tools tend to feel more responsive, particularly for remote workers.
For the people running IT, the main gain is consistency. One set of policies applies across every location and user, managed from a single place. Adding a new office, onboarding a contractor, or responding to a new threat becomes a policy change rather than a hardware project.
For leadership, the benefit is clearer oversight. A unified view of who is accessing what, from where, makes it easier to spot unusual behavior and to show regulators, insurers, and clients that controls are actually in place.
Running It In House Or Outside
Building and operating this kind of architecture internally requires real expertise across networking, security, cloud platforms, and identity management. Larger organizations with established security teams sometimes choose to do it themselves.
Many smaller and mid-sized businesses take a different route. A managed SASE service places the design, deployment, monitoring, and ongoing maintenance with a specialist provider, while the business retains ownership of its policies and decisions about access.
The usual trade-offs apply. Handing over day-to-day operations reduces internal workload and brings in specialist skills, but it also creates dependence on the provider’s responsiveness and judgment. Clear agreements on incident response times, reporting, and escalation are what make the relationship work. So does clarity about responsibility, since gaps tend to appear where each side assumes the other is handling something.
Mistakes Worth Avoiding
Trying to switch everything over at once is a common error. Moving in stages, often starting with remote workers or a single branch, lets problems surface early without disrupting the whole business.
Neglecting identity is another. Access decisions in this model depend heavily on knowing who someone is and whether their device is in good shape. Weak password practices or outdated account records undermine the entire approach.
Leaving policies too open defeats the purpose. Copying old, broad access rules into a new system preserves the same risks under a more modern label. The migration is a natural moment to review who genuinely needs access to what.
Forgetting the user experience causes friction too. Security that slows people down or blocks legitimate work tends to get bypassed. Testing with real staff before a full rollout helps catch those issues early.
Questions To Start With
Where do staff actually work on a typical week, and how much of their traffic still passes through the office?
How many separate security tools does the business run, and do they enforce the same rules?
Could the team say, quickly and confidently, who has access to the company’s most sensitive data?
How long does it take to give a new starter or contractor secure access today?
Security built around a building made sense when work happened in one. Now that work happens almost anywhere, protection works best when it follows the person rather than waiting at a door they rarely walk through.