Business-led IT and shadow SaaS: governance gaps to close

At a glance

What this is: This is 1Password’s case for governing shadow SaaS through visibility, discovery, and lifecycle management, with the key finding that 34% of applications sit outside company SSO.

Why it matters: It matters because unmanaged SaaS creates the same identity governance problems practitioners already face with NHI sprawl: hidden access, weak lifecycle control, and inconsistent review processes across business-owned tools.

By the numbers:

• According to IT professionals, 34% of applications sit outside of the company’s SSO.

👉 Read 1Password's analysis of business-led IT and shadow SaaS governance

Context

Shadow SaaS is what happens when business teams adopt applications outside central IT oversight. The governance problem is not the existence of those tools, but the lack of visibility, access control, and lifecycle handling that lets them sit outside identity and compliance workflows. For IAM teams, that turns ordinary productivity decisions into unmanaged access risk.

The primary issue is that application sprawl and identity sprawl reinforce each other. When IT cannot see which tools are in use, it cannot standardize SSO, review entitlements, or retire unused access cleanly. That is why governance for SaaS adoption now looks increasingly similar to NHI lifecycle control, especially where user delegation, API access, and embedded integrations expand the blast radius of a single unmanaged app.

Key questions

Q: How should security teams govern shadow SaaS without blocking business productivity?

A: Security teams should treat shadow SaaS as a discovery and lifecycle problem, not a prohibition problem. Let business units adopt tools when needed, then pull those tools into inventory, ownership, access review, and retirement workflows. That keeps innovation moving while restoring identity governance over the applications that matter.

Q: Why do unmanaged SaaS apps create identity governance risk?

A: Unmanaged SaaS apps create risk because they sit outside central visibility, which means IT cannot consistently enforce SSO, review entitlements, or offboard access. The longer an app remains invisible, the more likely it is to accumulate stale permissions, duplicate functions, and unmanaged data exposure.

Q: What do IAM teams get wrong about business-led IT?

A: The common mistake is assuming business-led IT means losing control. In practice, it means control has to shift from direct approval of every tool to governance of ownership, review, and retirement. If those controls are missing, business-led adoption becomes unmanaged sprawl rather than delegated decision-making.

Q: How do organisations know when a SaaS app should be brought under formal governance?

A: A SaaS app should be brought under formal governance when it is used by multiple teams, handles company data, or sits outside SSO and access review processes. Those are the signals that a convenience tool has become part of the operating environment and needs lifecycle control.

Technical breakdown

SaaS visibility as an identity control plane

SaaS visibility is the discovery and inventory layer that tells IT which applications are actually in use, who is using them, and whether they are connected to approved identity workflows. Without that view, apps accumulate outside SSO, renewals happen without review, and access decisions fragment across teams. In practice, visibility is the prerequisite for governance because you cannot certify, restrict, or retire what you cannot find. The control problem is not theoretical. It is an operating-model failure where identity records and application reality drift apart.

Practical implication: build continuous discovery into IAM and SaaS governance so unmanaged apps are identified before they become permanent exceptions.

Lifecycle management for business-led IT

Lifecycle management in SaaS governance covers onboarding, access changes, renewals, and offboarding for applications chosen by business teams. The point is not to block business-led adoption, but to ensure every app enters a governed process once it becomes part of work. That means mapping app owners, approval paths, access review cadence, and retirement criteria. When these controls are missing, the business may keep using tools long after IT has lost sight of them, which is how shadow IT becomes shadow data. The governance model is closest to NHI lifecycle discipline, even when the subject is a SaaS application rather than a credential.

Practical implication: treat each unmanaged SaaS app as a lifecycle object with an owner, review cadence, and retirement trigger.

SSO coverage and overlapping app consolidation

SSO coverage is one of the clearest signals of whether SaaS adoption is under governance or drifting into exception handling. If a large share of apps sits outside SSO, the organisation is likely supporting duplicate tools, inconsistent authentication paths, and hidden access paths that bypass central policy. Overlap also creates spend inefficiency, because teams may pay for multiple tools that do the same job. The technical problem is not only authentication fragmentation, but the absence of a clean control boundary between sanctioned and unsanctioned usage.

Practical implication: use SSO coverage and duplicate-app findings to prioritise consolidation before access risk and spend waste compound.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow SaaS is an identity governance problem, not a behaviour problem. The article correctly moves away from treating business-led IT as employee defiance. The real issue is that identity and access workflows lose sight of applications once adoption happens outside central approval paths. That creates unmanaged access, incomplete reviews, and unclear ownership across the application lifecycle. Practitioners should treat shadow SaaS as a governance boundary failure, not a user-discipline issue.

Business-led IT only works when governance follows usage. The article’s strongest point is that central IT does not need to own every app decision, but it does need a framework that brings unmanaged tools back into review, access control, and offboarding processes. That framing matches how modern IAM programmes have to operate across human, NHI, and delegated access patterns. The lesson is not to centralise every choice, but to ensure every choice becomes governable. Practitioners should design for distributed adoption with central oversight.

