Browser based remote access to servers with Syteca PAM instead of VPN: An external service provider urgently needs admin access. Do we really have to package a VPN client first, run an onboarding process, open firewall rules and hope that nothing goes wrong? There is a better way. With the PAM module from Syteca, privileged access to RDP, SSH, databases and web consoles runs directly in the browser, without a fat client, without a VPN client and without coupling the endpoint directly to the internal network. This article situates the approach within Zero Trust thinking, presents DMZ and HAProxy architectures and explains why the model is more secure and operationally leaner than classic VPN when it comes to browser based remote access.
📑 Table of contents
Introduction and goal · The challenge: VPN risks and operational effort · Sources · Conclusion and actions
Introduction and goal: browser based remote access with Syteca PAM instead of VPN
Privileged access is delicate, because it can alter systems, data and security parameters. Classic VPN models couple the endpoint broadly to the internal network and thereby shift part of the defence work to the client side. Consequently, NIST recommends modelling remote access architectures deliberately and drawing a clear line between portal or web access and network-wide tunnels. NIST SP 800-46 Rev. 2 describes how to design portal and terminal server access securely, particularly in the context of telework and BYOD, where exposure is elevated and protection needs are correspondingly higher (NIST SP 800-46, SP 800-46 Rev. 2). This is precisely where Syteca PAM comes in. Access operates at the application layer over HTTPS rather than at the network layer via a VPN tunnel, which is decisive for secure browser based remote access.
Admin access directly in the browser, without a VPN client and without local agents on the endpoint.
Understanding the challenge: why classic VPN becomes a risk for privileged access
A VPN tunnel binds the endpoint at network level to the corporate network and thereby opens several attack paths. Lateral movement within subnets, credential harvesting along the tunnel and a difficult separation between privileged and regular access all follow from this model. Furthermore, split tunnelling risks, high client management overhead and the BYOD or service provider issue compound the problem. NIST positions portal and web access as a controllable alternative and stresses that remote access technologies face an elevated threat level and therefore require strong authentication together with a minimised attack surface (SP 800-46 Rev. 2). For privileged sessions, least privilege is central. Accordingly, NIST control AC-6 addresses the consistent restriction of administrative rights (NIST SP 800-53 AC-6), which also reinforces browser based remote access.
Browser based access with Syteca PAM: mechanics and security anchors Zero Trust context and policies DMZ variant: Syteca gateway as bastion in the decoupling zone HAProxy variant: reverse proxy in front of Syteca for hardening and high availability Operational advantages in daily practice An honest assessment: when VPN still makes sense
Syteca PAM provides an HTTPS portal through which administrators and external service providers launch RDP, SSH or web console sessions, without the endpoint establishing a direct network connection to the target system. The gateway brokers the protocols, terminates TLS, verifies identity and context, enforces approvals just in time and performs session recording as well as tamper-proof audit logs. Moreover, credential vaulting ensures that administrators never see the target passwords. Authentication and authorisation take place before the actual resource session is established, which aligns with the principle never trust, always verify. NIST recommends aligning remote access to resources rather than to network segments and verifying authorisation before the session begins (NIST SP 800-46
In practice, browser based PAM is a ZTNA pattern. It provides application-layer access, based on identity and context, with minimal network exposure. Least privilege and just in time serve as the programmatic guardrails. NIST SP 800-53 AC-6 supplies the appropriate control level for enforcing minimised privileges (NIST SP 800-53 AC-6). For remote access one can additionally draw on NIST SP 800-171 3.1.12, which demands monitoring and control of remote access (NIST SP 800-171 3.1.12), while CMMC AC.L2-3.1.12 summarises the corresponding requirements for suppliers to the US defence industry (CMMC AC.L2-3.1.12). These controls favour browser based remote access, since they centralise enforcement.
– Placement: Syteca gateway or jump component in the DMZ.
– Inbound traffic from the internet restricted to port 443/TCP (HTTPS) to the gateway only.
– Firewall rules DMZ→internal strictly limited to the required target protocols, for instance RDP 3389/TCP and SSH 22/TCP, and initiated only from the gateway.
– Internal servers remain without internet exposure. RDP and SSH are purely internal and not reachable from the internet.
– Identity integration (Active Directory, Entra ID), MFA and approval workflows are enforced centrally on the gateway. Session recording and the audit trail satisfy compliance requirements. Consequently, this architecture significantly reduces the attack surface compared with broadly coupled VPN tunnels and strengthens browser based remote access.
HAProxy in the DMZ either terminates TLS or passes it through, enforces modern cipher suites (TLS 1.2 as a minimum), sets HSTS and rate limiting and checks backends via health checks. Furthermore, two HAProxy nodes can run in high availability with Keepalived or VRRP, and traffic to the backend can be re-encrypted. Strongly abbreviated example:
global …
defaults …
frontend https_in
bind :443 ssl crt /etc/ssl/certs/site.pem ssl-min-ver TLSv1.2
http-response set-header Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
acl is_api path_beg /api
use_backend syteca_api if is_api
default_backend syteca_portal
backend syteca_portal
option httpchk GET /healthz
server portal1 10.10.10.11:443 ssl check
backend syteca_api
server api1 10.10.10.12:443 ssl check
Note: in production environments, structured logging, connection limits and DoS protection are mandatory. Inbound permissions remain restricted to port 443. RDP and SSH are internal only and reachable exclusively from the gateway, which further benefits browser based remote access.
– Smaller attack surface: no broadly coupled network on the client; access to the resource instead of to an entire subnet.
– Audit-proof logging: session recording with video and keystrokes plus immutable logs, rather than sparse VPN metadata.
– Service provider access without VPN onboarding: browser login, MFA, time-bound approval and immediate offboarding.
– Credential hygiene: central vaulting, automatic rotation and no cleartext password in the administrator’s hands.
– BYOD-ready: no VPN or RDP clients on third-party devices; the risk is channelled at the gateway. NIST additionally recommends protecting BYOD and remote technologies and managing the associated risks explicitly (NIST SP 800-46). Taken together, these points make a compelling case for browser based remote access.
VPN is not dead. For full network access, lift-and-shift legacy scenarios or migration phases it remains a legitimate tool, ideally segmented and combined with strong authentication and active monitoring. For privileged access to clearly defined target systems, however, browser based remote access via PAM is generally more secure, operationally simpler and easier to audit, especially when least privilege is applied consistently in line with NIST AC-6 (NIST SP 800-53 AC-6).
Conclusion and actions
Browser based remote access with Syteca PAM shifts control from the network to the resource. Authentication, authorisation, approval and recording all take place at the gateway before any session reaches the target system. This reflects the Zero Trust maxim never trust, always verify and substantially reduces risk compared with network-wide VPN tunnels. For SMEs, this translates into less operational friction, better traceability and a clean separation for service provider access.
We recommend the following next steps for decision makers as a pragmatic starting point.
✓ Define mandate and scope: inventory privileged target systems (Windows and Linux servers, databases, appliances, web consoles) and set access channels (HTTPS via portal, no direct RDP or SSH exposures). Such clarity accelerates secure browser based remote access.
✓ Operationalise least privilege: define the role model, approval workflows, just in time access and session recording in a binding manner, referenced to NIST SP 800-53 AC-6 (Link) and to the remote access controls of NIST SP 800-171 3.1.12 (Link). In doing so, you further reinforce browser based remote access.
✓ Decide on the architecture: DMZ gateway with inbound port 443 only and tight DMZ→internal rules; optionally HAProxy in front for TLS hardening and high availability. Furthermore, assess telework and remote risks in line with NIST SP 800-46 and document operating processes such as monitoring, patching and backup carefully (SP 800-46 Rev. 2, NIST overview
Do you want to establish privileged remote access without VPN clients, with a DMZ gateway, HAProxy hardening, MFA, just in time approvals, session recording and credential vaulting? We accompany you from the architecture review through to the pilot, consistently referenced to the NIST recommendations on remote access and least privilege, in order to enable resilient browser based remote access. A few immediate conclusions for executive management and IT leaders: ✓ Decouple privileged access from VPN: rely on browser based remote access via a PAM gateway with MFA, JIT approvals, session recording and vaulting rather than on network-wide tunnels. This follows the NIST recommendations on remote access and least privilege (SP 800-46 Rev. 2, AC-6). ✓ Harden the architecture consistently: DMZ gateway with port 443 as the sole inbound port from the outside, strict DMZ→internal firewall rules and RDP and SSH kept internal only. Optionally, use HAProxy for TLS hardening, health checks and high availability via VRRP to support stable browser based remote access. ✓ Simplify and audit service provider access: no VPN onboarding, but instead browser login, time-bound approval, session recording and a complete audit trail. Consequently, offboarding takes minutes rather than days and improves the governance of browser based remote access. ✓ Anchor policies: define remote access controls in a binding manner in line with NIST SP 800-171 3.1.12 and CMMC AC.L2-3.1.12, including strong authentication, the role principle and audit-proof logging (NIST SP 800-171 3.1.12, CMMC AC.L2-3.1.12). In practice, such policies underpin sustainable browser based remote access. We are happy to demonstrate browser based admin access live, including MFA, just in time approval, session recording and vaulting. In a brief architecture review we sketch the DMZ or HAProxy variant tailored to your environment and prioritise the initial target systems. As a textual sketch of the architecture diagram: internet → outer firewall → DMZ with HAProxy and Syteca gateway → inner firewall → internal target servers. Consequently, this staged approach accelerates secure browser based remote access.Further information and advice
🎯 Key takeaways – act now
Frequently asked questions: FAQ on browser based remote access with Syteca PAM
What do the next steps cover?