How can security teams tell whether an IAM platform is too dependent on custom work?

What signals that the platform is compensating with custom work?

The clearest signal is not that customisation exists, but that routine identity operations only work when engineers keep patching gaps. If onboarding, offboarding, access changes, policy enforcement, or environment transitions require scripts, manual exceptions, or separate tools every time, the platform is acting like a control surface with missing primitives rather than a system with native lifecycle governance.

That distinction matters because a healthy IAM platform absorbs common transitions into the product model, while a fragile one exports complexity into code and operations. Once custom work becomes the default way to make basic flows happen, the organisation inherits hidden dependencies, fragile handoffs, and behaviour that is difficult to audit or repeat.

One practical way to test this is to ask whether the same workaround appears in multiple business processes. Repeated requests for bolt-on automation often mean the platform cannot express role changes, approvals, revocation, or segmentation cleanly enough for normal use. The IAM and Identity Provider Buyer’s Guide is useful here because vendor selection should be judged against those day-to-day lifecycle requirements, not just against login features.

Where does custom work become an architectural smell?

Custom work becomes a smell when it bridges a gap in core identity logic instead of integrating a special edge case. A single exception for a legacy system is manageable; a growing library of scripts for approvals, provisioning, entitlement cleanup, or policy translation usually means the platform is not representing the enterprise model directly.

That often shows up in three places: lifecycle events, policy expression, and control-plane visibility. If teams must inspect scripts to understand who gets access, or if policy intent lives outside the platform in someone’s code repository, then the authoritative record has shifted away from the IAM system. At that point, troubleshooting and governance both depend on tribal knowledge.

For a broader lifecycle lens, NHI Lifecycle Management Guide and Lifecycle Processes for Managing NHIs show the kind of native lifecycle handling mature identity systems should support, including provisioning, rotation, and offboarding as first-class operations.

When that lifecycle is not native, teams often compensate with one-off transformations, connector logic, or approval middleware. The result may work, but it is harder to test, harder to recertify, and much easier to break during replatforming or M&A integration.

What should security teams measure before they trust the platform?

Measure how often identity flows require code, how many production exceptions exist, and how much of the access model is represented outside the platform. The strongest indicator of dependency is not total automation, but the proportion of ordinary identity events that still need engineering intervention to complete correctly.

Also check whether custom work is compensating for missing governance features. If entitlement reviews, deprovisioning, environment separation, or privileged access decisions are implemented in scripts rather than policy objects, the platform may be creating an illusion of control while actually externalising risk into bespoke logic.

That is where cloud and entitlement discipline can be instructive. Cloud PAM and CIEM Guide helps distinguish effective permissions and rightsizing from nominal permissions, which is the same test security teams should apply when identity workflows are being built around custom glue.

CSA Cloud Controls Matrix is also relevant because it gives teams a control-oriented way to ask whether identity, auditability, and governance are being handled by the platform or by adjacent manual processes.

Risk and Threat Considerations

Heavy dependence on custom identity work increases exposure because the organisation loses standardisation, traceability, and repeatability at the exact layer that decides access. Small defects in scripts or workarounds can produce overprovisioning, delayed revocation, or inconsistent policy enforcement, and those failures tend to spread quietly across many accounts.

Failure mechanism: When core lifecycle and policy decisions are implemented outside the IAM platform, they are harder to review, harder to monitor, and easier to bypass than native controls. That creates hidden failure paths where a change request, connector update, or emergency fix can unintentionally widen access or leave stale permissions behind.

Impact: The practical impact is higher privilege exposure, slower offboarding, weaker audit evidence, and a larger blast radius if the custom logic is broken or abused. Over time, the identity program becomes dependent on a small number of people who understand the scripts instead of on controls that the organisation can operate consistently.

Practitioner Guidance

What to verify: Test whether common identity events, such as joiner, mover, leaver changes, entitlement updates, and privileged access requests, can be expressed natively without code. If the answer depends on an engineer remembering a workaround, the platform is already carrying hidden operational debt.

What to prioritise: Focus first on the flows that create the most recurring custom effort, not the most visible integrations. The most important cases are usually the ones that look mundane but happen at scale, because those are the ones that become brittle when the platform is upgraded or reconfigured.

Practitioner takeaway: A customisation here and there is normal, but a platform that needs custom work for everyday identity decisions is no longer governing identity complexity, it is exporting it into code and exceptions.

Related resources from NHI Mgmt Group

• How can security teams tell whether their recovery plan is too dependent on one platform?
• How can security teams tell whether their remote access model is still too dependent on perimeter trust?
• How can security teams tell whether SOC automation is too tightly bound to one platform?
• How can security teams tell whether an IAM platform is strong on governance or just login features?