SaaS security posture management is becoming identity governance

At a glance

What this is: This is a vendor roundup of SaaS security posture management tools, with the main finding that SSPM is being positioned as an identity governance and risk visibility problem, not just a cloud security checkbox.

Why it matters: It matters because SaaS apps, app-to-app access, and shadow IT now sit inside broader IAM and NHI programmes, so practitioners need posture controls that map to ownership, access review, and remediation workflows.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Zluri's roundup of the top 11 SaaS security posture management tools

Context

SaaS security posture management is the discipline of finding, assessing, and controlling risk across cloud applications, but in practice it now overlaps with identity governance because every connected app brings permissions, shared data, and offboarding risk. In that sense, SSPM is less about a tool category and more about how organisations govern access across a fast-growing SaaS estate.

Zluri’s roundup reflects a common market pattern: teams are buying posture tooling to compensate for incomplete visibility, inconsistent app ownership, and weak remediation loops. That is a familiar identity problem, whether the subject is human access, service accounts, or delegated app permissions.

The first-order issue is not how many tools exist. It is whether the organisation can turn discovery data into ownership, review, restriction, and retirement decisions before risky SaaS access becomes operational debt.

Key questions

Q: How should security teams govern SaaS applications that connect to identity systems?

A: Security teams should treat connected SaaS applications as governed identity surfaces, not as isolated tools. That means assigning ownership, rating permission impact, reviewing delegated access regularly, and revoking stale integrations when business use changes. The goal is to turn discovery data into a lifecycle decision, not just a visibility report. A single live inventory is the practical starting point.

Q: Why do SaaS apps create identity governance gaps?

A: SaaS apps create governance gaps because access often expands through delegated permissions, shadow IT, and untracked app ownership. Once an app is connected, it can retain data access long after the original approval is forgotten. That breaks joiner-mover-leaver assumptions and makes offboarding incomplete unless app ownership and review cadence are explicit.

Q: What is the difference between SaaS posture management and access governance?

A: SSPM focuses on discovering apps, scoring their risk, and surfacing misconfigurations, while access governance decides who or what should keep access and for how long. The two overlap, but they are not the same. SSPM becomes more useful when its findings feed recertification, restriction, and offboarding workflows.

Q: How can organisations tell whether SaaS security controls are working?

A: They are working when unmanaged apps shrink, high-risk permissions are reviewed on schedule, and app ownership is always identifiable. If posture data does not lead to removal, restriction, or recertification, the programme is producing visibility without control. A healthy signal is a shorter gap between app discovery and governance action.

Technical breakdown

SaaS discovery and shadow IT visibility

SSPM begins with discovering which SaaS applications exist, who uses them, and what data or identity connections they touch. In practice, this is an inventory problem with security consequences: unmanaged apps create blind spots in ownership, approval, and review. Discovery alone does not equal control, but without it, no downstream governance process can be reliable. The category often surfaces shadow IT because the real risk is not only the app itself, but the untracked identity paths created when users connect services outside approved workflows.

Practical implication: build a single SaaS inventory that ties every app to an owner, access path, and review cadence.

Risk scoring, policy enforcement, and SaaS access controls

SSPM platforms typically combine risk scoring with policy enforcement to decide which apps should remain, be restricted, or be removed. The technical model is straightforward: ingest app metadata, compare it to control rules, and push a governance decision back into the SaaS or identity layer. This only works when the risk model reflects real access impact, such as whether an app can read, modify, or delete business data. If scoring is disconnected from actual privileges, the output looks rigorous but does little to reduce attack surface.

Practical implication: align SaaS risk scores to actual permission scope, not just vendor reputation or app category.

Compliance reporting and audit-ready SaaS governance

A second core SSPM function is generating evidence for audits, recertification, and compliance reviews. That means showing which apps are approved, which data they touch, and whether the control state matches policy over time. For IAM teams, this matters because SaaS sprawl often escapes the normal joiner-mover-leaver process. The governance question is not whether a tool can export a report, but whether the underlying evidence is current, attributable, and useful for access decisions.

Practical implication: require audit evidence that links app ownership, data exposure, and remediation status in one control record.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Snowflake breach — Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSPM is becoming an identity control surface, not just a SaaS hygiene layer. The article’s own emphasis on discovery, risk scores, compliance, and app restriction shows that the category now sits inside governance rather than around it. That matters because every SaaS connection is also an identity relationship, and those relationships outlive the original approval unless someone owns them. Practitioners should treat SSPM outputs as inputs to IAM and IGA, not as a separate security silo.

