SaaS discovery exposes shadow apps, but not the identity risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Unixi's blog post: Shadow SaaS discovery exposes unmanaged applications, but inventory alone does not close the identity risk if employees still authenticate with credentials that can be copied, intercepted, or stolen.

Why it matters: IAM and identity security teams need to treat discovery as a starting point, because governance fails when visibility does not change how authentication actually happens across shadow apps.

Context

Shadow SaaS discovery is the practice of finding applications that sit outside central identity controls such as SAML or OIDC SSO. The governance gap appears when teams treat that inventory as evidence of security instead of evidence of exposure, because the authentication path is unchanged.

The problem is not only app sprawl. It is that users can still type, paste, save, or reuse credentials in browser-based logins, which keeps the human in the authentication loop and leaves the organisation exposed to secret harvesting.

In other words, discovery tells you where the shadow apps are. It does not by itself remove the credential handling patterns that make those apps risky for IAM and NHI governance.

Key questions

Q: What breaks when SaaS discovery stops at inventory and not access control?

A: What breaks is the assumption that knowing an app exists reduces risk. If users still authenticate with passwords, pasted vault secrets, or saved browser credentials, the exposure path remains open. Discovery without control only increases visibility into the problem, it does not stop AiTM phishing, infostealer theft, or session replay.

Q: Why do shadow SaaS applications create more risk than traditional third-party reviews capture?

A: Shadow SaaS expands the attack surface because it bypasses procurement, security review, and normal identity controls. A vendor may look low risk on paper, yet the app can still handle sensitive data, connect to critical systems, and be accessed with weak authentication. That mismatch creates hidden exposure, compliance gaps, and unmanaged paths into the environment.

Q: How do security teams know whether a discovery programme is actually working?

A: Look for evidence that the programme covers the full estate, refreshes its baseline regularly, and produces a manageable rate of validated findings rather than alert noise. A working discovery programme should improve confidence in where sensitive data exists, not simply generate more reports about what might be there.

Q: Should organisations rely on password vaults for non-SAML apps?

A: Vaults help with storage, but they do not remove the human login step that attackers exploit. If employees still reveal credentials to the browser, AiTM phishing and infostealers can still capture them. Organisations should use vaults only as part of a control model that also changes how sessions are initiated and governed.

Technical breakdown

Why SaaS discovery stops at exposure, not control

Discovery platforms identify shadow applications by scanning usage, domain patterns, or browser activity, but that is an inventory function rather than an enforcement function. The architecture tells you what exists, not whether access is mediated through SSO, whether credentials are reused, or whether sessions are governed after login. In identity terms, discovery improves observability but does not change the authentication path. That means the attack surface remains intact if users still authenticate directly to the application outside centrally managed controls.

Practical implication: treat discovery output as a control input, not as evidence that the identity risk has been reduced.

How human login flows keep credential exposure alive

When users type, save, or copy credentials into a browser form, the secret becomes visible to phishing kits, reverse proxies, browser session theft, and endpoint malware. AiTM phishing works by relaying the login in real time and capturing the session token, while infostealers harvest cached secrets from endpoints after the fact. Vaults can store credentials, but if the human still performs the login, the exposure window remains open. The technical weakness is not just where secrets are stored, but when and how they enter the browser.

Practical implication: reduce the number of places where humans can present reusable credentials to the browser.

Why managed execution changes the identity model

Managed execution shifts access from user-handled secrets to centrally controlled session initiation. Instead of relying on employees to authenticate manually to every shadow application, the organisation inserts policy enforcement at the browser layer so the login sequence is mediated. That changes the control point from post-discovery administration to runtime access enforcement. It is a governance shift as much as a technical one, because the objective is not just knowing which apps exist, but ensuring access happens through controlled, auditable pathways.

Practical implication: govern access at the point of session creation, not after the app has already been discovered.

Threat narrative

Attacker objective: The attacker wants to capture reusable credentials or session tokens that let them continue accessing shadow SaaS applications outside enterprise control.

