ServiceNow acquired Armis, a cyber exposure management platform that tracks nearly 7 billion connected devices in real time. Everyone is talking about this as a security acquisition. It’s really a visibility play, and the distinction matters more than it sounds like it should.
Two Populations on Your Network
Every network splits into two groups. The first is what you can log into: servers, databases, cloud workloads, anything ServiceNow Discovery can reach with credentials and go deep on, pulling software, configuration, and dependencies down to the level a service map actually needs. The second group is everything you can’t log into: plant controllers, medical devices, cameras, building systems, personal phones. No agent, no credentials, and often unsafe to scan even if you had them. That second group is frequently the majority of a real network, and today, credentialed Discovery sees it as little more than an IP address with a few open ports, if it sees it at all.
What Armis Sees That Discovery Can’t
Armis reads that second population from the outside. Passive traffic analysis, existing network infrastructure, and a library of billions of previously identified assets let it recognize a device without installing an agent or logging in. That’s how it covers operational technology, IoT, medical devices, and unmanaged endpoints, categories where credentialed discovery was never going to work in the first place, not because Discovery is deficient, but because those devices were never built to be logged into.
The two tools answer genuinely different questions. Discovery answers what an asset is made of. Armis answers what exists at all. Neither replaces the other, and treating this as ServiceNow swapping one scanner for a better one misses what actually changed.
Two Graphs, One Context Engine
ServiceNow’s own framing of the deal is worth taking seriously here. Armis’s asset graph and Veza’s access graph, acquired separately for identity visibility, both feed what ServiceNow calls its Context Engine, the layer that’s supposed to ground AI actions in business reality by mapping assets and identities to the services and policies that depend on them. Asset visibility and identity visibility were always two halves of the same problem. Buying both suggests ServiceNow reached the same conclusion.
That context only matters, though, if the thing consuming it can be trusted to act on it correctly. AI Control Tower is the piece meant to enforce that governance, tracking which agents exist and what they’re allowed to touch. It’s only as reliable as the asset and identity data underneath it.
The Deduplication Trap
Here’s where good intentions go wrong in practice. Feed device data into a CMDB from multiple sources, Discovery, Armis, an import, a manual load, without solid identification and reconciliation rules governing how those sources reconcile against each other, and the same physical device can land in the CMDB as two, three, or more separate records. This isn’t a hypothetical. It’s a well-documented pattern once multiple discovery sources feed the same CI table, and it’s exactly the failure mode KeenStack’s own duplicate-detection work was built to catch.
Get the identification and reconciliation design wrong while layering Armis on top of Discovery, and one device becomes five records. An AI agent querying that CMDB won’t know to treat them as one thing. It will read all five and act on each with total confidence, wrong at machine speed rather than slowly.
How Much of Your Network Can Your CMDB Actually Name
That’s the question worth sitting with before evaluating Armis, Discovery, or anything layered on top of either. A network is bigger than what’s credentialed and scannable, and an AI agent making decisions off an incomplete or duplicated picture of that network isn’t a minor data quality issue anymore. It’s the thing standing between a governed AI rollout and a confidently wrong one.
Not sure how much of your network your CMDB can actually name today? Get in touch with KeenStack and we’ll help you find out.
