What should IAM teams do when business units keep buying their own SaaS tools?

Why Intake Needs to Become the Control Point

When business units buy SaaS directly, IAM teams inherit the problem after the contract is signed and users are already active. The practical fix is to move governance upstream, so identity, approval, ownership, and exit obligations are checked before the app goes live. That turns SaaS from a surprise integration into a managed onboarding event.

Intake is where you decide whether the organisation can support the app’s identity model, whether it needs federated login or local accounts, and who will own offboarding when the tool is retired or a vendor relationship ends. Without that gate, every later review becomes a cleanup exercise.

For this control point, treat intake as a lifecycle checkpoint, not a procurement formality. NHIMG’s Lifecycle Processes for Managing NHIs is useful here because the same pattern applies to SaaS accounts, service connections, and the credentials that keep them alive.

What Shared Ownership Changes Operationally

Shared ownership means IAM is not the only team with a stake in the app’s identity posture. The business owner has to accept responsibility for access sponsorship and business justification, while IT or security owns the control design, review cadence, and deprovisioning path. That split matters because no one team can otherwise prove who approved what, who can revoke it, or who owns exceptions.

A workable model needs three things documented before deployment: the identity source of truth, the approval path for new access, and the party responsible for removing users, tokens, and connected accounts when the app is shut down. If any one of those is missing, the organisation is effectively accepting an undefined access lifecycle.

This is also where broader programme design helps. NHIMG’s Identity Security Programme Guide reinforces the value of clear RACI and operating-model boundaries, and the IAM and Identity Provider Buyer’s Guide is a practical reference for evaluating whether the requested SaaS can fit the existing identity architecture.

How to Prevent Shadow IT from Becoming Shadow Access

The real failure mode is not just unsanctioned software, it is unsanctioned access paths that never enter the entitlement record. Once a SaaS app bypasses intake, you usually lose visibility over who has admin rights, which accounts are local only, what third-party integrations were added, and whether offboarding is even possible without a vendor ticket.

That is why the question is not “do we allow the tool?” but “can we support and unwind the identity relationships it creates?” Strong intake should force the answer to that question before any production use. If the app cannot be federated, inventoried, or cleanly retired, the burden shifts from convenience to risk.

For cloud-connected or API-heavy SaaS, the same issue can extend beyond users into keys, tokens, and service credentials. NHIMG’s Cloud Workload Identity Guide is relevant because many SaaS deployments quietly introduce machine-to-machine access that must also be governed, not just human sign-on.

Risk and Threat Considerations

Uncontrolled SaaS intake creates persistent identity sprawl, orphaned access, and weak offboarding, especially when departments create their own admin accounts or integrations outside central review. The risk is not theoretical: the longer those accounts and connections exist, the more likely they are to outlive the business need that justified them.

Failure mechanism: SaaS is adopted first and governed later, so the organisation never gets a complete record of ownership, entitlement scope, or deprovisioning responsibility. That makes dormant accounts, stale tokens, and unowned admin paths easy to miss during audits or incidents.

Impact: Access cleanup becomes recurring manual work, entitlement evidence fragments across teams, and any compromise or employee departure can leave behind active access that nobody is clearly accountable for removing.

Practitioner Guidance

What to prioritise: Put a hard intake gate in front of deployment and make approval depend on an explicit identity design, not on business urgency. If the tool cannot name its owner, auth pattern, and offboarding owner, it is not ready for production use.

What to verify: Confirm that every approved SaaS app has a documented source of identity truth, a reviewable approval trail, and a defined retirement process for users, admins, and integrations. The control should fail closed when any of those elements is missing.

Practitioner takeaway: The goal is not to block self-service buying, it is to ensure that every new SaaS app enters with a lifecycle, an owner, and an exit path that IAM can actually enforce.

Related resources from NHI Mgmt Group

• Who should own SaaS app lifecycle decisions when business units self-procure tools?
• Who should own SaaS security when business teams buy tools first and IT learns later?
• How should security teams make NHI best practices usable across the business?
• How can IAM and security teams reduce third-party risk from AI-enabled SaaS tools?