MACsec (IEEE 802.1AE) Explained: Link Layer Encryption and MKA

MACsec is the IEEE 802.1AE standard for encrypting and authenticating Ethernet frames between two directly connected devices, such as a server and its switch or two switches across a fibre. It protects every frame on that link, including ARP, DHCP and routing traffic, but only for one hop: each MACsec device decrypts, forwards and encrypts again. Keys come from the MACsec Key Agreement protocol (MKA), defined in IEEE 802.1X.

This post goes one level deeper than our 802.1X and EAP explainer, which covers port authentication, and our IKEv2 and IPsec explainer, which covers encryption at the IP layer. Here we stay on the link layer: what is inside a MACsec frame, the four GCM-AES cipher suites and why extended packet numbering exists, how MKA turns one shared key into rotating session keys, where MACsec is used, what it costs in MTU and throughput, where it stops protecting you, and a Linux setup with iproute2, wpa_supplicant, NetworkManager and systemd-networkd that you can verify with counters and a packet capture. If your worry is someone spoofing neighbours on a shared LAN, read ARP and IPv6 Neighbor Discovery explained alongside this one.

Key takeaways

• IEEE 802.1AE-2018 is the current MACsec standard. The IEEE board approved it on 27 September 2018 and published it on 26 December 2018. It replaced 802.1AE-2006 and folded in three amendments: GCM-AES-256 (2011), extended packet numbering (2013) and Ethernet Data Encryption devices (2017). A corrigendum followed in 2020 and a MAC privacy amendment, 802.1AEdk, in 2023.
• The IEEE abstract says MACsec "provides connectionless user data confidentiality, frame data integrity, and data origin authenticity." Confidentiality is optional: MACsec can run in integrity only mode, where frames are authenticated but readable.
• Every protected frame carries a Security TAG (SecTAG) after the source MAC address, with EtherType 0x88E5, and a 16 byte Integrity Check Value (ICV) at the end. With the optional Secure Channel Identifier included, MACsec adds 32 bytes to each frame.
• Four cipher suites are defined today: GCM-AES-128 (the mandatory default), GCM-AES-256, and the extended packet number variants GCM-AES-XPN-128 and GCM-AES-XPN-256. An amendment for an Ascon-AEAD128 suite, P802.1AEef, is in development.
• A 32 bit packet number can run out in well under a minute on a 100 Gb/s link carrying small frames, which forces a key change. XPN widens the packet number to 64 bits so this stops being a practical limit.
• MKA, specified in IEEE 802.1X-2010 and now 802.1X-2020, starts from a Connectivity Association Key (CAK), either pre-shared or derived from an EAP exchange. It derives two keys from the CAK to protect its own messages, elects a key server, and the key server distributes the Secure Association Key (SAK) that actually encrypts traffic, wrapped with AES Key Wrap.
• MACsec does not protect traffic inside a switch, beyond a router, or across a path that strips the tag. Endpoints and every MACsec hop see cleartext. Use it alongside TLS or IPsec, not instead of them.
• On Linux, ip link add ... type macsec and ip macsec set static keys for testing. The iproute2 manual itself says it is "wrong to just configure the keys statically and assume them to work indefinitely" and points to 802.1X key management as implemented by wpa_supplicant.

What MACsec is and which standards define it

MACsec sits at layer 2, between the Ethernet MAC and everything above it. The IEEE describes it as a way to secure all or part of a network "transparently to peer protocol entities that use the MAC Service." In plain terms, IP, ARP, LLDP, routing protocols and anything else that rides on Ethernet keep working unchanged above a MACsec port; they just stop being readable or forgeable on the wire.

Two standards do the work together. IEEE 802.1AE defines the frame format, the cipher suites and how a MACsec entity (the SecY) protects and validates frames. IEEE 802.1X defines the MACsec Key Agreement protocol (MKA) that discovers peers and distributes keys, as well as the port based network access control that most people know 802.1X for. The 802.1X-2020 abstract says it specifies "the media access method independent protocols that are used to discover and establish the security associations used by IEEE 802.1AE MAC Security."

Timeline of IEEE 802.1AE, 802.1X and their amendments

Dates below are the IEEE SA Standards Board approval dates and publication dates shown on each standard's IEEE SA page.

The IEEE 802.1 Security Task Group lists the 802.1AE and 802.1X revisions and the Ascon amendment as active projects. Two practical notes follow from the table. First, the 802.1AE-2018 and 802.1X-2020 PDFs are offered at no cost through the IEEE GET program, so you can read the real text rather than summaries. Second, if a device data sheet says "802.1AE-2006 compliant", it may predate GCM-AES-256 and XPN, so check the cipher suite list rather than the year.

