SaaS portfolio sprawl exposes identity governance blind spots

At a glance

What this is: This is a SaaS portfolio management guide that frames application sprawl as an operational, cost, and compliance problem, with identity governance sitting underneath every lifecycle decision.

Why it matters: It matters because SaaS sprawl expands the number of apps, permissions, and access paths IAM, IGA, PAM, and NHI programmes must inventory, review, and retire.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Zluri's guide to SaaS portfolio management and application lifecycle control

Context

SaaS portfolio management is the discipline of deciding which applications stay, which go, and which need tighter control. In identity terms, that means every app must have a clear owner, a defined access model, and an offboarding path when the business no longer needs it. Without those controls, portfolio rationalisation becomes a spreadsheet exercise rather than governance.

The article’s central claim is that SaaS growth creates visibility, renewal, and compliance pressure. That is true, but the deeper issue is that unmanaged application growth multiplies identity entitlements, secrets, and delegated access paths. For teams already dealing with human IAM, NHI governance, and lifecycle review, this is the same control problem expressed through a larger software estate.

Key questions

Q: How should security teams govern SaaS portfolio sprawl without losing access control?

A: They should govern SaaS sprawl as an identity problem, not only as an application count problem. Every app needs an owner, a defined access path, and an offboarding process for users, integrations, and stored credentials. If those three pieces are missing, portfolio management will cut cost without reducing access risk.

Q: Why do unused SaaS apps still create security risk after renewal is cancelled?

A: Unused apps often retain admin roles, OAuth grants, API keys, or embedded integrations even after business use declines. Cancelling the subscription does not automatically revoke those identity relationships. The risk is identity residue, where access survives longer than the application’s business purpose.

Q: What breaks when SaaS discovery does not include identity ownership?

A: Discovery without ownership leaves security teams with a list of tools but no way to determine who can approve access, remove credentials, or retire the app safely. That gap turns visibility into reporting only, because no one is accountable for the permissions attached to each application.

Q: Who should be accountable when a SaaS application is retired but access remains?

A: Accountability should sit with the application owner, but security, IAM, and procurement all have a role in verifying closure. The app should not be considered retired until access reviews, credential revocation, and downstream dependency checks are complete. This is a lifecycle control failure, not just a contract issue.

Technical breakdown

How SaaS portfolio scoring maps to access decisions

The article describes portfolio scoring as a way to decide whether to keep, update, retire, or replace an app based on age, usage, maintenance cost, and integration depth. From an identity perspective, those same signals should also determine whether the app still needs privileged access, API tokens, or service integrations. A low-value app can still carry high identity risk if it retains broad permissions or holds long-lived secrets. The technical weakness is that many portfolio tools score business value more reliably than identity exposure.

Practical implication: tie app rationalisation to entitlement review, not just usage or cost.

Why visibility matters for SaaS access and shadow IT

The guide repeatedly returns to visibility because an organisation cannot govern what it cannot enumerate. SaaS discovery is not only about finding unused licenses, it is also about finding hidden integrations, unsanctioned apps, and accounts granted access outside the normal procurement path. Shadow IT becomes shadow identity when users create app-to-app trust without central review. In practice, the technical failure is incomplete discovery across departments, devices, and connected services.

Practical implication: inventory apps, connections, and account owners together so discovery exposes identity dependencies.

Lifecycle management for SaaS apps and the identity residue they leave behind

The article’s lifecycle model covers introduction, growth, maturity, and decline, which is useful because identity risk changes at each stage. New apps usually accumulate permissions quickly, mature apps accumulate redundant access over time, and declining apps often become orphaned. The important detail is that retirement must include revoking access, closing integrations, and removing stored credentials. If any of those steps are missed, the app may be gone while its identity footprint remains active.

Practical implication: make retirement a joiner-mover-leaver event for applications, integrations, and secrets.

NHI Mgmt Group analysis

