How should security teams handle SaaS applications that are bought outside IT?

Why This Matters for Security Teams

Software bought outside IT is rarely just a procurement issue. It can introduce new authentication paths, third-party OAuth grants, service accounts, and API keys that never enter the normal control plane. That makes the application itself only part of the risk. The larger problem is lifecycle governance: who owns the app, who can approve access, and who revokes it when the business no longer needs it. NIST’s NIST Cybersecurity Framework 2.0 is clear that governance and asset management belong inside security operations, not outside them.

In practice, unmanaged SaaS often becomes an unmanaged identity surface. One business team subscribes to a tool, connects it to mail, storage, or CRM systems, and months later nobody can answer which permissions were granted or whether the vendor still needs them. That is how off-contract apps turn into shadow IT, then into hidden access paths. The pattern is visible in incidents such as the Salesloft OAuth token breach and the BeyondTrust API key breach, where third-party access became part of the attack path. In practice, many security teams discover this only after an integration has already been over-granted or abused, rather than through intentional intake and review.

How It Works in Practice

The right response is to treat every SaaS purchase as a governed technology asset, even if procurement happened without IT. Security teams should require a managed inventory that records the business owner, data classification, vendor, renewal date, and every connected identity or integration. That inventory should include OAuth apps, API tokens, SCIM links, SSO assignments, and any delegated admin roles. A SaaS app without a named owner or expiry date should be treated as an exception, not an accepted state.

Operationally, the workflow is straightforward:

• Intake the app into the inventory as soon as it is discovered.
• Assign a business owner who can justify the use case and approve renewal.
• Review all connected identities, secrets, and delegated permissions.
• Reduce access to the minimum required scope.
• Require renewal review before the contract continues, including a check for unused integrations.
• Remove access promptly when the app is retired or the business owner leaves.

This is also where NHI governance matters. SaaS tools frequently create non-human identities through machine-to-machine access, and those credentials often outlive the original business need. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding and revocation processes for API keys, which shows why renewal review must be tied to credential cleanup. Where possible, security teams should also align the SaaS inventory with discovery and monitoring so that approved apps are differentiated from unsanctioned ones. Current guidance suggests pairing procurement control with identity review rather than treating them as separate problems.

These controls tend to break down in fast-moving departments that can buy tools through a credit card or app marketplace without central approval, because ownership is ambiguous and integration sprawl happens faster than review cycles.

Common Variations and Edge Cases

Tighter SaaS control often increases friction for business teams, requiring organisations to balance speed of adoption against the risk of hidden access paths. Some environments therefore use a tiered approach: low-risk collaboration tools get lighter review, while tools touching customer data, finance data, or admin integrations face mandatory security intake. That is a pragmatic tradeoff, not a universal standard.

There is also no universal standard for how aggressively to remove dormant SaaS apps. Best practice is evolving, but most teams should start with the highest-risk cases: apps with OAuth grants, external sharing, or privileged admin connections. This matters because SaaS commonly becomes a container for long-lived access even after the original user leaves. NHIMG’s research links the problem to exposure and persistence, including incidents like the Snowflake breach and Sisense breach, where third-party access and secrets handling amplified impact.

Some organisations also adopt renewal reviews as a procurement gate, while others embed them in identity governance or vendor risk management. The key is consistency: if the business can renew the app, the business must also prove the access is still justified. Without that discipline, off-contract SaaS becomes a permanent exception with no clear owner.

Related resources from NHI Mgmt Group

• How should security teams handle risks from AI browser extensions?
• How should security teams handle AI agents that need to log into SaaS applications?
• How should security teams handle disconnected applications that sit outside identity tooling?
• How should security teams handle unmanaged SaaS applications in identity reviews?