What MACsec protects, hop by hop, and how it differs from IPsec and TLS

A MACsec link is a point to point relationship between two (or, on a shared medium, more) MACsec entities that share keys. The group of entities that share a CAK is a Connectivity Association (CA). Each sender has a Secure Channel (SC), identified by a 64 bit Secure Channel Identifier (SCI), and each channel uses a sequence of Secure Associations (SAs), each with its own key, the SAK. A two bit Association Number (AN) in every frame says which of up to four SAs the frame uses, so a sender can move to a new key while the receiver still accepts the old one for a moment.

What gets protected:

• Confidentiality of the frame's payload, from the byte after the SecTAG to the end of the user data, when encryption is on. The destination and source MAC addresses stay in the clear so switches can forward the frame.
• Integrity and origin authenticity of the whole frame, including the MAC addresses and the SecTAG, through the ICV. A forged or altered frame fails validation and is dropped (in strict mode) and counted.
• Replay protection through the packet number (PN), which increases with every frame. A receiver drops frames whose PN is lower than it expects, minus an optional replay window.

What it does not protect: the frame inside each MACsec device. MACsec is hop by hop. A switch that runs MACsec on both its ports decrypts on ingress, forwards in cleartext through its own silicon, and encrypts again on egress with a different key. That is a design choice, not a flaw: it lets bridges do normal layer 2 forwarding, VLAN tagging and quality of service on the cleartext frame.

MACsec compared with IPsec and TLS

RFC 4301 describes IPsec as providing security services "at the IP layer", and RFC 8446 says the primary goal of TLS is "a secure channel between two communicating peers." Neither sees ARP, LLDP or a routing protocol's hello packets on the wire. MACsec does, which is why it is the tool people reach for when the threat is a tap on a fibre, a rogue device on a patch panel, or a carrier in the middle of a leased Ethernet circuit. The trade is that it only covers the link you configure.

Inside the frame: SecTAG, ICV and the cipher suites

SecTAG layout

The SecTAG goes immediately after the source MAC address, where an 802.1Q VLAN tag would normally sit. The Linux kernel's macsec_eth_header structure, which follows the clause of 802.1AE that defines the tag, lays it out like this:

So the SecTAG is 8 bytes without the SCI and 16 bytes with it. The ICV adds 16 bytes at the end of the frame for the standard GCM suites. The kernel defines MACSEC_STD_ICV_LEN as 16 and, for testing, accepts ICV lengths from 8 to 32 bytes; use 16 unless you are matching something unusual.

The E and C bits together mean "this frame is encrypted." If E is clear, the frame is integrity only: the payload travels in the clear but any change to it fails the ICV check. The SC bit says whether the SCI is in the tag. On a point to point link the receiver can work out the sender's SCI without it, which saves 8 bytes per frame; with more than one possible sender it must be present. Linux defaults to sending the SCI (DEFAULT_SEND_SCI true in macsec.c), and NetworkManager's send-sci setting also defaults to true.

How the nonce is built, and why the packet number matters so much

All four standard suites use AES in Galois/Counter Mode (GCM). NIST SP 800-38D, which defines GCM, requires that the probability of the encryption function being invoked with the same IV and the same key on two different inputs be no greater than 2 to the power of minus 32. In practice that means one rule: never reuse an IV under a key.

MACsec builds the 96 bit IV deterministically. For GCM-AES-128 and GCM-AES-256, the kernel's macsec_fill_iv concatenates the 64 bit SCI with the 32 bit PN. For the XPN suites, macsec_fill_iv_xpn takes a 32 bit Short SCI (SSCI) and the full 64 bit PN and XORs them with a 96 bit salt. Because the PN increases with every frame, the IV never repeats while the key stays the same, as long as the PN never wraps. When the PN approaches its limit, the SA must be replaced with a new key. The iproute2 manual puts it bluntly: the same key must not be used with the same IV more than once, so "keys must be frequently regenerated and distributed."

The cipher suites

The 802.1AEbn abstract describes GCM-AES-256 as an option "in addition to the existing mandatory to implement Default Cipher Suite, GCM-AES-128." The 802.1AEbw abstract describes XPN as using a 64 bit PN "to allow more than 2^32 MACsec protected frames to be sent with a single Secure Association Key." The Ascon project would bring a lightweight authenticated cipher, standardised by NIST in SP 800-232 (published August 2025), to MACsec, which is aimed at constrained devices.

Worked example 1: how fast a 32 bit packet number runs out

The worst case for PN consumption is a link full of the smallest frames. A 64 byte Ethernet frame becomes 96 bytes with a 16 byte SecTAG and 16 byte ICV. On the wire every frame also costs 8 bytes of preamble and 12 bytes of inter frame gap, so each protected minimum frame takes 116 byte times, or 928 bits.

