They treat customization as proof that the platform fits the business, when it can actually mean the business process was never challenged. Excess customization often locks in legacy behaviour and makes the identity environment harder to govern, audit, and improve over time.
When customization is solving a process problem instead of a platform problem
Heavy customization often gets treated as evidence that the identity product is flexible and therefore “fit for purpose.” In practice, it can be a warning sign that the business process, approval model, or role design was never challenged. The result is usually a system that mirrors old exceptions, not a cleaner access model.
That matters because identity projects are supposed to reduce ambiguity, not preserve it. If every exception becomes code, configuration, or a bespoke workflow, the platform may still work technically, but governance becomes harder and the real operating model stays hidden in special cases.
Customisation can be justified when it enforces a genuine control requirement or a non-negotiable regulatory constraint. It is a problem when it is mainly used to avoid standardising access requests, approvals, entitlements, or lifecycle steps that should have been simplified before implementation.
Why excessive tailoring makes identity harder to govern over time
Once a project accumulates one-off rules, the identity estate becomes more expensive to understand and harder to change safely. New joiners, movers, and leavers inherit old logic, and teams lose the ability to tell whether access is granted because it is necessary or because the workflow has always done it that way.
Customisation also creates invisible technical debt. Each special case increases the surface area for testing, documentation, audit evidence, and future upgrades. The platform may still be secure on day one, but maintainability and control assurance degrade as the exception set grows.
That is why mature identity programmes treat standardisation as part of security design. A well-governed model should expose unnecessary complexity early, then force a decision about whether the business process should change or whether the exception truly belongs in the target state.
Projects that want a broader identity operating model often benefit from a Identity Security Programme Guide, because programme scope and governance should come before implementation shortcuts. For lifecycle control, the NHI Lifecycle Management Guide is useful where custom handling has created provisioning, rotation, or offboarding drift. If the project is already carrying too many exceptions, the broader Identity Security Posture Management (ISPM) Guide helps teams measure whether they are governing the environment or merely preserving it.
How to tell whether customization is justified or just inherited complexity
A useful test is whether the custom behaviour changes the security outcome or only preserves a legacy convenience. If the answer is convenience, local preference, or “that is how the downstream team works,” the customization is usually a candidate for removal, redesign, or escalation.
Another test is whether the exception can be expressed as a policy decision rather than a code path. If the business rule can be standardised, documented, and audited in a repeatable way, it is usually better to do that than to embed it deep in the identity stack.
When teams do need a flexible reference point for standards and controls, the Ultimate Guide to NHIs, Standards section is a useful benchmark for mapping identity controls to established security expectations. For auditability and control evidence, the Ultimate Guide to NHIs, Regulatory and Audit Perspectives reinforces why uncontrolled exceptions become a governance issue, not just an implementation style choice.
Where identity projects have already become hard to rationalise, the Identity and NHI Security Business Case Guide helps teams reframe the discussion around cost, risk, and operational friction rather than feature count. That is usually the right lens when customization is being used to avoid process change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access control | Custom identity tailoring affects access governance and exception handling. |
| Recommendation — Standardise access rules and minimise bespoke exceptions. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity management, authentication and access control | Identity customisation changes how access is granted and governed. |
| Recommendation — Align custom workflows to consistent identity and access controls. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Excess customization creates configuration drift and change risk. |
| AU-2 — Event Logging | Custom identity logic must remain auditable to support governance. | |
| Recommendation — Establish and enforce a controlled configuration baseline. Log custom identity decisions and retain review evidence. | ||
| CIS Controls v8 | CIS-5 — Account Management | Identity customisation often preserves legacy account and access patterns. |
| Recommendation — Use standard account lifecycle controls instead of bespoke exceptions. | ||
Practitioner Guidance
What to prioritise: Separate mandatory exceptions from convenience-driven tailoring. The first category should be small, documented, and owned; the second should trigger process redesign, not more configuration.
What to verify: For every custom rule, confirm whether it exists to meet a security, legal, or operational requirement, or whether it merely reproduces an old approval habit. If nobody can explain the control objective, the customization is probably a design smell.
Common mistake: Treating “it was hard to configure” as the same thing as “the business needs this.” In identity projects, friction often signals an opportunity to simplify the process, not a reason to encode the complexity permanently.
What good looks like: Most access paths should follow standard patterns, with a small and visible exception set that is reviewed and measured. The platform should describe the business, not freeze it.
Practitioner takeaway: The right question is not how much the identity product can be bent, but how much legacy behaviour the organisation is willing to carry forward in production.
Related resources from NHI Mgmt Group
- What do teams get wrong about perimeter security in identity-heavy environments?
- What do security teams get wrong about cyber resilience in identity-heavy environments?
- What do security teams get wrong about workload identity in cloud and CI/CD environments?
- What do security teams get wrong about MFA in identity attacks?