What breaks when organisations rely on manual connector development for critical integrations?

Why This Matters for Security Teams

Manual connector development looks harmless when the first integration works, but it becomes a control gap as soon as the environment changes. Each hand-built connector tends to encode its own assumptions about authentication, retries, entitlement scope, logging, and failure handling. That makes governance inconsistent across systems and leaves security teams without a reliable way to prove who can do what, when, and why.

This is especially risky for non-human identities because the connector is often the enforcement point for secrets, service accounts, and API access. When that logic is custom and undocumented, offboarding, rotation, and entitlement review drift apart. NHIMG research notes that only 5.7% of organisations have full visibility into their service accounts, which means many teams are already managing critical integrations with partial knowledge at best, not with the control fidelity expected under NIST Cybersecurity Framework 2.0. In practice, many security teams encounter connector sprawl only after a failed rotation, a broken integration, or an audit exception has already exposed the gap.

How It Works in Practice

Manual connectors usually break in the same places: identity handling, policy enforcement, and lifecycle automation. A developer hardcodes an API key, a service account, or a token exchange flow for one application, then reimplements slightly different logic for the next one. Over time, the enterprise ends up with a patchwork of connector-specific access paths rather than a standard model for workload identity, least privilege, and revocation.

The safer pattern is to treat connector development as a governed identity and access problem, not only an integration task. That means mapping each connector to a named NHI, attaching clear ownership, using short-lived credentials where possible, and logging the authorization decision that allowed the action. In mature environments, this is paired with central secrets management, policy-as-code, and lifecycle automation so that entitlement changes flow through the same approval and review process as other privileged access. Guidance from the NIST Cybersecurity Framework 2.0 supports this kind of control consistency, while NHIMG guidance emphasises visibility and rotation discipline across NHI estates.

Practically, teams should look for whether the connector can answer four questions: what identity is used, what permissions are granted, how long the credentials remain valid, and how revocation is enforced. That is where manual code often fails, because the connector becomes a hidden policy engine with no durable audit trail. NHIMG research on the Ultimate Guide to Non-Human Identities is useful here because it frames lifecycle management as a security control, not an administrative afterthought. The same pattern appears in the GitHub Repo Breach, where exposed OAuth tokens turned an integration weakness into broader compromise. These controls tend to break down when connectors are maintained by separate teams in legacy environments because ownership, configuration drift, and token sprawl make uniform enforcement impractical.

Common Variations and Edge Cases

Tighter connector control often increases delivery friction, requiring organisations to balance integration speed against governance depth. That tradeoff is real, especially in older systems where vendors expose limited APIs, authentication is inconsistent, or the only available option is a bespoke file drop or batch job. In those environments, current guidance suggests compensating controls rather than pretending the connector can be made fully standard overnight.

One common edge case is third-party integration, where a vendor-owned connector may require access to internal systems but cannot be managed like an internal service account. Another is shadow integration work, where developers bypass the approved path because the manual connector takes too long to provision. Both cases create entitlement exceptions that are hard to track and harder to retire. NHIMG has repeatedly shown how supply-chain style OAuth abuse can expand quickly, including in the Klue OAuth Supply Chain Breach, where integration trust became the attack path.

Where teams cannot eliminate manual connectors, best practice is evolving toward strict compensating controls: per-connector ownership, documented token scope, expiration by default, mandatory logging, and periodic recertification of both the integration and the identity behind it. There is no universal standard for this yet, but the direction is clear: manual development should be treated as temporary exception handling, not a long-term operating model.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on manual data classification for AI security?
• What breaks when organisations rely on manual permission granting?
• What breaks when CIAM integrations rely on custom development?
• What breaks when organisations rely on manual access reviews for NHIs?