Who is accountable for securing app-to-app connections and service accounts?

Accountability should sit with the system and business owners who approve the integration, with security setting policy, visibility, and control requirements. Identity, cloud, and application teams should share responsibility for inventory, approval, review, and revocation. If ownership is unclear, the organisation should treat the connection as risky until it is explicitly assigned and validated.

Why This Matters for Security Teams

App-to-app connections and service account often become the quietest path to broad compromise because they sit between application ownership, infrastructure administration, and security oversight. NHI Management Group has shown how often these identities go unmanaged, including the finding that NHIs outnumber human identities by 25x to 50x in modern enterprises. That scale makes unclear accountability more than a governance issue; it becomes an exposure multiplier. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access, review, and revocation must be assigned, not assumed.

In practice, this is where service accounts end up with no clear owner, no expiry, and no one prepared to answer for the access they retain after the original project changes direction.

How It Works in Practice

The accountable party is usually the business or system owner who approved the integration, because that party can define why the connection exists and whether it still needs to exist. Security should not own the business decision, but it should define the guardrails: approved authentication methods, minimum permissions, logging, review cadence, and revocation requirements. Identity, cloud, and application teams then operationalise those controls across inventory, lifecycle management, and monitoring.

Practically, that means each app-to-app connection should have a named owner, an explicit purpose, a documented data flow, and a defined expiration or review date. Service accounts should be treated as Non-Human Identities with their own lifecycle, not as technical leftovers. Controls should cover issuance, rotation, vaulting, approval workflow, and offboarding. NHIMG’s 52 NHI Breaches Analysis is useful here because many incidents follow the same pattern: a connection was created for convenience, then forgotten after the workload changed.

• Business owner approves the use case and risk acceptance.
• System owner maintains the inventory and confirms operational necessity.
• Security defines policy, review thresholds, and logging expectations.
• Cloud, platform, and identity teams enforce rotation, least privilege, and revocation.

For implementation, NIST guidance is most useful when mapped to concrete control ownership, while NIST SP 800-53 Rev 5 helps anchor access management, account monitoring, and contingency expectations. These controls tend to break down when integrations are created inside CI/CD pipelines without a recorded business owner or when service accounts are shared across multiple applications, because revocation then becomes operationally risky.

Common Variations and Edge Cases

Tighter ownership controls often increase administrative overhead, requiring organisations to balance faster delivery against stronger accountability. That tradeoff is real in environments with shared platforms, outsourced development, or legacy middleware, where one connection may support several services and one team may not have full context. Current guidance suggests the answer is not to dilute ownership, but to make it explicit: assign one accountable owner and document all operational stewards around that owner.

There is no universal standard for this yet, but best practice is evolving around workload-centric governance rather than human-centric ticketing. If a service account is embedded in a third-party integration, the internal owner still needs to approve the risk and the external supplier still needs to meet internal control requirements. This is especially important when a breach path is not obvious at creation time, as illustrated in the Dropbox Sign breach, where identity and integration trust assumptions became part of the exposure.

Where ownership becomes ambiguous, the safest operational stance is to treat the connection as untrusted until inventory, business justification, and revocation authority are all verified. That is the point at which governance shifts from theory to containment.

Related resources from NHI Mgmt Group

• Who is accountable when shared service accounts or API keys are left exposed?
• What problem does ownership attribution solve for service accounts and API keys?
• When do service accounts become a higher risk than ordinary user accounts?
• How should security teams govern Active Directory service accounts?