SaaS management platform choice is an identity governance decision

At a glance

What this is: This is an analysis of how SaaS management platform selection affects discovery, access governance, and compliance across enterprise software use.

Why it matters: It matters because SaaS sprawl creates identity, access, and audit gaps that cut across NHI, human IAM, and lifecycle governance programmes.

👉 Read 1Password's analysis of how to choose a SaaS management platform

Context

SaaS management is not just a procurement or cost problem. It is an identity and governance problem because the moment employees create tools outside central visibility, access, licensing, and third-party sharing decisions move outside normal control paths.

The article argues that teams need to decide whether they want a platform focused on spend reduction, IT operations, or both. That choice matters for IAM and IGA teams because discovery, offboarding, access reviews, and compliance evidence all depend on how broadly the platform can see and govern the SaaS estate.

Key questions

Q: How should security teams govern SaaS sprawl without creating excessive user friction?

A: Start by treating SaaS discovery as a governance prerequisite, then layer access review and offboarding controls onto the apps that matter most. Use the least intrusive discovery methods that still give you enough coverage to manage shadow IT, third-party access, and lifecycle events. The goal is visibility with enough trust to act on it.

Q: Why does SaaS management need to sit close to IAM and IGA?

A: Because SaaS adoption creates identity decisions outside formal procurement and provisioning paths. If a platform cannot connect discovery, access requests, offboarding, and review evidence, then IAM teams cannot reliably prove who had access, when it was removed, or whether the app was ever truly governed.

Q: What breaks when SaaS platforms only focus on spend optimisation?

A: You can remove unused licences and still leave access risk untouched. Spend tools may tell you where money is wasted, but they usually do not explain whether app access is still valid, whether third-party sharing is active, or whether offboarding has been completed across the full SaaS estate.

Q: Who should own SaaS governance when finance, IT, and security all care about it?

A: Ownership should be shared, but accountability must be explicit. Finance should own renewal and cost outcomes, IT should own lifecycle workflow quality, and IAM or security should own access governance and evidence. The control only works when those responsibilities are tied to a single decision model.

Technical breakdown

SaaS discovery as the control plane for shadow IT

SaaS discovery is the foundational mechanism in this category because a platform cannot govern apps it cannot see. Discovery may rely on expense feeds, browser activity, email analysis, or directory integrations, and each method exposes different blind spots. Expense data shows what was purchased, browser monitoring shows what was used, and email-based discovery can expose collaboration paths but creates intrusive access concerns. The governance issue is not only completeness, but also how much user privacy and trust the discovery method consumes to achieve that visibility.

Practical implication: choose discovery methods that match your risk tolerance and coverage needs before you try to automate governance.

Spend management versus IT operations in SaaS governance

Many platforms split along two distinct functions. Spend management focuses on license utilisation, duplicate purchases, and renewal optimisation, while IT operations focuses on onboarding, offboarding, access requests, and access reviews. Those are related but not interchangeable. Cost optimisation can remove waste without fixing access risk, and lifecycle automation can clean up entitlements without telling finance whether licences are being used efficiently. A useful platform has to connect both views if teams want to make defensible decisions about app adoption and access control.

Practical implication: do not buy a cost tool and assume it will solve access governance, or vice versa.

Third-party access and audit-friendly lifecycle control

The most security-relevant part of SaaS management is not merely knowing which apps exist, but seeing when users grant third-party access to company data and whether that access is revoked when needed. That turns SaaS management into a lifecycle governance layer for applications, not just a reporting layer. For IAM and compliance teams, the key question is whether the platform can support consistent onboarding, offboarding, and access review processes that stand up to SOC 2 or ISO 27001 expectations without forcing manual cleanup after every change.

Practical implication: validate whether the platform can evidence access removal and review activity, not just inventory applications.

NHI Mgmt Group analysis

SaaS management has become an identity governance problem disguised as an operations problem. The article is really describing a control boundary shift: app adoption now happens faster than central provisioning and review processes can keep up. Once that happens, lifecycle governance, access review, and third-party access tracking become core security controls rather than administrative tasks. The practical conclusion is that SaaS management must be evaluated as part of IAM and IGA architecture, not isolated finance tooling.

