D3-APLM Active Physical Link Mapping: Mapping Cables and Ports Automatically

When an alert names a MAC address or an IP, responders need to know which switch port and which wall socket it sits behind, and hand-drawn cabling records rarely answer that. MITRE D3FEND calls the automated answer Active Physical Link Mapping (D3-APLM), synonym Active Physical Layer Mapping, and defines it as a technique that "sends and receives network traffic as a means to map the physical layer." It sits under the Model tactic as a child of Physical Link Mapping (D3-PLM), and D3FEND marks it as disjoint from its manual sibling, Direct Physical Link Mapping (D3-DPLM). This page explains what D3-APLM records, the data sources that make it work, how to deploy it without creating a new privileged weak point, and where it stops being reliable. It is for network engineers, security architects and incident responders, and builds on the MITRE D3FEND Network Mapping Implementation Guide.

Key takeaways

• It answers "what is plugged into what". D3-APLM models device to device and device to port connections at layer 1, the view needed to locate, isolate or physically remove a device.
• Switch tables do most of the work. Neighbour discovery protocols (LLDP, CDP), MAC forwarding tables and spanning tree data, read over SNMP, reconstruct the cabling; D3FEND cites a patent that uses spanning tree data to resolve switch uplink ambiguity.
• It cannot see everything. Unmanaged switches, media converters and hubs appear as gaps. D3FEND's guidance for D3-DPLM is that where active mapping is not possible, physical inspection is needed.
• The collector is a privileged non-human identity. Read-only SNMPv3 with a restricted view, scoped source addresses and managed credentials.
• D3FEND gives it only inferred ATT&CK relations. They come from the generic Network Node artefact; the practical security value is location, isolation and change detection.

D3-APLM at a glance

How it works

D3FEND gives no knowledge base article for D3-APLM beyond the definition, so the mechanics come from its two references and the standards behind them.

• Infrastructure to infrastructure links: switches and routers running LLDP (IEEE 802.1AB) or CDP record which device and port sits at the far end of each of their ports. IEEE describes 802.1AB as a protocol and managed objects for "discovering the physical topology from adjacent stations in IEEE 802(R) LANs". A collector reads those tables over SNMP and joins them into port to port links.
• Endpoint to access port: endpoints rarely run LLDP, so the collector joins the switch MAC forwarding table (MAC seen on port) with ARP tables from routers (IP to MAC). A MAC seen on an access port, and only there, is that endpoint's physical attachment.
• Uplink disambiguation with spanning tree: on a switched network, every MAC is also seen on uplink ports. The SolarWinds patent cited by D3FEND uses spanning tree protocol data obtained through SNMP queries to identify switch to switch links and remove them from consideration when placing end nodes, reducing ambiguity about uplinks.
• Path probes: the traceroute patent cited by D3FEND identifies the devices behind each hop, which helps tie routed hops back to physical devices.

RFC 2922 (Physical Topology MIB, Informational, 2000) is a useful reference for the data model: it records physical connections between ports, allows several active or passive discovery mechanisms to feed it, ranks identifier quality, and represents areas it cannot resolve as "clouds". That last point is the honest limit of D3-APLM: some segments will only ever be inferred.

Physical versus logical mapping

The two share collectors and data, and most tools produce both views. The logical view is covered in D3-ALLM Active Logical Link Mapping.

Deploying it