The last column comes from the open source hostap code behind wpa_supplicant, which defines PENDING_PN_EXHAUSTION as 0xC0000000 and has the key server start a new SAK once the lowest PN in use passes it. At 400 Gb/s that is a fresh key roughly every seven and a half seconds under a worst case load. Every rekey is a distribution step that can fail, which is exactly why XPN exists.

With a 64 bit PN the same 400 Gb/s worst case takes 2^64 / 431.03 million, about 4.28 times 10 to the 10 seconds, which is roughly 1,356 years. At that point the key is replaced for policy reasons, not because the counter is running out.

Worked example 2: overhead on large and small frames

Take a full size frame carrying a 1,500 byte IP packet. Without MACsec it is 1,518 bytes plus 20 bytes of preamble and gap, so 1,538 byte times on the wire. MACsec adds 32 bytes (with SCI), so the protected frame costs 1,570 byte times. The goodput cost is 32 / 1,570, about 2 percent.

Now take the 64 byte minimum frame from the first example. It grows from 84 to 116 byte times, a 38 percent increase in wire time for the same payload. Links that carry mostly small packets, such as voice, market data or storage acknowledgements, feel MACsec overhead far more than bulk transfer links. Dropping the SCI on point to point links saves 8 of those 32 bytes.

How MKA derives and rotates keys

MKA is the control plane. Its messages, MACsec Key Agreement PDUs (MKPDUs), are EAPOL frames: EtherType 0x888E, registered to IEEE Std 802.1X, port based network access control. The hostap implementation sends them to the PAE group address 01-80-C2-00-00-03. MKPDUs themselves are not encrypted by MACsec; they carry their own integrity check and they wrap any key material they contain.

The key hierarchy

The MKPDU integrity check uses AES-CMAC (RFC 4493) with the ICK. The KDF is also built on AES-CMAC. This means that everything in MKA traces back to the CAK: anyone who holds it can join the CA, become a peer and receive SAKs. Protect the CAK like a private key.

What happens on the wire, step by step

1. Each participant starts announcing. It sends MKPDUs carrying its SCI, its MI, its MN, its key server priority and the CKN. Peers that hold the same CKN and can verify the ICV become "potential" peers.
2. Liveness is confirmed. When a participant sees its own MI and a recent MN echoed in a peer's MKPDU, that peer moves to the live peer list. The hostap code uses a 2 second MKA hello time and a 6 second MKA life time, so a peer that stays silent for 6 seconds is dropped. It also defines a shorter 0.5 second bounded hello time.
3. A key server is elected. The participant with the numerically lowest key server priority wins; ties are broken by the lowest SCI. In hostap's compare_priorities, a lower priority value wins and the MAC address breaks ties. The wpa_supplicant configuration notes say the peer "with lower priority will become the key server," meaning the lower number.
4. The key server picks the cipher suite and confidentiality offset, within what every live peer has said it supports, and decides whether MACsec is used at all.
5. The key server generates a SAK, wraps it with the KEK and distributes it in an MKPDU, together with the Association Number it should use.
6. Peers install the SAK for receive first, then report that they have it. When every live peer has installed it, the key server starts transmitting with the new SA and peers follow.
7. The old SA retires. The hostap code keeps it for a 3 second SAK retire time, so in flight frames on the old AN are still accepted.
8. Rekeying repeats when a peer joins or leaves, when the PN in use crosses the exhaustion threshold, or on a configured timer if your platform offers one.

Pre-shared CAK versus EAP

In both modes the SAK is still rotated by MKA, so the long lived CAK never encrypts data frames directly. The difference is how the root of trust gets onto the device and how you replace it.

Should secure versus must secure

The hostap configuration describes macsec_policy=1 as "Should secure, accept key server's advice to determine whether to use a secure session or not." Network platforms that implement MKA generally have to make the same choice: fall back to unprotected traffic if MKA fails, or block traffic until MKA succeeds. The fallback mode is convenient during roll out and dangerous afterwards: anyone who can make MKA fail, for example by dropping MKPDUs, gets a cleartext link. Decide per link which behaviour you want, and alert on any link running unprotected.

Where MACsec is used

Switch to switch and router to router links

This is the most common deployment: uplinks between access, distribution and core switches, or between routers in the same building, protected with a pre-shared CAK. The attack MACsec defends against here is physical: an optical tap, a patch panel port, or an unused fibre pair that someone splices into. Because MACsec covers every frame, it protects routing protocol hellos and LLDP as well as user traffic.

Data centre interconnect and leased Ethernet

