A live network port in a meeting room, a printer cupboard or a branch office is an open door into the LAN unless the switch decides who and what may use it. MITRE D3FEND names this control LAN Access Mediation (D3-LAMED), with the comment "Layer 2 Enforcement", and defines it as "the application of strict access control policies, systematic verification of devices, and authentication mechanisms to govern connectivity to a Local Area Network." It sits under the Isolate tactic as a child of Network Access Mediation (D3-NAM), beside Routing Access Mediation (D3-RAM). This card goes below the network-wide view in the D3-NAM Network Access Mediation card and covers the switch port itself: the four mechanisms D3FEND names, port host modes, failure behaviour when RADIUS is down, how to verify enforcement and how attackers get around it. It is written for network and security engineers who run wired and wireless access layers.
Key takeaways
- Four building blocks. D3FEND's article names access control lists, port security, RADIUS and 802.1X as the components of LAN access mediation; each covers a different gap and none is sufficient alone.
- No ATT&CK mapping in D3FEND. D3-LAMED isolates the Local Area Network artefact and no ATT&CK technique in the D3FEND ontology acts on it, so D3FEND lists no offensive techniques (checked November 2026). ATT&CK itself recommends 802.1X and device certificates as the M1035 mitigation for Hardware Additions (T1200).
- The host mode decides how strong the port is. A port that authenticates only the first device and then lets everything else through is weaker than one that authenticates each device individually.
- Failure behaviour is policy. What a port does when the RADIUS server is unreachable, or when a device fails authentication, has to be chosen deliberately and tested.
- Authentication is not encryption. 802.1X decides who gets on the port; it does not protect frames on the wire. Where a tap between an authenticated device and the switch is a credible threat, MACsec (IEEE 802.1AE) is the layer 2 answer.
D3-LAMED at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-LAMED (d3f:LANAccessMediation) |
| Tactic | Isolate |
| Parent technique | Network Access Mediation (D3-NAM), synonym Network Access Control |
| Sibling | Routing Access Mediation (D3-RAM) |
| Digital artefact | Local Area Network (D3FEND relation: isolates Local Area Network) |
| D3FEND comment | Layer 2 Enforcement |
| Components named by D3FEND | Access Control Lists, Port Security, RADIUS, 802.1X |
| Core standard | IEEE 802.1X-2020, Port-Based Network Access Control (Active Standard) |
| ATT&CK techniques in D3FEND | None listed |
| Main limitation | A device admitted on a port can be impersonated or shared unless the host mode, MAC limits and link encryption prevent it |
What D3-LAMED does
D3FEND's knowledge base article describes four components working together so that only authorised devices and users connect to the LAN. Each answers a different question at the access layer.
| Component (D3FEND) | Question it answers | Typical setting | What it does not do |
|---|---|---|---|
| 802.1X | Has this device or user authenticated before the port forwards traffic? | Port access entity in authenticator role, EAP-TLS with device certificates for managed endpoints | Protect frames after authentication |
| RADIUS | What level of access does the authenticated subject get? | Access-Accept with VLAN assignment (Tunnel-Type VLAN 13, Tunnel-Medium-Type 802, Tunnel-Private-Group-ID) or a named filter | Authenticate the device itself; it relays and decides |
| Port security | Which and how many MAC addresses may use this port? | A maximum number of learned MAC addresses per port and an action on violation | Prove identity; a MAC address can be copied |
| Access control lists | Which traffic is allowed once the device is on? | Per-port or downloadable per-session ACLs for each role | Decide admission |
IEEE 802.1X-2020 describes its own scope in the same terms: restricting use of IEEE 802 LAN ports to authenticated and authorised devices, and securing communication between ports through the protocols that establish IEEE 802.1AE MAC Security associations. The RADIUS attributes that carry the decision are set out in RFC 3580 (Informational, September 2003, updated by RFC 7268) and are covered in the D3-NAM card and the RADIUS Security Guide, so they are not repeated here.
Changing a decision after admission
Admission is not permanent. Two mechanisms end or change access for a device already on the port:
- Reauthentication: under RFC 3580, a Session-Timeout with Termination-Action set to RADIUS-Request (1) sets the time before the port must reauthenticate. A failed reauthentication is reported with Acct-Terminate-Cause 20 (Reauthentication Failure).
- Dynamic authorisation: RFC 5176 (Informational, January 2008) defines Disconnect-Request, which ends a session, and CoA-Request, which changes a session's authorisation without disconnecting it, sent to UDP port 3799. This is how a NAC or posture system moves a device into a quarantine VLAN within seconds rather than at the next reauthentication. RFC 5176 asks servers to discard requests from untrusted sources and to use per-client shared secrets, IPsec, or an Event-Timestamp with a suggested 300-second replay window.
ATT&CK techniques and D3-LAMED
D3FEND relationship: none listed. D3FEND derives offensive links from shared digital artefacts. D3-LAMED isolates Local Area Network, and no ATT&CK technique in the D3FEND ontology acts on that artefact, so the D3-LAMED page lists no techniques (D3FEND 1.6.0, checked November 2026). Do not report D3-LAMED as covering techniques on the strength of D3FEND.
The table below is NHI Mgmt Group's own view of ATT&CK v20 techniques where a layer 2 control changes the attacker's position, with the ATT&CK mitigation text where ATT&CK itself names the control. It is not part of D3FEND.
| ATT&CK ID | Technique | What LAN access mediation changes (NHI Mgmt Group view) | ATT&CK's own mitigation text |
|---|---|---|---|
| T1200 | Hardware Additions | An implant or rogue laptop plugged into a port is rejected or placed in a restricted VLAN | M1035: network access control policies such as device certificates and the 802.1X standard |
| T1557.002 | ARP Cache Poisoning | Only authenticated devices share the segment, and MAC limits reduce spoofed addresses | M1037: DHCP Snooping and Dynamic ARP Inspection on switches |
| T1557.003 | DHCP Spoofing | A rogue DHCP server must first be admitted to the segment | M1037: filter DHCP traffic on ports 67 and 68 from untrusted servers, port security and DHCP snooping on layer 2 switches |
| T1040 | Network Sniffing | MACsec on the link removes plaintext frames from a tap between device and switch | M1041: encrypt wired and wireless traffic |
For the device side of T1200, see MITRE ATT&CK T1200 Hardware Additions and M1034 Limit Hardware Installation. The closest mitigation pages are M1035 Limit Access to Resource Over Network and M1037 Filter Network Traffic.
Where it is implemented
LAN access mediation lives in access switches and wireless controllers, with a RADIUS or NAC policy server behind them. Vendors use different names for the same port behaviours. Two examples follow, listed alphabetically; the order is not a ranking, and the same concepts exist across the market.
Cisco IOS switches
Cisco documents the interface command authentication host-mode with the options single-host, multi-host, multi-domain and multi-auth. Its documentation describes multi-auth as authenticating multiple hosts on a single port individually, allowing one client on the voice VLAN and multiple authenticated clients on the data VLAN; once a VLAN is assigned to the first authorised host, later hosts must match it or are denied. Verification uses show authentication interface for the port.
Juniper Junos switches
Juniper documents three supplicant modes: single, which authenticates only the first device and gives later devices access without their own authentication; single-secure, which allows one device only; and multiple, which authenticates each device individually. Juniper also documents server-fail handling, with deny as the default when the RADIUS server is unreachable and permit, use-cache or a server-fail VLAN as alternatives, a server-reject VLAN for wrong credentials, a guest VLAN for devices without 802.1X, and MAC RADIUS for devices that cannot run a supplicant.
| Port behaviour | Cisco term | Juniper term | Security effect |
|---|---|---|---|
| Authenticate every device on the port | multi-auth | multiple | Strongest for shared ports; each device needs its own credential |
| One device only | single-host | single-secure | Suits desk ports with one endpoint |
| First device opens the port for others | multi-host | single | Use only where a downstream device is itself trusted to mediate |
| Device without a supplicant | MAC Authentication Bypass | MAC RADIUS | MAC address used as identity, so it can be copied |
Wireless LANs apply the same model: 802.1X with EAP-TLS on enterprise SSIDs, covered in the 802.1X and EAP-TLS Enterprise Wi-Fi Guide. Product and rollout choices for the policy server are in the Network Access Control (NAC) Guide and the Network access control (NAC) rollout playbook.
Where identity fits
The devices that cannot run a supplicant are almost all non-human: printers, cameras, badge readers, building controllers and medical or industrial kit. Each MAC bypass entry is an identity with no secret behind it. Give each one an owner and an asset record, keep these ports in restricted VLANs with tight ACLs, and prefer device certificates where the device can hold one. See D3-CBAN Certificate-based Authentication.
Implementation steps
- Map ports to roles. Classify every access port: user desk, shared meeting room, printer and IoT, voice, server, uplink. Decide the host mode and fallback VLAN for each class.
- Stand up the policy path. Deploy redundant RADIUS servers, per-switch shared secrets, and dynamic authorisation from the policy server only. Restrict UDP 3799 on the switches to the authorised server addresses.
- Issue device certificates. Enrol managed endpoints for EAP-TLS so admission rests on a key, not a password or MAC address.
- Run in monitor mode. Enable 802.1X in a mode that logs results without blocking. Collect at least two business cycles and fix failing devices before enforcing.
- Enforce in rings. Start with one floor or site, then wider. Keep a tested rollback per port group (return to monitor mode) and a named person who can apply it out of hours.
- Add port security and switch hardening. Set MAC address limits per port class, and enable DHCP snooping and dynamic ARP inspection where your switches support them, as ATT&CK's M1037 text suggests.
- Decide server-fail behaviour per port class. Deny is the safer default for general ports; a critical or server-fail VLAN with limited access may be justified for clinical, OT or safety devices. Write the choice down.
- Consider MACsec for exposed links. Where cabling passes through shared or public space, or for links into high-value zones, MACsec closes the gap between authentication and the frames that follow.
How to verify it works
- Unknown device test: plug an unmanaged laptop into a sample of ports of each class. Expect a reject, guest or quarantine VLAN, and a RADIUS or switch log line naming the port and MAC address.
- Piggyback test: on a port with an authenticated device, insert a small unmanaged switch and connect a second device. On multi-auth or multiple mode it must authenticate separately; on single-host or single-secure it must be blocked.
- Spoofed MAC test: clone the MAC address of a MAC bypass device onto a test laptop on another port. Confirm it lands only in the restricted VLAN and that profiling or duplicate detection raises an alert.
- Revocation test: revoke a test device certificate, then confirm the port refuses it at reauthentication, and that a CoA-Request from the policy server moves a test device to quarantine.
- RADIUS failure test: during a maintenance window, make the RADIUS servers unreachable from one switch and confirm each port class behaves as the written server-fail policy says.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Access ports in enforce mode | Rising toward 100% of user and shared ports | Monitor mode blocks nothing |
| Ports in a mode that admits unauthenticated devices after the first | Zero, or each one justified in writing | These ports allow piggybacking |
| MAC bypass entries with a named owner and live asset record | 100% | Unowned bypass entries are impersonation targets |
| Managed endpoints admitted by certificate | Rising quarter on quarter | Moves admission from identifiers to keys |
| Unknown device test pass rate | 100% of sampled ports | Proves enforcement end to end |
Limits, bypasses and failure patterns
- Weak host modes: a port that authenticates only the first device lets an attacker place a hub or small switch behind a legitimate endpoint and ride its session. Use per-device authentication on any port a visitor can reach.
- MAC addresses as identity: MAC bypass and port security both trust an identifier that any device can copy. A printer port becomes a way in for a laptop that takes the printer's address.
- Taps between device and switch: 802.1X does not encrypt traffic. Without MACsec, a device inserted inline after authentication can observe or inject frames on that link.
- Fail-open by accident: a permit server-fail setting, chosen to avoid an outage, quietly turns off mediation whenever RADIUS is unreachable. Decide it per port class and alert on server-fail events.
- Unprotected dynamic authorisation: a switch that accepts CoA or Disconnect requests from any source lets an attacker on the management network change or end sessions. RFC 5176's source checks and replay protection apply.
- Monitor mode forever: rollouts that never reach enforcement show healthy logs while blocking nothing. Track the enforce ratio as a metric.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-3 Device Identification and Authentication, IA-3(1) Cryptographic Bidirectional Authentication | Identify and authenticate devices before establishing a connection; EAP-TLS fits the cryptographic enhancement |
| NIST SP 800-53 Rev 5 | AC-18 Wireless Access, AC-3 Access Enforcement | Wireless admission and per-role enforcement after admission |
| NIST SP 800-53 Rev 5 | CM-8 System Component Inventory | The asset records that MAC bypass entries and device certificates depend on |
| NIST CSF 2.0 | PR.AA-03, PR.IR-01 | Users, services and hardware are authenticated; networks are protected from unauthorised logical access |
| MITRE ATT&CK | M1035, M1037 | Mitigations whose ATT&CK text names 802.1X, DHCP snooping and dynamic ARP inspection |
| MITRE D3FEND | D3-NAM, D3-LAMED | Parent and technique |
The 800-53 and CSF rows are NHI Mgmt Group's mapping by control intent.
Related countermeasures
- Routing Access Mediation (D3-RAM): the sibling for VPNs, tunnels and firewall rules above layer 2. See D3-RAM Routing Access Mediation.
- Network Resource Access Mediation (D3-NRAM): what an admitted device may do on a service. See D3-NRAM Network Resource Access Mediation.
- IO Port Restriction (D3-IOPR): the host-side equivalent for USB and other local ports. See D3-IOPR IO Port Restriction.
Practitioner checklist
- Classify every access port and assign a host mode and fallback VLAN per class.
- Use per-device authentication on shared and visitor-reachable ports.
- Admit managed endpoints with EAP-TLS device certificates.
- Give every MAC bypass entry an owner and keep those ports in restricted VLANs.
- Set MAC limits and enable DHCP snooping and dynamic ARP inspection where supported.
- Write and test the server-fail behaviour for each port class.
- Accept dynamic authorisation only from the policy servers, with replay protection.
- Move port groups from monitor to enforce in rings with a tested rollback.
- Run unknown device, piggyback and spoofed MAC tests on a sample of ports each quarter.
Standards and references
- MITRE D3FEND: LAN Access Mediation (D3-LAMED)
- IEEE: 802.1X-2020 Port-Based Network Access Control
- IETF: RFC 3580 IEEE 802.1X RADIUS Usage Guidelines
- IETF: RFC 5176 Dynamic Authorization Extensions to RADIUS
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- MITRE ATT&CK: T1200 Hardware Additions
- Cisco: IEEE 802.1X Multiple Authentication
- Juniper: 802.1X Authentication on switching devices
Related NHI Mgmt Group resources: D3-NAM Network Access Mediation · Network Access Control (NAC) Guide · RADIUS Security Guide · 802.1X and EAP-TLS Enterprise Wi-Fi Guide · MITRE D3FEND Guide