L2TP is a tunnelling protocol that carries point-to-point traffic over IP networks and is often paired with a security protocol for encryption. By itself it does not provide confidentiality. Defenders should confirm whether encryption is added, restrict access to tunnel endpoints, and monitor for unauthorised remote access use.
How L2TP moves traffic without adding security by itself
L2TP is a tunnelling protocol, so its job is to encapsulate traffic and carry point-to-point frames across an IP network. The tunnel gives the traffic a transport path, but it does not itself encrypt the payload. In practice, L2TP is usually paired with IPsec when confidentiality and integrity are required.
That division of labour matters: L2TP handles tunnelling, while the companion security layer provides protection against eavesdropping and tampering. This is why L2TP is often described as a VPN tunnelling component rather than a complete security solution.
For a broader VPN hardening view, see the VPN Security Guide, which covers tunnel security, hardening and replacement considerations.
What has to be in place for an L2TP tunnel to be trustworthy
Because L2TP alone does not guarantee confidentiality, the security of the tunnel depends on the surrounding controls. That means confirming whether IPsec or another encryption layer is actually enabled, whether the tunnel endpoint is exposed only to intended peers, and whether the authentication method is strong enough for the access being granted.
Operationally, the main questions are whether the tunnel is a legitimate remote-access path, a site-to-site path, or an unmanaged legacy dependency, and whether its use still matches the organisation’s security baseline. If L2TP is left in place for compatibility, the real control is in how tightly the endpoints, credentials and allowed routes are governed.
When tunnel authentication and access control need a formal baseline, the NIST SP 800-53 Rev 5 Security and Privacy Controls provides controls for access control, identification and authentication, audit and configuration management.
Why L2TP can still be useful, and where it becomes risky
L2TP remains useful where organisations need a standards-based tunnelling mechanism and already have a separate security layer protecting the session. The protocol is not the risky part on its own, but the deployment can become risky if people assume the tunnel implies encryption, or if exposed concentrators and remote-access endpoints are left broadly reachable.
That is why L2TP is often treated as an access mechanism that should be narrowly permitted, monitored, and paired with stronger protection at the endpoint and authentication layers. The protocol can also persist in environments longer than intended because it continues to function even when better designs are available.
Risk and Threat Considerations
The main risk is false assurance. If an organisation deploys L2TP without a separate encryption layer, traffic may be encapsulated but still observable in transit, and remote-access exposure can remain broader than expected. Attackers also look for legacy tunnel endpoints because they can provide a convenient entry point when authentication or configuration is weak.
Failure mechanism: A tunnel is treated as secure merely because it exists, while encryption, endpoint restriction or authentication strength is missing or misconfigured.
Impact: Confidential traffic may be exposed, unauthorised remote access may succeed, and the tunnel can become a stable path into internal systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | L2TP tunnels must be restricted to approved flows and endpoints. |
| IA-2 — Identification and Authentication (Organizational Users) | Remote-access L2TP depends on strong user authentication before tunnel use. | |
| SC-13 — Cryptographic Protection | The answer hinges on adding encryption because L2TP alone lacks confidentiality. | |
| Recommendation — Enforce approved tunnel flows and restrict L2TP endpoints to authorized paths. Require strong user authentication before permitting L2TP access. Apply cryptographic protection to the tunnel payload, not L2TP alone. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Tunnel endpoints and remote access must be tightly limited. |
| Recommendation — Limit L2TP access paths to approved users, devices, and endpoints. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Remote-access tunnel security depends on strong authentication to the endpoint. |
| Recommendation — Strengthen endpoint authentication before exposing L2TP access. | ||
| MITRE ATT&CK | T1133 — External Remote Services | L2TP is a remote-access service that can be abused for initial entry. |
| Recommendation — Monitor L2TP as an external remote service and investigate unexpected use. | ||
Practitioner Guidance
What to verify: Confirm whether L2TP is actually protected by IPsec or an equivalent encryption layer, and test the tunnel from the perspective of an unauthorised network path, not just a configured client. Also verify which endpoints are reachable from the internet and whether the authentication method matches the sensitivity of the access being granted.
Common mistake: Treating a working tunnel as evidence of adequate security. With L2TP, connectivity proves only that the tunnel functions, not that the traffic is confidential or that access is tightly controlled.
Practitioner takeaway: L2TP is a transport mechanism, not a security guarantee, so the real decision point is whether the surrounding encryption and access controls are strong enough for the data and trust boundary the tunnel crosses.