Discovery is the decisive control because you cannot govern unknown SaaS. The article shows that browser monitoring, expense analysis, and directory data each reveal different parts of the estate, which means discovery quality directly determines governance quality. That creates a visibility gap whenever teams rely on SSO coverage alone or assume procurement records represent reality. The practical conclusion is that coverage gaps should be measured explicitly, not inferred from platform adoption.

Lifecycle automation matters more than license cleanup once third-party access is in play. Spend savings are useful, but they do not address the deeper risk that access continues after business need has ended. This is where SaaS management intersects with identity lifecycle discipline: offboarding, access reviews, and entitlement removal are the real governance tests. The practical conclusion is that teams should judge platforms by how well they close access lifecycles, not only by how well they trim software costs.

Unified spend and operations views create a more defensible SaaS control model. The article correctly points out that finance, IT, and security often optimise against different facts. When those views stay separated, teams either overspend on licences or under-govern access. A combined model gives practitioners a better basis for recertification, renewal decisions, and application rationalisation. The practical conclusion is that governance teams should insist on shared evidence before they approve adoption or renewal decisions.

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 5.7% of organisations have full visibility into their service accounts, which shows how often governance starts from incomplete discovery rather than authoritative inventory.
• That visibility gap is why the NHI Lifecycle Management Guide is the right next resource for teams trying to connect discovery, offboarding, and review evidence.

What this signals

Discovery quality is becoming the limiting factor in SaaS governance. When teams cannot see the full application estate, every downstream control becomes partial by default. That is why visibility must be treated as a control objective, not an IT convenience, and why lifecycle and access governance need to be designed around incomplete discovery rather than perfect inventories.

Only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. That figure is a reminder that lifecycle discipline remains weak even in organisations that believe they have mature access controls. For SaaS-heavy environments, the same weakness appears when app access outlives the business need behind it.

A useful way to think about the problem is as access lifecycle debt: the longer an app, entitlement, or third-party connection stays unmanaged, the harder it becomes to prove that it should still exist. Teams that want better audit outcomes should align SaaS discovery with the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs and then measure how quickly they can close access gaps once discovered.

For practitioners

• Map your true SaaS estate before rationalising tools Use multiple discovery sources, including expense data, browser activity, and directory integrations, to compare purchased apps with actually used apps. Treat the gap between those sources as the first governance finding, not a reporting nuisance.
• Separate spend control from access governance requirements Define which decisions belong to finance, which belong to IT operations, and which require IAM or IGA review. Then choose a platform only if it can support the decision path you need, not just the cost reduction story you want.
• Test third-party access revocation as a control outcome Validate whether the platform can identify when users grant external access to SaaS data and whether it can show removal after offboarding or policy change. If it cannot evidence revocation, it is not a complete governance control.
• Build SaaS reviews into lifecycle governance Fold application entitlement checks into access reviews, onboarding, and offboarding so the same lifecycle process governs both software licences and access paths. That reduces shadow IT drift and makes audit evidence easier to produce.
• Use compliance evidence as a selection criterion Ask whether the platform can support audit-friendly records for access requests, removals, and review outcomes in a way that aligns with SOC 2 or ISO 27001 expectations. If the evidence model is weak, operational convenience will not offset governance risk.

Key takeaways

• SaaS management is an identity governance problem because discovery, access review, and offboarding all depend on seeing the full application estate.
• Platforms that optimise spend without lifecycle automation leave access risk and audit evidence gaps untouched.
• The right selection test is whether a tool can prove discovery coverage, third-party access control, and revocation outcomes in the same workflow.

Key terms

• SaaS discovery: SaaS discovery is the process of identifying which cloud applications are in use, who is using them, and how they are being accessed. In governance terms, it is the visibility layer that determines whether security and lifecycle controls can be applied at all.
• Shadow IT: Shadow IT is technology adopted outside approved procurement or security processes. In SaaS environments, it often appears as low-friction apps, unsanctioned collaboration tools, or third-party connections that bypass standard identity and compliance oversight.
• Access review: Access review is a recurring governance process used to confirm whether a user, service, or integration still needs an entitlement. For SaaS, it is only effective when the organisation can see the full app estate and link access to business ownership.
• Lifecycle automation: Lifecycle automation is the use of workflow and policy to provision, update, and remove access in response to joiner, mover, and leaver events. In SaaS governance, it reduces manual cleanup and helps ensure access does not outlive business need.

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 1Password: guidance on choosing a SaaS management platform. Read the original.