Accountability is shared across the business owner of the integration, the SaaS security team, and the vendor that issued or relied on the token. Governance frameworks should require named ownership, periodic access review, and clear offboarding for every connector that can reach sensitive records.
Why This Matters for Security Teams
When a third-party integration exfiltrates CRM data, the failure is rarely just technical. It usually reflects weak ownership of a non-human identity, unclear approval boundaries, and missing revocation discipline. NHIMG data shows 92% of organisations expose NHIs to third parties, which makes connector risk a mainstream governance issue rather than an edge case. That is why controls in the OWASP Non-Human Identity Top 10 and the Ultimate Guide to Non-Human Identities emphasize lifecycle management, not just initial access grant. The business owner, SaaS security team, and vendor may each hold a piece of accountability, but none can be allowed to assume the others are handling it. In practice, many security teams encounter this only after a connector has already copied records into a downstream app or attacker-controlled tenant, rather than through intentional offboarding or periodic access review.
How It Works in Practice
Accountability should follow the control plane, not just the data plane. The team that sponsors the integration owns the business use case and risk acceptance. The SaaS security team owns policy enforcement, monitoring, and review of the connector’s scope. The vendor owns the token issuance model, the security of its platform, and the ability to revoke or rotate the credential when abuse is suspected. That split lines up with NIST control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls, where access, audit, and configuration management are separate responsibilities.
Operationally, security teams should require:
- Named business owner and technical owner for every CRM connector.
- Explicit scope for objects, fields, and API actions the token can reach.
- Short token lifetimes, rotation rules, and immediate offboarding when the use case ends.
- Logging for token use, unusual export volume, and cross-tenant destinations.
- Periodic recertification so dormant integrations do not retain broad access indefinitely.
NHIMG’s 52 NHI Breaches Analysis repeatedly shows that compromise often follows overprivileged or poorly governed non-human access, not sophisticated zero-day exploitation. The practical lesson is that the vendor may issue the token, but the organisation that connected it still owns the risk of what that token can reach. These controls tend to break down when the integration is embedded in a shadow IT workflow with no inventory, no owner, and no revocation path.
Common Variations and Edge Cases
Tighter connector governance often increases operational overhead, requiring organisations to balance faster integrations against stronger review and revocation. There is no universal standard for shared accountability in third-party SaaS connectors yet, so current guidance suggests using a written RACI, contractual security clauses, and evidence-based access reviews. That matters because some failures begin with a legitimate integration and end with an attacker using its token to move data out of the tenant, as seen in incidents like the Klue OAuth Supply Chain Breach and the Vercel Context.ai OAuth Supply Chain Breach.
Edge cases include marketplace apps, reseller-managed connectors, and workflows where the vendor can act on behalf of multiple customers. In those environments, the question is not only who approved access, but who can actually revoke it within minutes. Best practice is evolving toward least-privilege tokens, just-in-time approval, and continuous monitoring of connector behavior, especially when CRM data is replicated into analytics, AI, or support systems. Where the organisation cannot prove ownership, scope, and revocation authority, accountability is already failing even before the data leaves the CRM.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Defines ownership and lifecycle control for non-human identities. |
| OWASP Agentic AI Top 10 | Connector abuse mirrors autonomous tool use and delegated access risk. | |
| CSA MAESTRO | Highlights governance for machine-to-machine and agentic access paths. | |
| NIST AI RMF | Accountability and monitoring are core AI risk governance expectations. | |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and access authorization apply to third-party connectors. |
Document ownership, monitor behavior, and escalate abnormal data movement through governance.
Related resources from NHI Mgmt Group
- Who is accountable when a third-party integration exposes sensitive healthcare data?
- Who is accountable when a third-party integration is abused?
- Who is accountable when a third-party integration keeps an NHI active after the business need ends?
- Who is accountable when replayed tokens come from a compromised third-party integration?
