Device security guidance

Do you need a VPN?

Whether you require a VPN will depend on the network architecture you use. For example, there would be little benefit in using a VPN if you've fully adopted a zero-trust approach to networking.

Also, if none of the advantages of VPNs mentioned above apply to you, there is no need to use one. Even if some of those reasons apply to you, there may be alternative ways to address the base problem. Legacy services may not be needed on devices outside the firewall, or blocking access to illegal websites could be done on-device, if required.

VPNs are complex to set up, require maintenance, and failure of a VPN could easily cause organisation-wide outages.

If you're using a walled garden architecture, or other architecture that requires end users' traffic to traverse untrusted networks and external firewalls then you should consider using a VPN. However, there are many aspects of a VPN to consider. These are addressed next.

The protocols most widely used for VPNs are Transport Layer Security (TLS) and Internet Protocol Security (IPsec). There are a variety of others, some of which (PPTP for example) have fallen out of use because of security concerns. Other protocols, such as Wireguard are growing in popularity and seem promising, but are yet to be proven in enterprise contexts.

Our recommendation is that IPsec be used for VPN access. IPsec is an open standard, meaning that anyone can build a client or server which will work with other IPsec implementations.

As an IPsec VPN client is built into many operating systems, no additional products are required to deploy a VPN. However, some third-party networks restrict or block IPsec traffic, so your mobile devices may, in certain situations, be unable to create the VPN connection.

TLS VPNs can also be used, though you will likely need to use a third-party client and server. In addition, products from different vendors will rarely inter-operate, so you will need to use both from the same vendor. Whilst TLS is standardised in a variety of RFCs, exactly how those protocols are used to create a VPN is not. However, TLS VPN connections can be more reliable when traversing Network Address Translation (NAT) devices, or enterprise firewalls.

From a security perspective, with all other things equal, there is very little difference in risk between using an IPsec and a TLS VPN.

Cryptography

We recommend client certificates for machine authentication, when using a VPN. Certificates have several advantages over Pre-Shared Keys (PSKs), including the ability to revoke just one certificate on your network and to store private keys securely (e.g. in a TPM or TEE), which we strongly recommend, when possible.

For specific guidance on configuring cryptographic parameters, see the NCSC's separate guidance on Using IPsec to protect data and Using TLS to protect data. As these recommended configurations are not always fully supported by built-in VPN clients on operating systems. We also give per-platform recommendations in the per-platform device guidance.

By using weaker profiles or algorithms than those recommended below, you will increase the risk of data compromise while in transit over untrusted networks.

To provide benefits, a VPN must establish a connection, remain connected while the device is in use, and reconnect if the connection is temporarily lost. Typically, there are three ways of implementing this behaviour: automatic, triggered, and manual.

• Automatic VPNs are brought up by the device whenever a network connection is requested by software on the device.
• Triggered VPNs are brought up whenever certain network connections from a defined list are made (internal intranet sites, for example).
• Manual VPNs require the user of the device to initiate the VPN by explicitly deciding to take an action (such as launching an application and clicking connect). The user will likely need to take this step again if the connection drops during or after use.

"Distinguishing automatic from forced

We distinguish automatic from forced because on some platforms it is possible for the user to disable the automatic VPN, whilst the platform still enforces VPN routing. This effectively prevents network connections from the device until the user re-enables automatic connections.

Depending on whether the VPN is forced or optional, choosing between automatic, triggered and manual could be a usability decision rather than security.

If the VPN is forced, but the initiation is manual, this will be a poor user experience as the device will not have any connectivity until the user manually starts the VPN. Conversely, if the VPN is optional, and the initiation is manual, then there is a risk of compromise from local attackers on an untrusted network, during the period when the device is not connected."

We advise you to use an automatic VPN, and where possible our per-platform guidance outlines a way of achieving this.

Full-device vs per-app VPN

Some operating systems and many third-party applications allow you to configure only certain applications to use a VPN on the device. This is mostly useful in a Bring Your Own Device (BYOD) scenario, where enterprises do not want network traffic from personal apps to traverse the corporate network. This approach can be used to prevent malicious personal apps attacking the corporate network, or to limit bandwidth consumption from data-intensive personal apps. A per-app VPN also enables latency-sensitive apps (such as VoIP applications) to avoid any increase in network latency from the VPN.

However, if deploying in this way, you need to define all the applications you want protected by the VPN in advance. As this is generally used in a BYOD scenario, users can always download another application to work around the per-app VPN restrictions. In some cases, it may not be possible to force system applications to use a per-app VPN.

