Discovery without access review leaves organisations with a list of apps but no decision path for removing unnecessary access. Connecting the two lets teams validate ownership, confirm whether usage is justified, and route dormant or unmanaged apps into the recertification process before they become long-lived governance gaps.
Why This Matters for Security Teams
SaaS discovery creates inventory, but inventory alone does not answer whether an application should still be trusted, owned, or reachable. Without a formal access review path, stale OAuth grants, forgotten service accounts, and unmanaged integrations stay active long after the business case has disappeared. That is exactly the gap the OWASP Non-Human Identity Top 10 and NHI governance guidance are meant to close.
NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface. When discovery stops at visibility, teams can report on risk but cannot reduce it. The more useful control is to connect each discovered SaaS app to an owner, an access decision, and a recertification path, using the lifecycle approach described in the NHI Lifecycle Management Guide.
In practice, many security teams encounter dormant SaaS access only after a token is abused, rather than through intentional recertification.
How It Works in Practice
The operational model is straightforward: discovery identifies the SaaS application, its connected identities, and the permissions in scope; access review decides whether that access is still justified. The two processes should share the same asset record, ownership metadata, and review cadence so a discovered app can move directly into a decision workflow instead of sitting in a spreadsheet. That linkage is especially important for app-to-app grants, where the “user” is really a workload identity or delegated token rather than a person.
A practical workflow usually includes:
- Classify the SaaS app by business owner, data sensitivity, and authentication method.
- Map all active grants, API keys, service accounts, and OAuth consents tied to the app.
- Route the app into periodic review if the owner is known, or exception handling if ownership is unclear.
- Revoke unnecessary access, then confirm the change was actually enforced across the SaaS control plane.
- Record the disposition so future discovery results inherit the prior decision.
For control design, the most useful guidance comes from pairing governance with lifecycle management. The Ultimate Guide to NHIs emphasizes that visibility, rotation, offboarding, and privilege reduction are linked, not separate problems. External standards are aligned on the same principle: access should be reviewable, attributable, and removable, and the OWASP Non-Human Identity Top 10 treats unmanaged credentials and excessive privilege as recurring root causes.
Teams also need a clear response path when a discovered SaaS app has no owner. Best practice is evolving, but current guidance suggests routing those records into an exception queue rather than leaving them outside review altogether. These controls tend to break down in federated SaaS environments with shadow IT and shared admin tenancy because discovery data is incomplete and ownership cannot be reliably assigned.
Common Variations and Edge Cases
Tighter review cycles often increase operational overhead, requiring organisations to balance stronger governance against analyst capacity and business disruption. That tradeoff is real, especially where SaaS sprawl is high and many integrations are low-value but still business-critical.
There is no universal standard for this yet, but the most effective programmes separate routine reviews from higher-risk exceptions. Low-risk apps can follow scheduled recertification, while dormant, unowned, or externally connected SaaS apps should be escalated immediately. This is where the Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks are useful because they frame stale access, weak ownership, and poor offboarding as lifecycle failures rather than isolated events.
Edge cases include vendor-managed SaaS instances, shared automation accounts, and inherited integrations after mergers. In those environments, discovery may find the app but not the decision maker. The right answer is not to suppress the finding; it is to preserve it as an open governance item until someone can affirm continued need, prove ownership, or remove access entirely.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Discovery must feed review to reduce stale NHI access and excessive privilege. |
| NIST CSF 2.0 | PR.AC-1 | Access permissions need ownership and approval to stay governed after discovery. |
| NIST CSF 2.0 | GV.RM-08 | Governance requires risk decisions, not just visibility into assets and apps. |
Tie discovered SaaS identities to review and revoke paths so unused access is removed quickly.
