How should teams decide whether an expensive software licence is still justified?

Why This Matters for Security Teams

A software licence is only justified when it produces measurable business value, not merely because it remains installed on a device. Security and asset owners often miss that active usage, not deployment status, is the real indicator of need. That same discipline appears in identity governance: unused entitlements, like unused software, tend to persist until they are reviewed and removed. A practical review model should combine activity evidence, cost, and operational dependency, then compare that against the licence tier in use and the alternatives available. This is consistent with the control discipline reflected in the NIST Cybersecurity Framework 2.0 and the broader visibility approach described in the Ultimate Guide to Non-Human Identities. In practice, many security teams discover a licence has become “essential” only after renewal pressure has already locked in the spend, rather than through an intentional usage review.

How It Works in Practice

The strongest renewal decision is based on observed foreground activity over a meaningful period, because it shows whether the software is actually being used, not just launched or left open. Teams should review more than one signal so the decision is defensible:

• Foreground activity across a review window, not a one-day snapshot.
• Frequency of use relative to the licence cost and business owner.
• Functional dependency, such as whether the software is required for a regulated workflow.
• Availability of lower-cost editions, shared seats, or alternative tools.

For security and IT operations, this works best when usage telemetry is paired with ownership records and explicit renewal criteria. The same principle underpins NHI governance, where lifecycle visibility matters more than possession alone. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts, which shows how often organisations overestimate what is actually in use. That visibility gap is also why licence rationalisation should be treated as a governance process, not a spreadsheet exercise, and why authoritative references such as the Ultimate Guide to Non-Human Identities are useful when building review discipline. In practice, teams should set thresholds for downgrade, reclaim, or renewal before procurement notices arrive, then require a business justification for exceptions. Where possible, align the review with the NIST Cybersecurity Framework 2.0 so ownership, accountability, and evidence all sit in one process. These controls tend to break down in shared workstations, VDI environments, and offline desktop tools because foreground activity does not reliably map to a single accountable user.

Common Variations and Edge Cases

Tighter licence governance often increases review effort, so organisations must balance savings against the administrative cost of collecting and validating usage data. There is no universal standard for what counts as “enough” activity yet, especially for specialised tools where a user may only open the application during peak project periods. Current guidance suggests separating genuine intermittency from low-value retention by examining workflow dependency, not just login or launch events. That is important because some licences support critical but infrequent tasks, while others are retained mainly out of habit. Teams should also watch for cases where one expensive licence is effectively shared by many users, because seat assignment can hide underuse at the individual level. NHIMG’s research on the JetBrains GitHub plugin token exposure is a reminder that dormant or forgotten access often remains available longer than intended, even when the original business need has faded. A second useful pattern is to treat exceptions as time-bound approvals with an explicit review date, rather than permanent renewals. That keeps finance and security aligned without forcing every low-frequency tool into the same policy. In environments with shared licences, contractor churn, or seasonal usage spikes, simple activity thresholds can misclassify legitimate demand as waste.

Related resources from NHI Mgmt Group

• How should teams decide whether to use IAM, IGA, or both?
• How do security teams decide whether to use validation or retrieval controls first?
• How should security teams decide whether legacy PAM still fits cloud-native access needs?
• How should teams decide whether an authorization index is too expensive for inline evaluation?