Accountability should sit jointly with security, IT, and the business owner that requested the integration. Security should define standards, IT should support discovery and control, and the business should justify access and confirm ongoing need. If no one owns the integration lifecycle, shadow access accumulates and offboarding rarely happens on time.
Why This Matters for Security Teams
SaaS-to-saas integration create an identity problem, not just an application problem. When a business unit connects one cloud app to another, the integration often inherits access to records, files, tickets, and messaging data without a clear lifecycle owner. That makes the connection a non-human identity governed by secrets, scopes, and revocation discipline. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why integrations are frequently discovered only after they have already spread across business workflows.
Security teams often assume the technical owner will clean up stale access, but the business usually treats the integration as a productivity feature, not an asset with recurring risk. That gap is where shadow access accumulates. The control expectation is therefore shared accountability, with standards from security, operational support from IT, and business justification from the requesting owner. This aligns with guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls and the governance focus in Ultimate Guide to NHIs — Key Challenges and Risks. In practice, many security teams encounter integration sprawl only after a business owner leaves or a vendor connection starts failing, rather than through intentional lifecycle management.
How It Works in Practice
Accountability should follow the integration lifecycle. The business owner requests the connection, explains the business purpose, and confirms who benefits from the data flow. Security sets the minimum control baseline for scopes, token handling, logging, segregation of duties, and periodic review. IT or platform teams then help discover the integration, register it, and enforce technical controls across the connected SaaS stack. This is the practical shape of ownership because the risk sits in both the identity and the workflow.
For mature programmes, the connection should be treated like any other NHI asset. That means the integration is inventoried, its credentials or OAuth grants are time-bounded, and its access is reviewed on a schedule that matches the business value. If the tool supports delegated auth, scope minimisation should be preferred over broad tenant-wide consent. If the tool uses API keys or tokens, those secrets should be stored in controlled systems, rotated, and revoked when the business need ends. The lifecycle should also include offboarding triggers tied to vendor termination, project closure, and changes in data ownership. The control logic should map to NIST Cybersecurity Framework 2.0 for governance and risk management, and it should be informed by breach patterns described in the Salesloft OAuth token breach and the BeyondTrust API key breach.
For risk acceptance, the key question is not who clicked “connect,” but who can prove the connection still needs to exist and who can remove it if that answer changes. These controls tend to break down when business units can self-authorise SaaS connections without central inventory because the organisation loses sight of both ownership and revocation.
Common Variations and Edge Cases
Tighter integration control often increases friction for business teams, requiring organisations to balance speed of adoption against auditability and revocation discipline. That tradeoff becomes especially visible in low-code platforms, managed marketplaces, and federated SaaS ecosystems where users can authorise connectors without involving IT.
Current guidance suggests three common patterns. First, some organisations assign the business owner as the risk owner and IT as the technical custodian. Second, others make the application owner responsible only for business justification, while security owns the control framework and exception process. Third, high-risk integrations involving customer data, finance systems, or admin scopes may require security approval before any consent is granted. There is no universal standard for this yet, but the ownership model must be explicit enough that revocation is not dependent on tribal knowledge.
Edge cases matter. Vendor-managed integrations can hide the real credential holder. Cross-functional automations may span multiple business units, so a single owner is not enough unless backup accountability is defined. M&A activity can also leave orphaned SaaS connections behind after directory and tenant consolidation. The practical lesson is reinforced by NHIMG research on Top 10 NHI Issues, which shows that visibility and offboarding remain persistent weaknesses across non-human identities. In the real world, the integration risk usually surfaces when someone asks who can safely turn it off, and nobody can answer quickly.
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 AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | SaaS integrations are non-human identities that need inventory and ownership. |
| CSA MAESTRO | Shared accountability fits agent and integration governance across business, IT, and security. | |
| NIST AI RMF | Governance and accountability are core AI RMF concerns for automated connected workflows. | |
| NIST CSF 2.0 | GV.RM-01 | Risk management demands clear ownership for third-party and SaaS connections. |
| NIST Zero Trust (SP 800-207) | SA, AC | Zero Trust requires continuous verification of every integration's access and trust. |
Inventory every SaaS integration, assign an owner, and review its access and lifecycle on a fixed cadence.
Related resources from NHI Mgmt Group
- Why do AI agents create governance risk when they query live business context from catalog systems?
- How should security teams reduce risk from dormant SaaS integration credentials in third-party ecosystems?
- Who is accountable when access review scoping decisions create audit gaps or miss high-risk roles?
- Why do SaaS environments still create identity risk even after SSO is in place?
