I have spent my career building security and privacy frameworks for organisations that cannot afford to get it wrong. Healthcare systems. Critical infrastructure. Enterprises operating across jurisdictions with conflicting data sovereignty requirements. And in every single engagement, the conversation eventually arrives at the same uncomfortable truth: the way most organisations handle remote access is fundamentally broken, and they know it.
The broken thing is the VPN. And fixing it is not just a security improvement — it changes how distributed teams work in ways that compound over time.
The Security Problem with VPNs
A VPN does one thing well: it extends a private network to a remote endpoint. What it does not do — and was never designed to do — is constrain what that remote endpoint can access once it is inside the network.
When a user connects via VPN, they typically receive access to a network segment. Depending on configuration, that can mean hundreds of reachable services, file shares, internal APIs, and administrative interfaces — the vast majority of which that user has no legitimate reason to access. From a security standpoint, this is an enormous blast radius. A single compromised VPN credential becomes a lateral movement ticket across your infrastructure.
We have seen this play out repeatedly in high-profile breaches. Attackers do not break through VPNs by defeating cryptography. They obtain credentials — through phishing, credential stuffing, or insider threats — and then walk in through the front door. The VPN's encryption protects the channel. It does nothing to scope what the channel can reach.
Open inbound firewall ports compound the problem. Every port that is reachable from the internet is a potential attack surface. Every one of those surfaces must be continuously monitored, patched, and defended. For organisations with dozens or hundreds of devices and locations, this becomes an unmanageable surface area — especially as the workforce becomes more distributed and the number of access points multiplies.
Zero-Trust Is a Different Architecture, Not Just a Tighter Policy
Zero-trust remote access is not a VPN with stricter rules. It is a fundamentally different model. The design principle is: no entity — user, device, script, or AI agent — ever receives implicit trust. Every connection is authenticated, every action is scoped, and nothing is assumed safe by virtue of its network position.
In awaBerry Remote, this architecture works as follows:
- No inbound exposure. The awaBerry agent on each device establishes an outbound-only HTTPS connection to awaBerry's relay infrastructure. Your firewall does not change. No new ports are opened. The device is reachable from the internet only through the awaBerry tunnel — and only when an authenticated session is active.
- Per-session authentication. Every remote access session requires explicit authentication through the awaBerry dashboard. There is no "always-on" connection waiting to be abused. When the session ends, the tunnel closes.
- Scoped access. A user connecting remotely via awaBerry reaches a specific device, using a specific access method (Remote Desktop, SSH, Web-to-Local, file browser), for that session only. They cannot pivot to adjacent devices. They cannot probe services outside the scope of their session.
- Full audit trail. Every session — creation, activity, and termination — is logged with identity, timestamp, and parameters. Security teams get a clean, structured record that is genuinely useful for incident response and compliance reporting.
What This Unlocks for Distributed Teams
When remote access is both genuinely secure and genuinely simple, the operational improvements are significant — and they extend well beyond the security team.
Engineers can access development devices from anywhere without waiting for IT to whitelist a home IP address or configure split tunnelling. Support teams can connect to customer systems in seconds with a documented, auditable trail of exactly what they accessed. Executives travelling for work can reach their office desktops from a hotel lobby without submitting a ticket to open a temporary firewall rule. New remote employees are onboarded to device access by adding them to the awaBerry dashboard — not by submitting a multi-day VPN provisioning request.
Remote Desktop and Web-to-Local port forwarding — two of awaBerry Remote's most powerful features — illustrate this well. Remote Desktop gives distributed team members full graphical access to a device from anywhere, at performance levels that make working on a remote machine feel natural. Web-to-Local lets a developer reach a locally-running application on a remote device — a database interface, a development server, a Jupyter notebook — directly in their browser, without that application ever being exposed to the public internet.
The Future of Secure Remote Work
The workforce is permanently distributed. The device fleet is global. The infrastructure connecting people to the tools they need should meet the security standards of 2026, not the operational habits of 2010.
Zero-trust remote access is not the future — it is the present standard for organisations that take security seriously. The teams I work with who have made the transition from VPN-based access to awaBerry's zero-trust model consistently report the same thing: they are more productive, their security posture is materially stronger, and they spend less time managing access infrastructure.
That combination — stronger security, less complexity, better user experience — is exactly what zero-trust remote access should deliver. Explore awaBerry Remote →
