They often treat integrations as transport rather than control points. In practice, the integration layer can become the place where access is created, modified, and revoked, so teams must govern it with the same discipline they apply to directories, PAM, and lifecycle management.
Why This Matters for Security Teams
IAM teams often underestimate integration platforms because they look like plumbing, not privilege. That framing breaks down quickly: iPaaS tools, ETL jobs, workflow engines, and CI/CD connectors frequently hold tokens, create service accounts, and trigger changes across systems. Once an integration can read, write, or revoke access, it is part of the control plane and should be governed that way.
This is why NHIs are not just another account class. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, while 97% of NHIs carry excessive privileges in typical environments, a pattern that makes integration layers especially risky when they are treated as “low-trust” intermediaries. The broader OWASP Non-Human Identity Top 10 also reflects this control gap: integrations become a place where secrets accumulate, permissions sprawl, and revocation is delayed.
In practice, many security teams discover the integration layer is an identity system only after a connector has already provisioned access that nobody can easily trace.
How It Works in Practice
The practical mistake is to govern the source application but ignore the middleware that brokers access between systems. Integration platforms often authenticate with long-lived API keys, broad OAuth grants, or shared service credentials, then use those privileges to call downstream SaaS, cloud, and internal APIs. That means the platform is not merely moving data. It is making authorization decisions on behalf of the business.
A stronger model treats each integration as a bounded NHI with its own lifecycle, owner, purpose, and expiry. Current guidance suggests the control set should include secret inventory, scoped entitlements, environment separation, and explicit revocation workflows. Where possible, credentials should be short-lived and task-bound rather than static. That aligns with the direction of NHI governance described in NHI Management Group’s Ultimate Guide to NHIs and the risk patterns documented in the 2024 Non-Human Identity Security Report.
- Map each integration to a named business owner and a defined system purpose.
- Separate connector credentials by environment so prod access is not reused in test or dev.
- Use least privilege at the API, queue, and dataset level rather than granting platform-wide access.
- Rotate secrets on a schedule and revoke them automatically when the workflow is retired.
- Monitor for privilege expansion, because integrations are often modified faster than directories or PAM policies.
For implementation detail, control mapping should also reflect standards such as PCI DSS v4.0 where secrets handling and access restriction are in scope, even when the “user” is actually a machine-to-machine connector. These controls tend to break down when one integration account is shared across multiple pipelines because attribution, revocation, and blast-radius reduction all become impossible.
Common Variations and Edge Cases
Tighter integration control often increases operational overhead, requiring organisations to balance fast delivery against visibility and revocation discipline. That tradeoff is most visible in low-code automation, partner-to-partner integrations, and event-driven pipelines where teams want speed and reuse. The safest answer is not always full segregation, but there is no universal standard for this yet, so maturity varies by risk and regulatory exposure.
One common edge case is “owned” integrations built inside product teams rather than central IT. Those often fall outside directory governance, PAM reviews, and joiner-mover-leaver processes even though they can still create or delete access. Another is third-party managed integrations, where the vendor controls the runtime but the enterprise still owns the data and the downstream permissions. In those cases, the control question shifts from “who runs the tool?” to “who can prove what it is allowed to do, and how quickly can it be stopped?”
Security teams should also be wary of assuming every integration can use the same pattern. Batch jobs, human-in-the-loop workflow approvals, and autonomous sync engines have different trust and rotation needs. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it highlights how quickly secrets, access scope, and third-party exposure become difficult to manage once integrations scale. Best practice is evolving, but the direction is clear: govern integrations as identities, not infrastructure.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Integration platforms often hide excessive privilege and secret sprawl. |
| NIST CSF 2.0 | PR.AC-1 | Access rights must be governed for machine-to-machine integrations too. |
| NIST AI RMF | The question is about governance of automated access decisions and accountability. |
Inventory every integration identity, scope its access, and remove shared credentials.
