MACsec Guide: 802.1AE, MKA and WAN MACsec

Ethernet links between switches, routers, data centres and branch sites usually carry traffic in the clear, so anyone who can tap a fibre, a patch panel or a carrier circuit can read or alter it. MACsec (IEEE 802.1AE) encrypts and authenticates Ethernet frames on each link at line rate, with keys negotiated by the MACsec Key Agreement protocol (MKA) defined in IEEE 802.1X. This guide explains how the standards fit together, the key hierarchy and modes, how to roll MACsec out on campus, data centre interconnect and WAN circuits, how to monitor it, and where it maps to control frameworks. It is written for network and security architects, network engineers and auditors who need to decide where MACsec belongs and run it without outages. Standard status was checked on the IEEE 802.1 working group pages on 8 November 2026.

Key takeaways

MACsec protects a link, not a path. Frames are encrypted on one Ethernet hop and decrypted at the next MACsec device, so it complements IPsec or TLS rather than replacing end-to-end encryption.
Two standards, one system. IEEE 802.1AE-2018 (with amendments up to 802.1AEdk-2023) defines frame protection; IEEE 802.1X-2020 defines MKA, which authenticates peers, elects a key server and distributes the Secure Association Key (SAK).
The CAK is the credential that matters. Whether it is a pre-shared key or derived from 802.1X EAP-TLS, the Connectivity Association Key is a machine credential that needs inventory, rotation and protection like any other secret.
Must-secure or it is optional. A should-secure policy falls back to clear text when the peer does not negotiate MACsec; links that must be protected need must-secure behaviour and monitoring of session state.
WAN MACsec needs carrier planning. Overhead, MTU, VLAN tags in the clear and whether the carrier forwards MKA frames decide whether a circuit comes up secured.

What it is and who it applies to

IEEE 802.1AE, MAC Security, provides connectionless confidentiality, integrity, data origin authenticity and privacy protection for Ethernet frames, and it is transparent to the protocols above it. The IEEE 802.1 Security task group lists IEEE Std 802.1AE-2018 as the base standard, with a corrigendum (802.1AE-2018-Cor1) and the 802.1AEdk-2023 amendment for MAC Privacy Protection. A revision (P802.1AE-2018-Rev) and an amendment adding an Ascon cipher suite (P802.1AEef) are in progress, so expect the standard to change.

MACsec is not a regulation: nobody is required to deploy it by name. It applies wherever an organisation needs to protect data in transit over links it does not physically control, or where the threat model includes tapping inside its own buildings. Typical users:

Data centre operators: encrypting data centre interconnect (DCI) fibre and dark fibre between sites at full line rate.
Enterprises with leased Ethernet circuits: protecting carrier Ethernet services between branches and data centres, where 802.1AEcg-2017 defined Ethernet Data Encryption devices for transparent secure connectivity across provider networks.
Campus and high security sites: switch-to-switch uplinks in shared risers, and switch-to-host links where 802.1X already authenticates endpoints.
Government and regulated sectors: where control frameworks require cryptographic protection of transmission (NIST SP 800-53 SC-8(1)).

MACsec compared with other transit encryption

Option	Layer and scope	Strengths	Limits
MACsec (802.1AE)	Layer 2, one Ethernet link at a time	Line rate in switch or PHY hardware; protects all traffic including ARP, DHCP and routing protocols on the link	Decrypted at each hop; needs MACsec capable hardware at both ends; carrier must pass the frames
IPsec	Layer 3, end to end across routed networks	Works over any IP path including the internet	Higher overhead and often lower throughput; only IP traffic. See the IPsec Security Guide
TLS or mTLS	Application session	Protects data end to end between workloads	Only the applications that use it; leaves other traffic on the link exposed
Optical layer encryption	Transport (optical) layer	Bulk protection of a wavelength	Specialist equipment; not covered by the IEEE 802.1 standards

Structure and key requirements

Frame protection

MACsec inserts a Security Tag (SecTAG) after the source MAC address and appends an Integrity Check Value (ICV) at the end of the frame, using EtherType 0x88E5. Juniper documentation describes this as an 8-byte header and a 16-byte tail; the SecTAG grows when the optional Secure Channel Identifier is included. Encryption uses AES in Galois/Counter Mode (GCM), which NIST SP 800-38D defines as authenticated encryption with associated data. Frames that fail the integrity check are dropped.

Cipher suite	Added by	When to use
GCM-AES-128	802.1AE-2006 (original)	Baseline; supported on almost all MACsec hardware, often the default
GCM-AES-256	802.1AEbn-2011	Where policy requires 256-bit keys
GCM-AES-XPN-128 and GCM-AES-XPN-256	802.1AEbw-2013 (extended packet numbering)	Links of 40 Gb/s and above, where a 32-bit packet number would exhaust quickly; XPN lets one SAK protect more than 2³² frames

MKA and the key hierarchy

