Inventory and signals: investigating an unfamiliar device

An unfamiliar network name appears on your phone. Your router displays an entry you do not recognize. Both observations raise a useful question: what relationship has actually been established between that identifier and the environment you administer? Answering it starts with a known reference and a controlled comparison.

We will build that reference using a router, computer and phone that belong to you. As you follow the exercise, you will put together a small inventory with supporting evidence and questions still to resolve. We will consult device information and administrative screens without collecting communication content, searching for credentials or demonstrating espionage.

What an inventory should explain

An inventory records which resources exist, their purpose, their owner and their relationships. NIST CSF 2.0 distinguishes hardware inventories, software/service inventories and representations of authorized communications. These categories help turn a list of names into an operational reference.^[1]

For this lab, use local aliases and a private table:

Field	Illustrative example	Question it answers
Asset and owner	PHONE-A, lab owner	Who can confirm its identity?
Purpose	Phone used in the exercise	Why should it be present?
Expected connection	Main household Wi-Fi	Which network should it join?
Evidence	Connection details on the phone itself	Where did the identification come from?
State and time	Connected, time recorded during the test	When was this observed?
Unresolved question	Router label not yet matched	What still needs clarification?

Use this fictional example as a starting point for your own record; it contains no real inventory or observations of CTW devices. When you need names, complete addresses, serial numbers or photographs of labels, keep them in your private record. If you want to explain what you learned publicly, use the aliases alone.

A signal, a name and a connection are different observations

A tool reports what its method can observe. Before interpreting a display, identify the question it can help answer:

Observation	What it can contribute	What remains unestablished
Instrument displays energy in a band	A radio response under the measurement conditions	Which device produced it and its purpose
Network list displays a name	A network was presented by the discovery interface	Ownership, authorization and connection to your network
Router lists a client	A record shown by equipment you administer	Whether it represents a current connection, history or address lease
Phone displays its own connection details	A local reference for that device and network	A match with the other records at the same time

NIST discusses unauthorized WLAN device identification and configuration monitoring as activities requiring suitable context and tools. It also distinguishes passive observation from active scanning; the label “scanner” does not define how a tool behaves.^[2] In the exercise, you will consult administrative screens and the details of your own devices. Check what each tool does: discovery procedures are not all strictly passive.

A concrete risk mechanism

Hypothetical scenario: someone connects a personal access point to a workplace network without involving its administrator. The device creates a communication path absent from the authorized network diagram. The issue is the changed access and configuration; an unusual name is merely one clue. Unauthorized access-point deployment is among the scenarios discussed by NIST.^[2]

Compare that with a neighboring network appearing in your Wi-Fi list, with no evidence linking it to your infrastructure. Classifying both cases as a connected intruder would erase a crucial distinction. An investigation must connect the observation, the asset and its authorization before choosing an action.

Prepare a small lab

Use a router you administer, a computer connected to the main network and your own phone available for a brief disconnection. Open the router’s application or administrative address already confirmed in its manual. If you lack that access, limit the exercise to the physical inventory and record router verification as pending.

Do not change passwords, rules or other devices’ connectivity. Leave private Wi-Fi address features enabled. On Apple devices, the address can differ between networks and, depending on the setting, change periodically. Check the address used for the current connection rather than assuming a physical label will match every record.^[3]

The exercise has a narrow objective: match one router entry to the phone in your hand and observe what the interface reports when only that phone’s Wi-Fi changes state.

Compare three moments

Record the initial reference. On the phone, open the connected network’s details and privately record its name and the Wi-Fi address used for that connection. On the router, locate the client page and check the manual’s explanation of its states. Compare the candidate entry with your phone, without relying solely on the router’s label.
Write the hypothesis before changing anything. Record: “the candidate entry corresponds to PHONE-A; after disconnecting it, I expect the interface eventually to report the change.” Note whether the page reports current connectivity or only history. Without that distinction, disappearance of the entry is not a valid success condition.
Turn off only the phone’s Wi-Fi. Keep the computer connected and refresh the router page using its normal interface control. Record the time and the result. Do not restart the router to force a particular outcome.
Restore the connection. Turn the phone’s Wi-Fi on and confirm the correct network. Read its connection details again, refresh the router page and compare the records. If the address changed, record the new relationship instead of treating the old entry as another confirmed device.
Write a bounded conclusion. State which evidence supports the match, which states you observed and what the interface did not let you establish.

Expected and observed: an illustrative example

Use this entirely illustrative table to learn how to record differences. Its observations are fictional: they are not CTW measurements or promised results. When you carry out the exercise, replace the observation column with your own records.

Moment	Recorded expectation	Illustrative observation	Possible interpretation
Before	Locate connected PHONE-A	Current address matches the candidate entry	Evidence supports the match at that moment
Wi-Fi off	Connection change, within the page’s reporting capabilities	Entry remains but is marked disconnected	A retained entry can represent history rather than an active connection
Wi-Fi restored	Rejoin the intended network	Entry indicates a connection again	The controlled change strengthens the match
Another unfamiliar entry	Obtain independent evidence	No owned device has been matched	Identity remains unresolved; do not conclude espionage

Resolve ambiguous results

The entry never changes: check whether you are reading history, whether the page refreshed and whether the device uses another address. Record the limitation; do not block a client simply to discover who loses service.

The label looks wrong: prioritize connection details checked on the device itself. A generic label is incomplete identification, not a risk classification.

The device is absent: confirm its actual network and what the page covers. You may be looking only at Wi-Fi clients on one access point while another device administers the connection. Mark the case as not assessed until you obtain the relevant information.

Turn the record into a decision

Use three states: confirmed, when evidence supports the identification; pending, when an observation remains unmatched; and not assessed, when the method does not cover the question. “Confirmed” describes identification, not a security guarantee.

Finish by restoring the phone’s original connection, signing out of router administration and storing the record privately. Findings requiring inspection of another person’s settings or equipment should go to the responsible administrator with the available context and evidence.

To test a specific boundary between known devices, continue with guest Wi-Fi and its limits. For the capabilities of particular instruments, explore the Devices guides.

References

NIST. The NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, 2024. Appendix A, ID.AM-01 through ID.AM-03. Source. Accessed 17 October 2026. ↩
SOUPPAYA, Murugiah; SCARFONE, Karen. Guidelines for Securing Wireless Local Area Networks (WLANs). NIST SP 800-153, 2012. Sections 3.1 and 3.2: monitoring and tools. Source. Accessed 17 October 2026. ↩ ↩²
APPLE. Use private Wi-Fi addresses on Apple devices. Updated 5 December 2025. Per-network addresses and private-address settings. Source. Accessed 17 October 2026. ↩