Unmanaged SaaS creates the same lifecycle failure mode that defines many NHI incidents. Access outlives visibility, ownership becomes ambiguous, and review cycles miss the point because the asset was never fully onboarded into governance. That is the same structural weakness seen in long-lived NHI credentials and delegated access paths. The specific failure mode here is lifecycle drift, where a tool remains operational after it has fallen outside policy. Practitioners should recognise that lifecycle control is the common discipline across SaaS, service accounts, and AI-enabled access.

SaaS consolidation is a governance signal, not just a cost exercise. The article shows how overlapping apps and underused licenses are tied to the same discovery gap that drives security blind spots. When teams consolidate without visibility, they can reduce spend but still leave hidden access paths intact. The more durable position is that consolidation should be driven by identity visibility first and cost optimisation second. Practitioners should connect procurement, IAM, and app rationalisation into one control loop.

Business and IT collaboration is now a control design requirement. The article is right that line-of-business teams often know the tools they need, but that knowledge only becomes safe when IT can translate it into policy, review, and retirement processes. This is where the named concept of governed business-led IT applies: decentralised selection with central lifecycle control. That model will shape how organisations manage SaaS, NHI-adjacent integrations, and eventually autonomous workflow tools. Practitioners should build the control loop now, before tool sprawl hardens into policy debt.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For the broader governance model behind this pattern, see NHI Lifecycle Management Guide for how discovery, rotation, and offboarding fit into one control loop.

What this signals

Business-led IT is becoming the default operating model for SaaS adoption, and IAM teams need to adapt to it. The question is no longer whether line-of-business teams will choose tools outside central procurement, but whether identity governance can absorb those choices without losing control. With 34% of applications already outside SSO, the practical signal is that discovery and lifecycle automation need to move closer to the point of adoption, not only the point of review.

Lifecycle drift is the named concept that matters here. It describes the state where an application remains active after governance has lost track of who owns it, who approved it, and when it should be retired. That drift looks similar across SaaS, NHI credentials, and delegated access paths, which is why programmes should align app governance with the same offboarding discipline used for machine identity.

The next step is to connect app visibility to policy enforcement rather than reporting alone. Teams that only inventory shadow SaaS will keep finding the same problem; teams that use the inventory to trigger review, consolidation, and retirement can shrink risk without slowing business adoption. That is where identity governance begins to operate as a control system rather than a checklist.

For practitioners

• Create a continuous SaaS discovery process Inventory applications across business units, then reconcile them against SSO coverage, approved app lists, and procurement records. Re-run discovery on a fixed cadence so new tools surface before they become unmanaged exceptions.
• Assign lifecycle owners for every business-led app Require each application to have an accountable owner for onboarding, access review, renewal, and retirement. Tie that ownership to the same review workflow used for access certification and deprovisioning.
• Use SSO coverage to prioritise remediation Target applications outside SSO first, because they are the likeliest to have fragmented authentication, inconsistent offboarding, and weak auditability. Use that list to drive standardisation and exception review.
• Consolidate overlapping tools before expanding licences Compare business-unit usage against existing enterprise tools, then remove duplicate apps where the managed platform already meets the workflow need. That reduces both spend waste and hidden access paths.
• Embed security review into business-led adoption Require a security and compliance checkpoint before an unmanaged app becomes part of standard work. Use that step to decide whether the app should be approved, restricted, or retired.

Key takeaways

• Shadow SaaS becomes a governance problem when applications sit outside SSO, ownership, and lifecycle control.
• The article’s key signal is that business-led adoption can coexist with security, but only when discovery and review are continuous.
• IAM teams should treat SaaS visibility, access review, and offboarding as one operating loop rather than separate tasks.

Key terms

• Shadow SaaS: Shadow SaaS is software adopted by business teams without full central IT visibility or approval. The risk is not the existence of the app itself, but the loss of identity governance, access review, and offboarding discipline once the tool becomes part of daily work.
• Business-led IT: Business-led IT is a governance model where line-of-business teams influence tool selection because they understand operational needs better than central IT does. In a secure programme, that autonomy is paired with visibility, approval paths, and lifecycle control so local choice does not become unmanaged access.
• Lifecycle management: Lifecycle management is the process of tracking an application or identity from onboarding through changes, review, renewal, and retirement. For SaaS, it ensures tools do not remain active without ownership, oversight, or an agreed reason to exist in the environment.
• Sso coverage: SSO coverage measures how much of an organisation’s application estate authenticates through central single sign-on. Low coverage usually means fragmented access paths, weaker policy enforcement, and harder offboarding, which makes it a useful signal for governance maturity.

Deepen your knowledge

SaaS visibility, lifecycle control, and access review are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for business-led IT in a similar environment, it is worth exploring.

This post draws on content published by 1Password: business-led IT and shadow SaaS governance. Read the original.