How does agentless hardware inventory work?

Agentless hardware inventory works when you stop expecting one scan to reveal the whole truth. The network shows what responded now, a user logon provides information from the computer itself, the directory describes managed accounts, and accounting confirms the asset and its value. A complete register appears only after these observations are reconciled.

An agent on every device makes regular collection easier, but its absence does not make inventory impossible. It changes the discipline: you must define boundaries in advance, collect evidence from several sources, retain the time of every observation, and never confuse a missing response with missing equipment. That last mistake is how organizations lose sight of laptops on business trips, powered-off standby servers, and equipment in isolated segments.

First define exactly what you are counting

The unit of inventory should be a physical piece of equipment, not an IP address, computer name, or row in an accounting export. An address changes with a new DHCP session, a name gets reused after reinstallation, and one accounting card sometimes covers a set containing a system unit, monitor, and peripherals. Treat any of these attributes as the asset itself and duplicates and false disposals become inevitable.

Give every physical device an internal asset_id that never moves to another unit. Store observed identifiers alongside it: serial number, SMBIOS UUID, interface MAC addresses, host name, accounting inventory number, user department, and location. Every value needs a source and collection time. A record saying "serial number ABC, obtained through a local query on 12 May" is stronger than "ABC" when nobody remembers where it came from.

Separate the asset's status from the quality of the information about it. A computer may be marked "in service" while its network data is stale. Another may respond on the guest network even though nobody has established its owner or reason for being there. A practical model has at least four independent fields: lifecycle status, responsible party, last observation, and confidence in the match.

Document coverage before the first query. Include corporate subnets, VPN pools, employee Wi-Fi, server VLANs, branches, laboratory segments, and out-of-band management ranges. Observe the guest network too, but do not automatically declare devices found there to be organizational assets. List exceptions separately: medical equipment, industrial controllers, point-of-sale systems, and other systems where only the service owner may authorize active probing.

Track virtual machines and cloud instances as a separate class even when accounting does not treat them as fixed assets. Their serial numbers, MAC addresses, and names can be cloned with a template, while their lifecycle may last minutes or days. A hypervisor or cloud platform ID links an instance to a technical object, but not to a physical server. For containers, you normally need a register of clusters, nodes, and approved images rather than every short-lived instance. Define this boundary before collection or one report will mix property, virtual resources, and network services. Keep contractor equipment as a separate type too, with an authorization expiry, contract owner, and expected segment. It will not be mistaken for owned property or disappear among guest connections.

The network maps presence, not a finished register

Start a network query with host discovery and only then collect permitted attributes. The Nmap manual explicitly separates host discovery from port scanning: the -sn option stops after locating available hosts. On local Ethernet, Nmap normally uses ARP; across a router it combines ICMP and TCP probes. A single ICMP ping is therefore weak evidence, and a silent host proves nothing.

Run discovery from several approved points, one in each major network zone. Firewalls, address translation, and inter-VLAN rules change visibility. A central scanner may miss a workstation that a local ARP query sees immediately. Before the run, agree on ranges, timing, rate, and probe types with the network and information security teams. Inventory does not excuse unauthorized scanning.

Save a minimal pass as XML so the next stage parses a structured result rather than terminal text:

nmap -sn -n -oX discovery-2025-05-12.xml 10.24.16.0/24

The XML contains host elements with status, addresses, and a MAC address when the source can see the local link. Do not turn this file straight into a computer list. It will contain printers, phones, access points, virtual interfaces, and temporary devices. It answers a narrow question: which network identifier appeared from this observation point at that moment.

Add DHCP leases, ARP or Neighbor Discovery tables from routers, Wi-Fi controller registrations, and switch data. RFC 2131 allows a DHCP client to identify itself with a client identifier rather than only a hardware address. You therefore cannot assume without checking that ClientId is a MAC address. On Windows DHCP Server, Get-DhcpServerv4Lease returns lease records, including active leases and, with -AllLeases, expired and declined ones. Lease history helps with laptops that are off today, but an old lease is not current presence.

You can query network equipment and printers through SNMP if the organization has already configured it securely. RFC 3418 defines sysDescr, sysObjectID, sysName, and sysLocation, but an administrator or manufacturer supplies these fields, and they are often empty or stale. Enabling SNMPv1 and a shared community string for inventory convenience creates needless risk. Use the existing protected configuration and read-only access instead of weakening a device for the audit.

