Should organisations prioritise remediation or discovery first in SaaS security?

They need both, but discovery comes first if they do not know where their access paths are. Once the inventory is accurate, remediation should be tightly automated so stale sharing, excessive privilege, and forgotten integrations are removed quickly. Otherwise, the programme becomes a reporting exercise.

Why This Matters for Security Teams

SaaS security programmes fail when teams choose between discovery and remediation instead of sequencing them. If access paths, OAuth apps, service accounts, and shadow integrations are still unknown, remediation will miss the highest-risk exposure. If inventory is accurate but stale access is left in place, the programme becomes a dashboard exercise rather than risk reduction. NHI governance follows the same logic: you cannot secure what is not visible, and you should not leave what is visible uncorrected.

NHIMG research shows why visibility comes first. In The State of Non-Human Identity Security, 85% of organisations reported they lack full visibility into third-party vendors connected via OAuth apps. That is a discovery problem before it is a remediation problem. The same pattern appears in broader control guidance from NIST Cybersecurity Framework 2.0, where asset visibility and risk response are linked, not treated as separate programmes. For SaaS, the practical priority is to find every identity and connection, then remove what no longer belongs.

Practitioners should also align this with NHI lifecycle thinking in the NHI Lifecycle Management Guide and the broader Top 10 NHI Issues, because SaaS access sprawl often hides the same control gaps. In practice, many security teams discover stale sharing and over-privileged integrations only after a breach or audit has already exposed them, rather than through intentional governance.

How It Works in Practice

The right operating model is iterative: discover, classify, remediate, then rediscover to verify the fix. Discovery should build a complete inventory of SaaS tenants, connected apps, delegated scopes, service accounts, bot users, tokens, and third-party vendors. That inventory must include ownership, business purpose, privilege level, last-used time, and whether the access path is user-managed or machine-managed. From there, remediation can be automated for low-risk, high-volume issues such as stale sharing links, dormant tokens, excessive API scopes, and orphaned app grants.

Automation matters because SaaS environments drift quickly. The Guide to the Secret Sprawl Challenge explains why fragmented control planes let secrets and credentials multiply across tools and teams. That is why remediation should not wait for the next manual review cycle once discovery is complete. Where possible, integrate policy checks into provisioning and deprovisioning workflows, use approved app allowlists, and tie exceptions to explicit owners and expiry dates. Current guidance suggests pairing least privilege with tight review loops, because broad standing access is what tends to accumulate in SaaS first.

• Discover every app-to-app and user-to-app connection before setting thresholds for action.
• Prioritise fixes for stale OAuth grants, over-privileged scopes, and abandoned integrations.
• Use automated revocation for low-confidence access paths and route exceptions to owners.
• Re-run discovery after remediation so the inventory becomes a control, not a snapshot.

NIST Cybersecurity Framework 2.0 supports this sequencing because identify and protect activities only work when response actions are fed by accurate asset understanding. These controls tend to break down when SaaS estates span multiple business units and each unit owns its own app catalogue because no single team can see the full access graph.

Common Variations and Edge Cases

Tighter remediation often increases operational overhead, requiring organisations to balance speed against change management risk. That tradeoff becomes sharper in SaaS platforms with business-critical automations, where a blunt revoke can interrupt revenue workflows or collaboration channels. Best practice is evolving here: there is no universal standard for how much tolerance should be given to dormant but business-approved access, so security teams should treat that as a documented exception, not an informal norm.

Edge cases usually involve shared service identities, admin-consent OAuth apps, and vendor-managed integrations that are owned outside the security team. In those environments, discovery may reveal access that cannot be immediately removed without breaking dependencies. The right response is not to delay remediation indefinitely, but to put those paths into a JIT-style review queue with explicit expiry, business owner sign-off, and compensating monitoring. That approach is especially important when secrets are long-lived and reused across workflows, because even a well-inventoried environment can remain exposed if credentials never rotate.

For teams dealing with repeated SaaS breaches such as the Salesloft OAuth token breach, the lesson is consistent: discovery finds the blast radius, but only disciplined remediation shrinks it. The answer is not discovery versus remediation. It is discovery first, remediation at machine speed, and continuous verification after each change.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• Should organisations prioritise external exposure or internal credential governance first?
• When does automated remediation make more sense than manual review in SaaS security?
• What is the difference between visibility and remediation in SaaS security?