Shadow IT in SaaS is fundamentally an ownership failure. The problem is not merely that an app exists outside formal approval. It is that no one can reliably answer who approved it, who owns the access, and when it should be reviewed or retired. That is why discovery tools have value only when they feed lifecycle governance. Teams should use SSPM to expose unmanaged ownership, then force that data into access review and offboarding processes.

Standards-driven SaaS governance is where posture data becomes operational. The strongest fit here is NIST Cybersecurity Framework 2.0, because the article is really about identify, protect, detect, respond, and recover across SaaS-connected identity paths. The named concept here is SaaS identity surface: the full set of application permissions, connected accounts, and data paths that make SaaS a governance boundary. Practitioners should measure that surface the same way they measure endpoint or cloud exposure.

For NHI programmes, SaaS posture is a proxy for secret and token exposure. Once SaaS tools start managing connected apps, shared data, and delegated permissions, they begin to overlap with NHI risk in the form of API keys, OAuth grants, and service integrations. That means posture review cannot stop at application configuration. Practitioners should extend governance to the identities and secrets that allow SaaS apps to act at all.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• That visibility gap is why practitioners should pair discovery with lifecycle governance, using NHI Lifecycle Management Guide to turn posture data into revocation and review actions.

What this signals

SaaS identity surface: the category is moving toward a broader control plane that combines discovery, delegated access review, and offboarding. Teams that treat SSPM as a reporting layer will keep finding risk without reducing it, because the real issue is the lifecycle of connected identity relationships. The relevant control question is whether every app can be tied to a current owner and a current business purpose.

For identity teams, the programme implication is clear. SaaS governance, NHI governance, and app ownership are converging, so operational models that split them across separate teams will create duplicate blind spots. The strongest posture programmes will use discovery to trigger access review, secrets review, and removal decisions in the same workflow.

The fact that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps shows how fast delegated access can outrun manual governance. That makes posture data a leading indicator, not a finish line, and it raises the bar for evidence quality in both IAM and audit programmes.

For practitioners

• Map every SaaS app to an accountable owner Create a live inventory that ties each application to a business owner, technical owner, approval path, and review cadence. Without ownership, discovery data cannot drive remediation or offboarding.
• Score applications by permission impact Classify apps based on whether they can read, modify, delete, or share business data, then use that score to drive restrictions and review priority. Treat high-impact permissions as governance triggers, not just metadata.
• Feed SSPM findings into access review workflows Route unmanaged apps, risky integrations, and stale approvals into access recertification and lifecycle processes so posture data becomes an enforceable decision. The goal is to turn visibility into revocation or restriction.
• Tie SaaS governance to secrets and delegated access checks Review which apps rely on OAuth grants, API keys, or stored credentials, and verify that those identities are rotated or removed when app ownership changes. This closes the gap between posture data and actual access paths.

Key takeaways

• SSPM now sits inside identity governance because SaaS risk is really about ownership, delegated access, and lifecycle control.
• Discovery without enforcement only documents shadow IT, while discovery plus recertification creates an actual control loop.
• Practitioners should treat app permissions, OAuth grants, and stored credentials as part of the same SaaS identity surface.

Key terms

• SaaS Security Posture Management: SaaS Security Posture Management is the practice of finding and assessing configuration, access, and compliance risk across cloud applications. It combines inventory, risk scoring, and control enforcement so security teams can reduce exposure in apps that are already connected to business data and identity systems.
• SaaS Identity Surface: The SaaS identity surface is the full set of application permissions, delegated accounts, OAuth grants, and data paths created by connected SaaS tools. It is the part of the environment where access, ownership, and lifecycle control intersect, and it becomes risky when those relationships are not reviewed or retired.
• Shadow IT: Shadow IT is the use of applications or services outside formal approval and governance processes. In SaaS environments, it is especially risky because hidden apps can still carry active permissions, data access, and delegated identity connections that outlive the original business need.
• Delegated Access: Delegated access is permission granted to one application or service to act on behalf of a user, group, or system. In SaaS governance, it creates durable access paths that must be reviewed like any other identity relationship, because the app can retain reach even after human ownership changes.

Deepen your knowledge

SaaS discovery, delegated access review, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your SaaS estate is growing faster than your ownership model, the course is a practical place to start.

This post draws on content published by Zluri: Top 11 SaaS Security Posture Management Tools in 2026. Read the original.