SaaS discovery exposes shadow apps, but not the identity risk

At a glance

What this is: This is an analysis of why SaaS discovery alone does not secure shadow applications, and why inventory without authentication control still leaves credentials exposed.

Why it matters: It matters because IAM, NHI, and access governance teams need to treat discovery as a starting point, not a control outcome, when users still log in with reusable secrets.

By the numbers:

• 73% of ransomware victims had a prior infostealer infection, according to Verizon's Data Breach Investigations Report.
• 50% to 85% of your software footprint lives outside SAML or OIDC single sign-on, according to Unixi.
• 65% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to Oasis Security & ESG.

👉 Read Unixi's analysis of SaaS discovery limits and managed execution

Context

SaaS discovery tools can reveal how much of an enterprise sits outside central SSO, but visibility is not the same as control. If users still authenticate by typing, pasting, or reusing passwords, the underlying identity exposure remains in place even after every shadow application has been catalogued.

The governance gap is not discovery itself. It is the persistence of the human login loop, where Adversary-in-the-Middle phishing, infostealer malware, and manual vaulting all keep secrets in circulation long enough for attackers to harvest them. That is a common enterprise condition, not an edge case.

For IAM and identity security teams, this is a reminder that discovery data should drive remediation design, not stand in for it. The operational question is whether controls can remove credentials from human hands at the point of authentication across unmanaged SaaS and browser-based workflows.

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 unmanaged SaaS applications stay risky even after they are discovered?

A: They stay risky because the authentication method usually does not change when the app is found. Users can still expose secrets during login, and attackers can still harvest those secrets from browsers, endpoints, or proxy-based phishing kits. The risk is in the login behaviour, not in the discovery report.

Q: How should security teams deal with SaaS vendors that charge extra for SSO?

A: Security teams should treat SSO as a baseline control requirement and measure vendors against it during procurement. If an application gates federation behind a premium tier, teams should quantify the security and operational cost of keeping separate logins, then decide whether the app can be approved at all.

Q: What should IAM teams prioritise after discovering shadow SaaS?

A: Prioritise the apps whose users still handle reusable credentials directly, because that is where credential theft is most likely. Then decide whether the right response is managed browser control, vendor migration, or formal exception handling. The goal is to remove the human from the secret-handling step.

Technical breakdown

Why SaaS discovery does not reduce authentication exposure

Discovery platforms locate unmanaged applications, but they do not change how those applications are accessed. If the authentication method remains typed passwords, saved secrets, or copy-paste flows, attackers can still intercept credentials through phishing proxies or endpoint malware. The risk sits in the login mechanics, not in the inventory record. That means a clean application list can coexist with a still-exposed authentication path. Practical implication: treat discovery outputs as input to access redesign, not as evidence that the app estate is safer.

Practical implication: Map each discovered app to its actual authentication path before deciding whether it is governed.

Why vaults alone do not close the human credential loop

Traditional password vaults centralise secrets, but they still leave humans handling those secrets during login. The moment a user copies a password out of the vault or pastes it into a browser form, the exposure window reappears. Vaults can help with storage and cataloguing, but they do not eliminate the moment of disclosure that attackers exploit. In practice, that means vaulting can reduce clutter while preserving the attack condition. Practical implication: separate secret storage from secret presentation at authentication time.

Practical implication: Use controls that remove human viewing and typing of credentials during sign-in.

Managed browser execution as an authentication control pattern

Managed execution shifts control to the browser layer so that unmanaged SaaS can be brought under enterprise policy without waiting for native SAML support. The important change is not the discovery of the app, but the governance of the session and sign-in flow. Active session monitoring and instant offboarding become possible even for non-SAML tools, because the enterprise is controlling how the user reaches the application. Practical implication: this pattern addresses the operational gap that discovery-only tools leave behind.

Practical implication: Apply browser-layer governance where application vendors cannot or will not support enterprise identity standards.

Threat narrative

Attacker objective: The attacker wants durable access to SaaS accounts and the data or downstream systems those accounts can reach.

1. Entry begins when an employee authenticates to a lookalike login page or uses a locally cached secret that can be harvested by malware. Escalation follows when the stolen credential or session token is replayed against a real SaaS application that has no stronger access gate. Impact occurs when the attacker persists through unmanaged access paths and reaches business data, tokens, or downstream connected systems.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Microsoft Midnight Blizzard breach — Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

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

NHI Mgmt Group analysis