When two sites are joined by dark fibre or a wavelength, MACsec between the edge devices at each end covers everything crossing the span. When the circuit is a carrier Ethernet service instead, the carrier's switches sit in the middle and may need to see a VLAN tag to deliver the service. The 802.1AEcg amendment, now part of 802.1AE-2018, specified Ethernet Data Encryption devices, which its abstract describes as two port bridges that use MACsec "to provide secure connectivity for attached customer bridges, or for attached provider bridges," and that may let those bridges keep using a VLAN identifier in transmitted frames. Confirm with your provider which tags their service needs to see before you enable MACsec across it.

Host to switch on access ports

Combined with 802.1X, MACsec can encrypt the cable between a desktop or server and its access switch. The EAP authentication proves who the device is, and the CAK derived from that exchange protects the link. It is less common than uplink MACsec because every endpoint needs a capable NIC or a software implementation, plus supplicant configuration.

Inside the data centre fabric

Some operators turn on MACsec on every server to top of rack link, often to satisfy a requirement that all data in transit is encrypted including traffic that never leaves the building. The IEEE 802.1 working group also has an active amendment, P802.1Qdt, that includes MACsec protection of Priority based Flow Control frames, which matters in lossless storage and AI training fabrics where PFC pause frames are control traffic worth authenticating.

Cars and other in-vehicle Ethernet

Automotive Ethernet has moved from cameras and infotainment into the main vehicle network, where a forged frame could reach a safety relevant controller. The OPEN Alliance, the industry group behind automotive Ethernet physical layers, lists an "Automotive MACsec Specification" and an "Automotive MKA Specification" among its published specifications. Check those specifications for how keys are provisioned in a vehicle; frame overhead and per frame latency also matter more there than in an office network.

Integrity only deployments

Some networks, particularly where cleartext inspection on the link is required for troubleshooting or regulation, use MACsec with encryption off. Frames are authenticated, so injection and modification fail, but the payload is readable. wpa_supplicant exposes this as macsec_integ_only=1; iproute2 as encrypt off.

Performance, MTU and hardware offload

MTU: the 32 byte problem

MACsec makes every frame up to 32 bytes longer. If the physical interface MTU stays at 1,500 bytes, the Linux kernel sets the MACsec interface MTU lower. The kernel code computes it as the parent MTU minus the ICV length minus the SecTAG length with SCI: 1,500 minus 16 minus 16, so 1,468 bytes. You have two choices:

On switch to switch links the usual answer is to raise the physical MTU, because those links already carry jumbo frames in most data centres. On host links where you cannot change the switch, accept the smaller inner MTU and check that applications cope. The kernel's macsec_change_mtu refuses an inner MTU that would not fit inside the parent with the overhead added, and its transmit path counts frames that would not fit as OutPktsTooLong.

Hardware offload

MACsec was designed for line rate hardware. GCM is parallel and the per frame work is fixed, so NICs, PHYs and switch ASICs implement it in the data path. Linux supports three placements for the crypto through the offload option in iproute2 (off, phy, mac), and NetworkManager and wpa_supplicant expose the same three values. Offload is off by default in all three tools. NetworkManager documents that requesting phy or mac on hardware that cannot do it makes the connection fail rather than silently falling back.

Software MACsec in the Linux kernel uses the kernel crypto API, so its throughput depends on the CPU's AES and carry-less multiply instructions. It is fine for labs, low rate links and many server uplinks, but test it at your real packet rate before you rely on it at tens of gigabits.

Latency

Hardware MACsec adds a small, fixed delay per frame inside the PHY or MAC. For most networks this is invisible. For time sensitive networks, check whether the PHY timestamps frames before or after the MACsec block, because that changes PTP accuracy; our PTP explainer covers why the timestamping point matters.

The limits of MACsec

• Cleartext inside every hop. A compromised switch, a mirror port on that switch, or a management plane that can configure SPAN sessions sees everything. MACsec protects the cable, not the box.
• No protection past layer 3. At the first router the frame is decrypted, the IP packet is routed and a new frame is built. If the next link has no MACsec, the traffic is in the clear there.
• Bridges in the path. A switch in the middle that does not do MACsec will usually still forward MACsec frames between two MACsec peers, because the MAC addresses are in the clear. But MKPDUs go to a reserved group address that standard bridges filter by default, so MKA between hosts across a non-MACsec switch often fails unless that switch is configured to forward EAPOL. Know which hop terminates which session.
• Metadata stays visible. Without 802.1AEdk privacy protection, an observer still sees source and destination MAC addresses, frame sizes and timing. The 802.1AEdk abstract says its privacy encapsulation is there to hide addresses and "reduce any correlation between observable frame sizes and transmission timing." Support for it is far less common than for base MACsec.
• Replay window trade offs. A replay window greater than zero lets reordered frames through, which some multipath or QoS heavy links need. It also lets an attacker replay a frame whose PN is within the window and that has not been seen yet. wpa_supplicant defaults to replay protection off (macsec_replay_protect=0) and a window of zero when it is on; turn it on explicitly.
• Validation mode. Linux supports strict, check and disabled. Only strict drops frames that fail validation. check counts failures but delivers the frames, which is useful for a migration and dangerous to leave on.
• Static keys and PN exhaustion. With static SAs configured through iproute2 or systemd-networkd there is no rekeying. When the PN runs out, the link stops, or worse, someone resets the PN with the same key and reuses IVs.
• Fallback to cleartext. As described above, should secure modes keep traffic flowing if MKA fails. That is an availability choice that undoes the security if you never notice.

