MPLS and Carrier WAN Security Guide: What the Carrier Protects and When to Encrypt

Many organisations still treat an MPLS VPN or a leased line as a private network, when the standards that define those services say plainly that they separate traffic but do not encrypt it. An MPLS L3VPN keeps your routes apart from other customers on the carrier's routers; it does not stop a carrier engineer, a misconfigured route target, a compromised provider edge router or a fibre tap from seeing or redirecting your packets. This guide sets out what each type of carrier WAN service actually protects, the trust you are placing in the provider, how to harden the customer edge, and how to decide when to add IPsec, MACsec or application-layer encryption on top. It is written for network architects, security architects and the people who negotiate carrier contracts. Overlay designs are covered in the SD-WAN Security Guide and Ethernet link encryption in depth in the MACsec guide.

Key takeaways

• Separation is not confidentiality. RFC 4364, the BGP/MPLS IP VPN standard, states that the architecture does not provide cryptographic privacy, and RFC 4381 says encryption must be layered on top if you need it.
• You are trusting the carrier's core and its people. RFC 5920 treats the provider core as a trusted zone and calls MPLS networks particularly vulnerable to insiders and compromised software within that zone.
• The customer edge is your responsibility. Static routing or authenticated CE-PE routing, prefix limits and filtering on the CE router decide how much a carrier fault can hurt you.
• Encrypt on a risk decision, not by habit. Data classification, regulatory expectations, how far you trust each provider and whether traffic crosses multiple carriers decide between CE-to-CE IPsec, WAN MACsec or relying on TLS in the applications.
• Carrier relationships are supplier risk. Portal accounts, change processes, subcontracted access circuits and inter-provider handoffs all belong in your third-party assurance, not only in the network design.

Carrier WAN services and what each protects

Enterprise WANs are usually a mix of services bought from one or more carriers. They differ in who controls routing, who can see traffic and what the carrier can change without you noticing.

For connections into public cloud over provider interconnects, see the Cloud Private Connectivity Guide.

What MPLS L3VPN does and does not give you

The design documents are clear about the security model. RFC 4364 (Standards Track, 2006) says VPN separation is comparable to Frame Relay or ATM provided that backbone routers do not accept labelled packets from untrusted links, labelled VPN routes are accepted only from trusted peers, and the control plane has not been successfully attacked. Section 13 also states that the architecture does not provide cryptographic privacy, that CE-to-CE cryptography can be used if desired, and that BGP and LDP sessions inside the provider should be protected with TCP MD5.

RFC 4381 (Informational, 2006, with an IESG note that the IETF did not review it for security) analyses the service in detail. Its conclusions are a useful checklist of what you are and are not buying:

