Start by treating discovery as a governance control, not just inventory. Every newly found app should be assigned an owner, linked to the identities using it, and reviewed for business need. If the app cannot be owned, reviewed, or revoked consistently, it should be treated as a governance exception rather than a normal part of the environment.
Why This Matters for Security Teams
Informal SaaS discovery is rarely just a shadow IT inventory problem. It is a governance problem because access often exists before there is an owner, a business purpose, or a revocation path. Once a SaaS app is being used by employees, service accounts, or API integrations, it creates an identity surface that must be governed like any other production dependency. That means understanding who is using it, what data it can reach, and how access will be removed when the need ends.
This matters because SaaS usage often bypasses standard onboarding and procurement controls. Security teams can miss the application until it has already accumulated OAuth grants, shared tokens, or embedded secrets. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a strong indicator of how often access paths remain undiscovered. Current guidance from the NIST Cybersecurity Framework 2.0 still points to asset visibility, ownership, and control validation as foundational governance tasks.
In practice, many security teams encounter SaaS risk only after an audit, breach, or billing review reveals that “temporary” access had become a permanent business dependency.
How It Works in Practice
Teams should treat every newly discovered SaaS app as a governed asset, not as a tolerated exception. The first step is to assign ownership, then identify the identities that can reach it, including human users, service accounts, and machine-to-machine integrations. From there, the app should be classified by business criticality, data sensitivity, and whether its access can be reviewed and revoked without breaking a legitimate workflow.
That review should include both direct authentication and indirect access. Many SaaS platforms are accessed through OAuth grants, shared API keys, forwarded credentials, or browser sessions that are difficult to see in conventional IAM tools. NHIMG’s Top 10 NHI Issues highlights that secrets and non-human identities are commonly overexposed, which is exactly why discovery must link applications to the identities and tokens that make them usable. The OWASP Non-Human Identity Top 10 is also useful here because SaaS access is often sustained by machine credentials that outlive the teams that created them.
- Require a named business owner before the app is accepted into the inventory.
- Map users, roles, API keys, service accounts, and OAuth consents to that app.
- Review whether the access is still needed, then reduce scope before expanding controls.
- Set a revocation plan for credentials, tokens, and linked accounts at offboarding time.
- Flag apps with no owner or no clean revoke path as governance exceptions.
Where possible, fold discovery into periodic access reviews and procurement checks so the same app is not rediscovered repeatedly as a new exception. These controls tend to break down in fast-moving SaaS environments where employees can self-provision tools and admins can grant broad OAuth consent without a central approval workflow.
Common Variations and Edge Cases
Tighter SaaS governance often increases friction for users and operations teams, requiring organisations to balance discovery speed against approval overhead. That tradeoff is real: overly rigid controls can drive more shadow usage, while permissive controls leave ownership gaps and revocation blind spots.
Best practice is evolving for SaaS apps that sit between IT, business units, and automation. For example, a collaboration app used by one department may look low risk until it is connected to shared storage, ticketing, or code repositories. In those cases, the access model needs to reflect the broader blast radius, not just the visible application. NHIMG’s Lifecycle Processes for Managing NHIs is relevant because the same lifecycle logic applies to SaaS-linked identities: ownership, rotation, review, and offboarding must all be explicit.
There is no universal standard for informal SaaS discovery yet, but current guidance suggests three practical rules: do not normalise anonymous ownership, do not allow unreviewed token sprawl, and do not keep apps in production if they cannot be revoked cleanly. That is especially important for third-party and contractor-heavy environments, where access can be granted outside core IAM and forgotten after the engagement ends.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 | Discovery must create a reliable SaaS asset inventory with owners. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Informal SaaS access often depends on unmanaged non-human identities and secrets. |
| NIST AI RMF | Governance requires ongoing accountability and risk review across AI-enabled SaaS use. |
Inventory and govern all SaaS-linked identities, tokens, and API keys before approving use.
Related resources from NHI Mgmt Group
- How should security teams govern SaaS apps that are discovered but not connected to IGA?
- How should security teams govern access when users move across devices and cloud apps?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