1. Agree the record format. For each link: device A and port, device B and port, discovery method, first seen and last seen. For each endpoint attachment: MAC, IP, switch, port, VLAN and time. Store it in the same source of truth as the hardware inventory.
2. Set up a read-only collector identity. SNMPv3 with authentication and privacy (RFC 3414 User-based Security Model), a view limited to the interface, bridge, LLDP and ARP MIBs needed, and device ACLs that accept SNMP only from collector addresses. Some platforms need extra configuration to expose MAC tables or LLDP data over SNMPv3; the Device42 manual cited by D3FEND notes cases on certain Cisco and Huawei devices.
3. Enable LLDP on infrastructure ports. It gives the most reliable switch to switch links. Decide deliberately about access ports, where LLDP also helps with phones and access points but advertises device details to whoever plugs in.
4. Pilot and verify on the floor. Pick one closet, run discovery, then check a sample of results physically. This is where D3-APLM and manual mapping (D3-DPLM Direct Physical Link Mapping) meet: inspection validates the automation and fills its gaps.
5. Schedule and diff. Rerun on a fixed cycle. A new device on a port, a MAC moving between ports, or a new switch to switch link are change events worth review.
6. OT and fragile devices. Read switch tables rather than probing controllers, schedule collection with the asset owner, and fall back to passive or manual methods where polling is not acceptable.
7. Roll back. If polling affects a device, remove it from scope, record the exception and map it manually. Retired collectors have their SNMPv3 users removed from every device.

Where identity fits

The collector account reads tables across every switch, so it is a privileged non-human identity: give each collector its own credentials, keep them in a secrets manager, rotate them and alert on use from unexpected sources. The SNMP Security Guide covers the protocol hardening.

Security uses of the physical map

ATT&CK techniques D3FEND relates to D3-APLM

Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-APLM. Its site shows "inferred and experimental" relations that arise because D3-APLM maps Network Node and Physical Link and may query Network Agent (D3FEND 1.6.0, checked November 2026): Web Shell (T1505.003), Transport Agent (T1505.002), Remote Email Collection (T1114.002), Create Cloud Instance (T1578.002), Delete Cloud Instance (T1578.003), Revert Cloud Instance (T1578.004), and Network Device Firewall (T1686.002). D3FEND lists the last one under an ID that ATT&CK has revoked; T1686.002 is the ATT&CK v20 successor. These come from broad artefacts and say little about physical mapping, so do not read them as coverage.

Measuring it

Limits and failure patterns

• Unmanaged switches and hubs: many MACs on one access port usually means a hidden switch. The map shows the port, not what is behind it.
• Aged-out tables: MAC forwarding entries expire after idle periods, so quiet devices drop off. Collect frequently enough and keep history.
• Virtualisation: many virtual machine MACs on a hypervisor uplink tell you the host, not the workload. Use the virtualisation platform's inventory for the rest.
• Wireless: a wireless client has no switch port; its attachment is an access point and a session, read from the wireless controller.
• Uplink confusion: without spanning tree or neighbour data, endpoints appear attached to uplinks. This is the ambiguity the spanning tree patent cited by D3FEND addresses.
• Overexposed collectors: write access or SNMPv1 and v2c communities shared across devices turn a mapping tool into a way to reconfigure the network.

Framework mapping

Practitioner checklist

• Record each link with both ports, method, first seen and last seen.
• Use a dedicated read-only SNMPv3 collector identity with a restricted view and source ACLs.
• Enable LLDP on infrastructure links; decide deliberately about access ports.
• Join MAC forwarding, ARP and spanning tree data to place endpoints on access ports.
• Spot check results physically at each site and map gaps manually.
• Alert on unknown MACs, MAC moves and new switches behind access ports.
• Give responders a fast lookup from IP or MAC to switch and port.
• Agree OT collection methods with asset owners before polling.

Standards and references

• MITRE D3FEND: Active Physical Link Mapping (D3-APLM)
• IEEE: 802.1AB Station and Media Access Control Connectivity Discovery
• IETF: RFC 2922 Physical Topology MIB
• IETF: RFC 3414 User-based Security Model (USM) for SNMPv3
• Google Patents: US8045488B2 Using spanning tree protocol (STP) to enhance layer-2 topology maps
• Google Patents: US10079749B2 Identification of traceroute nodes and associated devices
• Device42: SNMP Network Auto-Discovery

Related NHI Mgmt Group resources: MITRE D3FEND Network Mapping Implementation Guide · D3-PLM Physical Link Mapping · D3FEND Model Tactic · Asset Inventory and CMDB Security Guide · MITRE D3FEND Guide