SaaS security posture management exposes the limits of IAM

At a glance

What this is: This is Zluri’s summary of Forrester’s SaaS Security Posture Management Wave, with a focus on how SaaS access complexity and admin misconfiguration strain traditional IAM.

Why it matters: It matters because IAM, IGA, and PAM teams increasingly have to govern SaaS-native access patterns that sit outside classic directory-centric controls.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface

👉 Read Zluri's summary of Forrester's SaaS Security Posture Management Wave

Context

SaaS security posture management is the discipline of finding, evaluating, and correcting risky configuration and access conditions across SaaS applications. The problem exists because SaaS permissions, admin roles, and OAuth-connected integrations multiply faster than manual review cycles can handle, leaving identity teams with incomplete visibility into who can do what inside business-critical apps.

For IAM, IGA, and PAM programmes, the key issue is that SaaS access governance is no longer just directory administration. It now includes admin privilege discovery, app-level policy review, and remediation workflows that need to work across federated SaaS estates, not just within the corporate directory boundary.

Key questions

Q: How should security teams govern SaaS admin access across many applications?

A: Start by mapping each critical SaaS application’s admin roles, data-access settings, and approval paths. Then assign owners, define review cadence, and make revocation part of the same workflow as approval. The goal is to govern the application-level control plane, not just the identity directory.

Q: Why do traditional IAM tools struggle with SaaS security posture management?

A: Traditional IAM tools focus on authentication and central entitlements, but SaaS risk lives in app-specific roles, delegated consents, and configuration settings. That means the most dangerous exposure often sits outside the directory view. Teams need posture visibility at the application layer, not only at login or federation.

Q: What do security teams get wrong about OAuth-connected SaaS apps?

A: They often treat OAuth consent as a one-time setup step instead of a standing authorization that can outlive the original need. In practice, third-party apps may retain access long after ownership changes or project needs shift. Governance should track every grant as an accountable access path.

Q: How can organisations reduce risky SaaS permissions without slowing the business?

A: Use risk-prioritised workflows that let teams detect, approve, and revoke high-risk access in one process. That reduces the delay between finding a problem and fixing it. The best pattern is not more manual review, but faster governance actions tied to clear ownership.

Technical breakdown

SaaS posture management and admin entitlement drift

SaaS posture management looks for misconfiguration inside the application layer, where access is shaped by app-specific roles, tenant settings, and delegated admin rights. Traditional IAM tools were built to govern identities at the directory or federation layer, but SaaS apps often create their own permission models that diverge from central policy. That is why manual review does not scale when apps, admins, and integrations keep changing. Practical implication: security teams need visibility into SaaS-native roles and configuration states, not just user identity records.

Practical implication: Map each critical SaaS app’s admin and data-access model to a review process that can detect drift before it becomes exposed privilege.

OAuth-connected SaaS apps and delegated access risk

OAuth-connected apps extend access beyond the enterprise directory by allowing third-party services to act on behalf of users or workloads. That creates delegated trust relationships that are often invisible to standard IAM reports, especially when app permissions are granted broadly and never revisited. The security issue is not only authentication, but the persistence of authorization granted through tokens and app consents. Practical implication: governance must include visibility into third-party app consents and the scope of delegated permissions across the SaaS stack.

Practical implication: Inventory OAuth grants and third-party app consents so you can revoke standing access that no longer has a valid business purpose.

Why JIT access and workflow remediation matter in SaaS

SaaS posture tools become materially more useful when they can move from identification to remediation. Just-in-time access and workflow-linked misconfiguration fixes reduce the time privileged access remains active, while also giving security teams a way to treat SaaS admin rights as temporary rather than permanent. In practice, this is about turning SaaS access from a static entitlement problem into a governed lifecycle problem. Practical implication: control points should combine detection, approval, and revocation in one workflow instead of leaving each step to separate teams.

Practical implication: Use workflow-based remediation so risky SaaS permissions can be corrected quickly without relying on manual ticket handoffs.

NHI Mgmt Group analysis

SaaS posture management is becoming the control plane for identity in business applications. Traditional IAM stops at the boundary of authentication and directory policy, but SaaS risk sits inside the application where admins, permissions, and sharing settings define real exposure. That makes posture management less of a niche product category and more of an identity governance layer for SaaS-heavy enterprises. Practitioners should treat it as an extension of IAM and IGA rather than a separate security silo.

