What setup work does each asset inventory approach really need?

Why does agentless sound easier than it is?

Because the word describes what you do not install, not what you do have to do. An approach with no agents can still need dozens of credentials, network changes, scan schedules and people to check results. None of that is a reason to avoid it; it is a reason to plan for it.

Connector platforms: access and upkeep

A CAASM platform reads each source through its API. That means, for every tool you connect, an account with the right read permissions, sometimes write permissions for actions, and someone to notice when the source changes. Axonius's adapter directory lists 1,306 adapters; each needs API access and credentials, so time to full coverage grows with the number of tools you connect. JupiterOne describes its coverage as depending on how many integrations a team configures.

Hosting is the other decision. Axonius offers hosted SaaS or self-managed deployment on-premises or in your own cloud; the self-managed options put patching and capacity on your side. Device42 is customer-hosted on the pages we read: a virtual appliance plus at least one Remote Collector.

Scanning tools: reach and agreement

Network scanning needs a scanner that can reach each segment. runZero describes deployment as SaaS or on-premises, including air-gapped environments, with no agents, authentication or appliances required, which reduces prerequisites but still needs network placement. Lansweeper combines agentless scanning with passive detection by default and a traffic sensor. On OT networks the real work is agreement: which segments can be actively scanned, which only passively, and when.

Agents: deployment and lifecycle

An agent has to be packaged, deployed, updated and removed when devices retire. Lansweeper's agent is optional and aimed at laptops that rarely touch the network. ServiceNow describes a unified agent alongside agentless discovery. The effort scales with the number of device types and the maturity of your software deployment tooling.

EASM: seeds and attribution

External tools need starting points. Censys describes discovery that expands from seeds you add in the console or through the API, with assets found beyond the seeds shown separately. Microsoft Defender EASM offers a prebuilt inventory plus recursive discovery from seeds, and labels each asset with a state such as Approved Inventory, Candidate or Requires Investigation. Someone has to review the candidates, because a wrong attribution sends work to the wrong team.

CMDB: data model and ownership

A CMDB-centred approach needs decisions before data: which configuration item classes you track, which source wins each field, and who owns the record. ServiceNow sells Discovery with IT Operations Management, separately from ITSM, so licensing is part of the setup too.

Where does the work land after go-live?

Setup is a one-off; upkeep is not. Connector platforms need credentials rotated and connectors repaired when a source changes its API. Scanners need new segments added as the network grows. Agents need updates and removal from retired devices. EASM needs candidates reviewed every cycle. A CMDB needs its reconciliation rules applied every time. Ask each vendor who does that work in practice, you or them, and how they tell you something has stopped working.

How do you compare effort across vendors?

Ask each one the same four questions: what access do you need, from whom; what has to change on our network; who reviews results, and how often; and what breaks when a source changes. Then run a short proof of concept on a slice of the estate and time each step. Running a 30-day CAASM proof of concept has a plan.

How does the finder handle effort?

Indirectly. Question 02 asks whether you can install agents, and triggers either the own-agent check or the works-without-new-agents check. It does not score setup effort, because the vendors' pages do not give comparable figures.