Securing Remote Access Before It Was Mandatory

Remote access security in 2017 was a minority concern, handled by a VPN concentrator that nobody had reviewed since it was installed, and that neglect was about to become the most expensive architectural debt in the enterprise. The standard arrangement was straightforward and almost universally the same. A perimeter firewall, a VPN gateway, and the assumption that anyone who authenticated through it belonged inside. Users connected, received an internal IP address, and from that point had the network reach of someone sitting at a desk in the building. Third parties, integrators and support vendors used the same mechanism, frequently with shared accounts and no expiry. The whole model rested on one premise: that the network boundary meaningfully separated trusted from untrusted. NotPetya had just demolished that premise for anyone paying attention. Once inside a flat network, the malware moved without obstruction, and the boundary that was supposed to matter had no bearing on the outcome. The organisations that handled the sudden shift to remote work three years later with composure were, almost without exception, the ones that had done this architectural work before they were forced to.

What the VPN model actually gets wrong

It authenticates the connection, not the request. Once the tunnel is established, every subsequent action is implicitly authorised by the initial login. A compromised credential yields persistent internal presence rather than access to a single application. It grants network reach instead of application access. A finance user working from home needs the ERP and a file share. The VPN typically gives them routable access to everything the network routes to, including domain controllers, hypervisor management interfaces and the machines of colleagues. This is the amplifier that turns one compromised laptop into an estate-wide event. It treats third parties as employees. Integrator and vendor support access ran over the same VPN with the same reach, often through accounts shared among a partner's engineers, and frequently still active years after the project ended. The 2013 Target breach had already demonstrated where that leads, and almost nothing had changed. It ignores the device. A VPN validates the user and is generally indifferent to whether the machine is patched, encrypted, managed or personally owned and shared with a household. It has no useful telemetry. Connection logs show who connected and for how long. They rarely show what was reached, which makes both detection and post-incident investigation close to impossible.

The architecture that replaced it

The alternative that matured over the following years was not a product but a set of design decisions, and every one of them was available in 2017. Authenticate per application rather than per network. Access is brokered to a specific service after evaluating the user, the device and the context of the request. The user never receives an internal network address, which eliminates lateral movement as a capability rather than mitigating it as a risk. Require strong authentication everywhere, including for administrators and third parties. This is the highest-value single control in the category and the one most commonly still missing on exactly the accounts that matter most. Make device posture part of the decision. Managed, patched, encrypted, endpoint protection running. Unmanaged devices get a browser-based path to a narrow set of applications, not a tunnel. Give third parties time-bounded, purpose-specific access with individual accounts. Named engineers, scoped to the systems they support, expiring by default, with session recording for privileged work. Standing partner access is an unnecessary permanent exposure. Log the request, not the connection. Who accessed which application, when, from what device. This is what makes anomaly detection and incident investigation possible. The practical path for most organisations was incremental: multi-factor authentication first, then moving the two or three highest-risk applications behind an application-level broker, then third-party access, then reducing what remained on the VPN. Organisations that attempted a full architectural replacement as a single programme generally stalled; those that sequenced by exposure made steady progress.

Practical Guidance for Remote Access Architecture Review

• Enumerate every external access path, including the ones IT did not build. Vendor support tools, cloud management consoles, remote desktop gateways and legacy dial-in equivalents — the inventory is always longer than expected.
• Put multi-factor authentication on administrative and third-party accounts before anything else. These are the accounts with the most reach and the ones most often exempted for convenience.
• Replace network-level access with application-level brokering for your highest-risk systems first. Sequencing by exposure gets results; whole-estate replacement programmes stall.
• Give every third party individual, time-bounded, scoped accounts. Shared partner credentials with no expiry are the most common serious finding in any access review.
• Make device health a condition of access for anything sensitive. An unmanaged machine should reach a narrow browser-based set of applications, never a network tunnel.
• Log which applications were accessed, not merely who connected. Connection logs cannot support detection or investigation; request logs can.
• Review access on a schedule and revoke by default. Access granted for a project outlives the project unless expiry is automatic.
• Test whether a compromised remote credential can reach your core systems. If the answer is yes, that is the finding that justifies the programme.

The Regional Dimension

