App-to-app integration security is the practice of controlling how software services authenticate, authorize, and communicate with one another. It focuses on reducing excess privilege, limiting third-party exposure, and monitoring activity across connected systems so integrations support automation without becoming an unmanaged attack path.
Expanded Definition
App-to-app integration security governs how one software service trusts another across APIs, event streams, OAuth grants, service accounts, and workload identities. In NHI security, the core issue is not just whether an integration works, but whether it is granted only the minimum access needed, for the shortest practical time, with clear auditability and revocation paths. That scope aligns closely with NIST Cybersecurity Framework 2.0, especially around access control, monitoring, and recovery.
Definitions vary across vendors because some teams treat this as an API security problem, while others fold it into identity governance, cloud security, or zero trust. NHI Management Group treats it as an identity and privilege discipline for software-to-software trust, including the lifecycle of tokens, certificates, and delegated authorizations. It also overlaps with external-facing supply chain risk when a third-party app receives broad access into internal systems. Guidance is still evolving, so any durable program should assume integrations are identities that must be governed, not just connections that must be enabled.
The most common misapplication is assuming an approved integration is inherently safe, which occurs when access is granted once and never revalidated after scope changes, vendor changes, or account turnover.
Examples and Use Cases
Implementing app-to-app integration security rigorously often introduces operational friction, requiring organisations to weigh automation speed against tighter approval, monitoring, and revocation controls.
- A SaaS app uses OAuth to read email and calendar data, but the security team restricts the grant to specific scopes and reviews renewal events after a vendor update. The same trust pattern is discussed in the State of Non-Human Identity Security research.
- A CI/CD pipeline pushes build artifacts to production through a service account with short-lived credentials, secret rotation, and an audited approval workflow, consistent with NIST Cybersecurity Framework 2.0.
- A customer support chatbot connects to ticketing and knowledge-base systems, but its tool access is segmented so a compromised app cannot enumerate unrelated records.
- A third-party analytics tool receives webhook access only to specific events, not blanket API permissions, reducing blast radius if the vendor is later compromised.
- A legacy service account is replaced with workload identity federation so the integration no longer depends on a long-lived shared secret.
These patterns become visible in real breach analysis, including the Klue OAuth Supply Chain Breach and the GitHub Repo Breach, where trusted integrations became pathways for broader access.
Why It Matters in NHI Security
App-to-app integrations are often the quietest path into enterprise systems because they operate with human-approved trust but machine-speed execution. When those identities are over-privileged, poorly inventoried, or never rotated, attackers inherit durable access that bypasses interactive controls. NHIMG research shows that 92% of organisations expose NHIs to third parties, and 97% of NHIs carry excessive privileges, which means integration security is frequently a supply chain problem as much as an IAM problem.
This is why NHI governance must cover token lifecycle, vendor access reviews, scope reduction, logging, and offboarding. The most damaging failures usually are not caused by the integration itself, but by forgotten grants, stale secrets, and hidden trust chains between systems. If an organisation cannot answer which app can act as which identity, it cannot reliably contain abuse or prove least privilege. That gap also reflects the visibility problem documented in the Ultimate Guide to NHIs, where only 5.7% of organisations report full visibility into service accounts.
Organisations typically encounter the operational cost of app-to-app integration security only after a vendor compromise, token leak, or unexpected data movement, at which point the identity behind the integration becomes operationally unavoidable to address.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers excessive permissions and unmanaged NHI trust between apps. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access permissions and least-privilege enforcement for connected systems. |
| NIST Zero Trust (SP 800-207) | AC-5 | Zero trust principles apply to workload-to-workload authentication and authorization. |
| NIST SP 800-63 | Identity assurance concepts inform credential strength and lifecycle for machine identities. | |
| CSA MAESTRO | Agentic and automated tool use requires governed identity and constrained tool access. |
Use strong, revocable credentials for app identities and require reauthentication for sensitive changes.
