Identity teams should treat customisation as a last resort, not a design goal. The safer path is to use configuration, standard workflows, and native capabilities wherever possible, because code changes create upgrade risk, testing overhead, and support ambiguity. A sustainable IAM programme keeps the product closer to its supported state, which improves maintainability, predictability, and long-term security.
Why Customisation Creates Long-Term Risk in IAM Programmes
Customisation requests often sound minor, but in IAM they usually become permanent exceptions that are expensive to test, hard to document, and difficult to unwind. Every code path added to satisfy a local workflow can widen the gap between the deployed system and the vendor-supported product. That matters because identity platforms sit on the enforcement path for access, so small deviations can affect provisioning, approvals, auditability, and incident response. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges and 71% are not rotated on time, showing how quickly unmanaged exceptions become security debt.
The practical problem is not customisation itself, but the habit of using it to solve design issues that should have been handled through configuration, standard workflows, or policy. Once a custom approval rule, connector, or transformation is embedded, future upgrades need regression testing against that exception. In practice, many security teams discover the true cost only after an upgrade stalls or an audit questions why one business unit operates on a different control path than everyone else.
How to Approve Requests Without Creating a Fragile IAM Stack
Identity teams should evaluate each request against three questions: can the need be met through native configuration, does it represent a repeatable enterprise pattern, and will the change still make sense after the next product upgrade? That discipline keeps the platform close to its supported state and makes exceptions visible instead of accidental. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces controlled change, least privilege, and traceability rather than one-off implementation drift.
- Prefer configuration over code whenever the product already supports the requested outcome.
- Use reusable policy patterns for approvals, access reviews, and role assignments instead of building bespoke logic per application.
- Document every exception with an owner, expiry date, and review trigger.
- Test custom work against patching and upgrade scenarios, not just against the immediate business case.
- Track whether a request is solving a process problem, a data model problem, or a genuine product gap.
For non-human identities, the same discipline is even more important because secrets, connectors, and machine access paths tend to outlive the original use case. The 2024 Non-Human Identity Security Report found that 88.5% of organisations say their NHI practices lag behind or only match human IAM maturity, which is a warning sign that custom work is often being added before the underlying model is stable. These controls tend to break down when customisations are tied to business-critical workflows that no one has formally productised, because removal then feels operationally impossible.
When a Custom Request Is Justified, and How to Keep It Contained
Tighter control over customisation often increases delivery time and stakeholder friction, so organisations have to balance standardisation against genuine business constraints. Some requests are valid: a regulatory requirement, a documented integration gap, or a platform limitation that cannot be met any other way. The key is to treat those cases as exceptions with expiry, not as a new baseline. Where guidance is still evolving, current practice suggests that identity teams should define a formal exception path with architectural review, security sign-off, and a retirement plan from day one.
Good exception management means the team can answer three things quickly: who owns the custom logic, what breaks if it is removed, and when it will be revisited. That discipline also supports audit conversations, because it shows the organisation is not confusing temporary accommodation with permanent design. For deeper context on how identity failure accumulates through exceptions and weak lifecycle control, the Top 10 NHI Issues page is a useful companion. The approach breaks down in heavily bespoke environments where the IAM platform is being used as an application integration layer, because every workflow then looks like a special case and technical debt becomes the default operating model.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-5 | Customisations need governance, change control, and documented ownership. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Long-lived exceptions often create unmanaged NHI secrets and access paths. |
| NIST SP 800-63 | IAL2 | Identity assurance matters when custom workflows alter provisioning and approvals. |
| NIST Zero Trust (SP 800-207) | PA-1 | Zero trust favours policy decisions over ad hoc, code-driven access exceptions. |
| NIST AI RMF | AI governance principles apply when automation is used in IAM decision paths. |
Minimise custom NHI logic and enforce rotation, ownership, and removal dates for exceptions.
Related resources from NHI Mgmt Group
- How do infrastructure teams reduce identity technical debt without creating new risk?
- How should IAM teams handle project plans when a better identity architecture emerges midstream?
- How should software teams launch enterprise features without creating identity debt?
- How should teams manage access requests through the helpdesk without creating identity risk?