SaaS portfolio sprawl is an identity governance problem, not only a finance problem. The article frames value, renewal, and efficiency as the main drivers, but every unmanaged app also creates another set of permissions, tokens, and owners that must be governed. That means SaaS portfolio management belongs inside IAM, IGA, and NHI operating models, not beside them. Practitioner conclusion: treat app rationalisation as access rationalisation.

Shadow IT becomes shadow identity when app adoption outpaces ownership. The guide’s visibility theme is correct, but the real failure is that many organisations can see spend before they can see accountable access. Apps adopted outside central control often carry unmanaged OAuth grants, stale service accounts, and orphaned admin access. Practitioner conclusion: no app should be considered managed until its identity relationships are known.

Identity residue is the hidden cost of SaaS decline. The article’s lifecycle section shows why old apps still matter after business use drops off. Retired applications often leave behind active integrations, cached credentials, and unrevoked permissions that outlive the business purpose. Practitioner conclusion: decommissioning must include identity cleanup, not just license cancellation.

Application lifecycle governance is strongest when procurement, access review, and offboarding are joined. The article correctly treats SaaS management as a continuous process, but fragmented ownership lets one team buy while another team inherits the access risk. When lifecycle stages are separated from identity controls, entitlements persist longer than business need. Practitioner conclusion: align procurement, security, and offboarding on one lifecycle record.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Use NHI Lifecycle Management Guide to align retirement, revocation, and ownership handoff before app decline turns into identity residue.

What this signals

Identity residue is now the operating risk that SaaS management teams inherit. A portfolio can look rational on paper while still carrying abandoned grants, stale credentials, and integration sprawl underneath it. With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, the control gap is no longer theoretical, and teams should expect more hidden access paths than their current inventories show.

The governance shift is toward lifecycle evidence, not just application lists. If procurement can approve an app faster than security can verify its access closure, the organisation is accumulating unmanaged identity debt. Portfolio reviews should therefore produce a revocation trail, an owner trail, and a dependency trail, not just a cost summary.

For practitioners

• Build one inventory for apps, owners, and access paths Document every SaaS application with its business owner, connected accounts, admin roles, API integrations, and renewal date. Use the same inventory for finance, security, and access review so app rationalisation does not miss identity dependencies.
• Add entitlement review to SaaS rationalisation decisions Before renewing or retiring an application, check whether it still has privileged users, delegated OAuth grants, or service connections that would survive the commercial decision. Remove access first, then close the contract.
• Treat application retirement as an offboarding workflow When an app moves into decline, revoke admin access, remove stored credentials, delete unused integrations, and confirm no downstream workflow still depends on the account. Retiring the subscription alone does not close the identity exposure.
• Map shadow IT to shadow identity Extend discovery beyond approved software lists to find unsanctioned apps, personal workarounds, and app-to-app connections created without governance review. Pair discovery with access certification so hidden applications do not become hidden trust relationships.

Key takeaways

• SaaS portfolio management only reduces risk when it governs the identities attached to each application, not just the application count.
• The main exposure is identity residue: admin roles, integrations, and secrets that survive long after an app stops being useful.
• Teams should connect rationalisation to offboarding so every retirement includes credential revocation, access cleanup, and owner confirmation.

Key terms

• SaaS Portfolio Management: The process of assessing, classifying, and governing an organisation's cloud application stack so it aligns with business need and security expectations. In practice, it combines cost control, access oversight, renewal decisions, and retirement hygiene into one continuous management loop.
• Identity Residue: Access, secrets, and integrations that remain active after an application is no longer in active business use. The term captures the security gap between commercial retirement and technical decommissioning, where permissions persist longer than accountability.
• Shadow Identity: Unmanaged identity relationships created outside central governance, often through unsanctioned apps, delegated access, or hidden integrations. It is the identity-layer version of shadow IT, where the organisation may know a tool exists but not who can access it or how.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: SaaS Management SaaS Portfolio Management: A Comprehensive Guide. Read the original.