MACsec Explained: 802.1AE Link Encryption

Almost every security control on a network protects traffic at Layer 3 and above. IPsec encrypts IP payloads, TLS encrypts sessions, and VPNs tunnel across untrusted networks. But all of them assume the Layer 2 link underneath is just a wire that faithfully carries frames. MACsec breaks that assumption in the useful direction: it encrypts and authenticates every single Ethernet frame on the link itself, at Layer 2, so an attacker who physically taps the cable sees nothing but ciphertext.

This article explains MACsec (IEEE 802.1AE), how MKA distributes the keys, and where it fits. It extends the Infrastructure Security cluster guide.

A Platform Note, Up Front

This site's rule is that every capture is real. MACsec is one of the few features that cannot be demonstrated on the virtual platforms in the lab, and the honest thing is to say so and explain why.

SW1(config)# interface Ethernet0/0
SW1(config-if)#  macsec
                 ^
% Invalid input detected at '^' marker.

The IOL-L2 switch (and IOL-XE router) reject the interface-level macsec command outright. Interestingly, the key chain X macsec global command is accepted, which shows the software has partial awareness, but the data-plane encryption is not implemented, because MACsec encryption happens in dedicated hardware in the PHY, and a virtual switch has no such silicon.

That is not a limitation of this lab so much as a fact about MACsec: it is a hardware feature. Real MACsec runs on Catalyst 9000 series (9200/9300/9500), Catalyst IE industrial switches, ASR 900/1000, and Nexus platforms with MACsec-capable line cards. If you need to lab it, that is the hardware. What follows is the concept, the standard, and honest deployment guidance, with no fabricated MKA session output.

What MACsec Actually Does

MACsec operates hop by hop between two directly connected devices (switch-to-switch, or host-to-switch). On each link it provides:

The frame gets two new pieces: a SecTAG (a header, after the source MAC, carrying the association number and packet number) and an ICV (a trailer, the cryptographic integrity value). The original source and destination MACs stay in the clear so switches can still forward, but everything else, including the EtherType and the entire payload, is protected.

Because it runs in PHY hardware, MACsec adds essentially no latency and operates at line rate. This is the reason it is a hardware feature and the reason it cannot be virtualized: doing AES-GCM on every frame at 100 Gbps in software is not feasible, so it is offloaded to the interface silicon.

MKA: How the Keys Get There

Encryption is easy once both ends share a key. The hard part is agreeing on the key securely, and that is the MACsec Key Agreement protocol (MKA, defined in 802.1X-2010).

Two ways to establish the initial trust:

From that pre-shared or EAP-derived CAK, MKA elects a key server, which generates the actual encryption key (the SAK, Secure Association Key), distributes it to the peers, and rotates it periodically without dropping traffic. That rotation is why MKA exists rather than just configuring a static key: session keys change regularly, limiting the value of any single compromised key. The pre-shared-key path uses a key chain (the same key chain X macsec construct the IOL software half-accepted), and integrates with the RADIUS infrastructure from the AAA article for the EAP path.

The Configuration Shape

On a MACsec-capable platform, the pre-shared-key uplink config looks like this (shown for reference, not captured, per the platform note):

key chain MKA-KC macsec
 key 01
  cryptographic-algorithm aes-256-cmac
  key-string <hex-CAK>
!
mka policy MKA-POLICY
 macsec-cipher-suite gcm-aes-256
!
interface TenGigabitEthernet1/0/1
 mka policy MKA-POLICY
 mka pre-shared-key key-chain MKA-KC
 macsec

On working hardware you would then verify with show macsec summary, show mka sessions (looking for a Secured state), and show macsec statistics to watch encrypted and protected frame counters climb. Those commands return nothing meaningful on a platform without MACsec silicon, which is precisely why this article does not show them.

Where MACsec Fits, and Where It Does Not

MACsec is not a VPN and does not replace one. It secures individual links, hop by hop. A frame is decrypted at each MACsec-terminating device and re-encrypted on the next link. This has consequences:

• It protects the physical infrastructure. The classic use case is a link between two buildings over a fibre run you do not fully control, or a connection through a colo cross-connect. Anyone tapping that specific cable gets ciphertext.
• It is not end-to-end. Traffic is in the clear inside each device between hops. If you need true end-to-end confidentiality across many hops, that is IPsec or TLS, at Layer 3/4, not MACsec.
• Host-to-switch MACsec (via 802.1X) protects the access link from the endpoint to the first switch, complementing 802.1X port authentication: 802.1X decides who gets on, MACsec encrypts what they send.
• It stops the passive tap and the physical-layer attacker. That is its threat model: someone with physical access to a cable or patch panel. Against a compromised switch in the path, it does less, because that switch legitimately decrypts.

The pairing to remember: MACsec for the wire, IPsec for the route, TLS for the session. They protect different scopes and are frequently deployed together, MACsec on the sensitive physical links, IPsec across the WAN, TLS for the applications.

FAQ

Can I run MACsec in a virtual lab?

Not meaningfully. MACsec encryption happens in PHY hardware, which virtual switches do not have. IOL rejects the interface command. To lab it you need Catalyst 9000, IE switches, or ASR-class hardware.

Is MACsec a replacement for IPsec?

No. MACsec secures a single Layer 2 link, hop by hop. IPsec secures Layer 3 end to end across many hops. Different scope, often deployed together.

Does MACsec add latency?

Negligibly. Because it runs in the interface silicon at line rate, the overhead is a few bytes per frame (SecTAG + ICV) and essentially no added delay, which is exactly why it needs hardware.

PSK or 802.1X for the keys?

Pre-shared key for switch-to-switch uplinks (simple, static peers). 802.1X/EAP for host-to-switch, where each endpoint authenticates and derives its own key dynamically.

Does MACsec protect against a compromised switch in the path?

Only partially. Each MACsec device legitimately decrypts and re-encrypts, so a compromised switch sees cleartext. MACsec's threat model is the passive physical tap on a link, not a subverted node. For that, use end-to-end encryption higher in the stack.

Key Takeaways

• MACsec (802.1AE) encrypts and authenticates every Ethernet frame on a link, at Layer 2, in PHY hardware at line rate.
• It provides confidentiality (AES-GCM), integrity (ICV), replay protection, and origin authenticity, adding a SecTAG header and ICV trailer while leaving the MAC addresses visible for forwarding.
• MKA handles key agreement and rotation, seeded either by a pre-shared key (switch-to-switch) or 802.1X/EAP (host-to-switch, via RADIUS).
• It is hop-by-hop, not end-to-end. Traffic is cleartext inside each device between links. Pair it with IPsec (route) and TLS (session).
• Its threat model is the physical tap on a cable you do not fully control, cross-building fibre, colo cross-connects, sensitive uplinks.
• Honest platform note: MACsec cannot run on virtual IOL. It needs Catalyst 9000, IE, ASR, or Nexus hardware with MACsec silicon.

Next: 802.1X port authentication (the natural partner for host MACsec), or the Infrastructure Security cluster guide.