Join our Newsletter — 33% off our NHI Course

Layer 2 Tunneling Protocol (L2TP)

Layer 2 Tunneling Protocol is a network tunneling method used to carry private traffic across public or shared networks. It encapsulates layer 2 frames for remote access or site connectivity, but provides no encryption on its own, so confidentiality and integrity depend on separate security controls such as IPsec.

How L2TP Works

L2TP is a tunneling protocol, not a protection mechanism. It carries layer 2 frames across an intervening network so endpoints can extend remote access or site connectivity over infrastructure they do not fully control.

Because L2TP only encapsulates traffic, the protocol by itself does not hide content or prove integrity. In practice, organisations pair it with a separate security layer, most commonly IPsec, to provide confidentiality, integrity, and peer authentication.

Where L2TP Fits in Remote Access and Site Connectivity

L2TP is usually discussed alongside VPN designs because it supports the transport side of a private path. It can be used for client remote access, hub-and-spoke connectivity, or site-to-site transport where the objective is to make private traffic traverse a shared network safely.

The key architectural point is that L2TP defines how frames are encapsulated and delivered, while the surrounding VPN design defines how sessions are established, protected, and trusted. That separation is why protocol choice and security choice are not the same decision.

For protocol registration and interoperability details, the canonical reference remains the IANA registry, while implementation and standards work for tunnel-related internet protocols sits within the IETF.

Why L2TP Is Security-Sensitive

L2TP is security-sensitive because it often becomes part of a trust boundary for remote users, branch networks, or legacy VPN estates. If the encapsulation layer is mistaken for encryption, organisations can end up exposing traffic or credentials on networks they assumed were private.

That matters most when L2TP is deployed without a strong companion security control, or when older tunnel designs persist long after the surrounding access model has changed. In those cases, the protocol can remain operational while the assurance model quietly weakens.

For that reason, the practical security conversation usually shifts from “does L2TP work?” to “what protects the tunnel, what identities are trusted to use it, and what traffic is allowed once the tunnel exists?”

Operational Constraints and Modern Alternatives

L2TP can still appear in enterprise environments because it is widely supported and familiar, but it is often inherited rather than newly designed. That makes inventory, compatibility, and decommissioning decisions important, especially where the protocol is tied to older remote-access patterns.

When organisations reassess it, the key questions are whether the tunnel still meets current confidentiality requirements, whether its authentication stack is still suitable, and whether a more modern remote-access design would reduce exposure without breaking business connectivity.

In many environments, the real decision is not whether L2TP can connect two networks, but whether it should remain the mechanism used to do so.

Risk and Threat Considerations

L2TP risk usually comes from misapplied trust. If administrators assume the tunnel itself provides encryption or strong assurance, they may expose private traffic, weaken remote-access controls, or leave legacy VPN paths in place longer than intended.

Failure mechanism: The tunnel can still function while confidentiality, integrity, or authentication controls are missing, weak, or supplied by a separate component that is misconfigured or absent.

Impact: Attackers who intercept, abuse, or impersonate the access path can gain visibility into traffic, pivot through trusted connectivity, or exploit the tunnel as an unmonitored entry point into internal systems.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 SC-8 — Transmission Confidentiality and Integrity L2TP needs separate protection for tunnel confidentiality and integrity.
IA-2 — Identification and Authentication (Organizational Users) Remote-access L2TP deployments depend on authenticating users who enter the tunnel.
AC-4 — Information Flow Enforcement L2TP-based connectivity changes network trust boundaries and flow control decisions.
Recommendation — Apply SC-8 to protect tunneled traffic with explicit confidentiality and integrity controls. Enforce IA-2 to authenticate users before granting tunnel access. Use AC-4 to restrict what traffic may traverse the tunnel.
NIST CSF 2.0 PR.AA-05 — Managed Access Control Tunnel access should be explicitly governed as part of access management.
PR.DS-02 — Data-in-Transit is Protected L2TP by itself does not encrypt traffic, so in-transit protection must be layered on.
Recommendation — Apply PR.AA-05 to manage who can establish and use L2TP connectivity. Use PR.DS-02 to ensure L2TP traffic is protected in transit.

Practitioner Guidance

Why practitioners should care: Treat L2TP as a transport mechanism that must be paired with explicit security controls, not as a security boundary on its own. The operational question is whether your deployment still delivers the confidentiality and trust model your access design requires.

What to watch for: Legacy VPN estates often keep L2TP because “it still works,” even when the surrounding authentication, encryption, or segmentation model has moved on. That is usually the sign to review whether the protocol remains justified or simply persists by habit.