Configuration uses the platform’s native settings, rules, connectors, and templates to meet business needs. Customization means writing code or building bespoke logic to add features, attributes, integrations, or access behavior. Configuration is generally easier to maintain and update, while customization can increase complexity, slow deployments, and create dependency on specialized technical support for future changes.
Configuration keeps identity governance inside the product’s control plane
Configuration is the preferred path when the identity governance platform already exposes the control you need through policy, workflows, templates, connectors, or attribute rules. It keeps you aligned to the vendor’s supported operating model, which usually means easier upgrades, clearer troubleshooting, and less risk that a routine platform change breaks a business rule. For most organisations, this is the default choice for standard access review, request, approval, and certification patterns.
Configuration is also the cleaner option when the business requirement can be expressed as a governed setting rather than an exception. If you can achieve the outcome by adjusting role models, entitlement mappings, lifecycle rules, or approval routing, you preserve the product’s built-in observability and reduce the number of places where access logic can drift. That matters because identity governance is not just about making access work, it is about keeping access decisions explainable, repeatable, and auditable over time. NHIMG’s Ultimate Guide to NHIs is a useful reference point for the lifecycle and governance side of that discipline, even when the same operating principle applies to human identities.
Where identity governance extends into infrastructure, platform, or agent workflows, the same rule still holds: prefer native controls first, then verify whether the platform already supports the access pattern through policy rather than code. That is one reason many teams map governance decisions back to a baseline control set such as NIST Cybersecurity Framework 2.0 and hardening guidance such as CIS Benchmarks when they are deciding how much should be native and how much should be bespoke.
Customization changes the product, not just the settings
Customization is what you are doing when the business need cannot be met cleanly with built-in settings, so you add code, bespoke logic, custom integrations, or nonstandard attributes and access behaviour. That may be justified for a narrow, high-value requirement, but it changes the support model. You now own more of the logic, testing burden, documentation, and breakage risk whenever the platform, an upstream system, or a downstream connector changes.
The practical difference is that configuration keeps the governance rule visible to the product, while customization moves part of the rule into your engineering estate. In identity governance, that often shows up as custom entitlement calculations, special approval paths, homegrown reconciliation logic, or integration glue that translates between systems that were never designed to share a common access model. If those artefacts are not tightly controlled, they become a hidden dependency that only a few people understand. The result is slower change, harder audits, and a greater chance that a local exception becomes a long-lived governance gap.
This is where secure-by-default thinking becomes useful even in an identity governance discussion. A custom feature may solve an edge case, but if the same outcome can be achieved by adjusting a supported workflow or rule set, the native path is usually safer and easier to operate. The identity-security trade-off is not abstract: bespoke logic tends to age poorly, and access decisions are one of the worst places to let undocumented behaviour accumulate.
When to stay native, when to go bespoke, and what to watch
Risk and Threat Considerations
Identity governance customization increases the chance of misapplied access logic, regression during upgrades, and hidden privilege paths that are difficult to review. The more bespoke the logic becomes, the more likely it is that a small code change or connector failure will affect access approval, certification, revocation, or entitlement enforcement in ways the business does not immediately see.
Failure mechanism: Custom code or logic bypasses, overrides, or fragments the platform’s standard governance model, so access decisions no longer follow one consistently tested path.
Impact: You can end up with delayed revocation, inaccurate certifications, excessive access, or broken audit evidence, especially after changes to connected systems or platform upgrades.
Practitioner Guidance
What to prioritise: Treat native configuration as the baseline and reserve customization for requirements that cannot be expressed through supported policy, workflow, or attribute mapping. If a request can be satisfied by a setting, rule, or template, prefer that route before introducing code.
What to verify: For every customization, confirm ownership, test coverage, rollback approach, and upgrade compatibility. If the team cannot explain how the logic will be maintained after the original implementer leaves, the customization is already too risky.
Practitioner takeaway: Configuration is the governance-friendly default because it keeps access decisions in supported controls; customization should be the exception, used only when the business value clearly outweighs the maintenance and audit cost.
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, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorizations | Identity governance config/custom logic both shape access permissions and approvals. |
| CM-3 — Configuration Change Control | Customization adds change-control burden and upgrade risk in identity governance. | |
| Recommendation — Prefer native policy settings that enforce least-privilege access decisions and keep authorization changes auditable. Control bespoke changes with formal review, testing, and rollback before deployment. | ||
| CIS Controls v8 | 6 — Access Control Management | Identity governance is an access control function that benefits from standardized, maintainable controls. |
| 4 — Secure Configuration of Enterprise Assets and Software | Configuration versus customization is fundamentally a secure-configuration decision. | |
| 16 — Application Software Security | Custom logic in identity governance becomes software that needs secure development and testing discipline. | |
| Recommendation — Use supported access control mechanisms before introducing custom logic. Standardise on secure default settings and minimise unsupported custom changes. Apply secure development and testing controls to every custom workflow or integration. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Identity governance changes can affect how identity proofing and assurance are operationalised. |
| AAL — Authenticator Assurance Level | Custom access behaviour can unintentionally weaken how access assurance is enforced. | |
| Recommendation — Align governance rules to the required assurance level before altering identity workflows. Verify that custom access paths preserve the intended authenticator assurance. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Identity governance customisations often touch credential-bearing workflows and lifecycle controls. |
| NHI-07 — Lifecycle and Offboarding | Governance configuration must preserve reliable provisioning, revocation, and offboarding behaviour. | |
| Recommendation — Keep credential-related logic in supported controls and minimise bespoke handling. Use supported lifecycle controls so access removal remains predictable and testable. | ||
Related resources from NHI Mgmt Group
- What is the difference between identity analytics and access policy enforcement in campus identity governance?
- What is the difference between attack surface management and NHI governance?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
