IPAM for Security Teams: Using Addresses as Asset and Identity Context

Every alert starts with an IP address, and most investigations stall on the same question: which device, which person or which workload had that address at that moment? IP address management (IPAM) usually belongs to the network team as a planning tool, but its data is one of the best sources of asset and identity context a SOC can have. This guide explains how to turn IPAM, DHCP and neighbour data into a reliable IP-to-identity chain, how to use the address plan as security policy, how to handle shared and short-lived addresses, and how to secure the IPAM platform itself. It is for SOC leads, detection engineers, network security architects and asset inventory owners. For choosing a platform see the DDI buyer's guide; for protecting DHCP see the DHCP Security Guide.

Key takeaways

• Attribution is a chain, not a lookup. IP to MAC (lease or neighbour cache), MAC to switch port or access point, port or session to user (802.1X or RADIUS accounting), and device to owner (inventory). Each link needs time-stamped history.
• Time is the key field. Addresses are reused. Without accurate, synchronised timestamps, and source ports where addresses are shared, attribution is guesswork.
• The address plan is policy. Subnets mapped to zones, owners and sensitivity let detections and firewall rules reason about intent, not just numbers.
• IPv6 and cloud break old assumptions. Temporary IPv6 addresses change daily and cloud addresses churn by the minute, so lease logs alone are no longer enough.
• IPAM is a privileged system. Its admin accounts and API tokens can redirect traffic or hide assets. Treat it like other tier-one infrastructure.

Why IPAM data matters to security

CIS Controls v8.1 Safeguard 1.1 asks for an asset inventory that records network address (if static), hardware address, machine name, owner and department. Safeguard 1.4 asks organisations to enable DHCP logging on all DHCP servers or IP address management tools and use those logs to update the inventory weekly or more often. Safeguards 1.3 and 1.5 add active discovery (daily) and passive discovery. IPAM is where those streams meet. Used by the SOC, it answers four recurring questions.

Building the IP-to-identity chain

Treat attribution as a sequence of joins, each with its own data source and retention need.

Make it usable: build an enrichment service or SIEM lookup that takes (address, timestamp) and returns device, location, user and owner, with the confidence of each link. Store addresses in canonical form (RFC 5952 for IPv6, as RFC 9099 recommends) so the same address is not recorded several ways. See the SIEM Guide.

Time, ports and shared addresses

• Synchronised time: all lease, cache, RADIUS and security logs need a common, accurate clock. RFC 6302 (BCP 162) recommends UTC timestamps accurate to the second from a traceable source such as NTP. See the NTP Security Guide.
• Source ports: where addresses are shared through NAT44, NAT64 or DS-Lite, the public address alone does not identify a user. RFC 6302 recommends that internet-facing servers log the source port, plus transport protocol and destination port where several are used. Apply the same rule to your own proxies, VPN concentrators and load balancers.
• NAT translation logs: keep your own NAT and proxy translation logs so an external abuse report (public address, port, time) can be traced back to an internal address.
• Retention: align lease and cache history retention with your incident investigation window and legal advice. RFC 9099 notes that collecting and storing these logs can raise privacy and regulatory obligations.

IPv6 and cloud: addresses that keep changing

IPv6 temporary addresses: RFC 8981 (Standards Track, obsoletes RFC 4941) sets default temporary address lifetimes of one day preferred and two days valid, with a random offset so changes are not synchronised. Hosts can hold several addresses per prefix. Attribution therefore depends on neighbour cache history linking all those addresses to one MAC and port, not on DHCPv6 alone. RFC 9099 lists options that favour accountability: a /64 per host, stable privacy addresses (RFC 7217) within your network, or DHCPv6 instead of SLAAC where operating systems support it and the network enforces it. The IPv6 Security Guide covers the wider IPv6 controls.

Cloud and containers: private addresses in virtual networks are reassigned as instances and pods start and stop, and public addresses can be released back to the provider. For cloud workloads the stable identity is the instance, pod or function and its attached service account or role, not the address. Capture flow logs with resource identifiers, sync allocated ranges into IPAM so overlaps are visible, and enrich alerts at the time they fire.

Released public addresses: when a cloud public address is released but a DNS record still points at it, another customer may later be assigned it. Track public address allocations and release dates in IPAM and reconcile them with DNS records. See the Attack Surface Management Guide.

The address plan as security policy

An address plan organised around services and locations lets security policy follow structure. RFC 9099 makes this point and cautions that predictable addressing should never replace enforced perimeter rules.

• Tag every subnet: zone (user, server, OT, guest, management), site, owner, data sensitivity and expected device types. Export these tags to the SIEM and firewall management.
• Write detections against tags: "user subnet talking to management subnet on SSH" is clearer and survives renumbering better than a list of ranges.
• Use unique local addresses carefully: RFC 9099 notes that ULA prefixes from fd00::/8 must be generated pseudorandomly and filtered at domain boundaries.
• Keep the diagram current: CIS Safeguard 12.4 asks for architecture diagrams reviewed at least annually; the IPAM subnet hierarchy is the authoritative source for them.

