A common mistake is treating integrations as isolated projects instead of a reusable capability. That usually leads to duplicated work, inconsistent patterns, and slower future delivery. Teams also underestimate the operational burden of maintaining many connectors over time. A stronger model is to design for repeatability, so new integrations can be delivered, supported, and updated with less effort.
Why the one-off mindset breaks down
Integrations stop being simple as soon as they enter production. What looks like a single project usually becomes a living capability with version changes, authentication updates, schema drift, retry logic, monitoring, support, and incident response. When teams do not design for that lifecycle up front, each new connector is rebuilt from scratch instead of extending a repeatable pattern.
The practical failure is not just extra effort. It is the accumulation of small inconsistencies: one team handles secrets differently, another logs too much, another misses a deprecation notice, and a fourth has no owner for breakage after release. Over time, the integration estate becomes harder to govern than the core application it supports.
That pattern is visible in real-world breaches tied to integration sprawl and token exposure, such as Klue OAuth Supply Chain Breach, Vercel Context.ai OAuth Supply Chain Breach, and GitHub Repo Breach, Heroku and Travis CI OAuth Tokens. These are not isolated coding mistakes, they are examples of what happens when connector trust, token handling, and downstream access are not treated as a managed capability.
What repeatable integration capability looks like
A better model treats integrations as productised infrastructure. That means standard patterns for authentication, secrets handling, error handling, observability, ownership, and change control, plus a clear expectation that every new connector inherits those defaults unless there is a documented exception. The goal is not uniformity for its own sake, but lower variance in how integrations are built and operated.
Teams also need to distinguish between the code that creates an integration and the operational work that keeps it healthy. A connector is only “done” when it can be monitored, rotated, reauthorised, patched, and retired without heroic manual effort. That is especially important where integrations depend on external services that may change scopes, API behaviour, or consent models without warning.
In practice, this is where the lifecycle burden becomes visible. NHIMG’s Ultimate Guide to Non-Human Identities is useful because it frames the broader maintenance problem around governance, rotation, visibility, and offboarding for machine-facing access. The same operating model applies to integrations even when teams do not think of them as identity work.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 5 — Account Management | Integrations need ownership, provisioning, review and revocation discipline. |
| CIS Control 6 — Access Control Management | Repeatable integrations depend on consistent permissioning and secret-backed access boundaries. | |
| CIS Control 8 — Audit Log Management | Operationalising integrations requires visibility into failures, changes, and misuse. | |
| Recommendation — Assign and review connector owners, access paths, and revocation steps for every integration. Enforce least privilege and consistent access patterns for integration accounts and tokens. Log integration events so breakage, misuse, and unexpected access can be detected and investigated. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Treating integrations as capability requires defining them as a governed service with ownership. |
| PR.AA-01 — Identity and Access Management | Integration estates rely on repeatable authentication and authorization patterns for service access. | |
| PR.PS-01 — Platform Security | Reusable integration patterns reduce configuration drift, secret exposure, and operational fragility. | |
| Recommendation — Define integrations as an operational capability with explicit ownership and lifecycle accountability. Standardize authentication and authorization for connector accounts, tokens, and API access. Build secure, repeatable connector patterns that reduce drift and simplify ongoing support. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | Integrations often fail when credentials and tokens are handled as one-off assets. |
| NHI-03 — Overprivileged Non-Human Identities | Connector sprawl often leads to excessive permissions and weak blast-radius control. | |
| NHI-06 — Lifecycle and Offboarding | Reusable integrations must include retirement, rotation, and revocation as standard practice. | |
| Recommendation — Centralize and protect integration secrets so each connector does not create new exposure paths. Constrain integration permissions to the minimum needed and review them as usage changes. Define deprovisioning and rotation steps for every connector before it enters production. | ||
Practitioner Guidance
What to prioritise: Standardise the few integration controls that create the most repeatability, especially secret storage, credential rotation, ownership, logging, and decommissioning. If those are left to each squad, the estate will fragment quickly and support costs will rise faster than delivery speed.
What to verify: Every live connector should have a named owner, a documented failure mode, and a retirement path. If a team cannot say who rotates its credentials, who gets paged on failure, and how the integration is revoked safely, the work is not operationally complete.
Common mistake: Teams optimise for the first delivery and assume the second integration will be “similar enough.” The reality is that without reusable patterns, each new connector creates fresh review work, fresh exception handling, and fresh support overhead.
Practitioner takeaway: The real unit of work is not the first integration, it is the operating model that lets the tenth integration be delivered safely without adding proportional manual burden.
Related resources from NHI Mgmt Group
- What do teams get wrong when they treat identity verification as a one-time compliance task?
- What do teams get wrong when they treat evals as one-off checks?
- What do security teams get wrong when they treat web exploit writeups as one-off edge cases?
- What do teams get wrong when they treat sso as a one-time integration?