Connectivity Association Key (CAK) and name (CKN): the long-term secret shared by members of a connectivity association. Juniper documentation describes it as protecting control plane traffic. It comes either from a pre-shared key (static CAK) or from 802.1X EAP authentication with a RADIUS server (dynamic CAK, EAP-TLS with PKI).
Derived keys: MKA derives a Key Encrypting Key (KEK) and an Integrity Check Value Key (ICK) from the CAK to protect and authenticate MKA protocol data units (MKPDUs).
Key server: MKA elects a key server by priority. In Cisco IOS XE the priority runs 0 to 255, and 255 means the device never becomes key server.
Secure Association Key (SAK): generated randomly by the key server, distributed under the KEK, and used for data plane encryption. It is replaced periodically and whenever the key server changes.
Replay protection: a window of 0 enforces strict ordering; a larger window tolerates reordering. 802.1AEcg-2017 added multiple transmit secure channels for strict replay protection where frames can be reordered.
Confidentiality offset: 0, 30 or 50 bytes of the frame can be left unencrypted (but still integrity protected) so intermediate devices can read headers. Offset 0 encrypts everything after the SecTAG and is the right default.

Policy modes

Mode	Behaviour	Use it for
Must-secure	Only EAPOL (EtherType 0x888E) passes unencrypted; other unprotected traffic is dropped	Any link where clear text is unacceptable: DCI, carrier circuits, uplinks
Should-secure	Encrypts if the peer negotiates MACsec, otherwise sends in clear text	Migration windows only, with an end date
Integrity only	Frames authenticated but not encrypted	Rare cases needing visibility on the wire; document the exception

Identity and NHI requirements

MACsec is a device identity system as much as an encryption system. Every switch, router and endpoint in a connectivity association holds a credential that proves it belongs, and those credentials are non-human identities. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Static CAK (pre-shared key): recommended in Juniper documentation for switch-to-switch and router links. The CAK is a shared secret: store it in a secrets vault, never in configuration templates in Git, give each link or pair its own CKN and CAK, and rotate using key chains with overlapping lifetimes. Cisco IOS XE key chains support aes-128-cmac and aes-256-cmac keys with lifetimes and roll over to the next key when one expires.
Dynamic CAK (802.1X EAP-TLS): each device authenticates with its own certificate through RADIUS and the CAK is derived per session. This removes shared secrets but makes the device certificate, its private key and the issuing CA critical. See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide and the Enterprise PKI Design and CA Hierarchy Guide.
Who can read keys: network automation accounts and configuration backup systems often hold CAKs in clear. Limit which service accounts can retrieve them and log every read.
Revocation and replacement: when a device is returned, lost or decommissioned, remove its CKN from peers or revoke its certificate; a pre-shared CAK on a discarded line card still works on any matching peer.
NAC alignment: switch-to-host MACsec sits on 802.1X port authentication. See the Network Access Control (NAC) Guide.

Implementation steps