Our per-platform guidance recommends - and provides a configuration for - setting up a full-device VPN. Using a per-app VPN increases the risk that sensitive data may be sent outside the VPN by an application that is not included in a per-app VPN, or by a misconfiguration in the platform.

Split tunnelling

Like a per-app VPN, split tunnelling is a way of having some traffic use the VPN, whilst other traffic is permitted direct connectivity. This is generally achieved by only defining certain network routes (e.g. internal IP address ranges) as available via the VPN. The default gateway for all other traffic is then left as a direct connection.

This is generally used when the VPN is providing access to internal services on a corporate network, without attempting to prevent other connections. For example, high-bandwidth applications could be permitted direct access to the internet without being routed via corporate infrastructure, to save on bandwidth costs. And, as with per-app VPNs, latency-sensitive applications, such as a VoIP client, could minimise network latency by connecting directly.

Split tunnelling is generally not supported on native VPN clients, which typically have relatively simple configuration options. Windows operating systems can be configured to split tunnel by using custom routing rules, but the clients built into smartphones and tablets rarely support this configuration. Third-party clients are sometimes able to support this option.

Enabling split tunnelling increases the risk that sensitive data will be exposed to an unprotected network, and could enable external attackers to access internal resources by ‘pivoting’ through the device. In a scenario where you are relying on the VPN to route traffic for protective monitoring or duty of care reasons, enabling split tunnelling will undermine the benefit gained from those protections.

Managed tunnels

If there are specific services that you want to access outside of the VPN, you can do this through the use of managed tunnels. This involves traffic to that particular endpoint being sent outside of the configured VPN. Sensible reasons for doing this include reduction of the load on networks caused by video conferencing services or where the function of an application requires it to communicate directly on the network, such as Wi-Fi captive portal helpers.

We only recommend the use of managed tunnels in situations where the provider of the service that will be connected to outside the tunnel, provides:

1. Information demonstrating that connections to the service are protected as well as they would be by the VPN (e.g. the use of mutual TLS authentication).
2. Definitive statements that the service uses dedicated IP endpoints, so that only traffic to that specific service will pass outside of the VPN.

And where there’s a business requirement for users to access the service outside of the VPN - i.e. high-bandwidth services such as those used for video conferencing. We would also recommend this approach to enable Wi-Fi captive portal helpers to function

There are certain issues which are not directly related to the configuration of the VPN, but which will be affected by your choice of technologies and configurations, as outlined in the previous section.

Client and Server security updates

As with all software, both the client and server component will need to be regularly updated. On devices where the client is integrated into the operating system, these updates will naturally happen as a result of regular platform updates. Third-party software will need to be updated in some other way.

VPN services will be part of the internet-exposed attack surface of your organisation, so will need to be swiftly updated as soon as security patches are released

Tethering to devices with a VPN

Tethering, or mobile hotspots, involve connecting an external device to your smartphone in order to use the smartphone’s internet connection.

However, full-device VPNs can often have an impact on how tethering works on the underlying platform. Some platforms will route tethered devices’ connections outside of the smartphone’s VPN connection, while some smartphones will not route tethered traffic if there is a full-device VPN connected. If your users rely on tethering, an appropriate configuration should be selected to enable it.

There are two components to decide on: the Client and the Server.

You may wish to use the same vendor for both components, or adopt an open standard and use different vendors. Regardless, you should consider each aspect of VPN configuration described above.

The NCSC recommends:

• Use the IPsec protocol to give you the flexibility to choose from a wide variety of inter-operable products.
• Use certificate authentication. Store private keys in hardware-protected storage (TPM or TEE) if possible.
• Use the native client for your particular platform(s), if possible.
• Use a forced VPN to ensure apps cannot evade enterprise monitoring solutions (if you use them).
• Use a VPN which automatically connects, so the device user is not required to manually enable it.
• Use a full-device VPN and avoid split tunnelling to minimise the risk of data leaking outside the VPN.
• Use the platform's built-in captive portal helper, if there is one, or deploy a third-party one.
• Follow the NCSC's recommended cryptographic profiles for IPsec or TLS, as appropriate.

The NCSC recommends that you test several VPNs to find which meet your requirements, are robust and resilient. As devices configured as suggested here will be largely unusable if the VPN service has an outage. It's especially important that the architecture is resilient and has backup options, if components within the service fail.

Further guidance:

• Platform guides
• Network architecture
• NCSC guidance - Using IPsec to protect data
• NCSC guidance - Using TLS to protect data

Related blogs:

• NCSC blog post - Serving up some server advice
• NCSC blog post - NCSC IT: The architecture behind NCSC's IT system