Passive sources reduce load, but they need equally careful interpretation. Firewall logs, DNS queries, authentication events, and access-control records describe activity that has already happened, so you can analyze them without sending new probes. A logged address may belong to a load balancer, proxy, or translator, however, and a DNS name may outlive the computer. Retain a reference to the source event, its time window, and network context. Do not copy the entire network log into the asset register; extract only the fields needed to link an observation to a candidate. Passive history combined with a controlled active snapshot is more useful than constant aggressive scanning. The former shows past activity, the latter tests availability now, and neither proves ownership on its own.

Native remote queries reveal a computer's configuration

For managed Windows computers, a remote CIM query returns the model, manufacturer, serial number, UUID, memory, operating system, and network interfaces without a permanent agent. It uses native management interfaces and requires configured authentication, firewall rules, and permissions. Do not expose WMI or WinRM to an entire administrative segment, and do not run collection under a domain administrator account. Create a minimally privileged account and log its access.

Microsoft describes Win32_ComputerSystem as a source of manufacturer and model, Win32_BIOS as a source of the BIOS serial number, and Win32_ComputerSystemProduct as a source of the SMBIOS UUID. These values help, but the documentation warns that manufacturer-supplied information may be poor. Empty strings, placeholder serial numbers, and all-zero UUIDs occur in real fleets. A field does not become infallible merely because firmware supplied it.

This fragment collects a compact record from a remote host:

$session = New-CimSession -ComputerName PC-042
$cs = Get-CimInstance -CimSession $session -ClassName Win32_ComputerSystem
$bios = Get-CimInstance -CimSession $session -ClassName Win32_BIOS
$product = Get-CimInstance -CimSession $session -ClassName Win32_ComputerSystemProduct
$os = Get-CimInstance -CimSession $session -ClassName Win32_OperatingSystem
[pscustomobject]@{
  ComputerName = $cs.Name
  Manufacturer = $cs.Manufacturer
  Model = $cs.Model
  SerialNumber = $bios.SerialNumber
  UUID = $product.UUID
  OS = $os.Caption
  LastObservedAt = (Get-Date).ToUniversalTime().ToString('o')
  Source = 'remote-cim'
} | ConvertTo-Json -Compress
Remove-CimSession $session

The result is one JSON record containing the name, model, serial number, UUID, OS, time, and source. Handle four outcomes separately: successful collection; host reachable but access denied; management interface unavailable; and host not responding. Collapse them into one "not found" error and the team will troubleshoot the network when it needs permissions, or retire equipment that is merely turned off.

Query Linux and other systems on the same principle: use an approved administration channel that already exists, run a small set of read-only commands, and preserve field provenance. Do not enable SSH across the fleet solely for the register. If centralized management does not exist, logon collection or a physical check is safer than hastily opening a new channel.

Logon collection finds laptops outside the office network

A short user logon script closes the largest gap in network discovery: a device may stay away from the office subnet for months while regularly using a corporate account. The script runs on the computer, reads local attributes, and submits a small signed report when the corporate receiver is available. It needs no permanent background service.

For Windows, you can assign the script through an existing Group Policy or the management mechanism already accepted by the organization. Do not hide it or collect disk contents. The computer name, serial number, UUID, model, OS version, logged-on corporate user, and time are enough. Inform users about the collected fields and purpose under internal policy and applicable personal data requirements.

Delivery needs care. A shared folder that allows users to create files but not read other reports is better than a folder where every employee can see the whole fleet. An internal HTTPS receiver with device authentication, a size limit, and replay protection is better still. The server must treat input as untrusted: validate the schema, limit string lengths, and never use the submitted file name as a path.

A logon script does not prove the current owner. A shared computer reports the last person who signed in, an employee may temporarily use a loaner laptop, and a service account does not identify the person responsible for the asset. Keep the user as a last_user observation, and take assignment from the approved issuance process. Teams often blur this distinction and let a temporary logon silently rewrite responsibility.

The method has two more blind spots. A computer without a domain account will not run the script, and a long-unused device will not create a new event. Logon reports are good evidence of life and configuration, but they do not replace network, purchasing records, and room inspections.

