You cannot isolate a compromised host quickly, or prove a segment is really separate, if nobody knows which cable connects which port to which switch. D3-PLM Physical Link Mapping is the MITRE D3FEND technique for that knowledge: D3FEND defines it as identifying and modelling "the link connectivity of the network devices within a physical network", and lists the synonym Layer 1 Mapping. It sits in the Model tactic under Network Mapping, and it has two children: Active Physical Link Mapping, which uses network traffic, and Direct Physical Link Mapping, which records links by observation. This page explains what the model should contain, where the data comes from, how to keep it accurate and what it enables for defenders. It is written for network engineers, OT and data centre teams, and the security architects who rely on their maps. For the parent technique, see the D3FEND Network Mapping Implementation Guide.
Key takeaways
- D3-PLM models single hops, not paths. D3FEND's Physical Link artefact is one dedicated connection over physical media, so the model is a graph of device ports and the cables or radio links between them.
- Two sources must be reconciled. Discovered neighbour data (LLDP and similar protocols, MAC and ARP tables) shows what is connected now; documented cable records show what should be connected. Differences are findings.
- Discovery has blind spots. Unmanaged switches, passive patching, media converters and devices that do not speak a discovery protocol never appear in neighbour tables, which is why D3FEND also has a manual child technique.
- The map is sensitive data. RFC 2922 warns that physical topology data is sensitive and recommends SNMPv3 access controls; the same applies to the store that holds the map and the credentials used to collect it.
- Its value is in what it feeds. Fast containment at the switch port, segmentation validation and node inventory reconciliation all depend on an accurate Layer 1 model.
D3-PLM at a glance
| Field | D3-PLM Physical Link Mapping |
|---|---|
| D3FEND ID | D3-PLM |
| Tactic | Model |
| Parent technique | Network Mapping |
| Child techniques | D3-APLM Active Physical Link Mapping (sends and receives traffic to map the physical layer); D3-DPLM Direct Physical Link Mapping (direct observation, also called manual mapping) |
| Digital artefacts | Maps Network Node and Physical Link |
| Synonym | Layer 1 Mapping |
| D3FEND reference | LibreNMS Network Map extension documentation |
| Typical output | Port-to-port connection graph with device, interface, cable or circuit identifier, medium, location and verification date |
| Effort | Low to start from neighbour discovery; high to complete (patch panels, OT, unmanaged segments, remote sites) |
What the model contains
D3FEND describes a physical link as a dedicated connection over physical media (electrical, electromagnetic or optical, including free space) that represents only a single hop in a larger path. It notes explicitly that a physical link is not the same as a data link, because a data link can run over a telecommunications circuit made of several physical links. A useful D3-PLM model therefore records each hop separately. As a working minimum (our recommendation, not a D3FEND requirement), each link record holds:
- Endpoints: device and interface at each end (A and B), using the same identifiers as the network node inventory.
- Medium and path: copper, fibre, wireless bridge or carrier circuit, plus any patch panel or pass-through positions in between.
- Source and confidence: whether the link was discovered by protocol, inferred from forwarding tables or recorded by a person, and when it was last verified.
- Status: active, planned or being decommissioned, so that changes are tracked rather than overwritten.
- Location: site, room, rack and cable label, which is what a responder needs when the instruction is "pull this cable".
Data centre infrastructure tools model this directly. For example, the NetBox cable model records A and B terminations, type, status (Active, Planned or Decommissioning), label, colour and length, and can trace a path through pass-through ports until it reaches an endpoint.
Data sources and their limits
| Source | What it gives | Limits |
|---|---|---|
| LLDP neighbour tables (IEEE 802.1AB) | Adjacent device and port identity, read from each device, usually over SNMP or the device API; IEEE scopes the standard as a protocol and managed objects for discovering physical topology from adjacent stations in IEEE 802 LANs | Only devices that run LLDP; often disabled on edge or untrusted ports; passive patching invisible |
| Vendor neighbour protocols | Same idea as LLDP on some equipment; LibreNMS groups FDP, CDP and LLDP as "xDP" and picks per device type | Mixed fleets need several protocols; same blind spots as LLDP |
| MAC address and ARP tables | Which end hosts sit behind which switch port; LibreNMS uses ARP entries matching interface IP and MAC as a second link source | Inference, not observation: uplinks carry many MACs, tables age out, virtual hosts blur the picture |
| Physical Topology MIB (RFC 2922) | A standard table of port-to-port connections with discovery method and last-verified time | Informational RFC from 2000, not an Internet standard; support varies |
| Cable and DCIM records | Intended state, labels, patch panel positions, carrier circuit IDs | Drifts from reality unless every move, add and change updates it |
| Physical survey | Ground truth for unmanaged and OT segments (the D3-DPLM child) | Slow, costly and out of date the day after |
Active techniques that send probe traffic belong to the D3-APLM child; see D3-APLM Active Physical Link Mapping. Manual recording is covered in D3-DPLM Direct Physical Link Mapping.
How to build and maintain it
- Start from the node inventory. Physical links connect known devices, so reconcile the switch, router, firewall and access point list first. See D3-NNI Network Node Inventory.
- Turn on neighbour discovery where it is safe. Enable LLDP (or the platform equivalent) on infrastructure-to-infrastructure links. Decide per port class whether to advertise towards end hosts, guest ports or third parties, because the advertisement itself discloses device details.
- Collect with least privilege. Poll neighbour and forwarding tables read-only, with SNMPv3 authentication and privacy or an authenticated API, as RFC 2922 recommends for topology data. See the SNMP Security Guide.
- Load the documented state. Import cable and circuit records into one source of truth, with status values so planned work is not mistaken for live links.
- Reconcile and triage differences. A discovered link with no record, a recorded link that is never seen, and a port whose neighbour changed are the three findings to work. Start in report-only mode: publish differences to owners before treating them as incidents.
- Close the blind spots by hand. Survey unmanaged switches, media converters, wireless bridges and OT cells, and label them as manually verified with a date.
- Keep it current. Tie cable record updates to change tickets, re-poll on a schedule, and alert when a neighbour changes on a core or segment-boundary port.
Scale matters for presentation: LibreNMS notes that a global map of a large network draws and responds slowly and points to per-device or device-group maps instead. Most teams query the model rather than look at one picture.
Where identity fits
The collector itself is a non-human identity. SNMP users, API tokens and SSH keys that read every switch in the estate are high-value credentials: give them read-only views, keep them in a secrets manager, rotate them and record an owner. See the Secrets Management Guide.
What the model enables
| Use | How D3-PLM helps |
|---|---|
| Containment | Find the exact switch port, rack and cable for a host so it can be shut or unplugged without guesswork |
| Segmentation assurance | Show physical paths that bypass a firewall or join two zones, for example a dual-homed device or a stray patch lead; see the Network Segmentation Guide |
| Rogue device detection | A new neighbour or an unexpected MAC on an infrastructure port is a lead for the node inventory and NAC; see the Network Access Control (NAC) Guide |
| Logical mapping | Gives the physical substrate for D3-LLM; see D3-LLM Logical Link Mapping |
| Resilience | Reveals single points of failure, such as two "redundant" links in the same conduit or carrier |
| OT visibility | Records Layer 1 connections that discovery tools cannot reach; see the OT Asset Visibility Guide |
ATT&CK relationships
Relationship type: inferred only. As a Model technique, D3-PLM counters nothing directly. D3FEND's technique page (checked November 2026) shows a small set of offensive techniques that it infers through the digital artefacts D3-PLM maps, and labels these inferences experimental. They indicate overlap in the modelled objects, not that a Layer 1 map detects or prevents the technique. The practical note is NHI Mgmt Group's view.
| ATT&CK ID | Technique | Practical relevance of a physical link map (NHI Mgmt Group view) |
|---|---|---|
| T1578.002, T1578.003, T1578.004 | Create, Delete and Revert Cloud Instance | Low: cloud instances have no customer-visible Layer 1 |
| T1505.002, T1505.003 | Transport Agent, Web Shell | Low: the map helps locate and isolate the affected server, nothing more |
| T1114.002 | Remote Email Collection | Low |
| T1686.002 | Network Device Firewall | Moderate: knowing which device sits on which segment boundary shows where a disabled firewall opens a path. D3FEND still lists this under its earlier, now revoked Impair Defenses sub-technique ID; T1686.002 is the ATT&CK v20 successor |
See MITRE ATT&CK T1686 Disable or Modify System Firewall. Adversaries also gather topology for themselves; the defender's map should be at least as good as theirs. See T1590 Gather Victim Network Information.
How to verify it works
- Spot checks: pick random links from the model each quarter and confirm them on site or from device neighbour output.
- Containment drill: give responders a host name and time how long it takes to identify and disable the right switch port using only the model.
- Change test: move a patch lead in a lab or pilot site and confirm the model flags the neighbour change within the polling interval.
| Metric (example targets, not a standard) | What it shows |
|---|---|
| Share of infrastructure ports with a discovered or verified neighbour | Coverage of the model |
| Open differences between discovered and documented links, and their age | Drift and how fast it is worked |
| Links verified in the last 12 months (example window) | Freshness of manual records |
| Unexpected neighbour changes on boundary ports per month | Possible rogue or unplanned connections |
| Median time from host name to switch port in drills | Operational value for incident response |
Common failure patterns
- Treating discovery output as complete: unmanaged switches and passive patching hide whole segments, so the map looks clean exactly where it is least accurate.
- Documented state never reconciled: cable spreadsheets that are not compared with discovered neighbours become confident fiction.
- Collecting with write credentials: using read-write SNMP communities or admin accounts for discovery turns the mapping tool into a path to reconfigure the network.
- Advertising everywhere: neighbour protocols enabled on guest or third-party ports give any connected device the model, version and port details of the switch.
- No owner for drift: differences are reported but nobody is accountable for closing them.
- Logical and physical mixed up: recording a carrier circuit as one link hides the shared physical path that makes two "diverse" circuits fail together.
Framework mapping
| Framework | Reference | Relationship to D3-PLM |
|---|---|---|
| NIST CSF 2.0 | ID.AM-03 | Representations of authorised network communication and data flows are maintained |
| NIST CSF 2.0 | ID.AM-01 | Hardware inventories, the nodes that physical links connect |
| NIST SP 800-53 Rev 5 | CM-8 System Component Inventory | Components and their location, which the link model extends with connections |
| NIST SP 800-53 Rev 5 | PL-8 Security and Privacy Architectures | Architecture documentation that a physical map supports |
| CIS Controls v8.1 | Control 12 Network Infrastructure Management | Actively managing network devices and their documentation |
Practitioner checklist
- Reconcile the network node inventory before mapping links.
- Enable LLDP or equivalent on infrastructure links and decide deliberately where to advertise towards end hosts.
- Collect neighbour and forwarding tables with read-only SNMPv3 or API credentials held in a secrets manager.
- Hold cable and circuit records in one source of truth with status and last-verified dates.
- Reconcile discovered and documented links on a schedule and assign owners to every difference.
- Survey and label unmanaged, OT and wireless bridge links by hand.
- Restrict access to the topology store as sensitive data.
- Drill host-to-port lookup with incident responders and track the time it takes.
Standards and references
- MITRE D3FEND: Physical Link Mapping (D3-PLM)
- IEEE: 802.1AB Station and Media Access Control Connectivity Discovery
- IETF: RFC 2922 Physical Topology MIB
- LibreNMS: Network Map extension
- NetBox: Cable model
- NIST: SP 800-82 Rev 3 Guide to Operational Technology (OT) Security
- CISA: Foundations for OT Cybersecurity, Asset Inventory Guidance for Owners and Operators
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: D3FEND Network Mapping Implementation Guide · D3-LLM Logical Link Mapping · Asset Inventory and CMDB Security Guide · OT Asset Visibility Guide · MITRE D3FEND Guide