What goes wrong when onboarding depends on custom code?

Why This Matters for Security Teams

When onboarding depends on custom code, the identity lifecycle stops being a governed process and becomes an application engineering problem. That shifts access decisions into brittle scripts, one-off integrations, and hidden assumptions about user type, timing, and entitlement state. In higher education, those assumptions fail quickly because students, faculty, contractors, and temporary staff do not share the same lifecycle. The result is inconsistent provisioning, delayed deprovisioning, and audit gaps that are hard to defend.

The risk is not just operational friction. Custom onboarding logic often bypasses standard controls for approval, logging, and segregation of duties, which makes it harder to prove who received access, when, and why. NHI Management Group notes that 30.9% of organisations store long-term credentials directly in code in the Ultimate Guide to NHIs, and 79% have experienced secrets leaks, with 77% causing tangible damage. Those patterns matter here because custom onboarding code frequently embeds the same secrets and workflow assumptions that later become incident response problems. For policy and governance context, the FATF Recommendations are a useful reminder that identity and access controls lose value when they cannot be evidenced end to end. In practice, many security teams encounter the failure only after access sprawl or offboarding misses have already created exposure, rather than through intentional lifecycle testing.

How It Works in Practice

Custom onboarding usually starts as a practical shortcut: one script maps source attributes into downstream systems, another handles exceptions, and a third patches edge cases for a specific department. Over time, those scripts become the real policy engine. The problem is that the policy lives in code instead of in a controllable workflow layer, so every change requires developer time, regression testing, and environment-specific validation. That is especially risky when the organisation has multiple identity populations or when external systems expect different attributes, roles, or approval paths.

A stronger pattern is to separate orchestration from policy. The onboarding workflow should call defined approval steps, then apply declarative rules for role assignment, lifecycle state, and revocation. That makes it easier to audit and to test changes without rewriting logic in several systems. It also reduces the chance that a late-stage code change silently grants access to the wrong group or leaves a disabled account active. NHI Governance guidance in the Ultimate Guide to NHIs is especially relevant here because the same lifecycle discipline applies to service accounts, API keys, and automation identities, not just people. For identity assurance and access control design, FATF Recommendations reinforce the broader principle that governance must be traceable, reviewable, and attributable.

• Define onboarding as a workflow with explicit approvals, not as embedded conditional logic in application code.
• Keep entitlements in policy files or a provisioning platform so changes are versioned and reviewable.
• Test common and exception paths separately, especially for temporary roles, transfers, and exits.
• Log every provisioning and revocation event so auditors can reconstruct the lifecycle.
• Use the same lifecycle controls for human and non-human identities where systems overlap.

These controls tend to break down when source systems are inconsistent, because custom code then becomes a patch layer for bad data instead of a governed onboarding mechanism.

Common Variations and Edge Cases

Tighter onboarding control often increases administrative overhead, requiring organisations to balance speed against consistency. That tradeoff is real in higher education, where term-based hiring, student workers, adjunct faculty, and research collaborators can change state quickly. Best practice is evolving here, but current guidance suggests avoiding bespoke code for routine lifecycle logic unless the integration is truly unique and cannot be handled by a standard connector or workflow engine.

Edge cases usually appear where policy exceptions are frequent. A research lab may need rapid access for short-term collaborators, while a finance unit may require stricter approvals and delayed activation. If each exception is hard-coded, the organisation ends up with a shadow identity model that only a few developers understand. That creates change risk, especially during staff turnover or platform migrations. The safer approach is to define exception handling as policy, not as code branches. Where automation identities are involved, the same issue multiplies because machine access often survives longer than the project that created it. The Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why onboarding and offboarding logic should be designed for repeatability, not convenience. Guidance is clear on the direction, but there is no universal standard for every institution’s exception model yet.

Related resources from NHI Mgmt Group

• Why does custom code create problems in IGA programmes?
• What is the difference between code scanning and runtime identity monitoring?
• What usually goes wrong when authorization remains embedded in application code?
• What do security teams get wrong about authentication controls and trust?