Accounting confirms the asset, not its presence

The accounting register answers what the organization capitalized, at what cost, in which department, and under which inventory number. It does not prove that the device still exists, is connected, or remains with the named employee. The IT register answers operational questions. Forcing the two lists to match row for row usually damages both.

Normalize the export without altering the original. Extract the inventory number, description, serial number, acceptance date, department, responsible person, status, and document number. Trim surrounding spaces and normalize serial number case, but keep the original value beside it. Leading zeros in an inventory number matter, so do not let a spreadsheet turn it into a number.

Handle sets separately. If accounting records a "workplace" on one card while IT sees a system unit and two monitors, create a "set contains" relation instead of three fictional accounting numbers. If a repair replaces the system board, the UUID may change even though the accounting asset remains the same. That event needs component history and a repair document, not automatic creation of new property.

Reconciliation should produce work categories, not one "matched" column. Useful statuses include "exact match," "probable match," "accounting only," "IT observations only," "attribute conflict," and "inspection required." For a probable match, record the reason, such as the same model, department, and label when the serial number is missing. Record a human decision with its date and author too, or the next import will reopen an already resolved dispute.

Match sources by identifier strength

A manufacturer's serial number usually beats a name or IP address, but it still does not deserve blind trust. Identifier stability depends on the equipment class and firmware quality. For a desktop computer, a normalized serial number plus manufacturer is often a strong pair, with UUID as confirmation. For a network device, use a serial number from an approved management interface and the purchasing record. For a monitor that the network cannot see, you need its label, EDID data from the attached computer, and a physical check.

Define matching rules explicitly and apply them from strongest to weakest:

1. An exact match of a unique serial number and manufacturer links records automatically if the number is not on the placeholder list.
2. A valid UUID and model match creates a strong candidate, but a system board replacement requires a check of repair history.
3. A MAC address links network observations to an interface, not permanently to a chassis; docking stations, virtual adapters, and board replacement limit its value.
4. Host name, IP address, user, and department only raise or lower confidence. They must not create an automatic exact match.
5. A conflict between two strong identifiers sends the record for manual review and is never resolved by "latest source wins."

Do not merge records irreversibly. Preserve raw observations separately and create links with a confidence rating. You can then undo a bad match without rewriting history. This matters with cloned virtual machines, faulty firmware, and reused names.

Measure more than the date of last appearance. Source diversity matters too. A computer that responded on the network yesterday and submitted a local report with the same serial number has better confirmation than a host seen only in DHCP a month ago. An accounting card, however, adds evidence of ownership rather than evidence of activity. The confidence model must preserve that distinction.

For every automatic match, retain the rule version, input observations, and resulting score. A bare value of "95 percent" is useless when nobody can explain how it was calculated. Record a readable conclusion instead: serial number and manufacturer matched, UUID confirmed the link, and no conflicts appeared. Test the automatic-link threshold against a labeled sample from your own fleet because identifier quality varies by shipment and equipment class. A false merge is more dangerous than a temporary duplicate: a duplicate enters a queue, while wrongly merged devices hide an unknown asset and give it someone else's history. After changing rules, rerun old observations in a test copy and compare which links appeared, disappeared, or changed confidence. Matching then becomes an auditable procedure instead of an opaque formula.

Unknown equipment appears in the discrepancies

An unknown device is one that appeared in a controlled environment but could not be linked to an approved IT asset or permitted exception. Such a device does not always violate policy. It may be a new computer whose invoice has not yet been imported, a contractor's device, a personal phone on an allowed network, or a forgotten laboratory system. The investigation aims to establish its owner and authorization to connect.

Begin with a queue of network identifiers that recurred across several snapshots and still have no link. One brief appearance of a randomized MAC address on Wi-Fi deserves less priority than a host obtaining an address in a server VLAN every day. Random addresses on user devices and virtual interfaces make MAC counts inaccurate, so treat segment, recurrence, name, address-block manufacturer, and access-controller data as clues rather than conclusions.

Then find reverse discrepancies. An asset exists in the directory but has not logged on for a long time. An accounting card remains active, but neither the network nor a local report has seen the device. A logon script reports a serial number absent from purchasing records. A switch shows equipment on a meeting-room port even though nothing is assigned to the room. Each combination routes work to a different owner: support, accounting, purchasing, the network team, or the room custodian.