• Provided, if configured correctly: address and routing separation through VRFs and route distinguishers; hiding of the provider core from customers; resistance to label spoofing because PE routers must not accept labelled packets from customer edge routers.
• Not provided: confidentiality, integrity or origin authentication of your traffic; protection against misconfiguration in the provider core or against attackers with access to PE or P routers; full security for your own network.
• Inter-provider designs: where your VPN spans carriers (Inter-AS or carrier's carrier), you must trust every provider involved, and some Inter-AS options let one provider inject traffic into another's VPNs.
• Recommendations it makes: IPsec over the MPLS service when confidentiality or integrity is required or the provider is not fully trusted; static routing on the CE-PE link where possible; authentication on dynamic PE-CE routing; per-VRF maximum-prefix limits and GTSM.

The route target is the critical control inside the carrier. A route is imported into a VRF when one of its route targets matches the VRF's import list, so a single wrong route target on a provisioning change can leak routes, and therefore traffic, between customers. That is a carrier-side error you cannot see from your CE router except through unexpected routes.

Threats to carrier WANs

Telecommunications providers are a deliberate target. The Salt Typhoon Telecom Intrusions 2025 page describes how China-linked actors used stolen credentials and network device access to stay inside carrier networks, which is exactly the provider-core compromise that RFC 4381 says MPLS VPN separation does not address.

Deciding when to encrypt

RFC 5920 places cryptographic protection according to trust: protect the access link if only the PE-CE path is untrusted, protect PE-to-PE if the backbone is untrusted, and use CE-to-CE protection if you trust nothing outside your premises. For an enterprise customer only CE-to-CE gives you control of the keys. The UK NCSC's IPsec guidance takes the same position from the other side: it assumes nothing about the bearer network, explicitly covers commercial WAN circuits, and notes that dedicated cloud links and inter-data-centre connections may also benefit.

Encryption options

• Point-to-point IPsec between CE routers or firewalls: follows NIST SP 800-77 Rev. 1 (Guide to IPsec VPNs, 2020). The NCSC recommended profile is IKEv2 with AES-128-GCM, HMAC-SHA-256 as the PRF, Diffie-Hellman group 19 or 14, X.509 certificates, and SA lifetimes of one day (IKE) and eight hours (child). See the IPsec Security Guide.
• Group encryption over MPLS: some vendors offer group-keyed IPsec that keeps the original IP header, so the carrier can still route on it and any-to-any traffic avoids a full mesh of tunnels. The trade-off is a shared group key held by every member, so the key server becomes a high-value system.
• WAN MACsec (IEEE 802.1AE): encrypts Ethernet frames at line rate on point-to-point carrier Ethernet, wavelength and dark fibre. Agree MTU and tag handling with the carrier, since the extra header and any clear VLAN tags must pass through their service.
• Application-layer TLS only: acceptable where every flow is already encrypted and authenticated, but you lose protection of routing metadata and of any flow you missed.

Plan for post-quantum change in long-lived WAN encryption: see Post-Quantum Readiness for VPNs and IKEv2 Guide.

Hardening the customer edge

Whether or not you encrypt, the CE router is the boundary between your network and the carrier, and it should treat the carrier as an untrusted neighbour.

• Routing to the PE: prefer static routes where the design allows, as RFC 4381 recommends. Where you run eBGP with the PE, use session authentication (TCP-AO where both sides support it, otherwise TCP MD5), GTSM, a maximum-prefix limit and strict inbound and outbound prefix lists. See the BGP and Routing Security Guide.
• Do not extend your IGP to the carrier: run OSPF or EIGRP to the PE only when the carrier service requires it, with authentication and filtering, and keep your internal IGP passive on WAN-facing interfaces. See the Interior Routing Protocol Security Guide.
• Filter inbound: apply an access list on the WAN interface that permits only routing with the PE, your encryption peers and expected site-to-site traffic, and drop anything sourced from your own internal ranges.
• Segment behind the CE: treat the WAN as a zone with firewall policy between sites rather than a flat extension of each LAN. See the Network Segmentation Guide.
• Carrier-managed CE: if the carrier manages your CE routers, it holds administrative access and any encryption keys configured on them. RFC 5920 notes that a provider managing customer encryption devices could access user traffic, so either encrypt behind the managed CE on devices you control or document that trust in the contract.

Where identity fits: carrier accounts and WAN keys

Carrier WANs create several non-human and shared credentials that are easy to forget:

• Pre-shared keys: the NCSC discourages IPsec pre-shared keys and, where they are unavoidable, asks for at least 128 bits of entropy, uniqueness per device group and change on compromise. Certificates from an internal PKI are better.
• Routing session keys: BGP and IGP keys on CE-PE sessions are often agreed by email with the carrier and never rotated.
• Carrier portal and API accounts: accounts that can order circuits, change routing or open tickets with authority should be named, protected with MFA and reviewed like privileged access. See the Network Device Management Plane Hardening Guide for device-side administration.

Supplier assurance for carriers

Most carrier risk is contractual and operational. Questions to put to each provider and record in your third-party assessment:

1. Which organisations deliver each circuit end to end, including access subcontractors and partner carriers for international sites?
2. How are VRF and route target changes peer-reviewed and verified, and how will you be told about a provisioning error affecting your VPN?
3. Who on the carrier side can access your PE configuration and managed CE routers, from where, and with what authentication and logging?
4. Does the carrier filter labelled packets and protect its own BGP and LDP sessions, as RFC 4364 expects?
5. What incident notification commitments apply if the carrier's core or management systems are compromised?
6. Can the service carry your encryption (MTU, MACsec tags, IPsec throughput) without degradation?

See the ISO/IEC 27036 Supplier Relationships Guide for the wider assurance process.

Implementation steps

1. Inventory circuits and flows: list every carrier service, its type, its delivery chain and the data classes that cross it; mark flows that are not already TLS or otherwise encrypted.
2. Harden CE routers first: static routes or authenticated BGP with prefix limits, WAN interface filtering, control plane policing. This is low risk and immediately reduces exposure.
3. Decide encryption per circuit class: use the decision table above and record the risk acceptance where you choose not to encrypt.
4. Pilot encryption on two sites: measure throughput, latency, jitter and MTU effects, and test failover between primary and backup circuits.
5. Roll out by region or carrier: keep the old clear path available as a routed fallback during cutover, with a time limit for removing it.
6. Roll back safely: if encryption breaks an application, revert that site's routing to the clear path through change control and fix MTU or policy before retrying, rather than leaving the fallback permanent.
7. Update contracts: fold the supplier questions into renewals and service schedules.

Detection and measurement

• Route monitoring on CE routers: alert on any prefix received from the carrier that is not one of your sites, and on prefix count changes.
• Encryption state: tunnel or MACsec session down events, unexpected fallback to the clear path, rekey failures.
• CE-PE session events: BGP resets, authentication failures, maximum-prefix triggers.
• Carrier portal audit logs: logins and changes, reconciled against your change tickets.

Common failure patterns

• "MPLS is private, so we do not encrypt": the decision was never written down and nobody re-tested it when database replication and backup traffic started crossing the WAN in clear.
• Carrier-managed CE with carrier-held keys: encryption exists, but the party you were protecting against holds the keys.
• No prefix limits on CE-PE BGP: a carrier-side route leak installs routes into the whole enterprise.
• Flat WAN: every site can reach every other site on every port, so compromise of one branch reaches the data centre over the carrier network.
• Shared pre-shared key for all tunnels: one leaked configuration exposes every site, a pattern familiar from harvested device configurations in incidents such as the Salt Typhoon telecom intrusions.
• Forgotten backup circuits: the primary MPLS path is encrypted, but the ISDN, 4G or broadband backup routes traffic in clear.

Framework mapping

Practitioner checklist

• Record every carrier circuit, its service type, delivery chain and the data classes that cross it.
• Write down the encryption decision for each circuit class, including the risk acceptance where you do not encrypt.
• Use CE-to-CE IPsec or MACsec with keys the carrier never holds wherever the carrier is not fully trusted.
• Prefer static CE-PE routing; otherwise authenticate BGP, enable GTSM and set prefix limits and filters.
• Filter inbound traffic on WAN interfaces and segment sites behind firewall policy.
• Replace shared pre-shared keys with certificates, or unique high-entropy keys per device group.
• Protect carrier portal accounts with MFA and reconcile their changes against your tickets.
• Include backup and out-of-band circuits in the same encryption and monitoring standard.

Standards and references

• IETF: RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs)
• IETF: RFC 4381 Analysis of the Security of BGP/MPLS IP Virtual Private Networks
• IETF: RFC 5920 Security Framework for MPLS and GMPLS Networks
• NIST: SP 800-77 Rev. 1 Guide to IPsec VPNs
• NCSC: Using IPsec to protect data
• IETF: RFC 5082 The Generalized TTL Security Mechanism (GTSM)

Related NHI Mgmt Group resources: SD-WAN Security Guide · IPsec Security Guide · MACsec · Interior Routing Protocol Security Guide