Foundations: Know What You Own

Part 1 of the Foundations Series

Basic doesn't mean easy. It means fundamental and foundational. If we neglect our foundation our whole architecture crumbles.

TL;DR

Asset inventory is the most regulated, most recommended, and most under-built capability in security. Every framework tells you to do it. Almost nobody builds one that can actually support the weight of what comes next. This post walks through what a real asset inventory looks like at each stage of maturity, why the compliance version falls short, and where this needs to go as our environments fill up with non-human actors.

---

The Eye-Roll

If you've ever sat in a room where a regulator or auditor stressed the importance of maintaining an asset inventory, you've probably seen a senior practitioner's eyes glaze over. I've watched it happen with one of the best CISOs I've worked with. He's pushed mature security tooling into previously undefended M&A networks and found active breaches in the process. He doesn't need to be sold on asset inventory. He needs the recommendation to stop being so thin.

His frustration isn't that the guidance is wrong. It's that "maintain a list" doesn't begin to describe what he actually built, or what it took to make that list useful under pressure. The regulation gets people to the starting line. Everything after that is on you.

This post is an attempt to lay out the full distance. If you've been doing this long enough that the recommendation feels obvious, good. I'm putting structure around what you already know. If you're earlier in the journey, this is the map.

Why This Is Regulated

Every major security framework starts in the same place: you can't protect what you don't know about.

That's not a bumper sticker. It's the reason initial intrusions so often happen on the systems nobody was watching. The box that didn't get the EDR agent. The server a third party stood up and forgot about. The subnet that came over in an acquisition and never got folded into the security program. An unmonitored asset is a hiding place where an adversary can persist, and you can't monitor what isn't in your inventory.

This is why regulators care. They're trying to get organizations to the starting line. The problem is that most compliance implementations stop there.

The Compliance Version vs. The Operational Version

A compliance-driven asset inventory is a list. It has hostnames and maybe IP addresses. It gets updated when someone remembers to update it. It lives in a spreadsheet. It satisfies the auditor. In practice it's often not even one list: it's several lists in separate systems that don't talk to each other, each maintained by a different team with a different update cadence and a different definition of "asset."

That's crawl. That's the floor. And for a lot of organizations, that's where it stays, because the regulation doesn't describe what comes after.

The frustration practitioners feel with this isn't about the regulation being wrong. It's that a checkbox implementation doesn't serve as a foundation you can build on. It's a static artifact that answers one question ("do we have a list?") and can't answer any of the questions that actually matter during an incident, a vulnerability triage, or a coverage review.

Crawl, Walk, Run, Fly

Here's how I think about the maturity progression. Each level unlocks specific capabilities the one below it can't support.

Crawl

A list exists. You can count your hardware assets. You can hand it to an auditor and check the box.

What you can answer: "How many assets do we have?" (approximately)

What you can't answer: almost everything else.

Walk

The list is actively maintained. Every asset has an owner. During an incident, you can answer: who owns this system, what does it do, and who do I call. You're tracking lifecycle now, not just current state. When something gets decommissioned, you know when it happened and who did it. You know what you own now and what you've owned in the past.

This matters more than people think. If a corporate-branded laptop shows up on eBay, can you determine whether it was properly wiped and retired through your process? Or did it just vanish from the network one day and nobody followed up? That's an inventory maturity question, not a hardware disposal question.

At this level the inventory is a shared map. Incident responders and leadership are working from the same picture. You can scope lateral movement risk. You can identify system owners for notification. You're not running a scavenger hunt during a crisis.

Run

This is where the concept of "asset" expands well past hardware.

You're tracking user and non-user accounts. Service accounts. Identities. Virtual instances across cloud providers. Software bills of materials. And increasingly, AI agents: autonomous software actors that hold credentials and access systems on behalf of users or the organization.

Here's a number that should bother you: the average enterprise currently has an 82-to-1 ratio of non-human identities to human ones. That ratio is accelerating. Most asset inventories don't account for any of it.

At the run level your inventory also knows which security products have visibility on each asset and when they last checked in. First observed, last observed, by which tool. Coverage gaps are visible, not assumed. You can answer the question: if 15% of my assets quietly fell out of coverage, would I even notice?

That question is scarier than it sounds. Telemetry loss is usually noisy. Coverage erosion is silent.

Exposure surface is mapped. You know what's internet-facing, what's in a trusted enclave, what's reachable from where. Data classification is overlaid from DLP observations. Vulnerability management data is integrated where possible, though patch state and network topology remain ephemeral and hard to fully enumerate. That's worth naming honestly rather than pretending it's solved.

Fly

A unified, cross-environment source of truth. On-prem, AWS, Azure, GCP reconciled into one queryable system. The inventory is no longer a reference document. It's the decisioning layer underneath everything else.

Vulnerability prioritization is exposure-informed: an RCE in a trusted enclave with no inbound exposure is a different conversation than the same CVE on internet-facing attack surface. That decision requires deep asset knowledge that a CVSS score alone can't provide.

The inventory is structured for machine consumers, not just human ones. This is the part most people haven't thought about yet. As agentic response systems mature, they will need to query asset context at machine speed to make triage and containment decisions. If your inventory is a spreadsheet or a CMDB that requires a human to interpret, you've built a ceiling into your program that blocks the next generation of capability.

