How should organisations handle homegrown IAM systems that still power core identity workflows?

Why This Matters for Security Teams

Homegrown IAM systems often stay in production because they still satisfy critical workflows, but that does not make them low risk. The practical issue is that custom identity code tends to encode business exceptions, stale assumptions, and fragile automation that no one wants to interrupt. NHI Management Group has documented how identity failures are rarely abstract; the Ultimate Guide to NHIs shows how excessive privilege, weak rotation, and poor offboarding remain common across non-human identity estates.

For core identity workflows, the question is not whether the system is elegant. The question is whether it can still enforce deprovisioning, account claim, approval evidence, and auditability under stress. That is where many homegrown platforms fail: they work until a dependency breaks, an engineer leaves, or a compliance review asks for proof the platform was never designed to produce. NIST’s SP 800-53 Rev. 5 is clear that access control, audit, and configuration management need repeatable enforcement, not tribal knowledge. In practice, many security teams discover the brittle parts of a homegrown IAM stack only after a failed offboarding, not during a planned control review.

How It Works in Practice

The safest way to manage a homegrown IAM system is to treat it as a constrained control plane with explicit risk boundaries. First, map each workflow to the control it performs: joiner-mover-leaver, account claim, role assignment, secret issuance, approval logging, and exception handling. Then separate reliable functions from custom code paths that depend on named developers, undocumented APIs, or manual database edits. The goal is to identify which parts can be monitored and which parts need replacement.

Practitioners should prioritise the workflows that are hardest to recover manually. Deprovisioning is usually the highest-value control because delays create direct exposure. Account claim is next, because weak proofing or stale ownership records let the wrong person inherit access. Audit evidence matters as well, since homegrown systems often cannot reconstruct who approved what, when, and why. That gap becomes material during incident response and compliance testing.

Use the Top 10 NHI Issues research to pressure-test whether the system is hiding long-lived secrets, excessive privilege, or incomplete revocation. For control design, current guidance suggests pairing the legacy platform with stronger external enforcement such as policy-as-code, immutable logging, and periodic access recertification rather than trusting the custom system alone. Where possible, validate event trails against NIST control expectations for auditability and least privilege, and use runtime checks to stop silent privilege drift.

• Inventory every identity workflow the system owns, including exceptions and manual overrides.
• Measure deprovisioning latency, not just whether deprovisioning exists.
• Tag custom code paths that modify access without a second system of record.
• Export logs to a durable store before legacy components are retired or rewritten.

These controls tend to break down when the homegrown platform is tightly coupled to HR, directory, or CI/CD automation because one failed integration can block both identity changes and evidence generation.

Common Variations and Edge Cases

Tighter control over a homegrown IAM system often increases operational overhead, so organisations need to balance continuity against the risk of hidden failure. Some teams keep the legacy system for read-only history while moving enforcement to a modern control layer. Others keep only the identity records and replace credential issuance first. There is no universal standard for this yet, but best practice is evolving toward strangling high-risk functions before full replacement.

One common edge case is a system that still owns account claim but no longer owns deprovisioning. That split can create a false sense of safety because the identity record looks current while access revocation still depends on custom code or manual tickets. Another issue is hybrid estates where non-human identities span on-prem directories, cloud IAM, and application-level roles. In those environments, a single homegrown workflow may be “correct” in one system and wrong everywhere else. The 2024 Non-Human Identity Security Report notes that 88.5% of organisations say non-human IAM lags human IAM, which fits the reality that legacy identity tooling often reflects past operational needs more than current security expectations.

Where the custom system cannot produce defensible evidence, treat that as a transition-risk signal, not merely a reporting inconvenience. That is usually the point at which replacement planning should accelerate.

Related resources from NHI Mgmt Group

• Should organisations let AI handle permission changes in identity workflows?
• How should organisations handle fake document risk in identity proofing workflows?
• How should IAM teams handle systems that are outside their identity governance tools?
• Why do password managers still leave organisations exposed to phishing?