Why Security Programs Stall Before They Start

Security programs rarely fail at the interesting end. They fail at step one, on a question that sounds too basic to put on a slide: what is connected to this network?

Everyone in the room already knows the answer is incomplete. The scanner sees what has an agent. The network team sees what has an address. The plant sees what it can walk up to and touch. Nobody owns the union of those views, so the gap stays a rumor instead of becoming a work item, and every capability built on top of it quietly inherits the gap.

The shape of the problem

The industry numbers are clear about the scale of the problem. By ServiceNow's own accounting, exposures compound across OT equipment, medical devices, IoT sensors, physical AI and industrial controllers, and 40% of those assets remain invisible to every tool built for the IT perimeter, while the average enterprise runs more than 70 security tools, each seam between consoles a place where context is lost.

What that looks like on the ground is less dramatic and more expensive. A vulnerability program that cannot reconcile its own findings. One financial-services security team running many scanners could not reconcile scanner results against ServiceNow for audit, because deduplication and mapping were not one-to-one. And it knew, separately, that many assets were never discovered at all. The remediation queue is not wrong so much as unprovable, and unprovable work is the kind that gets deprioritized.

AI makes the same gap louder. ServiceNow puts unsanctioned AI use at 69% of enterprises, with an average of 400 days to discover it, and AI-generated code carrying up to 75% more vulnerabilities than human-written code. An agent you have not discovered is an asset with permissions and no owner. That is the old problem wearing new clothes.

Why the foundation is the part that gets skipped

Foundational data is unglamorous, and it is the only linear problem in the stack; the one you can scope, cost, and measure before you start. It is also where the outcome is decided: you cannot read the manual, drop sensors in, and expect high-fidelity data, and the difference between a working agentic security program and a stalled one is whether discovery is trusted and the CMDB is accurately populated.

Two failure modes are worth naming, because they look nothing alike and end in the same place.

• The pilot that proves nothing. A spreadsheet-based inventory exercise, run once, correct for about a week. It answers "do we have a gap" and never becomes an operating capability.
• The program that never ships. One large enterprise had the connectors built and early momentum, then moved the work elsewhere; three years later it still was not deployed. The lesson is not that the wrong delivery choice produces a bad outcome. It produces nothing, and three years of nothing is hard to see on a status report.

Where the CoreX and AGN partnership fits (and why it exists at all)

Complete Discovery and high-fidelity data are two different disciplines, and they are usually sold as one. Getting sensors placed correctly in a segmented plant network is network engineering. Turning what those sensors find into a trusted, sustainable asset record with an owner and a lifecycle is platform engineering. Teams that are genuinely good at the first are rarely the ones you want doing the second.

That is the whole reason the partnership exists: AGN built depth in network infrastructure, segmentation, and plant understanding, and Armis named them Deployment Partner of the Year at Armis Accelerate 2025. CoreX built the other half, the Service Graph Connector and many of the graph connectors and integrations from security tools into the CMDB, roughly 30 OT implementations, and vulnerability response work going back to ServiceNow's SecOps launch in 2016, productized since as VRX.

Neither of those halves is a solution on its own. Deployed sensors with no reconciliation give you a second console to ignore. A clean CMDB schema with no discovery underneath it is a model of a network rather than the network. The reason to put them on one accountable engagement is that the seam between them is exactly where these programs break, and a seam nobody owns is not a seam that gets fixed.

What we are not going to claim: that this is finished work. The joint engagements are in flight, not in the rearview. If you want a vendor telling you a five-month-old partnership has a decade of shared case studies, there is plenty of that copy available elsewhere.

What we would suggest instead

• Ask what percentage of your asset estate is discovered by something other than an agent. If nobody can answer, that is the finding, not the discovery tool evaluation that follows it.
• Pick one audit question you currently cannot answer cleanly and treat closing it as the scope. "Reconcile scanner findings to the asset record for one business unit" is a project. "Improve asset visibility" is a budget line that dies in Q3.
• Separate discovery from reconciliation when you scope the work, even if one party delivers both. They have different owners, different acceptance criteria, and different ways of going wrong.
• Insist that sustainability be in scope. A record that decays after go-live costs more than no record, because people trust it for a year first.
• Put your AI inventory in the same program as your device inventory. It is the same question about ownership, permission, and state.

An open question

Here is the part we do not have a settled answer to, and would like to argue about publicly: who should own the unknown asset?

Security finds it. IT operations has to model it. The business unit funds it. In practice, the responsibility lands on whoever is least able to refuse it, which is why the gap persists across reorganizations. If you have seen an ownership model that survives contact with a plant floor or a retail estate, we would rather hear it than pitch at you.

If you are working through how discovery, asset data, and security operations should fit together in ServiceNow, let's have a conversation.