What happens when app-to-app connections are created without IT oversight?

When integrations are created without IT oversight, organisations can lose track of who connected what, which permissions were granted, and whether the connection still serves a valid business purpose. The result is hidden access, compliance gaps, and a larger attack surface. Over time, those unmanaged links can persist long after the original user or workflow changes.

Why Unmanaged App-to-App Connections Become a Security Problem

App-to-app connections are often treated as simple automation, but they are still trust relationships with permissions, data access, and lifecycle obligations. When those links are created outside IT oversight, the organisation may not know which system owns the connection, whether the granted scope is appropriate, or whether the integration is still needed. That creates governance blind spots that can outlive the original business request. For a control perspective, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it maps those blind spots to access management, configuration management, and monitoring expectations.

In practice, many security teams discover unmanaged integrations only after a user leaves, a workflow changes, or an audit asks for evidence that no one can quickly produce.

How Unmanaged Integrations Create Hidden Privilege

Once an integration is authorised, it usually inherits enough access to move data, trigger actions, or read records in one or more systems. If no one tracks the approval path, the identity behind the connection, and the business owner, the integration can behave like a permanent exception rather than a managed control. That is where the risk grows: permissions are rarely revalidated, tokens and secrets may remain active, and the connection can continue working even when the original justification no longer exists.

The practical failure is not simply that the integration exists. It is that the organisation loses the ability to answer basic questions about it. Who approved it? What data can it reach? Which service account or API key does it use? When was it last reviewed? Without those answers, revocation becomes difficult and monitoring becomes incomplete. In larger environments, the problem is amplified by SaaS sprawl, low-code tooling, and shadow automation, where business users can connect services faster than central teams can review them.

Ownership becomes unclear when business teams create connections without a formal control point.
Privilege can be broader than expected because integrations often need machine-to-machine authentication.
Secrets and tokens can persist beyond their intended use if there is no lifecycle review.
Logging and alerting may not cover the full path between the source app and the target app.

Where organisations do maintain approval records, inventory, and periodic recertification, unmanaged app-to-app links are easier to detect and remove. Where those controls are missing, the integration effectively becomes an undocumented access path, and that is where the guidance breaks down most quickly.

Common Breakpoints in Shadow Integration Environments

Tighter governance often slows down lightweight automation, so organisations have to balance speed against control. The most common breakpoints appear when teams optimise for convenience and treat every connection as a one-time setup instead of a standing access relationship.

One edge case is a low-risk read-only integration. Even then, it still needs ownership and review because low privilege today can become broader privilege after a product change or permission expansion. Another common variation is delegated consent in SaaS ecosystems, where a user authorises an app directly and the permission boundary is defined by the platform rather than by internal approval. That can be legitimate, but it should not be confused with being unmanaged. The difference is whether the organisation can inventory, assess, and revoke the connection on demand.

There is also a governance distinction between formal enterprise integrations and informal workflow automation. The first may be centrally designed but still poorly monitored; the second may be business-efficient but entirely outside normal review. The security question is not whether the tool is sanctioned in theory, but whether the connection is visible, owned, and periodically validated in practice. NIST SP 800-53 Rev 5 Security and Privacy Controls is most helpful where teams need a control baseline for keeping those relationships inventoried and reviewable.

Risk and Threat Considerations

Unmanaged app-to-app connections create a durable access-risk class because they combine hidden privilege with weak lifecycle control. The main exposure is not only unauthorised access, but also stale access that remains valid after the business need, user role, or vendor relationship has changed.

Failure mechanism: Attackers and insiders can abuse over-scoped tokens, unattended service credentials, or forgotten integrations to reach data and functions that normal users should no longer control. Because these links often bypass interactive login, they can evade the review process applied to human accounts and remain active until someone inventories and revokes them.

Impact: Organisations can lose confidentiality over connected data, create unaudited change paths into business systems, and expand the blast radius of a compromise across multiple applications. They also inherit compliance and evidence problems when they cannot show who approved the connection, what access it had, or whether it was removed in time.

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 CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Unmanaged integrations create unclear access ownership and weak revocation.
Recommendation — Inventory app-to-app access and remove standing permissions that lack an accountable owner.
CIS Controls v8	6 — Access Control Management	The issue is uncontrolled permissions and stale access paths between applications.
	5 — Account Management	Connections often depend on service accounts, tokens, or shared identities.
Recommendation — Enforce approval, review, and revocation for every app-to-app access relationship. Track non-human accounts and rotate or disable credentials tied to unused integrations.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	App-to-app links commonly rely on tokens, API keys, or certificates.
	NHI-02 — Inventory and Ownership	The core failure is losing visibility over who owns and uses each connection.
	NHI-05 — Access Scope and Least Privilege	Unmanaged integrations often keep broader permissions than they need.
Recommendation — Bind each integration credential to an owner and revoke it when the business need ends. Maintain a complete inventory of integrations with explicit ownership and review dates. Limit each integration to the minimum scope required and recertify that scope regularly.

Practitioner Guidance

What to prioritise: Treat integration inventory as an access-control problem, not just an IT asset list. The first question is whether each connection has a named owner, a clear business purpose, and a revocation path.

What to verify: Check that the team can produce evidence for approval, scope, last review date, and current credential status. If any one of those is missing, the connection should be treated as unmanaged until proven otherwise.

Decision rule: If a business user can create or connect an app without a control checkpoint, then the organisation needs a review process for consent, permissions, and periodic recertification. If that process already exists but cannot revoke or audit the connection quickly, it is not strong enough in practice.

Practitioner takeaway: The real danger is not integration speed itself, but the loss of ownership over standing machine access; once that happens, removal becomes much harder than approval.