How to set up MACsec on Linux, step by step

The steps below use two Linux hosts, A and B, cabled directly or through a switch that forwards EAPOL. Use a dedicated test interface. Warning: turning MACsec on changes which frames the parent interface accepts. Do not configure it on the interface you are using to manage the host, and confirm the interface name before each block.

Step 1: check the interface, kernel module and tools

# Confirm which interface you are about to change. It must NOT be your management link.
ip -br link show
ip -br addr show
IF=enp2s0   # set this to your test interface after checking the output above

# Kernel support and tool versions
modinfo macsec | head -n 3
ip -V
wpa_supplicant -v
ethtool -k "$IF" | grep -i macsec   # shows offload features if the NIC exposes any

If modinfo macsec finds nothing, your kernel was built without CONFIG_MACSEC. For wpa_supplicant, MKA needs a build with CONFIG_MACSEC=y and the Linux MACsec driver interface CONFIG_DRIVER_MACSEC_LINUX=y; both are enabled in the upstream defconfig.

Step 2 (lab only): static keys with iproute2

This is the fastest way to see MACsec frames on the wire, and it is not a production configuration. Generate one 128 bit SAK per direction and note each host's MAC address.

# On each host
openssl rand -hex 16          # one key per direction; copy the values carefully
ip -br link show "$IF"        # note this host's MAC address

# Host A (MAC aa:aa:aa:aa:aa:aa), peer B (MAC bb:bb:bb:bb:bb:bb)
ip link add link "$IF" macsec0 type macsec port 1 encrypt on replay on window 0 validate strict
ip macsec add macsec0 tx sa 0 pn 1 on key 01 KEY_A_TO_B_32_HEX_DIGITS
ip macsec add macsec0 rx port 1 address bb:bb:bb:bb:bb:bb
ip macsec add macsec0 rx port 1 address bb:bb:bb:bb:bb:bb sa 0 pn 1 on key 02 KEY_B_TO_A_32_HEX_DIGITS
ip link set macsec0 up
ip addr add 10.99.0.1/24 dev macsec0

# Host B mirrors it: its tx key is KEY_B_TO_A, its rx channel is A's MAC with KEY_A_TO_B
ip link add link "$IF" macsec0 type macsec port 1 encrypt on replay on window 0 validate strict
ip macsec add macsec0 tx sa 0 pn 1 on key 02 KEY_B_TO_A_32_HEX_DIGITS
ip macsec add macsec0 rx port 1 address aa:aa:aa:aa:aa:aa
ip macsec add macsec0 rx port 1 address aa:aa:aa:aa:aa:aa sa 0 pn 1 on key 01 KEY_A_TO_B_32_HEX_DIGITS
ip link set macsec0 up
ip addr add 10.99.0.2/24 dev macsec0

ping -c 3 10.99.0.2   # from A

Note encrypt on. The kernel's default is DEFAULT_ENCRYPT false, so without it you get integrity only MACsec. For XPN, the man page shows cipher gcm-aes-xpn-128 on the link and xpn, salt and ssci on each SA instead of pn. Remove the lab setup with ip link del macsec0 before you move on.

Step 3: MKA with a pre-shared CAK in wpa_supplicant

Generate a CAK and a CKN once and copy them to both hosts through a secure channel.

openssl rand -hex 16   # CAK: 32 hex digits (128 bit); 64 hex digits for a 256 bit CAK
openssl rand -hex 32   # CKN: 2 to 64 hex digits
install -d -m 0700 /etc/wpa_supplicant

Write /etc/wpa_supplicant/macsec-enp2s0.conf with mode 0600 on both hosts:

ctrl_interface=/run/wpa_supplicant
eapol_version=3
ap_scan=0

network={
    key_mgmt=NONE
    eapol_flags=0
    macsec_policy=1
    macsec_integ_only=0
    macsec_replay_protect=1
    macsec_replay_window=0
    macsec_offload=0
    macsec_port=1
    mka_cak=REPLACE_WITH_32_OR_64_HEX_DIGITS
    mka_ckn=REPLACE_WITH_CKN_HEX
    mka_priority=16
}

