Category: Fundamentals

What is Passive Asset Discovery?

Keeping track of IT assets has always been a challenge. Organisations accumulate laptops, servers, mobile devices, cloud instances, and software subscriptions faster than anyone can reasonably document them. For years, the answer was a spreadsheet maintained by a diligent IT administrator – an approach that works until the moment it doesn’t. Passive asset discovery offers a fundamentally different model: instead of asking people to record what exists, you let your existing systems tell you automatically.

Active vs Passive Discovery

To understand passive discovery, it helps to contrast it with active discovery.

Active discovery involves scanning your network to find devices. Tools send ping requests, SNMP queries, or agent-based probes across IP ranges and report back what responds. Active discovery is useful, but it has limitations: it only finds devices that are powered on and reachable during the scan window, it can generate unwanted traffic on sensitive network segments, and it tells you very little about who owns a device or what software runs on it.

Passive discovery takes a different approach. Rather than probing the network, it collects asset data from the systems you already operate – management platforms, identity providers, endpoint security tools, and cloud consoles – through their APIs. Because these platforms continuously record information as part of their normal operation, the asset data they expose is always current without any additional scanning.

The two approaches are complementary. Many organisations use passive discovery as their primary source of truth and supplement it with occasional active scans for validation. But for day-to-day asset tracking, passive collection is where the bulk of useful, accurate data comes from.

Where the Data Comes From

Modern IT estates generate asset information as a by-product of their normal operation. The key is knowing where to look.

### Microsoft Graph

For organisations using Microsoft 365, Microsoft Graph is a rich source of endpoint data. Intune-managed devices, Entra ID (formerly Azure AD) registered machines, and user-to-device relationships are all queryable through a single API. You can retrieve device compliance status, operating system versions, and the user each device is associated with – without installing any additional agents.

### Mobile Device Management

Whether you use Microsoft Intune, Jamf, or VMware Workspace ONE, your MDM platform already knows every enrolled device, its hardware model, serial number, and enrolment status. Polling the MDM API gives you a continuously updated device list that reflects joiners, leavers, and hardware refreshes automatically.

### Endpoint Detection and Response

EDR tools such as Microsoft Defender for Endpoint, CrowdStrike, and SentinelOne maintain a real-time view of every agent reporting in. An EDR-managed device that stops reporting is often the first sign of a lost, stolen, or decommissioned machine – long before anyone updates a spreadsheet.

### Cloud Providers

AWS, Azure, and Google Cloud all expose inventories of running instances, storage volumes, and network interfaces through their management APIs. Because cloud resources are created and destroyed constantly, automated polling is the only practical way to maintain an accurate record.

### Identity Providers

Your identity provider – Entra ID, Okta, or similar – knows which users exist, which groups they belong to, and which applications they are licensed for. This is invaluable for software asset management, as it lets you tie licences to real people rather than purchase orders.

Why It Replaces Manual Tracking

Manual spreadsheet tracking suffers from well-understood problems:

• Stale data. A spreadsheet is a snapshot from the moment it was last edited. The moment a laptop is reassigned or a virtual machine is spun up, the record is out of date.
• Single point of failure. One person owns the file. When they are on holiday, no one updates it.
• No audit trail. Spreadsheets do not record who changed what, or when. For compliance purposes, that is a significant gap.
• No reconciliation. There is no automatic way to detect that a device listed in the spreadsheet no longer reports to your MDM, or that a user has three SaaS licences assigned when their role only requires one.

Passive discovery addresses all of these. Data is refreshed continuously by automated polling, multiple authorised users can access a shared source of truth, and every change is logged by the systems that reported it. The audit trail is built in.

Practical Benefits

The most immediate benefit is accuracy. When asset records are populated from the systems that actually manage those assets, the data is correct by construction. A laptop that Intune reports as compliant is, by definition, the laptop Intune manages – there is no transcription step where errors creep in.

A second benefit is coverage. Passive discovery naturally captures assets that manual tracking tends to miss: the developer who created a cloud instance outside the normal procurement process, the contractor enrolled in the MDM but never added to the asset register, the software trial that became a paid subscription and was never cancelled.

A third benefit is timeliness. Because APIs return current state on every poll, you detect changes – a device going offline, a licence being assigned, an instance being terminated – within the polling interval rather than at the next quarterly audit.

What Passive Discovery Does Not Do

Passive discovery is powerful, but it is not a complete answer on its own. It depends on the systems it queries being properly configured. A device that was never enrolled in MDM, never had an EDR agent installed, and was never registered in the identity provider will not appear in any API response. No amount of passive polling will find it.

For this reason, mature asset management programmes combine passive discovery from authoritative sources with periodic active scanning as a safety net. The passive data provides the rich, detailed, continuously updated register; the active scan confirms that nothing has slipped through the gaps.

Getting Started

If you are new to passive discovery, start by inventorying the systems you already operate that expose asset data. For most organisations, the most valuable sources are:

1. Your identity provider, for users and licences 2. Your MDM, for managed devices 3. Your EDR, for endpoint coverage 4. Your cloud provider APIs, for infrastructure

You do not need to connect all of them at once. A common starting point is the identity provider and MDM, since together they give you a view of users, devices, and software that covers the majority of an organisation’s estate. From there, you can layer in additional sources as your needs grow.

Passive asset discovery is not a single tool or product. It is an approach – one that replaces the fragile, manual habits of the past with a data pipeline that runs itself. For any organisation managing more than a handful of devices, it is the foundation of accurate, audit-ready asset management.

Understanding Asset Lifecycle and Operational States

