How does Link encryption work?

Link encryption protects data on a single communication link by encrypting traffic between two adjacent network nodes. Each hop decrypts and re-encrypts the traffic, so intermediate devices can still inspect or route it. Defenders should assess every hop, because compromise of a node exposes traffic on that link segment.

How link encryption works at each hop

link encryption protects traffic on a single communication segment, not the entire end-to-end path. The sender encrypts frames or packets before handing them to the next node, and that node decrypts them so it can inspect, forward, or re-encrypt traffic for the next segment. That means confidentiality is preserved on the wire for that hop, while the intermediate device still sees the plaintext.

Because each hop terminates protection locally, the security boundary is the link itself. The benefit is strongest where you need to protect traffic across an exposed transport segment, such as a radio link, leased line, backhaul, or other shared medium. The trade-off is that trust shifts to every device that terminates the link, since those systems can observe the traffic after decryption.

What link encryption does and does not protect

Link encryption hides traffic from passive observers on the protected segment, but it does not automatically protect the payload once it is decrypted at a hop. If the intermediate node is compromised, the attacker can see or alter traffic on that segment despite the encryption. That is why link encryption is best understood as hop-by-hop protection, not as a substitute for end-to-end encryption when the data itself must remain opaque across the whole route.

It also does not solve endpoint compromise, weak access control, or poor key handling. If keys are exposed, if a device is mismanaged, or if the hop terminates in a weak administrative domain, the encryption can still be bypassed in practice. For that reason, the operational question is not only whether the link is encrypted, but also whether every terminating node is trusted, hardened, and monitored. For a broader primer on encryption modes and deployment patterns, see the Encryption Guide.

Where practitioners need to be careful

The main design choice is whether the link crosses a boundary that you do not fully trust. If it does, link encryption can reduce interception risk in transit, but it leaves each hop as a point where the data is available in cleartext. That is acceptable in some network designs, but it requires you to treat the terminating devices as security-critical assets, not as passive forwarding equipment.

In layered architectures, link encryption is often used alongside other controls rather than alone. It can reduce exposure on a segment while higher-layer protections preserve confidentiality across the broader path. That is why practitioners should think in terms of threat surface per hop, not in terms of a single yes-or-no encryption decision. The same logic applies in specialised environments such as space and satellite links, where command and telemetry paths often rely on hop-specific protection and strict control of the devices that terminate the link, as described in the Space and Satellite Cybersecurity Guide.

Risk and Threat Considerations

Link encryption reduces exposure to eavesdropping on the transport segment, but it concentrates trust in the devices that decrypt and re-encrypt traffic. If one of those nodes is compromised, the attacker gains visibility into traffic on that link segment and may be able to tamper with it before it is forwarded onward.

Failure mechanism: A hop that terminates the encrypted link becomes the point where plaintext exists, so compromise of that node or its key material defeats protection for that segment.

Impact: Traffic can be observed, modified, or replayed on the affected hop, and downstream systems may receive data that appears legitimate because the link itself is still functioning.

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, CIS Controls v8 and NIST SP 800-57 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	Link encryption is a transmission-layer confidentiality control.
	IA-9 — Service Identification and Authentication	Hop-by-hop re-encryption depends on authenticated network nodes or services.
	IA-5 — Authenticator Management	Link encryption depends on protecting the keys and authenticators used at each hop.
Recommendation — Encrypt data in transit on each protected link segment. Authenticate each terminating node before allowing link re-encryption. Manage and rotate link keys with strict lifecycle controls.
CIS Controls v8	CIS-3 — Data Protection	Link encryption is a data protection safeguard for traffic in transit.
Recommendation — Encrypt sensitive data in transit across exposed network links.
NIST SP 800-57	Key Management	Hop-by-hop encryption is only as strong as its key lifecycle and protection.
Recommendation — Apply disciplined key lifecycle management for every link key.

Practitioner Guidance

What to verify: Confirm exactly which devices terminate the encrypted link, who administers them, and whether those systems are inside a trust boundary you are willing to inherit. If the answer is unclear, treat the segment as higher risk than the encryption banner suggests.

What to prioritise: Protect hop-terminating devices and their keys first, because those are the control points that determine whether the encryption is actually meaningful. In practice, the weakest hop defines the real assurance level of the path.

Practitioner takeaway: Link encryption is valuable for protecting traffic on the wire, but the security outcome depends on the trustworthiness of every hop that can decrypt it.