Yes. Expanding SaaS access without token governance increases the number of identities and integrations that can be abused after login. Organisations should first inventory tokens, reduce token lifetime, and review delegated permissions. Otherwise, every new SaaS connection widens the attack surface without improving control.
Why This Matters for Security Teams
Token governance should usually come before broader SaaS expansion because every new app connection multiplies the number of credentials, delegated scopes, and machine identities that can be abused after login. SaaS adoption often looks like an access problem, but in practice it is a credential lifecycle problem. If long-lived tokens remain active, a single compromised integration can reach far beyond the original user account.
This is not theoretical. NHIMG research on the Salesloft OAuth token breach shows how stolen tokens can translate into downstream data access even when the primary login path is not the issue. The broader pattern is also visible in the Guide to the Secret Sprawl Challenge, where secret proliferation and weak lifecycle control create exposure that basic perimeter controls do not catch. OWASP’s OWASP Non-Human Identity Top 10 reinforces the same point: non-human credentials need their own governance, not just user-centric IAM policies.
In practice, many security teams discover token sprawl only after an integration has already been abused, rather than through intentional control design.
How It Works in Practice
Start by inventorying every token type in use: OAuth refresh tokens, API keys, service account secrets, app-to-app grants, and automation credentials. Then map each token to an owner, a purpose, a scope, and an expiry condition. That inventory is the foundation for deciding which SaaS applications are safe to add next. If a tool cannot support short-lived credentials, delegated scopes, or revocation APIs, it should not be treated as a routine expansion candidate.
The practical sequence is usually:
- Reduce token lifetime so credentials expire quickly after use.
- Remove standing delegated permissions that are no longer needed.
- Use RBAC to limit who can create or approve new SaaS integrations.
- Require JIT approval for higher-risk connections and admin scopes.
- Revoke orphaned tokens when users leave or apps are decommissioned.
These steps align with the direction set by the OWASP Non-Human Identity Top 10 and with operational lessons from the Dropbox Sign breach, where exposed integration credentials became an access path rather than a minor hygiene issue. The Ultimate Guide to NHIs also frames the core principle: a token is an identity artifact, not just a secret string. That means governance has to cover issuance, scope, monitoring, rotation, and revocation across the full lifecycle.
Current guidance suggests treating SaaS onboarding as a control gate, not an entitlement afterthought, especially when the new connection can read mail, files, tickets, or CRM data. These controls tend to break down when legacy SaaS platforms lack scoped OAuth support because the organisation is forced into long-lived static tokens.
Common Variations and Edge Cases
Tighter token control often increases onboarding friction, so organisations must balance speed against containment. That tradeoff becomes sharper in environments with many business-owned apps, partner integrations, or automation workflows that depend on wide permissions. Best practice is evolving here, and there is no universal standard for how much delegated access is acceptable across every SaaS platform.
Some exceptions are practical rather than ideal. For example, read-only reporting integrations may justify broader scope if the platform cannot issue narrow permissions, but those cases should still have short TTLs and explicit ownership. In regulated environments, token review should be paired with access recertification so that dormant integrations are identified before they become blind spots. The Internet Archive breach and the Sisense breach both illustrate how exposed credentials and overextended access can turn a single integration into a broader incident.
For teams following OWASP Non-Human Identity Top 10 guidance, the key is to avoid equating SaaS growth with maturity. Expansion is only safe when token hygiene, approval flow, and revocation are already working. Otherwise, new app access simply increases the number of places an attacker can persist after initial compromise.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Token rotation and revocation are central to limiting NHI abuse. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control governs SaaS entitlements and delegated scopes. |
| NIST Zero Trust (SP 800-207) | SC-31 | Zero trust supports continuous verification of app-to-app access paths. |
Continuously validate token use and limit trust to the minimum context required at request time.
