How should security teams manage SaaS access when employees use both managed and unmanaged apps?

Security teams should treat SaaS access as an identity governance problem, not just an app inventory problem. Start by discovering where accounts exist, then map ownership, privilege, and business purpose. Prioritise controls that reduce blind spots, enforce least privilege, and separate approved from shadow IT. The goal is to secure access without creating friction that pushes users around controls.

Why This Matters for Security Teams

When employees use both managed and unmanaged SaaS, the real risk is not simply shadow IT. It is fragmented identity governance: accounts are created outside procurement, OAuth grants persist after the business need changes, and privileged access accumulates without consistent review. That creates blind spots across both sanctioned and unsanctioned apps, especially where login is federated but authorization is still handled inside the SaaS tenant. Guidance in the OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs — Key Challenges and Risks both point to the same operational issue: identity sprawl becomes the control failure before the app itself does.

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. Even though this question is about employee SaaS use, the same pattern applies to the machine and app credentials that back integrations, automations, and delegated access. In practice, many security teams discover the exposure only after a user, vendor, or integration has already been granted access that nobody can fully enumerate.

How It Works in Practice

Effective SaaS access management starts with discovering all identities attached to each application: employees, contractors, service accounts, OAuth apps, bots, and delegated admin roles. The control point is not the app catalogue alone. It is the relationship between the identity, the entitlement, and the business purpose at the moment access is granted. The Ultimate Guide to NHIs – Lifecycle Processes for Managing NHIs is useful here because it frames access as lifecycle-managed, not one-time approved.

Security teams should separate managed SaaS from unmanaged SaaS, but apply the same governance pattern to both:

• Discover who has access, including accounts created through social login or personal email.
• Map every access path to an owner, approver, and business justification.
• Classify apps by sensitivity, data scope, and integration risk.
• Review OAuth consent, tokens, and third-party connectors as standing access.
• Use least privilege and time-bound access where the SaaS supports it.

From a control perspective, this aligns with the NIST Cybersecurity Framework 2.0 emphasis on governance, asset visibility, and access control, even when the apps themselves are not fully managed by IT. For unmanaged apps, the practical goal is not perfect prohibition. It is making hidden access visible, then shrinking the blast radius through federation, conditional access, and rapid deprovisioning when a user changes roles or leaves.

Teams also need to treat integrations as part of the SaaS estate. Many unmanaged app problems are really over-scoped API tokens, stale admin sessions, or third-party connectors that outlive the original use case. These controls tend to break down when employees can self-provision new SaaS through personal accounts because the organisation loses both lifecycle control and authoritative inventory.

Common Variations and Edge Cases

Tighter SaaS governance often increases friction for users, so organisations must balance speed against control. That tradeoff becomes sharper in departments that buy tools outside central IT, where approval delays can drive more shadow IT rather than less. Current guidance suggests using risk-based tiers instead of a single approval path for every app.

Managed SaaS can usually be governed through SSO, SCIM provisioning, and conditional access, but unmanaged apps often sit outside those integrations. In those cases, security teams may need compensating controls such as browser isolation, identity-aware proxies, CASB visibility, or contractual restrictions on data use. The Top 10 NHI Issues and the Ultimate Guide to NHIs are both helpful when the SaaS estate includes automation, because the same access review can miss service principals even when human accounts are well tracked.

There is no universal standard for this yet, but the strongest programs treat unmanaged SaaS as a governed exception, not a permanent free-for-all. The biggest exception is a business-critical app with no enterprise federation support. In that case, control should shift to monitoring, periodic attestation, and data minimisation rather than pretending the app can be fully standardised overnight.

Related resources from NHI Mgmt Group

• How should security teams use AI to reduce certification fatigue in access reviews?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams use IAST and RASP in NHI governance?