Identity arsenal gap shows why IdP dashboards miss shadow SaaS

At a glance

What this is: This is an analysis of how traditional IdP-centric IAM misses unmanaged applications, with the key finding that authentication can occur before discovery or governance.

Why it matters: It matters because IAM, IGA, and security teams cannot rely on dashboards or quarterly discovery alone when users can create trust events in shadow SaaS instantly.

By the numbers:

• Most traditional identity controls leave out the 50%–85% of applications that don’t natively support these frameworks.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read Unixi's analysis of the identity arsenal gap and Shadow SaaS governance

Context

Traditional identity programmes often assume that an application must be discovered, reviewed, and integrated before access can be governed. In practice, users authenticate to new SaaS tools, browser-based services, and AI productivity apps long before security teams build a formal control path, which creates an identity arsenal gap in the enterprise IAM model.

That gap matters because IdP dashboards can look clean while unmanaged authentication is still happening outside the governance perimeter. For teams responsible for NHI, human IAM, and emerging agentic AI access, the lesson is the same: visibility lag turns identity controls into hindsight controls, and hindsight is not a security strategy. See the Ultimate Guide to NHIs for the lifecycle and visibility baseline that traditional programmes still need to close.

Key questions

Q: How should security teams govern shadow IT in SaaS environments?

A: Security teams should govern shadow IT by treating it as unmanaged access, not just unsanctioned software. Start with continuous discovery, then map each app to owners, data types, delegated scopes, and revocation paths. The control goal is to reduce hidden access paths before they become business-critical dependencies.

Q: Why do traditional IAM controls fail to capture the real application footprint?

A: Because most IAM programmes are built to govern apps after discovery and integration, while users can authenticate to new services immediately. That timing gap means quarterly inventory and manual onboarding always trail actual usage. The result is a dashboard that looks complete even when access is still happening elsewhere.

Q: What is the difference between application discovery and runtime visibility?

A: Application discovery tells you what exists in the environment, usually after the fact. Runtime visibility tells you what is actually authenticating right now, which is the control point that matters when users can create trust relationships before formal onboarding. For governance, the second is the one that closes exposure.

Q: How can IAM teams reduce the impact of browser or device compromise on credentials?

A: Move secrets into a dedicated vault, enforce unique passwords, and verify that offboarding removes access cleanly across all synced devices. Then test what remains exposed if a browser session or endpoint is taken over. The goal is to keep one compromise from becoming a full credential event.

Technical breakdown

Why discovery lags authentication in modern IAM

Discovery is a governance process, not an access prerequisite. In browser-driven work, a user can authenticate to a SaaS app with a password, OAuth token, or federated login before the app is ever inventoried by IT. That creates a timing mismatch: the trust decision happens at the point of use, while governance happens later through audit, review, or integration. This is why traditional IdP-centric models can be accurate for known applications yet blind to the broader usage surface. The issue is structural, not cosmetic.

Practical implication: shift from periodic app discovery to continuous authentication visibility so governance can begin at first use.

What the identity arsenal gap means for shadow SaaS

Shadow SaaS is not just unsanctioned software. It is any application that sits outside the identity control plane because it lacks native SAML, SCIM, or formal provisioning hooks. When those apps still accept valid credentials, trust is established without the normal governance controls that IAM teams depend on. That produces an unmanaged access lane where data can be stored, shared, and exfiltrated without appearing in standard identity workflows. The problem is less about the app category and more about the control model failing to see it in time.

Practical implication: classify unmanaged SaaS by authentication method and data exposure, then prioritise the highest-risk apps for runtime visibility.

How browser-level governance changes the control point

Browser-level identity control moves the enforcement point closer to the actual authentication event. Instead of waiting for backend integration, the control layer can observe and govern the session as it forms, which is useful when the app is unmanaged or does not support enterprise federation. That does not eliminate IAM, but it changes where control starts. The architectural shift is from post-discovery administration to real-time observation and policy application at the edge of the session.

Practical implication: evaluate whether your control stack can govern sessions before backend onboarding, not only after federation is in place.

NHI Mgmt Group analysis

Identity governance fails when discovery is treated as a prerequisite for control. Traditional IAM programmes were built around known applications, known connectors, and known provisioning paths. That assumption breaks in browser-mediated work because authentication can occur before discovery ever happens. The implication is that visibility lag is now a governance defect, not a reporting inconvenience.

