An IP address often becomes shorthand for a device: for example, “the NAS is 192.168.1.50” or “the printer is at this address.” That usually works on a small network. But the address can point somewhere else without anyone doing anything unusual. A DHCP lease changes, a device connects through a different interface, or a router keeps an old record. Sometimes the laptop you're checking from has a stale local neighbor entry.
IP addresses aren't unreliable. They just need context: when you checked them and on which network. Before changing a router setting, deleting a supposedly unknown device, or entering credentials on a web page at a familiar address, check that the address still belongs to the device you expect. This guide is for networks you own or are authorized to administer.
IP addresses and device identity
On an IPv4 LAN, an IP address is a network-layer address. Ethernet and Wi-Fi deliver local traffic to a link-layer address, normally a MAC address. Address Resolution Protocol (ARP) associates a local IPv4 address with a link-layer address so traffic can reach it on that local network. ARP doesn't confirm that the readable name, router label, and physical device all match. It only supplies a mapping that appears current for traffic on that segment. RFC 826
DHCP keeps a separate record. With the finite DHCP leases typically used on home networks, the server allocates an address for a limited time and records the binding. Router interfaces often use those bindings to build a “connected devices” list. A lease entry is useful history, but it doesn't check whether a service is running or give a device permanent ownership of an address. A sleeping device, or one that's out of Wi-Fi range, may stay on the list until its lease expires. RFC 2131
Treat the IP address as part of the device's identity record. For a device you care about, write down its name, interface, MAC address, IP address, location or role, and when you observed them. An example hostname such as “OfficePrinter” alone isn't enough. Names can be copied, changed by the router, or left over from a printer that's been replaced.
Common reasons for a familiar address to change hands
Lease reuse is normal. A phone, laptop, or smart plug disconnects, its lease expires, and the DHCP server later gives that address to another client. When the old device returns, it may get a different address. This is expected behavior, especially with a small DHCP pool or devices that frequently come and go.
One device can also have several network interfaces. A NAS might have Ethernet and Wi-Fi; a laptop might connect through a dock, VPN, or USB adapter. Each relevant interface has its own local identity and may get a different address. Checking the Wi-Fi interface's address tells you nothing about the Ethernet interface.
Private Wi-Fi addressing can make the picture harder to follow. Modern devices may use a private MAC address for a particular Wi-Fi network. Apple says this is intended to reduce tracking across Wi-Fi networks, and its behavior depends on the network and privacy setting. A router reservation or inventory note tied to an earlier Wi-Fi MAC address may no longer match the current connection. Apple: private Wi-Fi addresses
Old records can mislead you even when the address hasn't changed. A router may show an old DHCP lease, while an operating system keeps an ARP or neighbor-table entry until it ages out. Browser history or address-bar suggestions may contain a hostname from an earlier visit. Investigate any certificate warning on the current connection before entering credentials. Compare these clues with other observations before drawing a conclusion.
Mapping checks before changes
Start with the router or DHCP server for the LAN you're checking. Confirm the network or VLAN and find the current lease or client entry. Record its IP address, MAC address, hostname if shown, lease status, and the time you checked. If the router only has a historical entry, that's evidence of a past connection, not a current one.
Next, check from a client on the same LAN or VLAN. On many systems, the local ARP or neighbor table shows the MAC address recently associated with an IP. Compare it with the router's current record. If they match, that supports both observations referring to the same local interface at roughly the same time. If they don't, pause. The client could be on a different segment, one record could be older than the other, or the address could have changed hands.
Follow that with an authorized check specific to the device. A printer might identify itself on its status page. A NAS might show its serial number or hostname on its administration page, while a managed switch might show a port and MAC address. A familiar-looking login page isn't proof. Check a detail you're unlikely to confuse with another device, and don't enter a password until the address, expected certificate or hostname, and device identity make sense together.
Work through the comparison in this order:
- Confirm that the checking client and the target device's interface share the intended local subnet and Layer 2 segment, and select the corresponding router interface or DHCP scope. Matching SSIDs alone are insufficient.
- Record the router's current IP-to-MAC association and its timestamp or lease state.
- Compare that MAC address with the checking machine's recent ARP or neighbor entry.
- Confirm a device-specific attribute through a normal local management path you're authorized to use.
- Update your own note only when the separate observations agree.
Don't clear tables, reboot the router, or repeatedly reconnect a production device just to get a quick answer. You could lose timing evidence or interrupt another user. When records disagree, wait for normal device activity where possible, then take another timestamped observation.
Limits of an IP address as evidence
An unfamiliar address alone doesn't prove there's an intruder. It could belong to a guest device or reflect a new private Wi-Fi address, a stale lease, a static address, or a device behind another network boundary. A MAC vendor prefix is only a hint, too. It doesn't identify the model or owner, and vendor lookups are especially weak for private and locally administered addresses.
An address doesn't prove availability either. A device can have a valid lease while it's asleep, while a service is stopped, or while a firewall blocks the one probe you tried. And a response to a local request doesn't mean every service on that device is healthy. Keep the question narrow: “Which interface had this address at this time?” is answerable; “Is everything fine?” isn't.
If an important local service needs a predictable address and the client is configured to use DHCP, confirm the correct interface and set up a documented DHCP reservation on the authoritative DHCP server. Retain the verified current address where appropriate; changing it can disconnect sessions when the client adopts the new address and may require updates to DNS and dependent configurations. This keeps one authority responsible for allocation and makes the record easier to audit. You'll still need to check DNS, Wi-Fi coverage, VLAN rules, power, or the service itself. A reservation doesn't replace those checks.
A short record for the next change
For a NAS, printer, server, or home-automation hub, keep a short inventory row. Include its role, interface, MAC address, reserved address if any, hostname, VLAN or SSID, and last-confirmed date. Review the row when you change routers, replace hardware, or move a device from Wi-Fi to Ethernet. Remove retired hardware from reservations and notes so its old identity doesn't leave you guessing later.
An inventory or monitoring tool can help you compare observations from different dates. DeviceShelf is one option for discovering devices on a local network and retaining observations. Treat it as another source of observations, not a definitive verdict on identity or security. Confirm important changes with the router and the device itself.
You don't need a perfectly static network. You need to know what each observation tells you and record enough context to compare it later. That gives you a reason to stop and check before a familiar number sends you to the wrong device.