Manual permission review is no longer a viable control for SaaS estates. The report’s underlying problem is scale: access artifacts, admin roles, and app configurations multiply faster than review teams can certify them. When that happens, governance becomes periodic and retrospective while the risk is continuous. Practitioners need to re-evaluate whether access review cadences are aligned to the actual pace of SaaS change.

Third-party OAuth access is a visibility problem before it is a breach problem. Once external apps can act through delegated consent, the real issue is whether security teams can see the scope of those grants and tie them back to accountable owners. That is a governance gap, not just a technical one. Practitioners should assume that any SaaS programme with broad OAuth usage has hidden access paths until proven otherwise.

Named concept: SaaS identity surface drift. The article points to a problem where configuration, delegated access, and admin entitlements expand faster than central governance can absorb them. That drift breaks the assumption that identity control is stable once access is provisioned. The implication is that identity teams must manage SaaS access as a living surface, not a fixed catalogue of roles and accounts.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity governance is still operating without complete asset visibility.
• For a deeper governance baseline, see Ultimate Guide to NHIs for lifecycle, rotation, and offboarding controls that help close visibility gaps.

What this signals

SaaS identity surface drift: once SaaS admin rights, delegated consents, and configuration settings accumulate faster than review cycles, governance shifts from preventive to reactive. That is the practical signal for IAM leaders to move control ownership closer to the app layer and away from directory-only thinking.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, privilege sprawl is the default condition in modern identity programmes. The same logic applies in SaaS estates, where admin roles and delegated access often outgrow the original approval intent.

The next governance step is to connect SaaS posture findings to lifecycle action, not just dashboards. Teams that can pair discovery with revocation, ownership, and review will be better positioned to manage SaaS risk at enterprise scale.

For practitioners

• Inventory SaaS admin paths across priority applications Build an app-by-app view of who can change settings, approve access, and delegate permissions in the SaaS platforms that matter most to the business. Focus first on the systems that carry customer, financial, or regulated data, then tie those admin paths back to named owners and review dates.
• Review OAuth consents and third-party app grants Identify all external apps connected through OAuth and classify the permissions they hold, the data they can reach, and the owner responsible for each grant. Prioritise removal of consents that have no current business justification or that were inherited without a reassessment.
• Replace manual certs with workflow-based remediation Use approval and revocation workflows that let security teams correct risky SaaS permissions without waiting for the next quarterly review. Where possible, make remediation part of the same process that detects the issue so access does not remain active after it has been flagged.
• Align SaaS governance to identity lifecycle controls Treat SaaS admin rights, app consents, and delegated access as lifecycle-managed privileges that can be provisioned, reviewed, and withdrawn. This helps IGA and PAM teams apply consistent control logic to SaaS settings rather than relying on ad hoc application ownership.

Key takeaways

• SaaS security posture management addresses the application-layer access and configuration drift that traditional IAM tools do not fully see.
• The biggest governance risk is not just misconfiguration, but standing delegated access and admin privilege that outlive the original business need.
• Practitioners should treat SaaS posture controls as part of IAM, IGA, and PAM lifecycle management, not as a separate bolt-on process.

Key terms

• SaaS Security Posture Management: SaaS Security Posture Management is the process of finding and correcting risky settings, permissions, and administrative exposures inside SaaS applications. It extends identity governance into the application layer, where access is often shaped by app-specific roles, sharing controls, and delegated consents.
• Delegated OAuth Access: Delegated OAuth access is authorization granted to a third-party application to act on behalf of a user or workload. The risk comes from the breadth and persistence of the consent, which can outlast the original business need if it is not reviewed and revoked.
• SaaS Identity Surface Drift: SaaS identity surface drift is the gradual expansion of admin rights, app settings, and shared access paths that central teams do not fully track. It matters because the effective identity boundary shifts inside the SaaS application, not just in the directory or federation layer.
• Application-Layer Governance: Application-layer governance is the set of controls that manage permissions, configuration, and accountability inside a business application rather than only at login. For SaaS, it is the difference between knowing who authenticated and knowing who can change data, policy, or access settings.

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 governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Forrester’s SaaS Security Posture Management Wave summary. Read the original.