1. Entry occurs when users authenticate to shadow SaaS applications through typed, saved, or copy-pasted credentials instead of centrally mediated login paths.
2. Credential harvesting follows when AiTM phishing or infostealer malware captures reusable secrets or session material from the browser and endpoint.
3. Impact is preserved access to unmanaged applications, with stolen credentials and session tokens extending exposure beyond the original login event.

Breaches seen in the wild

• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Visibility is not governance: Shadow SaaS discovery creates an inventory of unmanaged applications, but an inventory is not a control plane. The governance failure is assuming that naming the app changes the access path. Practitioners should treat discovery as evidence of exposure, not evidence of remediation.

The real control gap is the human login loop: If employees can still type, save, or paste credentials into browser forms, the identity risk remains unchanged. AiTM phishing and infostealers exploit that loop because the secret still passes through human-visible handling. The implication is that security programmes must measure where credentials are presented, not just where apps are catalogued.

Managed execution is the missing governance layer: The article points to a named concept that matters here, browser-layer access governance, where policy is applied at session initiation rather than after inventory. That approach matters because shadow apps are often outside SAML support and cannot be made safe by discovery alone. Practitioners should rethink access governance as runtime enforcement across the browser, not as post-hoc app administration.

Discovery tools create administrative debt when they stop at the admin layer: Once an organisation has a list of shadow apps, the burden shifts to IT and SecOps to chase vendors, negotiate support, or rely on manual vaulting. Those paths preserve the exposure window and stall governance. The implication is that the programme must be designed to close access dynamically, not just document friction.

Identity assurance depends on how access is executed, not how complete the inventory looks: A full list of non-SAML apps does not reduce credential theft risk if the same users still authenticate manually. The article correctly frames this as a balance-sheet problem: quantified liability is not eliminated liability. Practitioners should redesign the identity model so app discovery is followed by enforced session control.

From our research library:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.

What this signals

Shadow app discovery should trigger access redesign, not just cleanup: When discovery exposes a long tail of non-SAML tools, the next question is not how many apps exist but how authentication is still being executed. If the human login loop remains intact, the programme has only improved visibility, not resilience.

Browser-layer governance becomes the differentiator: The article points toward a control model that mediates session creation before the user reaches the application. That is a materially different posture from inventory-led governance, because it changes the point at which access is enforced and audited.

The practical signal for IAM and NHI teams is simple: if discovered apps are still reachable through typed or copied credentials, the organisation has not solved shadow IT risk, it has only documented it.

For practitioners

• Map shadow apps to authentication paths Classify each discovered SaaS application by how users actually sign in, including typed passwords, saved credentials, copied secrets, and SSO mediation.
• Remove human handling from login flows Prioritise the applications where employees still interact directly with reusable credentials, because those flows are easiest for AiTM phishing and infostealers to abuse.
• Replace manual vault-only workflows Where discovery has exposed non-SAML tools, do not leave access parked in a password vault and a spreadsheet; enforce a controlled browser-mediated session instead.
• Track remediation as runtime control Measure whether discovery output leads to enforced access control at the point of authentication, not just ticket creation or vendor escalation.

Key takeaways

• Shadow SaaS discovery exposes unmanaged applications, but the underlying identity risk remains if employees still authenticate with credentials that can be copied or intercepted.
• The critical failure mode is visibility without execution control, because inventory alone does not break the human login loop that attackers exploit.
• Security teams should treat discovery as the start of access redesign, with runtime enforcement at the browser or session layer as the real control objective.

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.
• Managed Execution: A .NET runtime model where code is compiled to intermediate language and verified before execution. The runtime checks metadata and memory access rules to preserve isolation and support security enforcement. This helps the platform control how code runs, but it does not replace secure design or input validation.
• Adversary-in-the-middle phishing: A phishing method that places an attacker between the user and the real identity provider so the attacker can intercept or relay the authenticated session. It often preserves the user experience, which is why it can evade awareness and some detection paths while still producing usable session tokens.
• Infostealer: An infostealer is malware built to collect credentials, session material, tokens, and other authentication data from infected systems. In NHI programmes, the risk is not only theft but reuse, because harvested workload secrets can unlock cloud access long after the initial infection.

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.