Working from home in 2008 meant one thing: dialling a VPN and waiting. Waiting for the client to connect. Waiting for the token code to refresh. Waiting for a 40MB attachment to crawl down a domestic broadband line and back up again. Waiting, most often, for a licence to free up, because the concentrator had been sized for the handful of executives and support engineers who were expected to use it — not for a department. Remote work existed. It just wasn't designed. It was an exception process bolted onto an architecture that assumed everyone sat inside the building.
The Architecture Was the Problem
The standard enterprise network of the period was a perimeter with a soft interior. Applications lived on internal servers, authenticated against the directory, and trusted anything on the corporate LAN. There was no meaningful concept of an application being available from outside. The VPN existed to solve that by pretending the remote laptop was inside the building. It worked, in the sense that packets arrived. It produced four structural problems that shaped the decade that followed: Everything went through one point. All traffic — including web browsing that had nothing to do with corporate systems — was backhauled through the concentrator. Performance was governed by the capacity of a single appliance and the bandwidth of one office's internet connection. Capacity was licensed, not elastic. Concurrent-user licensing meant remote access was a scarce, pre-purchased resource. Guidance from this period on enterprise telework architecture is careful to note that remote access solutions require deliberate sizing, tiering and security design rather than ad hoc deployment — advice that NIST later codified in its telework and remote access guidance. Access was binary. Once connected, a remote user typically had the same broad network reach as someone at a desk. A compromised home machine became a compromised network position. The alternative — granular access per application — did not exist in most deployments. Collaboration was file-based. No real-time co-editing. Work meant checking a document out of a share, editing it locally, and putting it back — or, more commonly, emailing it and creating a version conflict nobody resolved until Friday.
What It Felt Like to Work That Way
The friction was not evenly distributed, and that is what made it corrosive. People in the office had a normal working day. People at home had a degraded one: slower systems, worse meeting audio, no visibility into hallway conversations, and a persistent suspicion from managers that remote meant idle. Presence was measured by physical presence because nothing else could be observed, so working from home was a favour granted rather than an arrangement designed. The result was a self-reinforcing loop. Remote work was bad, so few people did it, so nobody invested in making it better, so it stayed bad. Two things broke the loop, twelve years apart. The 2008 downturn cut travel and office costs enough to make remote arrangements financially interesting. 2020 removed the option of not solving it.
What Actually Changed
The fix was not a better VPN. It was moving the applications. Once email, documents, CRM, ticketing and finance systems became services reachable over the internet with their own authentication, the need to place a remote device "inside" the network largely disappeared for knowledge work. The VPN shrank back to its legitimate use — reaching legacy systems and infrastructure that genuinely live on a private network. The security model followed. Instead of trusting the network location, modern access control evaluates identity, device posture and context per application. This is the substance of zero trust, and it is a direct response to the 2008 failure mode: a single credential granting broad lateral reach. The collaboration layer changed too, and arguably mattered more. Real-time co-editing removed the check-out-and-merge ritual entirely. Persistent chat gave distributed teams something closer to ambient awareness. Recorded and transcribed meetings made attendance optional for information-only sessions. What has not changed is the failure pattern. Organizations that treat remote work as an exception still build exception-quality infrastructure for it, and their remote staff still have a worse day than their in-office staff.
Building Remote Infrastructure That Holds
- Move applications out from behind the VPN. Every system that can be reached directly with strong identity and device checks removes load, latency and a class of lateral movement risk. Keep the VPN for what genuinely needs a private network path.
- Make identity the control plane. Single sign-on for everything, phishing-resistant authentication, conditional access based on device posture, and per-application authorisation rather than network-wide trust.
- Size for full remote, not for the exception. The pandemic taught this lesson expensively: capacity built for twenty percent of staff fails at one hundred percent, and the failure arrives on the worst possible day.
- Manage devices, not the network. Encryption, patch enforcement, endpoint detection and remote wipe. If the device is trustworthy and identity is strong, its physical location stops mattering.
- Instrument the remote experience. Measure application response times and connection reliability from where people actually work. The office experience tells you nothing about the remote one.
- Design the collaboration layer deliberately. Shared documents with real-time editing, a written decision record, explicit response-time norms and meeting formats that work when everyone is remote. Infrastructure without working practices produces connected employees who still cannot get anything done.
- Include residency in the design. Remote access to systems from other countries, and cloud services processing data abroad, both raise data location questions — particularly for regulated data in the GCC and Europe. Decide this at design time rather than during an audit.
The Broader Lesson
The VPN era looks primitive now, but the mistake was not technological. It was treating a working pattern as an edge case and then building infrastructure that made it one. Any arrangement that only some of your people use will be under-resourced and under-measured until something forces the issue. That was true of remote access in 2008. It is true today of hybrid meeting rooms, of contractor onboarding, of mobile-first access, and of every system that works beautifully for headquarters and badly for everyone else.
Common Questions
Why was remote work so difficult before cloud applications?
Applications lived on internal networks and trusted the corporate LAN. Remote users had to tunnel in through a VPN, which backhauled all traffic through a single appliance sized for a small number of concurrent users.
Is a VPN still necessary?
For legacy systems and infrastructure that genuinely require a private network path, yes. For SaaS and modern applications, identity-based access with device posture checks is faster, safer and more granular.
What is zero trust, in plain terms?
Access decisions based on verified identity, device health and context for each application, instead of granting broad network access because a connection came from a trusted location.
How should remote access capacity be planned?
For full remote operation, not for the expected percentage of remote users. Capacity planned around normal conditions fails during exactly the events — disruption, crisis, weather, illness — that create the demand.
Build Modern Remote Infrastructure — Outpace moves your applications out from behind the VPN, puts identity and device posture at the centre of access, and designs the collaboration layer so remote work is the default rather than the exception.