Custom code is organisation-specific software written to bridge gaps between an IGA platform and the systems it must manage. It can solve integration problems, but it also creates maintenance burden, upgrade risk, and security review overhead. The more custom code a governance stack depends on, the harder it becomes to scale safely.
Expanded Definition
Custom code in identity governance is the organisation-specific logic used to connect an IGA platform to applications, directories, cloud services, and homegrown systems that the platform does not support natively. It is usually written to translate data models, automate approvals, enrich entitlements, or enforce local business rules.
The term is narrower than general integration work because it refers to bespoke code embedded in or adjacent to governance workflows rather than a standard connector or vendor-supported extension. In practice, custom code often becomes a hidden control surface: it can carry policy decisions, data transformations, and exception handling that are not obvious to auditors or administrators. Usage varies across vendors, and the exact boundary between sanctioned configuration, scripting, and true custom code is still evolving.
A useful boundary to keep in mind is that custom code solves a gap only for as long as the underlying platform and target system stay stable. Once either side changes, the code becomes part of the maintenance and assurance burden.
Examples and Use Cases
Custom code appears when organisations need identity workflows to work across imperfectly aligned systems. It is often practical, but every extension adds a dependency that must be tested and understood.
- Mapping application-specific attribute names into an IGA provisioning workflow so entitlements can be created without manual re-entry.
- Writing a script to reconcile local role structures with enterprise RBAC models when a legacy application has no supported connector.
- Adding approval logic for unusual access requests where the vendor workflow cannot express the organisation's policy.
- Transforming account status data from an HR or directory source before the governance platform can act on it.
- Handling exceptions for APIs, service accounts, or machine credentials where standard onboarding and offboarding logic is incomplete. The OWASP Non-Human Identity Top 10 is useful context when those exceptions involve machine identities and secrets.
One tradeoff is that custom code can reduce short-term integration friction while increasing long-term coupling. That is especially true when the code embeds business rules that only a few people understand.
Security Implications
Custom code expands the attack and failure surface of an identity governance stack because it can process sensitive identity data, make access decisions, and move credentials or tokens between systems. When it is poorly reviewed, outdated, or overprivileged, it can introduce logic flaws that create unintended access, broken approvals, or silent provisioning failures.
In operational terms, the most common failure mode is drift: the code no longer matches the platform version, the target application API, or the governance policy it was meant to enforce. That can produce orphaned accounts, incomplete revocation, stale entitlements, or duplicate records. It can also obscure auditability because the effective control is no longer visible in the vendor product alone.
NHI Mgmt Group research shows that 30.9% of organisations store long-term credentials directly in code, which is directly relevant here because bespoke integration logic often becomes the place where secrets are handled, cached, or embedded. When custom code touches those values, mistakes can turn a governance convenience into a credential exposure path.
Domain and Governance Relevance
Custom code matters in NHI governance because many non-human identities are managed through integrations rather than through clean, native platform support. Service accounts, API keys, workload identities, and automation tokens often sit behind bespoke workflows that must create, update, rotate, and revoke access across multiple systems.
That changes governance in a practical way: the organisation is no longer only managing identities, it is also managing the reliability of the code that governs them. Ownership becomes important, because someone must maintain the logic when systems change, validate that revocation still works, and ensure secrets are not trapped in scripts or integration layers. The bigger the dependence on custom code, the harder it becomes to prove that identity controls are consistent, complete, and timely.
For NHI programs, the central question is not whether custom code is allowed, but whether it is controlled well enough to preserve lifecycle assurance, least privilege, and offboarding integrity across machine identities.
Risk and Threat Considerations
Custom code introduces material risk because it often sits on the path between governance policy and enforced access. If the code fails, is bypassed, or contains a logic flaw, an identity control can appear to exist while actually leaving standing access, stale entitlements, or unrevoked machine credentials in place.
Failure mechanism: Bespoke integration logic is prone to version drift, exception handling errors, weak secret handling, and overbroad execution privileges. Attackers and insiders can benefit when these flaws expose tokens, weaken provisioning checks, or preserve access after supposed offboarding.
Impact: The likely consequences are unauthorised access, incomplete revocation, broken audit evidence, and a wider blast radius across the systems that depend on the custom integration.
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 and MITRE ATT&CK 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Custom code often stores or handles machine credentials and API keys. |
| Recommendation — Remove secrets from custom integration code and manage them through controlled secret storage. | ||
| CIS Controls v8 | CIS 16 — Application Software Security | Bespoke identity code needs review, testing, and secure change control. |
| CIS 12 — Network Infrastructure Management | Custom connectors depend on stable integration paths and controlled system trust boundaries. | |
| Recommendation — Review custom identity code for defects, insecure handling, and unsafe logic before release. Restrict and document the integration paths that custom governance code depends on. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Custom code can directly enforce or weaken access decisions in governance workflows. |
| Recommendation — Validate that custom workflow logic preserves least-privilege access decisions. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Identity custom code can expose or mishandle embedded secrets and tokens. |
| Recommendation — Hunt for embedded credentials in custom scripts and replace them with managed secrets. | ||
Practitioner Guidance
Common misunderstanding: Teams often treat custom code as a temporary bridge, then leave it in place for years as the integration spine of the governance program. That creates a hidden control dependency that deserves the same ownership and review discipline as any other access-enforcing component.
Governance implication: Assign explicit accountability for each custom integration, including code maintenance, change review, and retirement criteria. If the logic is essential to identity lifecycle control, it should be tracked as part of the control environment rather than as an informal workaround.
Practitioner takeaway: The main question is not whether custom code works today, but whether it can still be trusted after the next platform change, policy update, or identity lifecycle event.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
