Governance becomes harder to maintain, slower to change, and more difficult to prove during audits. Custom dependencies also create hidden ownership problems, because the organisation may not know which control outcomes rely on local engineering rather than supported product configuration.
Why custom code makes IGA harder to govern
IGA is strongest when core outcomes, such as provisioning, access changes, reviews, and revocation, are driven by repeatable product capabilities. Once those outcomes depend on custom code, governance stops being a standard operating model and becomes a bespoke engineering asset. That makes the control plane harder to understand, harder to reuse, and harder to validate consistently across applications and teams.
Custom logic also creates a hidden dependency between identity governance and local development decisions. When a control is implemented in scripts or point integrations, the organisation must treat that code as part of the control itself, not as a harmless technical detail. A good baseline for this operating model is IAM and IGA Basics, because it distinguishes governed entitlement processes from ad hoc implementation choices.
The practical consequence is that the same business rule can behave differently in different systems, especially when local teams patch exceptions into one-off workflows. Over time, that produces role drift, exception drift, and inconsistent enforcement of joiner-mover-leaver logic. If the organisation cannot explain where the rule lives, who owns it, and how it is tested, the control is already weaker than it appears.
Why change slows down and audit evidence gets brittle
Custom integrations slow change because every policy update has to be checked against code paths, connector behaviour, and downstream system dependencies. Instead of changing a supported configuration once, teams end up coordinating engineering, operations, and governance just to make a routine access rule safe. That raises maintenance cost and increases the chance that a necessary control change is delayed or implemented inconsistently.
Auditability also suffers because evidence becomes fragmented. Auditors do not just want to know that access is managed, they want to see how the control is operated, whether it is repeatable, and whether exceptions are tracked. When the logic sits in local scripts, the evidence often depends on tribal knowledge, code comments, or a developer’s explanation rather than on a clear product workflow. For that reason, the governance and audit perspective in Ultimate Guide to NHIs, Regulatory and Audit Perspectives is useful even here, because it shows how control evidence degrades when ownership and lifecycle are not explicit.
One-off integrations also make it harder to prove that reviews, approvals, and deprovisioning actually happened at the right time. A control can look complete in a dashboard while the real enforcement sits in a disconnected script or manual handoff. That gap is especially dangerous when a team assumes the platform owns the control, but the actual outcome depends on a custom service or local job.
Why ownership becomes the hidden failure mode
The biggest structural issue is often not the integration itself, but the ownership ambiguity it creates. If the business outcome depends on custom code, someone must own its lifecycle, test coverage, failure handling, and retirement. Without that ownership, the organisation may preserve a control only because nobody has noticed that it is effectively unmaintained.
That is where governance breaks down in practice. A supported IGA configuration can usually be reviewed through platform administration, change management, and standard operating procedures. A local integration may be invisible to those processes, which means the organisation can no longer confidently answer basic questions such as which controls rely on bespoke engineering, which ones are replicated across systems, and which ones will fail silently when an upstream API changes.
When those dependencies are not catalogued, the organisation also loses the ability to manage exception risk at scale. One custom connector may be tolerable. Dozens of them create a governance estate that is hard to inventory, hard to test, and hard to decommission cleanly. The result is not only technical fragility, but also accountability fragility.
Risk and Threat Considerations
Custom IGA code expands the attack and failure surface because it can preserve excessive access, bypass normal review flow, or fail open when integrations break. The more the control outcome depends on local engineering, the easier it is for stale logic, untested exceptions, or abandoned ownership to create long-lived privilege and poor auditability.
Failure mechanism: A bespoke rule, script, or connector drifts from the intended governance model, then continues operating after the business process, target system, or approval logic has changed.
Impact: Access may remain active after it should have been removed, reviews may miss the real enforcement point, and auditors may be unable to trace the control from policy to execution with confidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-1 — Access Control Policy and Procedures | Custom IGA logic needs formal control ownership and procedure discipline. |
| AC-6 — Least Privilege | Custom integrations can preserve excessive access if rules drift or fail open. | |
| AU-2 — Audit Events | Bespoke code must produce evidence that the governance action actually occurred. | |
| Recommendation — Document and govern access-control procedures for any bespoke IGA workflow. Constrain any bespoke IGA integration to least-privilege outcomes and permissions. Log custom IGA decisions and retain evidence for review and audit. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | One-off integrations are configuration items that need controlled change handling. |
| A.5.15 — Access control | The subject is about how access governance is enforced when implementation is custom. | |
| Recommendation — Treat custom IGA integrations as controlled configuration items with defined ownership. Apply access-control rules consistently across supported and bespoke IGA paths. | ||
Practitioner Guidance
What to verify: Identify every IGA outcome that depends on custom code or a one-off integration, then confirm who owns it, how it is tested, and what happens if it fails. If the answer is unclear, treat that dependency as part of the control estate, not as an implementation detail.
Decision rule: If a control outcome can be achieved through supported configuration, prefer that path over bespoke code. Reserve custom logic for genuinely exceptional cases, and require explicit lifecycle ownership, monitoring, and retirement criteria before accepting it.
Practitioner takeaway: The main danger is not that custom code exists, it is that the organisation starts relying on it without the same discipline it would demand from any other control.
Related resources from NHI Mgmt Group
- What breaks when an IAM platform depends on custom code instead of configuration?
- What breaks when multi-tenant authentication depends on large amounts of custom backend code?
- How should engineering teams design integrations that work across multiple community platforms without creating brittle one-off code paths?
- What breaks when enterprises keep modernizing identity through custom integrations and code rewrites?