Why does custom code create problems in IGA programmes?

Why This Matters for Security Teams

In IGA programmes, custom code is not just an implementation choice. It becomes a second policy surface that must be tested, repaired, and understood every time the target system, schema, or entitlement model changes. That is where governance drifts from the intended control model. Security teams trying to reduce risk should prefer repeatable integration patterns that align with NIST Cybersecurity Framework 2.0 and the identity lifecycle discipline described in Ultimate Guide to NHIs.

Custom logic also weakens auditability. Control evidence gets buried inside application-specific scripts, brittle transforms, and one-off exceptions that few people can safely change. In practice, that makes it harder to prove who approved access, how access was revoked, and whether policy actually executed as designed. NHIMG research shows that 30.9% of organisations store long-term credentials directly in code, which is a strong indicator that code-based integration often spreads beyond convenience and into risk.

That matters because IGA is supposed to standardise control, not create a hidden dependency on a developer who remembers how a connector was built three years ago. In practice, many security teams encounter broken access reviews only after the first upgrade or schema shift has already disrupted enforcement.

How It Works in Practice

Custom code creates problems because every exception becomes a maintenance obligation. A scripted connector may work for one SaaS app, one HR feed, or one directory schema, but it usually assumes field names, timing, and entitlement logic that will not stay stable. When any of those inputs change, the integration fails silently or partially, which is worse than a visible outage because access decisions can continue on stale data.

Configuration-based integration reduces this fragility by keeping the control logic inside supported product capabilities rather than embedded in bespoke code. That usually means using documented APIs, event hooks, or standard connectors, with policy expressed through configuration and workflows instead of custom branching logic. The operational goal is not zero flexibility, but fewer unique paths that need bespoke testing.

• Map source systems to standard identity attributes first, then use transformation only where it is unavoidable.
• Keep provisioning, deprovisioning, and certification logic declarative so policy changes do not require code edits.
• Use change control and regression testing for any custom connector, especially where entitlements affect privileged access.
• Separate business exceptions from technical exceptions so auditors can see why an override exists.

For NHI-heavy environments, the same lesson applies to service accounts and machine identities. NHIMG’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which illustrates how easily operational drift accumulates when controls depend on fragile implementation details. The control model should be simple enough that a rotation, revocation, or approval rule can survive platform change. These controls tend to break down when teams use code to compensate for missing product features across multiple disconnected systems, because each workaround creates another point of failure.

Common Variations and Edge Cases

Tighter standardisation often increases implementation effort at the start, requiring organisations to balance short-term project speed against long-term control stability. That tradeoff is real, especially when a legacy IGA platform must integrate with older databases, mainframes, or custom business apps that do not expose clean APIs. In those cases, some custom code may be unavoidable, but best practice is evolving toward limiting it to thin adapters rather than placing policy decisions in code.

There is no universal standard for this yet, but current guidance suggests treating custom code as an exception register item with explicit ownership, test coverage, and retirement criteria. That is especially important where access decisions are tied to joiner-mover-leaver workflows, because a broken connector can delay revocation as easily as it can delay provisioning. The broader governance expectation is to keep policy in configured rules, not in opaque scripts.

Another edge case is vendor lock-in. Some platforms advertise flexibility but actually require custom development for routine identity events. Security teams should challenge that pattern early and compare it with standards-led approaches from NIST Cybersecurity Framework 2.0. Where integration code cannot be eliminated, the minimum safe posture is strong documentation, version control, peer review, and a plan to remove the custom path when the platform matures.

Related resources from NHI Mgmt Group

• Why do SaaS apps create governance problems for IAM and IGA programmes?
• Why do AI agents create ownership problems for IAM and IGA programmes?
• Why do AI agents create governance problems for traditional IGA programmes?
• Why do secrets create disproportionate risk in NHI environments?