A common mistake in asset tracking is to treat an asset’s status as a single value. A spreadsheet column headed “Status” might contain values like “active”, “offline”, “in repair”, or “retired” – a mix of concepts that answer different questions. Is the device still in service? Is it currently powered on? Is it broken? Conflating these into one field produces ambiguity and makes the asset register harder to use. The solution is to separate two distinct dimensions: lifecycle state and operational state.

Two Different Questions

Lifecycle state answers the question: where is this asset in its relationship to the organisation? It tracks the asset from acquisition through active use, through any maintenance periods, to final retirement and disposal. Lifecycle state changes relatively infrequently – a laptop might be active for three years before being retired.

Operational state answers the question: what is this asset doing right now? It tracks whether the asset is online, offline, degraded, or unresponsive at the current moment. Operational state changes frequently – a laptop that is online today might be offline tonight, and back online tomorrow morning.

These are independent dimensions. An asset can be in the “active” lifecycle state but currently “offline”. It can be “in maintenance” and “online”. It can be “retired” and therefore have no operational state at all. Treating them as separate fields, rather than one combined value, gives a clearer and more useful picture of the estate.

Lifecycle States

A practical lifecycle model typically includes the following states:

### Procured

The asset has been purchased or otherwise acquired but not yet deployed. It exists in the organisation’s records but is not in use, capturing devices in transit, in stock, or awaiting configuration.

### Active

The asset is deployed and in use. This is the normal steady state for the majority of an estate’s lifespan. An active asset is expected to report to its management systems, though it may be temporarily offline at any given moment.

### In Maintenance

The asset is undergoing planned maintenance, repair, or upgrade. It is still owned and expected to return to active use, but is temporarily not in normal service. This state explains why a device might be offline without triggering an incident alert.

### Retired

The asset has been decommissioned and is no longer in use. It may still physically exist – awaiting disposal, data wiping, or return to a leasing company – but is not part of the active estate. Retired assets should remain in the register for audit purposes.

### Disposed

The asset has been physically disposed of or returned. The record remains for audit and compliance, but the asset is gone. This is the terminal lifecycle state.

Transitions between these states should be recorded with timestamps. The resulting lifecycle history – when the asset was procured, when it went active, when it was retired – is exactly what compliance auditors look for under frameworks like ISO 27001 (Annex A.8.1) and ITIL asset management processes.

Operational States

Operational state reflects the asset’s current technical condition, as reported by whichever management system observes it:

### Online

The asset is reachable and reporting normally. For a laptop, this means the MDM or EDR agent has checked in recently. For a cloud instance, it means the instance is running and responding to health checks.

### Offline

The asset is not currently reachable. This does not necessarily mean there is a problem – a laptop can be offline simply because it is powered off outside working hours. The key is the expected behaviour: an asset that is expected to be online but is offline may warrant investigation.

### Degraded

The asset is online but not fully functional. This might mean a cloud instance that is running but failing health checks, an endpoint with an EDR agent that has stopped updating, or a device reporting errors. Degraded state is a signal that something needs attention, even though the asset has not failed entirely.

### Unknown

The asset’s operational state cannot be determined. This happens when no management system has reported on the asset recently, or when reports conflict. Unknown state is itself actionable – it usually means an agent has been removed, a device has been factory-reset, or the asset has fallen out of management entirely.

Why the Distinction Matters

Consider a laptop assigned to a remote worker. Its lifecycle state is “active” – a deployed, owned asset. Its operational state might be “offline” because the worker closed the laptop for the evening. Neither indicates a problem. An asset tracking system that uses a single status field has no clean way to represent this. If “offline” is recorded as the status, it looks like the asset might be lost or broken. If “active” is recorded, it conceals the fact that the device is currently unreachable.

Now consider a laptop whose lifecycle state is “active” and whose operational state has been “unknown” for two weeks. This is a meaningful signal. The device may have been lost, stolen, or had its management agent removed. The lifecycle state has not changed – it is still an active, owned asset – but the operational state reveals that something requires investigation.

Separating the two dimensions also improves alerting. A sensible policy might be: notify the asset owner if an active asset’s operational state is “degraded” or “unknown” for more than 48 hours. This is straightforward to implement when lifecycle and operational state are separate fields, and nearly impossible to express when they are conflated into a single value.

Implementation Guidance

To implement this model in practice:

1. Use separate fields. Every asset record should have a `lifecycle_state` field and an `operational_state` field, each with its own allowed values. 2. Derive operational state from source systems. Operational state should be determined automatically from management systems. If the EDR last checked in within the expected interval, the state is “online”; otherwise “offline” or “unknown” depending on how long it has been. 3. Manage lifecycle state deliberately. Lifecycle transitions should require an explicit action – a person or workflow marks an asset as retired, disposed, or in maintenance. They should not change automatically from operational state, because a device going offline does not mean it has been retired. 4. Record transitions. Both state changes should be logged with timestamps. Lifecycle history supports compliance audits; operational state history supports incident investigation and trend analysis. 5. Define expected operational behaviour per asset. Some assets are expected to be online continuously (servers); others only during working hours (user laptops). This determines when an offline state should trigger an alert.

Reporting Across Both Dimensions

With both dimensions tracked, reporting becomes more powerful. You can answer questions like: how many active assets are offline for longer than expected, which assets have been in maintenance beyond the agreed window, how many retired assets are awaiting disposal, and the average time an asset spends in each lifecycle state before transitioning.

These are the questions IT, finance, and compliance stakeholders actually need answered. A single status field cannot support them. Two well-designed fields can.

Separating lifecycle and operational state is a small design decision that pays off every day the asset tracking system is in use. It reduces false alarms, improves audit evidence, and gives everyone who consults the register a clearer view of what is actually happening across the estate.