Every option above is documented in the upstream wpa_supplicant.conf: eapol_version=3 is required for MACsec, ap_scan=0 is the mode for wired drivers, eapol_flags=0 is required for wired authentication, and mka_priority defaults to 255. Give the host you want as key server the lower number (here 16 on A, for example 32 on B).

chmod 600 /etc/wpa_supplicant/macsec-enp2s0.conf
wpa_supplicant -i "$IF" -D macsec_linux -c /etc/wpa_supplicant/macsec-enp2s0.conf -d

Run it in the foreground with -d the first time so you can watch the peer become live, the key server election and the SAK install. wpa_supplicant creates the MACsec interface on top of the parent; find its name with ip -d link show type macsec, then put your IP address on that interface, not on the parent. Once it works, run it from your distribution's wpa_supplicant service unit for that interface.

One detail worth knowing: the hostap MKA code we read lists GCM-AES-128 and GCM-AES-256 in its cipher suite table. If you need the XPN suites end to end with MKA, confirm your supplicant and your switch both negotiate them.

Step 4: the same with NetworkManager

NetworkManager drives wpa_supplicant for you. Its documented macsec settings include parent, mode, mka-cak, mka-ckn, encrypt (default true), port (default 1), send-sci (default true), validation and offload.

nmcli connection add type macsec con-name macsec-lab ifname macsec0 \
  macsec.parent "$IF" macsec.mode psk \
  macsec.mka-cak REPLACE_WITH_32_HEX_DIGITS macsec.mka-ckn REPLACE_WITH_CKN_HEX \
  macsec.encrypt yes macsec.validation strict \
  ipv4.method manual ipv4.addresses 10.99.0.1/24
nmcli connection up macsec-lab

NetworkManager's documentation says the CAK must be 32 hexadecimal characters, so this path supports 128 bit CAKs. Store it with the secret flags your environment uses rather than leaving it readable in a profile that gets backed up.

Step 5: systemd-networkd, static keys only

systemd-networkd has supported Kind=macsec netdevs since version 243, with [MACsec], [MACsecReceiveChannel], [MACsecTransmitAssociation] and [MACsecReceiveAssociation] sections. Its documented keys take a 128 bit key per association, and there is no MKA option in those sections, so it suits static or externally managed keys.

# /etc/systemd/network/30-macsec0.netdev
[NetDev]
Name=macsec0
Kind=macsec

[MACsec]
Port=1
Encrypt=yes

[MACsecReceiveChannel]
Port=1
MACAddress=bb:bb:bb:bb:bb:bb

[MACsecTransmitAssociation]
KeyId=1
KeyFile=/etc/systemd/network/macsec0-tx.key
PacketNumber=1
UseForEncoding=yes

[MACsecReceiveAssociation]
Port=1
MACAddress=bb:bb:bb:bb:bb:bb
KeyId=2
KeyFile=/etc/systemd/network/macsec0-rx.key
PacketNumber=1
Activate=yes

The documentation asks for key files readable by the systemd-network user, for example owned by root:systemd-network with mode 0640. Attach the netdev to the parent with MACsec=macsec0 in the parent's .network file. Treat this as a static key setup with the PN exhaustion and rotation problems described above.

How to verify MACsec is working and monitor for failures

Check the configuration

ip -d link show macsec0     # cipher suite, ICV length, encrypt, validate, replay, window, offload
ip macsec show macsec0      # TX SC and SAs, RX SCs and SAs, which AN is in use, current PN

Look for encrypt on, validate strict, replay on, the expected cipher suite and one active receive channel per peer. With MKA you should see the SA association number change after each rekey.

Look at the wire

Capture on the parent interface, not on macsec0:

tcpdump -i "$IF" -nn -e -c 20 ether proto 0x88e5      # protected data frames
tcpdump -i "$IF" -nn -e -c 10 ether proto 0x888e      # MKPDUs (EAPOL)
tcpdump -i "$IF" -nn -e -c 20 'not ether proto 0x88e5 and not ether proto 0x888e'

The first capture should show steady traffic with EtherType 0x88E5. The third should be empty or close to it once everything rides the MACsec interface; if you see IP, ARP or LLDP in the clear on the parent, something is bypassing MACsec.

Read the counters

ip -s macsec show macsec0

The Linux implementation keeps the counters that 802.1AE defines. The ones worth alerting on:

A quick way to watch them during a change:

watch -n 5 "ip -s macsec show macsec0 | grep -E 'InPktsNotValid|InPktsLate|InPktsNotUsingSA|InPktsUnknownSCI|OutPktsTooLong'"

