Unreported Is Not “No”

Your asset inventory has a column of blank cells. That column is the finding.

Most security dashboards are binary. A disk is encrypted or it isn’t. An account has MFA or it doesn’t. That works right up until no tool has anything to say about a given device — and then the platform has to pick a side. It almost always picks the flattering one. The device doesn’t get reported as unencrypted. It quietly stops being counted at all.

That’s how you end up presenting 94% disk encryption to an audit committee and having no honest answer to the only question that matters: 94% of what?

Two different problems that look identical on a dashboard

There are two reasons a control can look weak.

The first is a control problem. You have a tool watching the device, the tool is reporting, and what it reports is bad. Encryption is off. MFA isn’t enrolled. The bucket is public. You know exactly what to fix and roughly what it costs.

The second is a coverage problem. Nothing is watching. There is no data because there is no tool, or the tool is deployed and never checked in. Nothing is red, because nothing is anything.

These require completely different responses. A control problem is a remediation ticket. A coverage problem is a procurement or deployment conversation, and often a budget line. Collapse them into one binary field and you lose the ability to tell them apart — which means you spend remediation effort on the wrong half of your estate and walk into an assessment unable to describe your own scope.

Give the blanks their own state

When we built Asset Inventory into RealCISO, this is the decision we spent the most time on. Every posture field is tri-state: Yes, No, and Unreported.

Unreported means no connected provider sent a value. It is not a no, and it is not counted as one. A device showing Unreported for disk encryption is not sitting in your unencrypted count — it’s a device nothing has told you about, counted separately, and filterable on its own.

Filtering a posture field to Unreported is the fastest way to find gaps in your tooling rather than in your controls. It’s a different list, and usually a more uncomfortable one, because it’s the part of the estate your security spend isn’t reaching.

Don’t invent gaps for tools nobody bought

The second half of being honest about coverage is not manufacturing it.

If a platform flags “No EDR” at an organization that has never bought an EDR, it hasn’t found anything. It’s generated a wall of red for a decision that was already made, and taught the user to ignore the page.

So coverage gaps only fire for tool categories you have actually connected. “No EDR” stays silent until an EDR is connected — at which point it becomes a real and useful finding, because now it means you own this tool and it isn’t reaching these machines. Same for “Not in MDM.” The exception only exists once you’ve earned the right to be measured against it.

One asset, every source behind it

The other half of a usable inventory is not counting the same laptop three times.

A device enrolled in your MDM that also runs your EDR agent and gets picked up by your vulnerability scanner is one device with three sources — not three rows. Merging is deterministic, on one identifier per asset type: serial number for devices, email for people, resource ID for cloud.

Two guardrails matter more than they sound. Placeholder serials — Default string, System Serial Number, To Be Filled By O.E.M. — never merge anything, because otherwise every white-box machine in your fleet collapses into one nonsense record that looks compliant. And an identifier matching an implausible number of records is treated as bad data rather than a real asset. Anyone who has tried to build this from spreadsheets has been burned by both.

Open any asset and you see the resolved value for every field, plus one card per source showing what that specific provider said, when it last collected, and a link through to the underlying evidence. When two tools disagree, the one closer to the asset wins — your device manager knows more about a laptop than the scanner that swept it once — and precedence applies per field, so a lower-priority source still fills in anything the higher one never reported.

The same principle, one layer up

This isn’t only about inventory. It’s how the whole evidence pipeline is built.

Integrations collect evidence. Automated tests run against that evidence and return pass or fail. And then they stop — a test result never changes your control assessment. The result shows up on the control page, it’s recorded in history, and a human decides what the control status is.

That separation exists for the same reason tri-state posture does. A test can only see what’s connected. If it could set your control status, the platform would be telling you your MFA is compliant while fifty people sit on a local directory it has never heard of. A test result is an input to a judgment, not a substitute for one.

What to do with this on Monday

You don’t need our platform to act on the idea. If you run an inventory today, three questions are worth an hour:

1. When a field is blank, what does your dashboard count it as? If the answer is “a pass” or “nothing,” your top-line percentages are describing your visibility, not your security.
2. What’s your denominator? 94% of enrolled devices and 94% of devices that exist are very different claims. Only one of them survives an assessor.
3. Which of your gaps are gaps in tools you own? That’s the list worth funding first. You already paid for the coverage; it just isn’t landing.

Retired assets deserve the same treatment, incidentally. When a sync stops seeing a device, we mark it retired with the date it was last seen rather than deleting it — hidden from lists by default, out of every count, purged after 90 days, and restored automatically if it reappears. A decommissioned laptop that silently vanishes from your records is a question you can’t answer later.

The thing that hurts organizations is rarely the red item on the dashboard. Somebody is already working that one. It’s the item nobody was measuring.

---

FAQ

What’s the difference between an asset inventory and a security inventory?
A security inventory is a point-in-time record of the security products you’ve bought and what they cover. An asset inventory is the live list of the assets those products are protecting. One is the coverage claim; the other is the ground truth it runs against.

Do I have to build or maintain the inventory?
No. It populates from the integrations you’ve already connected, on the same sync that collects your automated evidence, and empties itself as assets are decommissioned. If it’s empty, no connected integration has collected an asset yet.

Which tools feed it?
MDM and endpoint management, EDR, vulnerability scanners and network asset intelligence feed devices. Identity providers and directories feed people. Cloud providers feed cloud resources and data stores. An integration only appears in the lists it can actually speak to.