Discovery without authentication control is a measurement exercise, not a security control. A list of shadow applications tells teams where the exposure may exist, but it does not change the mechanism that creates the exposure. If identity governance stops at finding apps, the human login loop stays intact and attackers still have a credential path to abuse. The practical conclusion is that inventory must be paired with enforced authentication change, not treated as an end state.

Human-handled secrets create a repeatable exposure pattern across shadow SaaS. Typed passwords, pasted vault secrets, and saved browser credentials all create the same operational weakness: the secret exists in a form that a user can reveal, malware can steal, or a proxy can intercept. This is why discovery tools generate anxiety faster than they generate risk reduction. Practitioner takeaway: the security model must remove humans from secret handling at sign-in.

Managed execution is a governance pattern, not just a convenience layer. When an enterprise can enforce access policy, session visibility, and offboarding at the browser layer, it closes the gap that niche SaaS vendors and slow procurement cycles leave open. That matters because identity governance cannot depend on every application vendor meeting enterprise SSO requirements. The implication is that access governance must be portable across applications, not contingent on native support.

Shadow SaaS is really an identity governance problem disguised as an application discovery problem. The article's central point is that the security question is not how many apps are hidden, but how many hidden apps still accept reusable credentials. That reframes the market discussion from visibility tooling to control placement. Practitioners should therefore measure whether a discovery programme changes authentication behaviour, not just reporting depth.

Discovery creates a governance backlog unless it is attached to remediation authority. If IT can only report on non-SAML apps but cannot enforce new access paths, the programme accumulates unresolved exceptions faster than teams can close them. That backlog becomes its own risk surface, because business users keep the applications alive while security preserves the exposure. The conclusion is straightforward: remediation authority must be designed into the operating model.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to the same report.
• This is why the OWASP Non-Human Identity Top 10 matters now: identity exposure becomes a governance problem when discovery does not remove standing access.

What this signals

Discovery programmes will keep underperforming unless they are tied to enforcement. The market may continue to reward visibility claims, but practitioners should judge these programmes by whether they change authentication behaviour across unmanaged SaaS. Discovery data that does not alter access patterns simply adds reporting weight to an already visible problem.

Shadow SaaS governance is moving toward control placement at the browser layer. That shift matters because it decouples access governance from native SSO support and gives teams a path to manage applications that vendors cannot or will not integrate cleanly. In practice, browser-mediated access becomes a compensating control for application ecosystems that will not be standardised quickly.

Human credential handling remains the weak link, even where inventory is strong. The security problem is not lack of awareness, but the continued use of reusable secrets in workflows that attackers already know how to intercept. Teams should expect identity governance to shift from application enumeration to secret-free access paths and session governance.

For practitioners

• Inventory the real authentication path for every discovered app Classify each shadow SaaS application by whether users authenticate with SSO, typed passwords, vault copy-paste, or browser-managed session controls. Discovery is only useful when it is tied to the actual access path, not the app name alone.
• Eliminate human handling of reusable credentials Prioritise controls that prevent users from seeing, typing, or copying secrets during login. That is the point where AiTM phishing, infostealers, and session theft become materially harder to execute.
• Attach remediation authority to discovery outputs Require every unmanaged application finding to route to a concrete access decision, such as managed browser execution, vendor offboarding, or formal exception approval. A spreadsheet of findings without decision rights becomes a backlog, not a control.
• Use browser-layer governance for non-SAML tools Where vendors cannot support enterprise identity standards, enforce access policy and session monitoring at the browser layer so offboarding and access changes remain under enterprise control.

Key takeaways

• SaaS discovery exposes hidden applications, but it does not by itself reduce authentication risk.
• The control gap is the human login loop, where typed or copied credentials remain available to attackers.
• Effective governance requires remediation authority, managed access paths, and secret-free authentication at the point of use.

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.
• Human Login Loop: The human login loop is the sequence where a person sees, types, pastes, or reuses a secret during authentication. That loop is exploitable because phishing proxies, infostealers, and browser capture techniques target the moment the secret passes through human hands.
• Credential exposure window: Credential exposure window is the time period during which a secret remains usable, copyable, or replayable before it is revoked or replaced. The shorter that window, the less chance there is for abuse. In database governance, reducing this window is often more important than merely storing the secret securely.

What's in the full article

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

• The browser-extension access flow used to bring non-SAML apps under managed enterprise authentication
• How active session monitoring and instant offboarding work across arbitrary web tools
• The operational trade-offs between vendor SSO roadmaps, app bans, and manual credential vaulting
• The specific way managed execution changes the exposure window for AiTM and infostealer attacks

👉 The full Unixi post explains how managed execution closes the shadow app authentication gap.

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.