What should organisations do when software sprawl starts driving cost and risk?

Why This Matters for Security Teams

Software sprawl is not just a procurement problem. Every duplicated SaaS app, shadow tool, and orphaned plugin adds another authentication path, another data flow, and another place where secrets, tokens, or delegated permissions can linger after business need has changed. That creates direct cost pressure, but it also expands the attack surface and makes audit evidence harder to defend. Current guidance from the NIST Cybersecurity Framework 2.0 is clear that governance needs to connect asset inventory, risk decisions, and access control, not treat them as separate exercises.

For NHI Management Group, this is where software sprawl starts to intersect with non-human identity exposure. When tools proliferate, so do API keys, service accounts, OAuth grants, and machine-to-machine trust relationships. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which is exactly the kind of hidden overlap software sprawl tends to create. See Ultimate Guide to NHIs — Key Challenges and Risks and Top 10 NHI Issues for the deeper control failures behind that pattern.

In practice, many security teams encounter audit friction and unexpected access exposure only after duplicate software has already become embedded in business workflows.

How It Works in Practice

The practical response is to treat software rationalisation as a control program, not a one-time cleanup. Start by building an authoritative inventory of approved applications, integrations, and business owners. Then compare licence consumption against real usage, because purchased seats and active seats are often not the same thing. The goal is to identify where spend is high but adoption is low, where multiple tools serve the same function, and where apps are still trusted despite having no current owner.

Security teams should join that inventory to access governance. Every retired tool should trigger revocation of its related API keys, service accounts, OAuth grants, and integration tokens. This matters because unmanaged software often leaves behind dormant NHI pathways even after the application itself is removed. The Oasis Security & ESG report notes that 72% of organisations have experienced or suspect a breach of non-human identities, which is a strong reminder that duplicated tools are not just wasteful, they are security-relevant. For control structure, the NIST Cybersecurity Framework 2.0 supports this kind of inventory-to-access linkage.

• Establish a single approved software catalogue with named business owners.
• Validate licence usage against active demand, not procurement commitments.
• Retire duplicate tools when the business case cannot be defended.
• Revoke related credentials, tokens, and integrations as part of decommissioning.
• Review vendor access and third-party connections before removal is complete.

These controls tend to break down in highly decentralised environments where departments buy SaaS tools directly and no one maintains an authoritative owner for each integration.

Common Variations and Edge Cases

Tighter software governance often increases short-term operational overhead, requiring organisations to balance immediate cleanup against business continuity. The hardest cases are not the obvious duplicate apps, but tools embedded in workflows, shared across departments, or tied to regulated data. In those situations, best practice is evolving toward risk-based retirement rather than blanket removal, because the cost of breaking a critical workflow can exceed the savings from eliminating a licence.

There is also no universal standard for how much duplication is acceptable. Some organisations tolerate overlapping tools if one is a fallback for resilience, while others enforce a strict single-tool policy to simplify audit and access review. The key is to document the exception, name the owner, and set a review date. Where third-party integrations exist, the software decision should also include secret rotation and permission review, since dormant integrations can survive long after users stop interacting with the application. For broader governance context, the Ultimate Guide to NHIs — Why NHI Security Matters Now is useful for explaining why software sprawl and identity sprawl tend to reinforce each other.

In mature programs, the question is not whether every tool can be eliminated, but whether each one has a clear owner, a measurable use case, and an exit plan.

Related resources from NHI Mgmt Group

• Why do unmanaged software licenses create identity risk as well as cost waste?
• Why does credential sprawl create governance risk in distributed organisations?
• When should organisations treat an NHI as a high-priority risk?
• When should organisations prioritise access governance over software spend optimisation?