For ongoing monitoring, export the counters to whatever collects your interface statistics and alert on any increase in InPktsNotValid, on InPktsUnknownSCI, on links where MKA reports no live peer, and on any link that should be secured but is passing traffic unprotected. On switches, the same counters are usually available through the vendor's CLI, SNMP MIB or the 802.1AE and 802.1X YANG models, which the 802.1AEdk amendment and 802.1X-2020 cover.

Test failure on purpose

Before you trust the monitoring, break things in a lab: change one byte of the CAK on one side and confirm the peer drops out of the live list and your alert fires; unplug and replug the cable and time how long MKA takes to recover; and in a should secure configuration, block EAPOL on a test switch and confirm you notice the link falling back to cleartext.

Common mistakes

• Running static iproute2 keys in production. The man page calls it a debugging and testing tool. Without MKA nobody rotates the SAK, and on a fast link the PN runs out in minutes.
• Forgetting encrypt on. The Linux default is integrity only. Your link authenticates frames and carries them readable.
• Leaving validation at check after a migration. Failures are counted and delivered. Move to strict and confirm the counters stay flat.
• Leaving replay protection off. wpa_supplicant's default is off. Turn it on, and only widen the window if you measured reordering.
• Should secure everywhere, forever. Fallback to cleartext is a roll out aid. Pick must secure on links where an outage is better than an unprotected link, and alert on fallback where you keep it.
• Ignoring MTU. A 1,500 byte parent gives a 1,468 byte MACsec interface. Large frames get counted as OutPktsTooLong and dropped, and the symptom looks like a flaky application, not a crypto problem.
• One CAK for the whole estate. A pre-shared CAK on hundreds of links means one leak exposes all of them and nobody ever rotates it. Use distinct CAKs per link or per site, and keep them out of configuration backups and tickets.
• Assuming MACsec covers the path. It covers one hop. Check every hop between two endpoints, including the ones run by a carrier.
• Expecting MKA to cross a plain switch. MKPDUs go to a reserved group address that bridges filter by default. Host to host MACsec through an unconfigured switch fails in a way that looks like a key mismatch.
• Not testing hardware offload behaviour. Some NICs and PHYs support only certain cipher suites or SCI settings in hardware. NetworkManager fails the connection if offload is requested but unavailable; other tools may need you to check.
• Treating MACsec as a replacement for TLS. Inside every switch and at every endpoint the data is cleartext. Applications still need end to end encryption and authentication.

FAQ

What is the difference between MACsec and IPsec?

MACsec encrypts Ethernet frames on one link at layer 2 and protects all protocols on that link, including ARP and routing protocols. IPsec encrypts IP packets at layer 3 and can protect traffic across routers between two hosts or gateways. MACsec is usually done at line rate in hardware; IPsec reaches further but only covers IP traffic that matches its policy.

Does MACsec encrypt the MAC addresses?

No, not in base 802.1AE. The destination and source MAC addresses stay in the clear so switches can forward frames, although the ICV authenticates them. The 802.1AEdk-2023 amendment adds a MAC privacy encapsulation that hides them, but support for it is much rarer.

What is the MACsec EtherType?

0x88E5, registered in the IANA IEEE 802 numbers registry to IEEE Std 802.1AE. MKA messages use the EAPOL EtherType 0x888E.

How much overhead does MACsec add?

Up to 32 bytes per frame: a 16 byte SecTAG including the optional 8 byte SCI, plus a 16 byte ICV. Without the SCI it is 24 bytes. That is about 2 percent on full size frames and up to 38 percent extra wire time on minimum size frames.

What is the difference between a CAK and a SAK?

The CAK is the long term key shared by members of a connectivity association, either configured or derived from EAP. MKA derives two keys from it to protect its own messages. The SAK is the short lived key that actually encrypts data frames; the elected key server generates it, wraps it and distributes it, and it is replaced on rekey.

What is MACsec XPN and when do I need it?

XPN, extended packet numbering, uses a 64 bit packet number instead of 32 bits, through the GCM-AES-XPN-128 and GCM-AES-XPN-256 suites added in 802.1AEbw-2013. On links of 40 Gb/s and up a 32 bit PN can run out in under a minute with small frames, forcing constant rekeys, so XPN is the normal choice for high speed links.

Can MACsec work through a switch that does not support it?

Data frames usually pass, because the MAC addresses are in the clear. MKA often does not, because MKPDUs are sent to a reserved group address that standard bridges do not forward unless configured to. Many deployments therefore run MACsec only between directly connected devices.

Is MACsec quantum safe?

The data encryption is AES-GCM with 128 or 256 bit keys, a symmetric scheme. With a pre-shared CAK there is no public key exchange in MKA at all. When the CAK comes from EAP, the strength depends on the EAP method and the certificates it uses, which is where post quantum questions apply.

