Home › Learn

How do you physically locate a compromised device during incident response?

By Thaddeus Stepanovich — Founder, Harbinge.rs · 14 years in EMS and healthcare IT

Why doesn't the network already tell you where the device is?

Every SOC has some version of this moment: an alert names a hostname or an IP, someone confirms it's compromised, and the room goes quiet for a second because the obvious next question — where is it — doesn't have an obvious answer. This isn't a tooling failure so much as a mismatch between what network systems are built to know and what a responder actually needs to know. Network infrastructure describes logical position. Incident response needs physical position. Those are not the same thing, and the gap between them is where minutes disappear.

Switch and port mapping is the closest thing most environments have to a location system, and it's genuinely useful — it will tell you which switch, and often which port, a wired device is connected to. But a switch port maps to a patch panel, and a patch panel maps to a wiring closet, not to a room. Getting from "port 14 on the third-floor closet switch" to "the workstation in exam room 6" requires either a maintained patch panel diagram (frequently out of date the moment a cable gets re-terminated) or someone physically tracing a cable run. Neither is fast, and both assume the device is wired in the first place.

Wi-Fi gives you even less precision. Associating to an access point narrows a device to that AP's coverage area, which in a typical office or clinical floor can span dozens of rooms and, in open-plan or high-density deployments, an entire wing. Signal-strength-based triangulation across multiple APs can tighten that estimate, but it requires infrastructure most organizations haven't deployed for this purpose, and even a well-tuned deployment produces an estimate — a probability cloud on a floor plan — not a room number. It's coarse by design; Wi-Fi was built to move packets, not to answer facilities questions.

DHCP leases and ARP tables tell you which subnet a device is on and, if you're lucky, which building or floor that subnet is scoped to. That's a meaningful narrowing on a large campus, but subnets routinely span multiple rooms, multiple departments, or in some flat network designs, multiple floors. And all three of these signals — switch port, Wi-Fi association, subnet — describe a snapshot of network attachment at a point in time. A laptop that's been unplugged and carried to a different desk, or a phone that's roamed to a different AP since the alert fired, has already invalidated whatever the network told you. Roaming devices in particular defeat all three signals at once: by the time you've traced the port, the device may have moved to a different jack entirely.

None of this means network telemetry is useless during containment — quite the opposite, it's usually the first and fastest way to narrow a search from "somewhere in the organization" to "somewhere on this floor." The point is narrower: network signals answer "where was this device logically attached," and incident response needs "where is this physical object, right now, in a building I can walk into." Closing that gap requires a separate, deliberately maintained record of physical location — the kind an asset tracking system exists to provide.

What does the seizure scenario actually look like?

Once a device is confirmed compromised, the response usually isn't purely digital. Someone has to physically reach the machine to disconnect it from the network, image its drive for forensics, or place it under chain of custody if the incident may involve legal action, regulatory reporting, or law enforcement. Each of those actions has its own time pressure, and they compound.

If the device is still live and potentially exfiltrating data or spreading laterally, every minute it stays reachable on the network is a minute of continued exposure — but pulling the plug before forensics has captured volatile memory or network state can destroy evidence you need for the after-action review or a legal proceeding. That tension between "contain it now" and "preserve evidence first" is exactly why speed to physical location matters: the faster a responder can stand in front of the device, the sooner they can make a deliberate decision — live imaging, controlled disconnection, or seizure — instead of an emergency one made from a description over the phone.

Chain of custody adds another layer once a device might end up as evidence. Documentation of who touched the device, when, and what was done to it starts the moment someone physically interacts with it — not after IT gets around to writing an incident report. A responder who has to first find the device, then figure out whose it is, then determine what's connected to it, is generating gaps in that record before the clock even starts on formal documentation. A location system that also names the last known user and asset owner closes part of that gap before the responder arrives.

None of this is abstract inconvenience. A security incident already carries pressure from executives who want answers, from legal counsel who want the exposure window bounded, and potentially from regulators or customers who need to be notified within a fixed timeframe. Asset location shouldn't be the variable that determines how long all of that takes.

Why do stale CMDB records make it worse?

The instinctive fallback when network signals run out is the CMDB: look up the asset tag, see what room it was assigned to, and go there. This works exactly as well as the CMDB's location field is current — which, as covered in our look at why CMDB location data goes stale, is often not very. Location is the single fastest-decaying attribute in most configuration databases, because assets move constantly while the record only changes when someone deliberately opens a form and edits it.

During an incident, a stale record doesn't just fail silently — it actively misdirects the response. A responder who trusts a six-month-old room assignment and walks there first has burned real time before discovering the record is wrong, and now has to restart the search with less runway and less patience from everyone watching the clock. Worse, if the device was reassigned to a different user or department since that record was last touched, the "owner" information the responder relied on for context — who to interview, whose credentials to check — may also be wrong, compounding the delay across two dimensions instead of one.

This is precisely why the critical first minutes of physical containment are so often the slowest part of the whole response, even though they involve the least technical complexity. A SOC analyst can pull logs and confirm compromise in minutes. Finding the actual box, when the only map you have describes a building that no longer matches reality, can eat far more time than the analysis that triggered the search in the first place.

What preparation makes location instant?

The fix isn't a faster inventory audit run more often — that just narrows, temporarily, how stale the record can get before the next incident. The fix is changing what keeps the record current between audits, so that "where is this device" is always answered from a recently confirmed record instead of a database entry from whenever it was last touched.

Three things make the difference in practice. First, locations that get regularly re-confirmed as a side effect of routine IT work — a technician closing a ticket, servicing a device, or walking a floor for an unrelated reason — rather than relying on a dedicated audit cycle or a policy that assumes people will remember to update a form. Second, a floor-plan-based display for responders who don't know the building well: a first responder pulled from a shared security team, an MSP technician, or anyone unfamiliar with which door leads where benefits enormously from seeing a pin on an actual floor plan instead of parsing a room-number string from a spreadsheet. Third, an audit trail attached to every location confirmation — who confirmed it, and when — that stands up on its own in the after-action review, rather than requiring someone to reconstruct events from memory or scattered ticket notes after the fact.

Put together, these turn location lookup from a research task into a lookup: the responder isn't tracing cables or triangulating Wi-Fi signal under time pressure, they're reading a record that was kept current by work the organization was already doing.

Where Forager fits

Forager keeps a running, timestamped record of where every asset was last confirmed, generated as a side effect of the technician work your team already does — closing tickets, servicing devices, walking floors during routine rounds. When a SOC alert names a device, "where is workstation XYZ right now" is answered from that last attestation, complete with which technician confirmed it and exactly when, instead of from a CMDB field of unknown age.

Device Hunt, Forager's search-and-navigate feature, takes that a step further for exactly the scenario this article describes: point it at an asset and it surfaces the last confirmed location on the building's actual floor plan, so a responder unfamiliar with the site can walk directly to the right room instead of interpreting a room-number string or asking around. That's useful whether the responder is your own IT staff, a rotating MSP technician, or a security team member who has never set foot in the building before.

Forager is HIPAA-ready by design, and a Business Associate Agreement (BAA) is available for organizations that need one to run it against protected health information environments. It doesn't replace your SOC tooling or your incident response plan — it removes the one step in that plan that depends on a physical building matching a database record. See how Forager works.