A connected application is a software service linked to another system so it can access data, authenticate users, or exchange events and commands. In identity security, it typically relies on delegated authorization, API credentials, or tokens, which must be governed as non-human identities, monitored for scope, and revoked when no longer needed.
How connected applications work
A connected application is not just a generic integration. It is a software service that is intentionally linked to another system so it can exchange data or trigger actions, and that link usually creates a persistent trust relationship that must be managed over time.
In practice, the connection may be established through OAuth-style delegated access, API keys, service tokens, signed assertions, or other credentials that let one system act on behalf of a user or another workload. The security importance comes from the fact that the connected app can inherit meaningful access without being a human user, so the connection itself becomes a control point.
Why connected applications matter to identity security
Connected applications sit at the boundary between applications, platforms, and identities. They often need read access, write access, event subscriptions, or permission to call downstream APIs, which means the scope granted to the connection can be broader than the end user realises.
That makes them a common place for overprivilege, excessive scopes, stale access, and weak ownership. If the original business need changes, the connection should be revisited, because a once-useful integration can become an unnecessary standing path into sensitive systems.
Common trust and control patterns
Most connected applications depend on explicit registration, consent, or administrator approval before they are allowed to operate. Mature environments distinguish between the application identity, the user identity, and the permissions granted to each, instead of treating the integration as a simple feature toggle.
Strong controls usually include tightly scoped tokens, separate credentials for each environment, inventory of active integrations, periodic review of granted permissions, and a clear owner who can revoke access when the integration is retired or abused. Where the connection is machine-to-machine, the same discipline applies to secret storage, rotation, and expiry.
What can go wrong if the connection is poorly governed
Connected applications can become a hidden pathway for data exposure or unauthorized action when permissions are broader than intended, credentials are reused, or the integration is no longer monitored. Because they are meant to operate continuously, compromise can persist unnoticed longer than with an interactive user account.
Good governance treats the connected app as an operational trust relationship, not a one-time setup step. That means the organisation should know what the app can access, why it needs that access, who owns it, and how fast it can be cut off if the relationship becomes unsafe.
Risk and Threat Considerations
Connected applications concentrate trust in a reusable software-to-software relationship, which makes them attractive targets for credential theft, token abuse, consent phishing, and privilege escalation. If the integration is over-scoped or forgotten, attackers may gain durable access to data and workflows even after the initial user session ends.
Failure mechanism: A connected application is granted more access than it needs, or its secret, token, or delegated grant is exposed, reused, or left active after the business need has passed.
Impact: The attacker or unintended process can read data, modify records, trigger actions, or move laterally through connected systems without needing a normal interactive login.
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 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Connected apps often rely on delegated credentials and scopes that can exceed business need. |
| NHI-02 — Secret Leakage | Connected applications commonly depend on API keys, tokens, or service secrets that can be exposed. | |
| Recommendation — Constrain connected-app scopes to the minimum required and review permissions before renewal. Store connected-app secrets securely and monitor for exposure across code, logs, and pipelines. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Connected applications authenticate to downstream systems through tokens, keys, or assertions. |
| Recommendation — Verify token handling, rotation, and validation for every connected application integration. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Authentication | Connected applications frequently authenticate as services or workloads to other systems. |
| AC-6 — Least Privilege | The core risk in connected applications is excess access relative to their business function. | |
| IA-5 — Authenticator Management | Connected applications rely on credentials, tokens, and secrets that need lifecycle management. | |
| Recommendation — Require strong service-to-service authentication for connected applications and track each trust relationship. Limit connected applications to least privilege and remove unused access paths promptly. Rotate and retire connected-app authenticators on a defined lifecycle rather than leaving them permanent. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control are Managed | Connected applications require governance over identities, access scope, and authorization paths. |
| Recommendation — Inventory connected applications and manage their access as part of identity and access control. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Many connected applications use delegated authorization flows and token-based federation. |
| Recommendation — Validate OAuth and OIDC flows carefully when connected applications depend on delegated access. | ||
Practitioner Guidance
Why practitioners should care: Treat every connected application as a governed identity-bearing integration, not as a convenience feature. Its access should be discoverable, attributable, and reviewable just like any other privileged path.
What to watch for: Long-lived tokens, broad API scopes, undocumented integrations, and connections that keep working after the business owner has forgotten them are all signs that the trust relationship needs review. If a connected app cannot be clearly tied to an owner and a purpose, its access should not remain open by default.
Related resources from NHI Mgmt Group
- OAuth Connected App
- Why do application-level access reviews miss SoD risk in connected systems?
- Who is accountable when a vulnerable BI application exposes connected databases, stored credentials, and scheduler execution paths to unauthenticated attackers?
- How should security teams govern access when only part of the application estate is connected to SSO and SCIM?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org