Why do installed apps create poor evidence for software spend decisions?

Why This Matters for Security Teams

Installed applications are easy to count but hard to interpret. A desktop suite can be deployed to every endpoint, start automatically, and still deliver little actual business value if users never open it. That makes install counts a weak proxy for spend decisions, especially when procurement, IT, and security each see a different version of the truth. NHI Management Group’s research shows how visibility gaps distort governance elsewhere too: only 5.7% of organisations have full visibility into their service accounts, which is a useful reminder that inventory alone is not evidence of effective control.

For software spend, the same mistake shows up as over-licensing, false renewal pressure, and missed opportunities to reclaim seats. Mature decision-making needs usage telemetry, session frequency, feature adoption, and role context, not just presence on disk. The NIST Cybersecurity Framework 2.0 frames this as a governance and measurement problem, not simply an asset count problem. In practice, many security teams discover shelfware only after renewal negotiations or audit disputes have already locked in the cost.

How It Works in Practice

Effective software spend governance starts by separating deployment from consumption. Installed state tells you that software exists on a device; telemetry tells you whether it is being used, by whom, and for what work. Current guidance suggests combining endpoint inventory with application launch data, active minutes, feature-level events, and identity context so that decision-makers can distinguish a dormant entitlement from a genuinely valuable workload.

A practical model usually includes three layers:

• Inventory: what is installed, where it is installed, and which licence pool it maps to.

• Usage: when the app is opened, how often it is active, and whether usage is concentrated in a few teams or spread across the organisation.

• Business relevance: whether the app supports a regulated process, critical workflow, or niche function that justifies retention even at low frequency.

This is where evidence quality matters. A security or ITAM team should not treat auto-start behaviour, background services, or preloaded suites as proof of adoption. The better question is whether the software delivers measurable value relative to the licence tier being paid for. That same discipline appears in NHI governance, where the Ultimate Guide to NHIs and the JetBrains GitHub plugin token exposure illustrate how broad visibility without lifecycle proof can still leave organisations exposed. For spend decisions, usage evidence should be reviewed alongside renewal dates, exception lists, and ownership records, then converted into a reclaim or retain decision that a business manager can defend. These controls tend to break down when offline software, shared devices, or VDI environments suppress reliable telemetry because the install signal remains visible while genuine user activity becomes hard to measure.

Common Variations and Edge Cases

Tighter usage-based governance often increases operational overhead, requiring organisations to balance savings against reporting quality and user impact. Not every low-usage app should be removed. Some tools are essential for compliance, executive workflows, seasonal work, or incident response, even if launch frequency is modest. Current guidance suggests flagging these cases explicitly so that exception handling does not masquerade as adoption.

There is no universal standard for “active use” yet. Some organisations measure launches per month, others use minutes in focus, and others rely on task completion signals. The right threshold depends on licence model, application type, and whether the software is shared, specialised, or regulated. Browser-based apps and SaaS subscriptions add another wrinkle because the real usage signal may live in identity logs, not endpoint inventory.

For high-cost suites, best practice is evolving toward renewal reviews that combine finance, security, and departmental owners rather than leaving the decision to procurement alone. That approach reduces false positives, but it still depends on clean data and consistent definitions. If telemetry is incomplete, install data can still help with discovery, but it should never be treated as evidence of value on its own.

Related resources from NHI Mgmt Group

• Why do duplicate SaaS apps create identity governance risk?
• Why do SaaS apps create identity governance risk as they spread across the business?
• Why do SaaS tools create more access risk than traditional software?
• Why do SaaS buying decisions create access governance risk?