How should security teams use application usage data to decide whether an app is still worth renewing?

Using usage data as a renewal signal

application usage data is most useful when security teams treat it as evidence of business dependence, not just proof that people logged in. A renewing app should show repeat usage, multiple active users or workflows, and value that is hard to replace quickly. If telemetry shows only a few sporadic sessions, a narrow user base, or activity that looks like one-off administrative access, the renewal decision should move into a review of necessity, overlap, and ownership.

That matters because unused or weakly used applications still carry identity, data, and integration risk even when they appear “quiet.” The renewal question is therefore not whether the app exists, but whether it continues to justify its cost and operational burden. Teams should compare usage trends against the app’s role in core processes, dependency chains, and control coverage. The Ultimate Guide to NHIs — Key Research and Survey Results is useful here because it shows how identity sprawl and weak visibility often persist until teams examine real usage, not just inventory records. In practice, many renewals are approved on contract timing long before anyone asks whether the application still has measurable operational value.

How usage data should be interpreted in practice

Good renewal decisions depend on reading usage in context. Raw login counts can be misleading because a heavily automated app may have few human logins but still be business critical, while an app with many logins may be duplicated by another platform or used only because it is the default path. Security and software asset teams should look at a small set of indicators together: unique active users, frequency of use, breadth across business units, depth of feature use, and whether the app participates in important workflows or integrations.

• High activity in a narrow pilot group may justify renewal if the app supports a live operational process.
• Low activity across a broad license base often indicates overprovisioning or shelfware.
• Administrative-only access should be separated from true end-user adoption.
• Usage tied to a single team needs a stronger ownership case than usage spread across multiple functions.

Teams should also look for signs that usage data is incomplete. VPN access, shared accounts, service accounts, and embedded automation can all hide the real footprint of an application. That is why renewal review should combine telemetry from the app, identity provider, and finance or asset records rather than relying on one source alone. If the application exposes credentials, tokens, or machine-to-machine integrations, the question is not only whether users are logging in, but whether the app still supports critical non-human access patterns that would be expensive to replace. The OWASP Non-Human Identity Top 10 is relevant when those workflows depend on machine identities or automation paths that are not visible in standard user activity reports.

Usage also needs a time window that reflects business rhythm. A quarter-end tool may look dormant for most of the year, and a seasonal system may spike only during a narrow period. These controls tend to break down when telemetry is fragmented across business units and automation paths because the renewal decision starts to reflect reporting gaps rather than actual demand.

Common renewal edge cases and governance traps

Tighter renewal screening often increases review overhead, so organisations need to balance cost recovery against the risk of cutting something that supports a hidden workflow. The hardest cases are not the obviously unused apps; they are the ones with intermittent or indirect use, where value sits in a downstream process rather than in frequent direct logins. Best practice is evolving, but there is no universal standard for treating rare usage as either disposable or essential.

One common trap is treating low usage as automatic cancellation without checking whether the app is a control point, a fallback system, or a dependency for integrations. Another is renewing a platform because it is embedded in operations even though the actual footprint is concentrated in one team and could be consolidated elsewhere. A third is overlooking machine-driven use, where service accounts or API keys keep an application active even when human adoption is low. When that happens, the renewal decision should consider whether the app is supporting stable business use or simply preserving technical debt.

For organisations with many overlapping apps, the practical decision is often to classify the app into one of three buckets: renew, review for consolidation, or retire. The right answer depends on whether the app has demonstrable ongoing use, a replacement path, and an owner willing to defend its continued place in the stack. When usage data cannot explain why the app still exists, the renewal case is usually weaker than the contract suggests.

Practitioner Guidance

What to prioritise: Start with apps whose licenses or contracts are due first and rank them by low usage, narrow ownership, and overlap with other tools. That gives security teams a clean way to surface renewal candidates without turning every application into a manual review.

What to verify: Confirm that the usage data includes both human and non-human activity, and check whether the app supports a workflow that would disappear if the tool were removed. If telemetry cannot distinguish direct use from background automation, treat the renewal signal as incomplete rather than decisive.

Decision rule: If an app shows limited recent use, no clear cross-functional dependency, and no unique control or workflow role, treat renewal as a consolidation or retirement decision instead of a default extension.

Practitioner takeaway: Renewal decisions are strongest when usage data reveals durable business dependence; if the data only proves that the app was not fully removed yet, the default should be a deeper review, not a renewal.

Related resources from NHI Mgmt Group

• How can security teams tell whether a SaaS application is still worth keeping?
• How do security and data teams decide whether to use full reprocessing or incremental pseudonymization for SAP backups?
• How do security teams decide whether to use data lineage, classification, or DLP for insider risk?
• How should security teams decide whether blockchain is appropriate for storing application data?