What should organisations do when users create or onboard apps outside central IT?

Why This Matters for Security Teams

When users can connect SaaS apps without central IT, the organisation inherits a governance problem that looks like convenience but behaves like identity sprawl. Those apps often receive broad OAuth scopes, inherit stale access paths, and bypass the controls normally applied to sanctioned systems. That makes offboarding, auditability, and incident response much harder, especially when the app stores tokens or can call downstream APIs.

This is not just a visibility gap. It is an entitlement lifecycle issue that belongs alongside access review, secrets management, and third-party risk. NHI Management Group has repeatedly highlighted how secrets exposure and weak lifecycle controls turn ordinary integrations into durable attack paths, including in the Ultimate Guide to NHIs and the JetBrains GitHub plugin token exposure research. The same lesson applies here: unmanaged app onboarding creates access that survives user departure, policy changes, and sometimes even security tooling.

Security teams that treat this as a procurement problem alone usually miss the identity layer. In practice, many security teams encounter uncontrolled app access only after a user leaves, a token is abused, or a routine audit exposes that no one knows who owns the app.

How It Works in Practice

The operational goal is to turn self-onboarded apps into governed identities with owners, scopes, and revocation paths. Start by discovering apps through SSO logs, consent grants, CASB telemetry, SaaS admin APIs, and directory audit trails. Then classify each app by business owner, data sensitivity, and whether it creates a human-facing or machine-to-machine access path.

After discovery, map the app to the same lifecycle controls used for approved systems: approval, periodic review, offboarding, and token rotation. For apps that use OAuth or API keys, review the exact scopes and connections rather than relying on the app name. Many “small productivity apps” actually hold write access to email, storage, source code, or ticketing systems. Current guidance from the NIST Cybersecurity Framework 2.0 supports this kind of continuous governance approach, even though there is no universal standard for every SaaS onboarding model yet.

• Assign a named business owner and a technical steward for every app.
• Review consented scopes, not just user lists.
• Revoke unused tokens and remove dormant integrations on a schedule.
• Require offboarding triggers when the owner leaves or the app is no longer needed.
• Log app creation, consent, and privilege changes for audit and incident response.

Use the NHI lifecycle mindset from the Ultimate Guide to NHIs to bring these apps into entitlement review and rotation workflows, because the risk is usually in the persistent credential, not the interface itself. These controls tend to break down in large federated SaaS environments because app consent can be granted outside the visibility of central identity teams.

Common Variations and Edge Cases

Tighter control over self-onboarded apps often increases friction for users, so organisations have to balance agility against governance overhead. The best practice is evolving toward tiered treatment rather than a single rule for every app.

Low-risk productivity tools may be allowed through a pre-approved app catalog, while higher-risk integrations that touch source code, finance, customer data, or admin APIs need stronger review and explicit owner approval. Some environments also have to account for shadow M2M connections, where an employee creates an app that later behaves like a service identity with ongoing API access. That is why identity governance for apps should include both human approval and machine credential review.

There is no universal standard for this yet, but current guidance suggests that organisations should treat consented SaaS access like any other privileged access path. For regulated sectors, this should also feed vendor risk, retention, and incident response workflows. If the app can mint tokens, call APIs, or persist after the user leaves, it should be managed as an identity-bearing workload rather than a convenience tool.

In practice, the hardest cases are apps created in business units with no central admin oversight, because ownership is ambiguous and revocation becomes a manual chase across multiple platforms.

Related resources from NHI Mgmt Group

• Why do shadow IT apps create identity risk even when users still have valid SSO access?
• Why do shadow SaaS apps create a governance problem, not just an IT inventory problem?
• Why do unused SaaS apps still create security risk after renewal is cancelled?
• Why does shadow AI create more risk when organisations try to prohibit it?