Remote access architecture in the Gulf carries constraints that the standard guidance does not anticipate, and several of them cut in unexpected directions. The integrator-operated estate is the dominant factor. A large share of regional ERP, HR and infrastructure is implemented and maintained by systems integrators whose engineers require privileged remote access, frequently continuously and often from offshore delivery centres in India, Egypt or the Philippines. In practice this means standing administrative access held by people the client has never met, through accounts shared within the partner's support team, over connectivity the client does not control. Three contract questions follow directly: are partner accounts individually named and attributable, can access be revoked unilaterally within the hour without the partner's cooperation, and is privileged session activity recorded and available to the client. Most regional organisations cannot answer affirmatively on any of the three, and this is the single largest remote access exposure in the region. Offshore shared service centres create a related structure. Groups running finance, HR or IT operations from Dubai, Riyadh, Cairo or Manila have staff in one jurisdiction accessing systems and data in another continuously — which makes remote access simultaneously a security control and a data residency mechanism. Remote administration of an in-country system from abroad is, under several regional interpretations, a cross-border access that requires the same scrutiny as a data transfer. Saudi PDPL and the cloud computing framework, UAE sector rules, and the separate DIFC and ADGM regimes each treat this differently, which means the access architecture has to encode jurisdictional rules rather than merely technical ones. Application-level brokering helps here in a way rarely mentioned in vendor material: it makes access decisions auditable per user, per application and per location, which is exactly the evidence a regulator asks for. Connectivity and platform history shaped regional choices too. Historic restrictions on consumer voice and video services meant regional organisations adopted enterprise collaboration platforms through different routes than their European counterparts, and remote work depended on mobile networks and home connections of variable quality. That has two consequences for architecture: latency-sensitive thick-client ERP access over a tunnel performs poorly for remote users, which is an argument for browser-based application access independent of security; and mobile-first access patterns are more common, which makes device management on personally owned phones a central rather than peripheral problem. Two further specifics. The regulatory position has firmed considerably — national cybersecurity authorities in the UAE and Saudi Arabia, central bank frameworks, and sector requirements in energy, health and telecommunications now treat privileged and third-party remote access as a named control with evidence expectations, and the access register has become an audited artefact. And workforce mobility matters more here than elsewhere: employment-linked residency means departures can be abrupt, with employees leaving the country within days. Offboarding that depends on a manual checklist will leave active credentials behind, which makes automated deprovisioning tied to the HR record a security control rather than an administrative nicety.

The objection worth taking seriously

The fair criticism is that this architecture was recommended enthusiastically to organisations that could not implement it, by vendors who sold the components. Application-level access brokering assumes applications that support modern authentication. A great many regional and mid-market estates run software that does not: on-premise ERP with proprietary clients, legacy payroll engines with government interface modules, manufacturing and warehouse systems, database clients, and equipment management consoles that expect to be on the same network segment. For these, the honest answer in 2017 — and frequently still — is a jump host with strong authentication and session recording, which is a compensating control rather than the target architecture. Pretending otherwise leads to programmes that deliver the easy applications and leave the critical ones on the old path, producing cost without closing the actual exposure. There is also a cost and complexity argument that deserves respect. Identity brokering, device management, conditional access policy and privileged session recording is a stack with licensing and operational overhead, and it requires someone to maintain policy as applications and roles change. An organisation with three IT staff will get more risk reduction from four things — multi-factor authentication on everything reachable from the internet, individual named accounts for every third party with expiry dates, endpoint management that confirms machines are patched and encrypted, and removal of any remaining direct remote desktop exposure — than from a partial implementation of a zero trust programme that nobody has time to operate. Partial implementations of complex architectures are frequently less secure than well-run simple ones, because policy gaps are harder to see. And a point about the 2020 narrative. "Zero trust would have saved you" was asserted widely afterwards, but plenty of organisations with conventional VPN architectures came through remote working without incident, because they had MFA, decent endpoint hygiene and controlled third-party access. The architecture matters, and it matters less than those three fundamentals. Organisations that sequence correctly get most of the benefit early; organisations that buy the architecture and skip the fundamentals get an expensive false sense of security.

Common Questions

What single change reduces remote access risk most?

Multi-factor authentication on every externally reachable service, with no exemptions for administrators, service accounts or third parties. The exemptions are where the compromises happen, and they are usually granted for convenience rather than technical necessity.

How should legacy applications that cannot support modern authentication be handled?

A hardened jump host with strong authentication, per-session authorisation and session recording, placed in its own network segment. Treat it as a documented compensating control with a review date, not as the destination.

Is a VPN obsolete?

Not obsolete, but it should be the narrow exception rather than the default. Keep it for the specific protocols and systems that genuinely require network-level connectivity, scope it tightly, and move everything else to application-level access.

How does AI change remote access security?

Most immediately by weakening the human verification steps that surround it. Voice cloning makes the service desk call that resets a password or enrols a new authenticator a poor identity check, and AI agents now hold credentials and access systems on behalf of users — which means the access model has to treat them as privileged non-human identities with scoped permissions, expiry and logging, rather than as extensions of the user who configured them. Most organisations have no inventory of these, which is the same gap that unowned service accounts represented a decade ago, arriving faster. On the defensive side, behavioural analysis across access requests is genuinely better at flagging the impossible pattern — a user authenticating from two continents, a support engineer touching systems outside their history, a service account suddenly interactive — and that only works if you log requests at application level rather than connections at network level. Which returns to the same architectural conclusion, now with a second reason: identity-aware access is what makes the detection possible.

---

Remote Access Architecture Review — authenticate the request, not the network; and give every third party a named account with an expiry date.