The Integration Problem

Here's a structural issue that nobody caused on purpose but everybody has to solve.

If you have workloads across on-prem infrastructure, AWS, Azure, and GCP, and no way to reconcile what lives where, how do you make informed decisions about coverage or risk? You can't. You're working from fragments.

SIEM and EDR platforms each maintain their own view of your environment. They're optimized for their own ecosystem, not for giving you a unified picture. The result is multiple partial inventories with no central authority. This isn't a vendor problem to complain about. It's an integration problem the customer owns. But it needs to be named, because it's the default state for most organizations and it undermines every capability that depends on knowing what you have.

Some gut-check questions:

If you assume you threw EDR on all your system builds but aren't running reports on agent health, you're in for a rude awakening. If you lost visibility to 10 or 20 percent of your assets in the estate, would you even notice? If you don't have a real asset count, how do you know how many agents are supposed to be there?

Non-Human Identities and AI Agents

The 82:1 ratio I mentioned earlier is just service accounts, API keys, tokens, and machine identities that already exist in most enterprises. AI agents are a new category on top of that.

These aren't hypothetical. Organizations are deploying autonomous agents that interact with production systems, make decisions, and hold real credentials. OWASP published the Agentic Top 10 in December 2025, and three of the top four risks center on identity, delegated trust, and tool access. The through-line to asset inventory is direct: agents mostly amplify existing vulnerabilities rather than creating new ones. If your inventory foundation is weak, agents inherit and multiply that weakness at machine speed.

An agent needs the same inventory rigor as any other identity. Who created it. What it can access. What tools and data sources it connects to. Who is accountable for its actions. When it should be decommissioned. If you can't answer those questions about your service accounts today, you definitely can't answer them about your AI agents. And the agent population is growing faster than the service account population ever did.

Where This Lands

The structure and quality of your asset inventory determines what you can build on top of it. Today that's human decision-making during incidents and vulnerability prioritization. Tomorrow it's autonomous systems that need structured, queryable context to operate safely.

Every framework starts with "know what you own." None of them describe the full journey. The regulator is trying to get you to the starting line. The rest of the distance is yours to cover.

Build the foundation like you're going to put weight on it. Because you are.

---

Appendix: Regulatory Landscape

This section is reference material for anyone who wants to trace the requirements back to their source.

NIST CSF 2.0 (ID.AM): The Identify function's Asset Management category covers hardware inventories (ID.AM-01), software and services (ID.AM-02), network data flows (ID.AM-03), supplier services (ID.AM-04), asset prioritization by criticality (ID.AM-05), and data inventories (ID.AM-07). The underlying NIST 800-53 control is CM-8, which at higher impact levels requires automated mechanisms for maintaining complete, accurate inventories and detecting unauthorized components. Framework-level guidance: tells you what to inventory but stays technology-neutral on how.

CIS Controls v8.1 (Controls 1 & 2): The most prescriptive of the major frameworks. Requires active management of all enterprise assets including those in cloud environments and those not under direct enterprise control. Defines six asset classes: Devices, Software, Data, Users, Network, and Documentation. Implementation Groups (IG1 through IG3) provide a maturity progression that loosely maps to crawl-walk-run. CIS also provides the clearest articulation of the adversary's perspective: attackers have demonstrated the ability, patience, and willingness to inventory and control enterprise assets at large scale to support their own objectives.

ISO 27001:2022 (Annex A 5.9, 5.10, 5.11): Requires organizations to develop and maintain an inventory of information and other associated assets, including assigned owners. Unique among major frameworks in explicitly requiring lifecycle tracking from creation through processing, storage, transmission, deletion, and destruction. Also addresses asset return upon termination of employment or contract (A.5.11), making it the only major framework that speaks directly to the decommissioning and disposal scenario.

PCI DSS v4.0 (Requirements 12.5.1, 2.4, 4.2.1.1, 6.3.2, 6.4.3, 9.9.1): Takes a scoping-first approach. Every system that stores, processes, or transmits cardholder data is in scope, along with anything on the same network without segmentation controls. PCI v4.0 expanded inventory requirements to include certificate inventories, bespoke and third-party software component inventories, and payment page script inventories. As of April 2025, organizations must also perform risk assessments on assets approaching end-of-life. PCI demonstrates the trajectory of what "asset inventory" means over time: it started as a hardware list and now covers certificates, code components, and scripts.

CISA BOD 23-01: The most operationally aggressive directive. Requires all Federal Civilian Executive Branch agencies to perform automated asset discovery every 7 days and initiate vulnerability enumeration every 14 days using privileged credentials. Demands on-demand asset discovery and vulnerability enumeration within 72 hours of a CISA request, with results due within 7 days. CISA explicitly states that continuous and comprehensive asset visibility is a basic precondition for managing cybersecurity risk. This directive comes closest to demanding queryable, responsive asset data rather than a static document updated quarterly.

The pattern: Every framework begins with the same premise. They all stop at different points on the maturity curve. NIST and ISO describe what should be inventoried. CIS adds how often and how to validate. PCI expands what counts as an asset. CISA BOD 23-01 pushes toward operational tempo and queryability. None of them reach the fly state described in this post.