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.
Why This Matters for Security Teams
Unmanaged SaaS is risky because discovery does not change how the application is authenticated, authorized, or used. If users keep signing in with the same browser flows, saved credentials, and third-party login paths, the app can remain exposed to secret capture, token theft, and account takeover even after it has been catalogued. That makes discovery a visibility event, not a control event.
For security teams, the practical problem is that discovered apps often move from “unknown” to “known” without moving from “unsafe” to “bounded.” The login path may still allow password reuse, session replay, OAuth consent abuse, or harvesting through endpoint compromise and proxy-based phishing. Discovery helps with inventory, but the risk sits in the authentication behaviour and the trust path around it, not in the spreadsheet or report. Guidance around unmanaged NHI and secret exposure shows why this matters at scale, especially when credentials persist long after the team believes the issue has been addressed. Ultimate Guide to NHIs, Key Challenges and Risks
In practice, many security teams discover unmanaged SaaS only after a phishing kit, browser compromise, or token replay has already turned discovery into a retrospective exercise.
How It Works in Practice
The risk persists because unmanaged SaaS usually sits outside the controls that teams use to normalise access. Discovery may tell you the app exists, but it rarely rewires the login method, resets existing sessions, or forces a safer authentication pattern. If the app accepts passwords, persistent cookies, OAuth grants, or email-based recovery, those paths can remain exploitable until the access model itself is changed.
That is why the operational question is not “Do we know about the app?” but “What can still be stolen, reused, or replayed to enter it?” Common persistence points include:
- Saved browser credentials or autofill values that can be harvested from endpoints.
- Session tokens that survive discovery and are still valid until revocation or expiry.
- OAuth grants or API tokens that remain trusted even after the app is flagged as unsanctioned.
- Proxy-based phishing kits that intercept the login flow without needing to defeat the app directly.
The key control move is to treat discovered SaaS as an access-risk investigation, not an inventory cleanup. Teams should determine whether the app is identity-backed, token-backed, or password-backed, then assess where the reusable secret lives and who can obtain it. If the application is tied to a third-party identity workflow, discovery alone will not stop credential replay. A breach pattern such as OAuth token abuse illustrates how legitimate-looking access can continue after the app is “found.” Salesloft OAuth token breach
These controls tend to break down when the app is accessed through unmanaged endpoints or externally mediated login flows because the team cannot reliably see, revoke, or rotate the secret material in time.
Common Variations and Edge Cases
Tighter discovery often increases review overhead, so organisations have to balance inventory completeness against the cost of chasing every unsanctioned app. The right response also varies by authentication model: some apps can be made safer by centralising sign-in, while others remain risky because the third-party integration itself is the exposure.
One edge case is “shadow IT” SaaS that looks low impact but can still hold high-value tokens, linked email data, or delegated access into production systems. Another is when an app is technically discovered but still accessible through user-managed browser profiles, mobile logins, or personal accounts that sit beyond enterprise enforcement. In those cases, discovery can improve awareness without materially reducing attack surface.
There is also a difference between knowing an app exists and knowing whether it can be safely decommissioned. If users depend on it, the transition period becomes a parallel risk state in which the old login path and the new control path both remain active. That is where teams need current guidance, because best practice is still evolving on how much to block, broker, or migrate versus simply monitor.
Where unmanaged SaaS is tied to SaaS-to-SaaS integrations, the hardest cases are the ones where discovery reveals only the front door while the real exposure sits in the delegated token behind it.
Risk and Threat Considerations
The material risk is credential and token reuse after discovery. Once an unmanaged app is visible, attackers do not need the inventory record, they need the still-valid secret, session, or delegated grant that can authenticate them into the app.
Failure mechanism: The app remains reachable through browser-stored credentials, stolen cookies, OAuth consent, or proxied login capture, so discovery does not interrupt the trusted authentication path. That lets an attacker harvest reusable access material from the endpoint or intercept it during login.
Impact: The organisation can keep exposing SaaS data, connected APIs, and downstream accounts even after the app is identified. In some cases the discovered app becomes easier to target because defenders now know it exists but have not yet revoked the path into it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC — Organisational Context | Discovery must inform SaaS inventory and risk context. |
| PR.AA — Identity Management, Authentication and Access Control | The risk persists through reusable SaaS login and access paths. | |
| DE.CM — Security Continuous Monitoring | Discovery only helps when risky SaaS access is continuously observed. | |
| Recommendation — Use inventory context to classify unmanaged SaaS by business impact and access path. Enforce safer authentication and revoke stale access paths for discovered SaaS. Monitor SaaS sign-in behaviour and token use for abnormal access after discovery. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The question turns on authenticators, sessions and phishing-resistant login. |
| Recommendation — Adopt phishing-resistant authenticators and limit replayable login material. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Discovery and Inventory | Unmanaged SaaS stays risky when discovery does not change access governance. |
| NHI-03 — Secrets Management | Risk remains when secrets, tokens or cookies can still be captured. | |
| NHI-06 — Authentication and Authorization | The core issue is that access control does not improve when the app is found. | |
| Recommendation — Track discovered SaaS and tie each app to owner, login method and revocation path. Rotate and minimise reusable credentials exposed in SaaS login flows. Move discovered SaaS to stronger authentication and tighter authorization controls. | ||
Practitioner Guidance
What to prioritise: Treat the login mechanism as the control boundary. If the app is still using passwords, browser sessions, or delegated tokens, prioritise revocation and authentication hardening before updating the inventory record.
What to verify: Confirm whether the app has active sessions, long-lived tokens, shared credentials, or recovery paths that bypass enterprise control. If those still exist, the app remains materially risky even when it is fully documented.
Decision rule: If discovery has not changed the way a user authenticates, then the exposure has not really changed either. The control objective should be to remove reusable secret material, not just label the app as unmanaged.
Practitioner takeaway: Discovery reduces uncertainty, but only authentication change reduces risk, so the fastest win is to shrink the set of ways a secret can still be captured and replayed.