Classify links. List every link leaving physically controlled space (DCI, carrier circuits, shared risers) and every high value internal link. Record hardware MACsec support per port, required cipher suite and line rate.
Check hardware and licences. MACsec is usually implemented in specific PHYs or line cards. Confirm port support, XPN support for 40 Gb/s and faster links, and any licence (see the Availability notes below).
Choose the key mode. Static CAK for infrastructure links where both ends are your devices; dynamic CAK with EAP-TLS where you already run 802.1X and PKI, or for switch-to-host.
Define a policy. Cipher suite (GCM-AES-256 or XPN variant where supported), confidentiality offset 0, replay window 0 unless reordering is expected, SAK rekey interval, key server priority per site, and must-secure.
Generate and store keys. Create random CAKs per link in a vault, with a key chain of at least two keys and overlapping lifetimes.
Pilot in should-secure. On a non-critical link, bring MKA up in should-secure, confirm the session reaches Secured and that encrypted counters increase on both ends, then switch to must-secure in a change window.
Plan WAN circuits with the carrier. Raise interface MTU to absorb the overhead (Cisco's WAN MACsec troubleshooting note cites about 40 bytes at Layer 2 and suggests planning up to 32 bytes of header overhead), confirm the carrier passes MACsec and EAPOL frames, and decide whether 802.1Q tags must stay in the clear (Cisco ClearTag) so the provider can classify the VLAN and CoS. Many deployments change the EAPOL destination address because carrier services can drop frames sent to the default 802.1X group address.
Roll out in waves. One site or link class at a time, with a tested rollback: revert the interface to the previous policy, or to should-secure, from saved configuration.
Automate rotation. Schedule CAK rotation through the key chain and SAK rekey by time or volume, and test a rotation on the pilot link before relying on it.

Vendor implementation notes

Platforms are listed alphabetically; order is not a ranking. Both examples are taken from the vendors' own documentation and illustrate where standard concepts show up in configuration.

Topic	Cisco (Catalyst 9300, IOS XE 17.9)	Juniper (Junos, EX, QFX and MX)
Key modes	MKA with pre-shared key chains or 802.1X EAP-TLS	Static CAK (pre-shared key) or dynamic CAK from 802.1X with RADIUS
Cipher suites	gcm-aes-128 (default), gcm-aes-256, gcm-aes-xpn-128, gcm-aes-xpn-256	128-bit and 256-bit suites, with and without XPN, depending on platform and line card
Link types	Switch-to-host (`macsec`) and switch-to-switch (`macsec network-link`); XPN on switch-to-switch only	Point-to-point switch and router links; VLAN tags stay in clear on logical interface MACsec
Availability	GCM-AES-256 and XPN suites require a Network Advantage licence	A MACsec feature licence is required on EX and QFX switches, with some line card exceptions

Evidence and assessment

What to monitor

MKA session state per link: Init, Pending, Not Secured and Secured. Alert on any must-secure link leaving Secured, and on should-secure links that stay unsecured.
Peer liveness: MKA heartbeats default to 2 seconds in Cisco's description, with a peer dropped after three missed heartbeats; repeated keepalive timeouts indicate carrier or MTU problems.
Counters: encrypted and decrypted packets on both ends, frames dropped for integrity failure, replay drops and late frames. A rise in integrity failures on a carrier circuit can indicate tampering or a faulty optic.
Key events: SAK rekeys, key server changes, CAK rollover and expiry, and cipher mismatch messages.
Configuration drift: interfaces where MACsec was removed or policy changed to should-secure outside a change.

Metrics

Percentage of in-scope links in must-secure and Secured state (target 100 percent).
CAKs older than the rotation policy (target zero).
Links using shared CAKs across more than one pair.
Unplanned MKA session drops per month per link class.
Time to restore a secured session after a carrier event.

Audit evidence

Auditors will ask for the link inventory with classification, the MACsec policy (cipher suite, offset, mode), session state exports showing Secured with the cipher in use, the key management procedure including where CAKs are stored and who can read them, rotation records, and exception records for any link left in should-secure or integrity-only mode.

Mapping to other frameworks

Framework	Reference	How MACsec contributes
NIST SP 800-53 Rev 5	SC-8 Transmission Confidentiality and Integrity; SC-8(1) Cryptographic Protection	Encrypts and authenticates frames on in-scope links
NIST SP 800-53 Rev 5	SC-12 Cryptographic Key Establishment and Management; SC-13 Cryptographic Protection	MKA key distribution, CAK management, approved GCM cipher suites
NIST SP 800-53 Rev 5	IA-3 Device Identification and Authentication	Peers must hold the CAK or a valid certificate to join
NIST CSF 2.0	PR.DS-02; PR.AA-01	Protects data in transit; device credentials are managed identities
CIS Controls v8.1	Safeguard 3.10 Encrypt Sensitive Data in Transit	Link layer encryption for sensitive flows
ISO/IEC 27001:2022	A.8.20 Networks security; A.8.24 Use of cryptography	Network protection and cryptographic policy for links
MITRE ATT&CK	T1040 Network Sniffing; T1557 Adversary-in-the-Middle; T1200 Hardware Additions	Defeats passive taps and inline devices on protected links; an unauthorised device cannot join without the CAK

For the wider network design context, see the Network Security Guide and the Data Centre Network Fabric Security guide.

Common pitfalls

Should-secure left in production: a peer misconfiguration silently drops the link to clear text and nothing alerts.
One CAK for the whole estate: a single leaked key from a configuration backup exposes every link, and rotation becomes a fleet-wide outage risk.
Keys in configuration management: CAKs committed to templates or stored in clear in backup systems, readable by broad automation accounts.
No overlap in key lifetimes: the active key expires before the next is valid, MKA cannot roll over and the link goes down.
Ignoring MTU and carrier behaviour: MKA stays in Init or Pending because MKPDUs are dropped in transit or frames exceed the carrier MTU.
Assuming end-to-end protection: traffic is clear inside each switch and on any hop without MACsec; sensitive application data still needs TLS.

Practitioner checklist

Inventory and classify every link leaving physically controlled space, with MACsec capability per port.
Use must-secure on every in-scope link and alert when a session leaves Secured.
Prefer GCM-AES-256, and XPN suites on 40 Gb/s and faster links where hardware supports them.
Set confidentiality offset 0 unless a documented exception exists.
Generate unique CAKs per link or pair, store them in a vault, and restrict which service accounts can read them.
Configure key chains with overlapping lifetimes and test rotation on a pilot link.
Agree MTU, EAPOL handling and VLAN tag treatment with carriers before ordering WAN MACsec.
Remove CKNs or revoke certificates when devices are decommissioned or returned.
Export session state and rotation records quarterly as audit evidence.

MACsec: Layer 2 Encryption for Enterprise, Data Centre and WAN Links