SaaS management is now an identity governance problem

At a glance

What this is: This is an analysis of six SaaS management essentials and the article’s core finding is that SaaS sprawl should be treated as a governance and identity control problem, not only an application and cost issue.

Why it matters: It matters because IAM, IGA, and security teams need visibility into who owns, uses, and offboards access to SaaS applications across human and non-human identities.

By the numbers:

• Nearly 38% of companies work almost entirely on SaaS.
• 51% of organizations run most of their operations using SaaS applications.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Efecte's analysis of six steps toward successful SaaS management

Context

SaaS management becomes an identity governance issue the moment organisations lose track of who owns application access, who approves renewals, and who can still act inside dormant accounts. The article argues for better visibility across usage, spend, and security, but the underlying problem is access accountability across the application estate.

For IAM and IGA teams, the practical challenge is not simply inventorying subscriptions. It is connecting application usage to lifecycle controls, offboarding, password discipline, shared-account risk, and third-party access so that SaaS sprawl does not become an unmanaged identity layer.

NHI Mgmt Group has long treated unmanaged access as a lifecycle failure rather than a tooling gap, which is why SaaS governance needs to sit alongside human access reviews and machine identity oversight rather than outside them.

Key questions

Q: How should organisations govern SaaS access across business units?

A: Start with ownership, not inventory alone. Every SaaS application should have a named business owner, an IT owner, and a clear offboarding path. Then map users, contractors, and integrations to each app so access reviews can confirm who still needs it. That approach turns SaaS management into a lifecycle control instead of a licence-counting exercise.

Q: Why does SaaS sprawl create identity risk?

A: SaaS sprawl creates risk because access multiplies faster than governance. Each new application adds users, passwords, integrations, and third-party trust relationships. If teams cannot see who uses what and why, they cannot reliably revoke access, certify entitlements, or detect shared-account misuse. The result is lingering privilege and poor accountability.

Q: What do security teams get wrong about SaaS offboarding?

A: They often treat offboarding as a finance or procurement issue rather than an access control event. In practice, the risky part is not the cancelled subscription but the accounts, sessions, tokens, and shared credentials that remain active. Offboarding must therefore remove access from the application layer, not just close the purchase order.

Q: Which controls matter most when SaaS platforms handle sensitive data?

A: The controls that matter most are data classification, account ownership, access review, and offboarding discipline. If an application stores personal or regulated data, teams also need stronger logging, shared-account restrictions, and third-party governance. The goal is to ensure that SaaS convenience does not outrun identity and data accountability.

Technical breakdown

Who owns SaaS access and renewal governance?

SaaS management fails when ownership is vague. Every application has multiple decision points: who pays, who approves, who renews, and who retires the access. Without a clear owner, licence sprawl turns into orphaned entitlements, duplicated subscriptions, and weak accountability for offboarding. In identity terms, that is a lifecycle failure, because access remains active after the business need changes. The article’s emphasis on identifying key IT persons is really an ownership model for application governance.

Practical implication: assign a named owner for every SaaS application and tie renewal and offboarding tasks to that owner’s workflow.

Why SaaS portfolios need user-level visibility

A SaaS portfolio only becomes governable when organisations can answer who is using what and why. User-level visibility exposes duplicated tools, shadow subscriptions, and accounts created for one project but retained for months or years. That visibility also reveals where employees share access or where contractors keep credentials after their engagement ends. This is not just application rationalisation. It is access intelligence, and it forms the basis for recertification, deprovisioning, and control of unmanaged usage across departments.

Practical implication: maintain application-to-user mapping and review it as part of access certification and offboarding, not only finance reviews.

How SaaS sprawl creates security and compliance gaps

SaaS expands the attack surface because each application introduces authentication, shared data, and third-party trust boundaries. If an organisation cannot see how data is stored, how passwords are handled, or whether accounts are shared, the security model breaks down quickly. The article’s reference to GDPR also shows that SaaS governance intersects with regulatory obligations when personal data crosses applications and vendors. In practice, unmanaged SaaS is often where identity controls fail first because the business adopts the app faster than governance catches up.

Practical implication: classify SaaS applications by data sensitivity and identity risk, then enforce controls for shared accounts, password use, and offboarding.

NHI Mgmt Group analysis

SaaS governance is an identity lifecycle problem before it is a software portfolio problem. The article’s six steps are really about control ownership, entitlement visibility, and offboarding discipline. When organisations ask who is using what and why, they are already in lifecycle territory because access, not subscription count, is what creates operational risk. Practitioners should treat SaaS inventory as a governance input, not the end state.

