Securing remote access infrastructure against credential theft

Technical guidance for organisations on hardening VPN, RDP and SSH services, enforcing multi-factor authentication and adopting zero trust principles to mitigate the risk of credential-based attacks against remote access infrastructure.

1. Overview

Remote access services are among the most commonly targeted attack surfaces. SUVAT analysis indicates that compromised VPN credentials, exposed RDP endpoints and poorly secured SSH services accounted for initial access in over 60% of the cyber incidents reported to SUVAT in the 2024–25 reporting year. Threat actors routinely exploit weak or reused passwords, unpatched vulnerabilities in remote access appliances and the absence of multi-factor authentication to gain a foothold in organisational networks.

This guidance sets out the minimum security measures that organisations should implement to protect remote access infrastructure from credential theft and unauthorised access.

2. VPN security

2.1 Appliance hardening

  • Apply vendor security patches within 14 days of release. VPN appliance vulnerabilities are routinely exploited within days of public disclosure — emergency patching may be required.
  • Disable unused features, protocols and administrative interfaces. Restrict management access to an out-of-band network or a dedicated management VLAN.
  • Replace end-of-life appliances that no longer receive security updates.
  • Review and restrict split tunnelling configurations. Full tunnel is preferred for sensitive environments to ensure all traffic is subject to organisational security controls.

2.2 Authentication requirements

  • Enforce multi-factor authentication for all VPN connections without exception. SMS-based MFA is acceptable as a minimum; FIDO2 hardware tokens or authenticator applications are preferred.
  • Integrate VPN authentication with the organisation's identity provider to enable centralised account management, conditional access policies and prompt revocation of leavers' access.
  • Implement certificate-based device authentication in addition to user authentication to ensure only managed devices can establish VPN connections.

3. Remote Desktop Protocol (RDP)

3.1 Exposure reduction

Critical recommendation. RDP should never be exposed directly to the internet. SUVAT has observed a sustained and significant volume of brute-force attacks, credential stuffing campaigns and exploitation attempts targeting internet-facing RDP services. All RDP access must be mediated through a VPN, jump server or zero trust network access (ZTNA) solution.
  • Conduct regular external port scans to identify any inadvertently exposed RDP services (TCP 3389 or non-standard ports).
  • Disable RDP on systems where it is not required.
  • Use Remote Desktop Gateway (RD Gateway) with TLS encryption for centralised, auditable RDP access where a full VPN is not appropriate.

3.2 Session security

  • Enable Network Level Authentication (NLA) to require authentication before a full RDP session is established.
  • Configure session timeouts to automatically disconnect idle sessions after a maximum of 15 minutes.
  • Restrict RDP access to named user accounts with the minimum privileges necessary. Remove the default "Administrators" group from the Remote Desktop Users group.
  • Enable and monitor Windows Event Log entries for RDP logon events (Event IDs 4624, 4625, 4778, 4779).

4. SSH security

4.1 Configuration hardening

  • Disable password-based authentication entirely. Require public key authentication using ED25519 or RSA keys of at least 4096 bits.
  • Disable root login over SSH (PermitRootLogin no). Administrators should authenticate as named accounts and escalate privileges via sudo.
  • Restrict SSH access to specific users or groups using AllowUsers or AllowGroups directives.
  • Configure SSH to listen on a non-standard port as a defence-in-depth measure (this is not a substitute for proper access controls).
  • Disable legacy protocols and weak cryptographic algorithms. Use only modern ciphers (e.g. chacha20-poly1305, aes256-gcm) and key exchange methods.

4.2 Key management

  • Maintain an inventory of all SSH keys and their associated access rights.
  • Rotate SSH keys at least annually and immediately upon personnel changes.
  • Use SSH certificate authorities where feasible to issue short-lived certificates rather than relying on long-lived static keys.
  • Protect private keys with strong passphrases and, where possible, store them in hardware security modules or secure enclaves.

5. Monitoring for brute-force attacks

Organisations must implement monitoring and automated response capabilities to detect and mitigate brute-force and credential-stuffing attacks against remote access services:

  • Deploy an intrusion detection or prevention system (IDS/IPS) capable of identifying high-volume authentication failures.
  • Configure account lockout policies that temporarily disable accounts after a defined number of failed authentication attempts (SUVAT recommends 5 failures within 10 minutes, with a 30-minute lockout).
  • Implement IP-based rate limiting and geo-blocking where operationally feasible. Block connections from geographic regions where the organisation has no legitimate users.
  • Feed authentication logs into a Security Information and Event Management (SIEM) platform and configure alerts for anomalous patterns, including authentication attempts outside of business hours, connections from unusual locations and password spraying activity.

6. Session management

  • Implement session recording for privileged remote access sessions to support audit and forensic investigation.
  • Enforce re-authentication for sensitive operations during an active session.
  • Set maximum session durations appropriate to the risk level of the system being accessed. SUVAT recommends no more than 8 hours for standard sessions and 2 hours for highly privileged sessions.
  • Maintain detailed logs of all remote access sessions, including source IP, authenticated user, destination system, session duration and bytes transferred.

7. Zero trust principles

Organisations should work towards adopting zero trust architecture principles for remote access, in which no user or device is inherently trusted regardless of network location:

  1. Verify explicitly. Authenticate and authorise every access request based on all available data points — user identity, device health, location, service requested and risk score.
  2. Use least-privilege access. Grant the minimum permissions necessary for the task at hand. Use just-in-time (JIT) and just-enough-access (JEA) controls for privileged operations.
  3. Assume breach. Design networks and access controls on the assumption that a breach has already occurred. Segment access, encrypt all traffic end-to-end and continuously validate security posture.
Transition support. SUVAT recognises that migration to a zero trust architecture is a multi-year programme for most organisations. Organisations should develop a roadmap and deliver incremental improvements while maintaining the foundational controls described in this guidance. Contact SUVAT for advisory support on zero trust adoption.