IT risk management software leaves the identity surface exposed

At a glance

What this is: A Zluri roundup of IT risk management software argues that these tools help centralise risk visibility, automate monitoring, and surface SaaS exposure, but often stop short of governing identity as a boundary.

Why it matters: For IAM, IGA, PAM, and NHI teams, the gap matters because risk tooling that cannot govern access scope, delegated permissions, and lifecycle boundaries leaves identity exposure unmanaged.

Context

IT risk management software is intended to consolidate risk registers, monitoring, and response into one operational view. In practice, that only helps if the tool can see beyond systems and into the identities that use them, especially when SaaS sprawl and delegated access multiply the number of permission paths.

Zluri’s article frames the problem as one of visibility, but the deeper issue is governance. If identity exposure is treated as a reportable signal rather than a control boundary, then human users, app-to-app permissions, and machine access all remain part of the same unmanaged risk surface.

Key questions

Q: How should teams govern SaaS access when risk software only shows reporting data?

A: Teams should treat reporting as an input, not a control. If the platform can show that an app has broad access but cannot drive entitlement review, approval, and revocation, then governance still sits elsewhere. The practical test is whether risk visibility changes the access decision, not whether it produces a dashboard.

Q: Why does SaaS sprawl increase non-human identity risk?

A: SaaS sprawl increases NHI risk because every new integration can create tokens, service accounts, OAuth grants, and delegated permissions that persist outside normal review cycles. Those identities often have more reach than human users and fewer lifecycle checks. The result is wider attack surface and harder-to-audit access paths.

Q: What breaks when delegated app permissions are not part of IT risk management?

A: The governance model breaks at revocation. Teams may know an app exists and even score it as risky, but they still cannot answer who owns its access, when it should be removed, or whether the grant is broader than necessary. That leaves stale and overbroad permissions in place after the original need has passed.

Q: Should organisations use risk scores or entitlement reviews to control SaaS exposure?

A: They need both, but entitlement reviews carry the decision power. Risk scores help prioritise where to look, while reviews and offboarding decide whether access stays. If a score does not influence scope reduction or removal, it is only measurement. Governance starts when the score changes the entitlement.

Technical breakdown

Risk registers do not equal identity governance

A central risk register is useful for organising threats, owners, likelihood, and impact, but it is not the same thing as governing access. Risk software often aggregates findings from SaaS, cloud, and compliance systems without resolving whether the underlying identity is a human user, service account, or delegated application permission. That matters because each subject has a different lifecycle, revocation trigger, and blast radius. If the platform only records the risk after exposure is already present, the control plane remains descriptive rather than preventative.

Practical implication: treat risk registers as downstream evidence and require separate controls for identity lifecycle, entitlement scope, and revocation.

Why SaaS sprawl turns into identity exposure

The article’s emphasis on SaaS discovery points to a common failure mode: the more applications and integrations an organisation adds, the more identity edges it creates. Each app can bring its own OAuth grants, SSO trust, admin roles, and shadow access paths. When those connections are only inventoried as applications, teams miss the fact that the real security object is the identity relationship between systems. That relationship can outlive the user who created it, the app that owns it, or the approval that justified it.

Practical implication: inventory application-to-application and user-to-app relationships as first-class identity objects, not just as software assets.

Automated alerts are not the same as governed access

The article describes automated monitoring and alerts as a core feature of risk management software, but alerts alone do not change access behaviour. Detection can show that an application can modify files, read data, or connect through SSO, yet it does not answer whether that permission should exist, who approved it, or how it will be removed. In identity governance terms, that is a gap between observation and enforcement. The tool can flag unusual access, but governance still has to decide whether the access is valid at all.

Practical implication: pair monitoring with entitlement review and removal workflows so detection leads to enforcement, not just notification.

NHI Mgmt Group analysis

Identity surface, not infrastructure surface, is the real boundary IT risk tools fail to govern: The article describes risk management software as a way to centralise threats, controls, and reports, but that framing is incomplete when access is distributed across SaaS, SSO, and delegated application permissions. Once identity is the mechanism that connects the systems, the governance boundary has to move to the identity layer. Practitioners should judge these tools by whether they can represent and control identity relationships, not just catalogue software risk.

Identity exposure is a governance problem because the risk object persists after the original business action ends: A SaaS integration can outlive the user who approved it, the admin who configured it, or the workflow that justified it. That is why reporting alone does not close the exposure window. The field needs to treat delegated permissions as governed lifecycle objects, not as static configuration records.

Centralised risk scoring can create a false sense of control when entitlement scope is still unchecked: A high threat score on an application tells you something is risky, but it does not tell you whether the risky part is the app itself, the data it can access, or the identity grant that connects it to business systems. The practical conclusion is that risk scores must be paired with entitlement scope and offboarding governance before they have operational meaning.

Machine and human access now collapse into the same SaaS risk model: The article focuses on IT risk management software, but the underlying exposure pattern spans human users, service identities, and delegated app permissions. That makes identity governance cross-domain by default. Organisations that still separate SaaS risk, IAM, and NHI governance will miss the combined attack surface created by modern application sprawl.

Identity blast radius is the most useful concept for this category: The article’s strongest insight is not that risk software can report more, but that it can reveal how far a single identity relationship can propagate across SaaS tools. That blast radius becomes the measure that matters when access, data sharing, and integrations are all linked. Practitioners should use that concept to decide which identities, grants, and apps require the closest control.

What this signals

Identity exposure becomes the hidden control plane in SaaS-heavy environments: When organisations add more applications, the real risk growth comes from the identity relationships connecting them. Teams should therefore measure how many access paths each app introduces, not just how many apps appear in the estate.

Risk tooling should be judged by whether it changes access outcomes: A dashboard that only reports threat levels is not enough if no workflow exists to narrow permissions, remove stale grants, or force ownership. Practitioners need to know whether the tool can drive entitlement decisions, not simply describe risk.

Delegated access needs lifecycle ownership: App permissions, SSO trust links, and service access should have a clear owner and removal condition. Without that, identity exposure persists long after the business reason for the grant disappears.

For practitioners

• Map identity relationships, not just applications Build inventories that connect users, service accounts, OAuth grants, SSO links, and admin roles to each SaaS app so you can see the actual access graph.
• Separate detection from enforcement Use monitoring and risk scores to surface exposure, then tie those signals to entitlement review, approval, and revocation workflows.
• Classify delegated access by lifecycle owner Assign each third-party permission, integration, and app role to a named business owner and a removal trigger so access does not survive the need for it.
• Test whether risk scores change access decisions Validate that a higher risk score actually results in tighter scope, shorter approval windows, or removal of access, rather than a dashboard-only escalation.

Key takeaways

• IT risk management software is useful for visibility, but identity relationships remain the part that most often escapes control.
• In SaaS-heavy environments, the attack surface expands through delegated access, integration sprawl, and broad permissions.
• The practical response is to connect risk scoring to entitlement review, removal triggers, and ownership for every access path.

Key terms

• Identity Surface: The identity surface is the full set of credentials, tokens, tool permissions, and delegated identities an AI agent can use during execution. It matters because agents often do not operate through a single account, and partial visibility into that surface creates false confidence about control coverage.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Entitlement review: A governance process that checks whether users, service accounts or systems still need their access. For modern identity programmes, the limitation is timing: if reviews happen too late or too rarely, access may already have been misused before the review occurs.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.