Shared accounts and unmanaged offboarding are the hidden failure modes in SaaS estates. The article’s warning about password sharing and off-boarding points to a familiar pattern: access outlives the business need. That failure mode is not solved by procurement oversight alone. It is solved only when IAM, security, and application owners treat account retirement as part of the service lifecycle.

Identity blast radius: SaaS sprawl increases the number of places where one stale account, one shared password, or one unreviewed vendor connection can expose multiple systems at once. The more distributed the application layer becomes, the more difficult it is to contain privilege creep and unknown access paths. For practitioners, that means the governance unit is the account and its lifecycle, not the subscription line item.

Compliance pressure will keep pulling SaaS management into formal identity controls. The article’s GDPR reference is a reminder that application governance becomes auditable only when access and data handling can be traced back to named owners. That pushes SaaS management closer to IAM, IGA, and third-party risk governance. Practitioners should expect the control question to shift from adoption to accountability.

NHI oversight and SaaS governance are converging through third-party access. SaaS ecosystems increasingly include service accounts, API integrations, and automated workflows alongside human users. That means unmanaged SaaS is not only a human access issue. It is also a machine and integration identity issue, and teams that separate those programmes will miss the combined risk.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For a deeper control model, see NHI Lifecycle Management Guide, which extends the same accountability logic into provisioning, rotation, and offboarding.

What this signals

Identity blast radius: as SaaS portfolios expand, the real governance problem is not the number of apps but the number of places where one stale account can create cross-system exposure. Teams that still treat SaaS as a procurement topic will miss the lifecycle failures that actually drive risk.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, SaaS governance increasingly overlaps with secrets hygiene and integration oversight. That means application review cycles need to include human access, automated access, and the credentials that tie them together.

For practitioners, the next step is to join SaaS inventory to control ownership, access review, and third-party governance. The organisations that do this well will have a clearer path to auditability because they can explain not only what tools exist, but who can still act through them.

For practitioners

• Assign a named owner to every SaaS application Map each app to a business owner and an IT owner, then require those owners to approve renewals, retire unused licences, and validate offboarding. This creates a clear accountability chain for access decisions and prevents orphaned subscriptions from lingering.
• Create a user-to-application access map Maintain a current inventory of which users, contractors, and integrations can access each SaaS application, including shared accounts and delegated access. Use that map in access reviews so certification is based on real usage rather than procurement records.
• Fold SaaS offboarding into IAM workflows Make account removal, token revocation, and password resets part of the same offboarding workflow used for HR leavers and contractor exits. Include application-specific checks for active sessions, external sharing, and connected integrations.
• Review SaaS security with a data and identity lens Classify applications by the sensitivity of the data they store and by the identity controls they require, including MFA, shared-account restrictions, and retention rules. This helps separate low-risk tools from applications that need stronger governance.
• Track unmanaged usage as a control gap Measure shadow subscriptions, unapproved apps, and personal account use outside the sanctioned application list. Treat those findings as evidence of control drift, not just cost waste, and route them into governance remediation.

Key takeaways

• SaaS management is no longer just about cost control. It is an identity governance problem because access, ownership, and offboarding determine the real risk.
• The biggest failure modes are familiar ones: shared accounts, missing ownership, stale access, and unmanaged integrations that outlive the business need.
• Practitioners should connect SaaS inventory to IAM, IGA, and lifecycle controls so application growth does not become invisible privilege growth.

Key terms

• SaaS Governance: The set of policies and operational controls used to manage SaaS applications across ownership, access, spend, and risk. In practice, it connects procurement decisions to identity lifecycle controls so applications can be reviewed, retired, and audited like any other access surface.
• Application Ownership: The assignment of clear responsibility for an application’s use, renewal, security, and retirement. In identity programmes, ownership matters because no access review or offboarding workflow works well when nobody is accountable for the application itself.
• Access Recertification: A periodic review of who still needs access to an application, system, or entitlement. For SaaS, recertification must include users, contractors, and integrations, because stale access often survives longer than the business need that created it.
• Shared Account Risk: The security and accountability problem created when multiple people use the same login or credential. Shared accounts weaken traceability, complicate offboarding, and make it difficult to prove who performed an action inside a SaaS application.

What's in the full article

Efecte's full post covers the operational detail this analysis intentionally leaves for the source:

• Practical guidance for assigning application owners across IT, finance, and business teams.
• Specific ways to track who is using what and why across SaaS estates.
• Discussion of vendor consolidation, spend control, and under-utilised capability cleanup.
• The article's own examples of security and compliance concerns around passwords, account sharing, and GDPR.

👉 The full Efecte post expands on governance, spend, security, and compatibility checks for SaaS estates.

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 building or maturing an IAM programme, it is worth exploring.