By Yair Knijn · January 1, 2026

You revoked their badge and their VPN. You never reclaimed the IP space they provisioned.

The offboarding checklist your audit lead signs off on covers identity cleanly. Badge deactivated, SSO session killed, VPN cert revoked, MFA tokens deregistered, mailbox delegated. Every line maps to a person and a credential, and every line gets a checkmark. The control works because identity has an obvious owner: the human who just left.

Address space has no such owner field on that checklist. The engineer who walked out provisioned a /22 for a load test eighteen months ago, reserved three /26 blocks for a migration that slipped, and stood up two test VPCs with their own CIDRs. None of that is identity. All of it is still routed.

What an access-only offboarding checklist misses

NIST SP 800-53 control AC-2 treats account management as a lifecycle: you disable accounts on separation and you review them on a defined cadence. Most teams read that as "deprovision the human." The control also covers the resources tied to that account, and that second half is where IPAM lives. A revoked VPN cert stops one person from connecting. It does nothing to the subnet they carved, which keeps answering ARP and keeps appearing in route tables long after the cert is dead.

Security guidance for 2026 now pushes a post-departure review inside 48 hours that hunts for ownership gaps in dashboards, automation, and billing. Address space belongs on that same list, and it almost never is, because access tooling and address tooling are different systems that never compared notes.

Self-service allocations that outlive their requester

Self-service is the multiplier. You gave engineers a portal or a Terraform module so they could grab a subnet without filing a ticket, and they did, hundreds of times. Speed was the point. The cost is that every one of those allocations records a request timestamp and frequently nothing about who is accountable for it after the person rotates teams or leaves.

So the 10.40.0.0/16 a departed engineer reserved sits there. Nobody decommissions it, because decommissioning it requires knowing it was theirs and knowing it is safe to pull. Neither fact is written down. The block is live, routable, and ownerless, which is the exact definition of the ghost space that surfaces a year later as an allocation nobody on the call can explain.

Owner-to-allocation mapping as an offboarding control

The fix is unglamorous: every allocation carries a current owner, and that owner is a real, resolvable identity, not a free-text note from 2024. When the mapping exists, offboarding gains a query it never had before, and the audit lead can run it on the day someone leaves:

• List every CIDR, reservation, and DHCP scope owned by the departing identity.
• Flag which of those are still serving live leases versus reserved-but-idle.
• Force a reassignment or a reclamation decision before the account closes, not after.

That turns address space into something an offboarding workflow can actually act on. The departing person stops being a dead end and becomes a key you look up.

Turning departures into a reclamation trigger

The strongest version wires the HR or directory event straight into IPAM. A separation gets recorded, IPAM resolves that identity to its allocations, and anything orphaned drops into a reclamation queue with a hold timer instead of vanishing into the routed-but-forgotten pile. You reconcile the claim against what DHCP and DNS actually serve, confirm nothing live depends on the block, and reclaim it on a schedule you can defend in an audit.

Spot IPAM keeps an owner-to-allocation map for every block in your Environment, so a departure resolves to a concrete list of CIDRs, reservations, and scopes you can reassign or reclaim before the account is closed. See how the ownership and reconciliation features turn an offboarding event into a clean reclamation instead of next year's unexplained allocation.