A recognizable failure looks like this. Discovery found 10.24.16.87, DHCP retained the name DESKTOP-7K2, and the directory contained a disabled object with the same name from three years earlier. An automated system merged the records by name and closed the exception. An inspection found a contractor's computer that had accidentally received an old name copied from instructions. Had the rule required a serial number or UUID, the device would have remained in the unknown queue and received the right review.

Switch MAC tables, access point data, patch-panel records, and floor plans help locate equipment physically. They narrow the location to a port or zone, but only a limited group should have access. Do not broadcast a general list of unknown devices across the company: it may contain names of people, phones, and sensitive rooms. Assign the investigation to the segment owner with only the data that person needs.

Agentless inventory has measurable blind spots

Agentless inventory does not provide constant visibility and should not pretend otherwise. Powered-off equipment, isolated networks, devices behind NAT, equipment without a manageable interface, monitors, and stockroom inventory need other forms of confirmation. The less often a source observes an asset, the faster confidence in its current status declines.

Set a freshness period by class and source. A local report from a work laptop one week ago may be normal, while the same gap on a server port calls for review. Exact intervals depend on the organization's operating model, so do not copy someone else's numbers. Document your intervals, the response owner, and permitted exceptions.

You cannot treat the Active Directory catalog as a precise last-logon sensor either. Microsoft explains that lastLogonTimestamp replicates after a delay calculated around a 14-day interval with a random reduction. The attribute suits a rough search for inactive accounts, but not the question "who logged on yesterday?" Exact analysis requires an understanding of other attributes and domain controllers, while inventory should treat it as one weak observation.

Reconsider the agentless choice if you need near-continuous software control, rapid device revocation, detailed telemetry, or configuration confirmation outside logon sessions. That does not mean the project failed. Architecture should follow the required frequency and depth. A mixed model often makes sense: servers and managed workstations use the approved management tool, while uncommon, old, and specialized devices rely on network and documentary methods.

Do not collect extra data "just in case." Installed software, accounts, geolocation, and network connections create more risk than a model and serial number. Record the purpose, source, retention period, and access group for every field. An asset register must not quietly become an employee surveillance system.

Repeatable reconciliation matters more than a perfect first snapshot

A working process consists of regular snapshots, normalization, matching, and an exception queue. Every run should retain a job ID, observation point, range, time, rule version, and errors. The team can then distinguish a device's real disappearance from an account failure or firewall change.

Do not remove an asset after one missed observation. Move it through states: "observed," "observation overdue," "confirmation required," "physically found," "in stock," "transferred," and "retired." Transfer and retirement statuses change only under an approved document. A network query may open an investigation, but it has no authority to dispose of property.

Build quality control around a few clear queues: new unknown devices, strong-identifier conflicts, assets without recent observations, accounting cards without links, and IT objects without evidence of ownership. Every queue needs an owner and a review period. A coverage percentage without an exception list says little because anyone can improve it by deleting awkward records.

Before scheduling regular runs, conduct a trial cycle in one branch or network segment. Compare the discovered identifiers with DHCP, the directory, and actual workstations, then manually investigate every discrepancy in a small sample. The trial exposes wrong ranges, docking-station duplicates, prohibited device classes, and fields that suppliers populate with placeholders. Establish operating measures: the share of assets with a fresh observation, number of unknown devices, conflicts between strong identifiers, average age of an open investigation, and decisions reversed after inspection. These measures manage the queue rather than decorate a report. If unknown-device counts suddenly fall after a rule change, check whether the rule has started merging records too easily.

When refreshing a fleet, require the supplier to provide a machine-readable list of serial numbers before acceptance, link it to documents, and physically check a sample. GSE.kz controls the path of its manufactured equipment from production through delivery and support, so a fleet project with GSE can define transparent transfer of identifiers and service history in advance. For a mixed fleet, put the same requirements in the purchasing specification for every supplier.

The first cycle will almost certainly produce dirty data. Do not clean it with manual edits in the final spreadsheet. Fix the normalization rule, source, or issuance process and then run reconciliation again. After several cycles the register becomes more accurate, not because the scanner learned to see everything, but because each discrepancy gained a cause, an owner, and a verifiable resolution.