Who should own decisions about unused assets and licences?

Why This Matters for Security Teams

Unused assets and licences are not just a cleanup task. They are a control ownership problem. When no single business or process owner is accountable, dormant SaaS seats, API subscriptions, service accounts, and premium capabilities can persist long after the business need ends. That creates unnecessary cost, but more importantly it creates residual access that security teams must still defend. The right ownership split is usually business validation plus IT or security enforcement, aligned to governance in the NIST Cybersecurity Framework 2.0.

NHI Management Group research shows why this matters: only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, while 97% of NHIs carry excessive privileges. That means unused assets often remain tied to credentials, permissions, or paid entitlements that can still be abused if left unattended. The control objective is not just cost recovery. It is to make sure somebody can answer whether the asset still has a legitimate purpose, and if not, remove it cleanly through an owned workflow. In practice, many security teams encounter licence sprawl only after an access review, an audit finding, or a breach exposes tools that no one remembered to retire.

How It Works in Practice

Best practice is to assign decision ownership to the business or process owner for each asset class, then require IT, security, or procurement to enforce the action. That split avoids a common failure mode: central teams can revoke access, but they cannot reliably determine whether a tool, licence, or integration still supports a live business process. The owner answers the question “should this still exist?”, while operations answer “how do we remove it safely?”

For NHIs and connected workloads, the same principle applies to service accounts, API keys, CI/CD tokens, and machine credentials described in the Ultimate Guide to NHIs. Ownership should be tied to the system or workflow consuming the credential, not to a generic IT queue. A practical review flow usually includes:

• Inventory the asset, licence, or secret and map it to a named business owner.
• Confirm whether the asset supports production, test, or no current use.
• Apply a revoke, downgrade, or reclaim action with an approval trail.
• Record a review date so the asset is challenged again at the next cycle.

For broader governance, the NIST Cybersecurity Framework 2.0 reinforces that accountability, asset management, and access control need clear ownership rather than ad hoc cleanup. This works best when the owner is measured on utilisation and business value, while security measures compliance with revocation, logging, and exception handling. These controls tend to break down when ownership sits in a shared mailbox or a generic platform team queue because nobody has authority to declare the asset unnecessary.

Common Variations and Edge Cases

Tighter ownership controls often increase operational overhead, requiring organisations to balance cleanup speed against approval friction. Not every unused asset should be treated the same way. A stale test licence, an abandoned contractor seat, and an orphaned production API key carry different business and security consequences, so the ownership model should reflect risk and context. Current guidance suggests that low-risk, low-cost items can be auto-expired after a review window, while higher-risk entitlements need explicit business sign-off before removal.

Edge cases usually appear when ownership is unclear because the original sponsor has left, a team has restructured, or the asset supports multiple departments. In those cases, the decision should escalate to the service owner, product owner, or application owner rather than defaulting to IT. If no accountable owner can be identified, the asset should be placed into a time-bound exception process rather than left active indefinitely. For NHIs, this is especially important because unused credentials can remain valid long after human owners assume they are harmless, and the same problem is documented across the Ultimate Guide to NHIs. The real-world failure point is usually not the removal action itself, but the absence of a named person who can justify keeping the asset alive.

Related resources from NHI Mgmt Group

• Who should own access decisions when service management and IAM are connected?
• Who should own access decisions when ITSM and IAM responsibilities overlap?
• Who should own role definitions and role retirement decisions?
• Who should own access review decisions in an IAM programme?