The identity arsenal gap is a named control gap, not a user behaviour problem. The core issue is not that employees are careless, but that the enterprise control plane does not see every application where identity events occur. When an app lacks SAML or SCIM support, the identity stack often has no native enforcement path. Practitioners should treat unmanaged authentication surface as an architecture gap that expands risk faster than policy reviews can reduce it.

Visibility must become continuous if IAM is expected to govern Shadow SaaS. Quarterly discovery and periodic audit are too slow for environments where users can create new trust relationships in minutes. This is where NHI governance, human IAM, and AI-adjacent access patterns converge: the control question is not who approved the app, but whether the session could be seen at the moment access was granted. Teams need to rethink control timing, not just control coverage.

The future IAM programme will look more like runtime governance than inventory management. When authentication happens first and discovery happens later, the dashboard becomes an evidence source, not an enforcement mechanism. That changes how organisations should think about application ownership, data placement, and access review scope. The practical conclusion is that identity teams must govern what is actually authenticating, not only what has been formally onboarded.

From our research:

• 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.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity governance is operating with incomplete inventory.
• That visibility problem is also why the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs remains the best next step for teams trying to close governance gaps across human, machine, and shadow access.

What this signals

Identity arsenal gap: enterprises should expect governance pressure to shift from onboarding workflows to continuous session visibility, because static inventories no longer describe the actual access surface. Teams that still equate a green IdP dashboard with control will undercount unmanaged SaaS, browser-based access, and emerging AI-driven usage paths.

The practical next move is to treat runtime visibility as an identity control, not a nice-to-have telemetry layer. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need to identify, protect, detect, respond, and recover across the full access surface, not just the applications that were formally integrated.

For programmes that already track non-human access, the same logic applies to human and machine identity: if the session is real, the risk is real, regardless of whether the app has been onboarded. That is why lifecycle governance, access review scope, and data placement decisions need to be redesigned around what is actually authenticating rather than what the directory says should exist.

For practitioners

• Map unmanaged authentication paths Inventory browser-authenticated SaaS and productivity apps that bypass SAML, SCIM, or formal onboarding. Prioritise the apps that accept corporate credentials and store sensitive data before quarterly discovery can catch them.
• Separate visibility from onboarding Create a runtime visibility layer for sessions that occur outside the normal IdP workflow so governance can start at first use rather than after integration.
• Classify shadow apps by identity risk Rank unmanaged apps by the credential type used, the data stored, and whether the app can be accessed with reusable tokens or passwords that extend exposure beyond a single session.
• Extend access review scope beyond managed apps Include shadow SaaS and browser-level authentications in recertification so reviews reflect the real application footprint, not just the IdP dashboard.

Key takeaways

• The central problem is a visibility gap, not a lack of policy, because authentication can occur before governance sees the application.
• The article’s evidence points to a large unmanaged application surface, which makes dashboard-based confidence misleading for IAM teams.
• Practitioners need runtime visibility and broader recertification scope if they want identity governance to reflect actual access, not just managed access.

Key terms

• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.
• Identity arsenal gap: The identity arsenal gap is the space between the applications an enterprise can govern and the applications where authentication is actually happening. It shows up when tools depend on backend integration before they can enforce policy, creating a time lag that attackers, users, and unmanaged workflows can exploit.
• Runtime Visibility: The ability to observe what an AI client actually accessed, which tools it used, and how it behaved during a session. It is more useful than entitlement snapshots for agent governance because it captures executed reality, not just approved access.
• Browser-mediated identity: Browser-mediated identity is access that is established, maintained, or abused through the web session rather than only through a traditional login boundary. It matters because cookies, tokens, and session state can become attack assets, especially when unmanaged devices and SaaS applications are involved.

What's in the full article

Unixi's full article covers the operational detail this post intentionally leaves for the source:

• Browser-level discovery mechanics and how Key Derived Authentication is applied in practice
• How universal single sign-on is handled for unmanaged and shadow applications without backend configuration
• The specific implementation logic behind continuous discovery across decentralized work environments
• Why the approach avoids the traditional SSO tax and what that means for operational deployment

👉 The full Unixi article covers browser-level control, continuous discovery, and universal SSO mechanics in more detail.

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.