Detecting with IPAM data

The unallocated-address detection is effective because legitimate systems rarely send traffic to space that has never been assigned, while scanning does.

Securing IPAM itself

IPAM and DDI platforms can change DNS records, DHCP options and reservations. Whoever controls them can redirect traffic or quietly remove an asset from view.

• Admin access: phishing-resistant MFA for administrators, role separation between read-only SOC users and editors, and change approval for scope and option changes.
• API and automation identities: IPAM is often driven by orchestration, infrastructure-as-code pipelines and cloud sync connectors. Give each integration its own scoped service account or token, store secrets in a vault, rotate them and log their use. See the Secrets Management Guide.
• Audit logging: send IPAM change logs to the SIEM and alert on bulk deletions, scope changes and DHCP option changes.
• Integrity checks: reconcile IPAM with discovery data on a schedule so that a deleted record does not hide a live device.

Rolling it out

1. Agree ownership: network team owns allocation; security owns tags for zone and sensitivity, enrichment and detection use.
2. Centralise lease and cache history: collect DHCP logs from every server and IPAM tool, and start neighbour cache polling on IPv6-enabled segments.
3. Fix time first: confirm every source uses synchronised UTC time before building joins.
4. Tag subnets: start with management, server and OT ranges, then user and guest.
5. Build the enrichment lookup: pilot it in triage for one quarter and measure how often it returns a confident user and owner.
6. Add detections: unknown devices in sensitive subnets, unallocated-address contact, released public addresses.
7. Extend to cloud: sync cloud ranges and capture resource identifiers in flow logs.

Rollback: enrichment and detections are read-only on network data, so they can be switched off without network impact. Changes to DHCPv6 versus SLAAC or per-host prefixes are network changes and need the network team's normal change and rollback process.

Decision guidance

• Small organisations: a spreadsheet plus centralised DHCP logs and RADIUS accounting may be enough. Focus on time sync and log retention.
• Mid-size organisations: a dedicated IPAM with API access and SIEM enrichment gives most of the value.
• Large or IPv6-heavy organisations: add neighbour cache collection, switch-port history and, where switches support it, source address validation (SAVI), which RFC 9099 notes is trustworthy only when MAC addresses are themselves protected by 802.1X or similar.
• Cloud-first organisations: prioritise resource identifiers and workload identities over address history; use IPAM mainly for overlap control and public address tracking.

Detection and measurement

• Percentage of SOC alerts where enrichment returns device, owner and user with high confidence.
• Percentage of active subnets with zone, owner and sensitivity tags.
• Lease and discovery devices not matched in the asset inventory, and time to resolve them (CIS Safeguard 1.2 expects weekly handling).
• Coverage of time-synchronised log sources feeding attribution.
• DNS records pointing at addresses no longer allocated to you (target zero).

Common failure patterns

• Current state only: IPAM shows who has an address now, but the incident happened last week. Keep history.
• Clock drift: lease logs and firewall logs a few minutes apart attribute activity to the wrong device on busy networks.
• IPv4 thinking on IPv6 networks: relying on DHCPv6 logs when hosts use SLAAC and temporary addresses leaves gaps.
• No source ports on shared addresses: abuse reports cannot be traced through NAT or proxies without port and translation logs.
• Untagged subnets: detections hard-code ranges and break after renumbering.
• Over-privileged integration tokens: a sync connector with full write access becomes a way to change DNS and DHCP silently.

Framework mapping

Practitioner checklist

• Centralise DHCP lease logs from every server and IPAM tool and keep history.
• Poll IPv6 neighbour caches and keep MAC-to-port and wireless association history.
• Synchronise all attribution sources to UTC and log source ports on shared addresses.
• Tag every subnet with zone, owner, site and sensitivity and export tags to the SIEM.
• Build an (address, time) enrichment lookup with confidence per link.
• Detect unknown devices in sensitive subnets and contact with unallocated space.
• Track public and cloud address releases against DNS records.
• Protect IPAM admin access with phishing-resistant MFA and scope every integration token.

Standards and references

• CIS: Controls Assessment Specification, Control 1 Inventory and Control of Enterprise Assets
• CIS: Controls Assessment Specification, Control 12 Network Infrastructure Management
• IETF: RFC 9099 Operational Security Considerations for IPv6 Networks
• IETF: RFC 6302 Logging Recommendations for Internet-Facing Servers (BCP 162)
• IETF: RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE D3FEND: Network Node Inventory

Related NHI Mgmt Group resources: DHCP Security Guide · Asset Inventory and CMDB Security Guide · Network Access Control (NAC) Guide · DNS Security Guide