Does MACsec slow down my network?

Hardware MACsec in a NIC, PHY or switch runs at line rate with a small fixed latency. The main costs are the extra bytes per frame and the MTU change. Software MACsec in the Linux kernel depends on the CPU and should be load tested at your real packet rate.

Can I use MACsec on Wi-Fi?

MACsec is defined for IEEE 802 LANs in general, but Wi-Fi already has its own link encryption in 802.11 (WPA2 and WPA3), so MACsec is used on wired Ethernet in practice. 802.1X itself, the EAP framework, is shared between wired and wireless networks.

Where Safeguard fits

Safeguard does not configure switches, manage NICs, scan firmware or monitor MACsec counters, and it will not tell you whether a link is encrypted. The fit is narrower and indirect. MACsec on Linux depends on ordinary open source software: the kernel's macsec driver, iproute2, wpa_supplicant (hostap), NetworkManager and systemd. Those packages ship inside the container images, appliance builds and golden images you deploy, and they receive security fixes like any other component. Safeguard can scan those images and their SBOMs, show which projects carry a given version of wpa_supplicant or iproute2, match them against known vulnerabilities, and open upgrade pull requests where you build the image yourself. For switch and NIC firmware, the fix still has to come from the hardware vendor.

Software supply chain hygiene still matters for a link layer protocol, because the code that negotiates MACsec keys is not inside the cable: wpa_supplicant, NetworkManager, iproute2 and the kernel ship as open source components in the images you rebuild and redeploy. The fit is indirect, and it covers only the software you build and ship, not switch or NIC firmware.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, image and remediation workflows, not link encryption or switch configuration. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at an appliance or host image that bundles wpa_supplicant, iproute2 and NetworkManager, the same scan lists the packages and versions inside it and their known vulnerabilities, so you know which images to rebuild when a supplicant advisory lands.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a dependency in a provisioning or network automation tool that writes MACsec configuration.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version, such as a specific wpa_supplicant release, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IEEE SA: IEEE 802.1AE-2018, Media Access Control (MAC) Security
• IEEE SA: IEEE 802.1AE-2006
• IEEE SA: IEEE 802.1AEbn-2011, GCM-AES-256 Cipher Suite
• IEEE SA: IEEE 802.1AEbw-2013, Extended Packet Numbering
• IEEE SA: IEEE 802.1AEcg-2017, Ethernet Data Encryption devices
• IEEE SA: IEEE 802.1AE-2018/Cor 1-2020, Tag Control Information Figure
• IEEE SA: IEEE 802.1AEdk-2023, MAC Privacy protection
• IEEE SA: P802.1AE revision project (PAR approved 10 September 2025)
• IEEE SA: P802.1AEef, Ascon Cipher Suite (PAR approved 10 December 2025)
• IEEE SA: IEEE 802.1X-2020, Port-Based Network Access Control
• IEEE SA: IEEE 802.1X-2010
• IEEE SA: IEEE 802.1Xbx-2014, MKA Extensions
• IEEE SA: IEEE 802.1X-2020/Cor 1-2026
• IEEE SA: P802.1X revision project (PAR approved 10 September 2025)
• IEEE 802.1 Working Group: Security Task Group
• IANA: IEEE 802 Numbers (EtherTypes 0x88E5 and 0x888E)
• ip-macsec(8), Linux manual page (iproute2)
• Linux kernel source: drivers/net/macsec.c
• Linux kernel source: include/net/macsec.h
• Linux kernel source: include/uapi/linux/if_macsec.h
• hostap: wpa_supplicant.conf (MACsec and MKA options)
• hostap: wpa_supplicant defconfig
• hostap: src/pae/ieee802_1x_kay.h (MKA timers)
• hostap: src/pae/ieee802_1x_kay.c (key server election, SAK distribution)
• hostap: src/pae/ieee802_1x_key.c (MKA key derivation)
• NetworkManager reference manual: macsec settings
• systemd.netdev(5): MACsec sections
• NIST SP 800-38D: Galois/Counter Mode (GCM) and GMAC, November 2007
• NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards, August 2025
• RFC 4301: Security Architecture for the Internet Protocol, December 2005
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, August 2018
• RFC 3748: Extensible Authentication Protocol (EAP), June 2004
• RFC 5247: EAP Key Management Framework, August 2008
• RFC 3394: AES Key Wrap Algorithm, September 2002
• RFC 4493: The AES-CMAC Algorithm, June 2006
• OPEN Alliance: automotive Ethernet specifications

Last reviewed: 23 October 2026. MACsec and 802.1X are both under revision at the IEEE, and Linux tool options change between releases; check the pages above for the version you actually run.