What breaks first is usually maintainability. Homegrown governance struggles when connectors change, policies need refinement, or new identity types appear, because the platform depends on custom code everywhere. Over time, this makes access visibility, certification, and offboarding harder to keep accurate and auditable.
Why scratch-built identity governance starts to fray
Homegrown identity governance usually looks manageable at first because the initial policy set is small and the number of systems is limited. The strain appears when the environment changes faster than the codebase. Every new connector, entitlement model, or identity type adds another exception path, and the governance logic starts to depend on custom fixes instead of a stable product model.
That is why maintainability becomes the first breaking point. When your governance layer is a collection of scripts, bespoke workflows, and point integrations, routine changes turn into engineering work. The platform is no longer absorbing complexity, it is externalising it into the code you now have to keep current.
As identity programs grow, the gap between “works today” and “remains auditable next quarter” gets wider. A governance design that cannot absorb identity and access management fundamentals tends to drift away from the operating model it is supposed to enforce.
Where the operational debt shows up first
The earliest operational failures are usually in the places that depend on consistency: access visibility, certification, and offboarding. If each source system needs custom mapping, then reporting becomes only as good as the last connector update. If each policy refinement needs code changes, then reviews slow down and edge cases accumulate. If each new identity class requires bespoke handling, then coverage becomes uneven across humans, service accounts, applications, and automation.
This is also where governance quality starts to depend on tribal knowledge. Teams remember which script handles which system, which exceptions are safe, and which workflows were patched after the last exception. That knowledge does not scale, and it is fragile when staff change or the environment is replatformed.
Governance programs that need to track many lifecycle states benefit from a design that can keep pace with change, especially for joiner, mover, and leaver processes and the recertification loops that depend on them.
Once maintenance becomes constant exception handling, the platform stops being a control and starts becoming another dependency. That is usually the moment organisations discover that the code is not the problem alone, the operating model around it is.
Why auditability degrades faster than teams expect
Homegrown governance often degrades silently. Access reviews may still run, but the data they rely on is partial or stale. Offboarding may still complete, but only for the systems that the custom workflow knows about. Certification may still produce approvals, but the underlying entitlement model may no longer match how access is actually granted.
The result is a growing gap between intended governance and provable governance. That gap matters because auditors, risk teams, and operators need evidence that the control covers the full scope of identities and permissions in play, not just the systems the custom code currently understands.
Auditability is easier to preserve when governance is mapped to a consistent entitlement and review structure, as reflected in access reviews and certification practices and the control logic behind segregation of duties.
In practice, the audit problem is rarely that the policy was never defined. It is that the implementation cannot reliably prove enforcement over time, especially after system changes, acquisitions, or new non-standard identity types.
Risk and Threat Considerations
When identity governance is coded from scratch, the risk is not just software maintenance burden. The deeper problem is control decay: every unhandled connector change, missing identity type, or delayed policy update creates a gap where access can remain visible on paper but uncontrolled in practice.
Failure mechanism: Custom governance logic becomes brittle as systems, entitlements, and identity populations change, so visibility, certification, and offboarding lose coverage faster than the code can be repaired.
Impact: Orphaned access, stale approvals, and incomplete revocation increase the chance of unauthorized access persisting beyond its intended lifetime, which weakens audit evidence and expands blast radius after compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Identity governance directly depends on account lifecycle control and review discipline. |
| Recommendation — Automate account inventory, review, and removal to keep governance current. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Scratch-built governance fails when account lifecycle and review logic cannot scale. |
| IA-5 — Authenticator Management | Governance code often breaks around credential rotation, expiry, and revocation workflows. | |
| AU-2 — Event Logging | Auditable governance needs logs that prove access changes and review outcomes. | |
| Recommendation — Centralize account lifecycle control and periodically review account validity. Manage authenticators with defined rotation, revocation, and replacement processes. Log governance actions and retain evidence for access decisions and removals. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Custom governance must enforce access rules consistently as environments change. |
| Recommendation — Define and enforce access rules through a maintained, repeatable control model. | ||
Practitioner Guidance
What to prioritise: Treat connector churn, policy churn, and identity-model churn as the true cost drivers. If a governance control depends on frequent code edits to stay accurate, it is already operating as a custom application, not a durable governance layer.
What to verify: Check whether the platform can absorb new identity types and entitlement sources without rewriting core workflows. A sound design should let you extend mappings, rules, and review scope without breaking historical evidence or creating parallel control paths.
Common mistake: Teams often optimise for the first deployment and ignore the third-year maintenance burden. The immediate implementation may succeed, but the control fails later when the organisation adds another cloud, SaaS stack, or machine identity class.
Practitioner takeaway: If governance cannot evolve without custom engineering, it will eventually trade control accuracy for delivery speed, and that is usually the point where maintainability, not policy intent, defines security quality.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org