Build vs. buy in IAM: why custom programs stall at scale

At a glance

What this is: This is SailPoint’s account of a failed attempt to build a custom IAM programme, showing how scope, integration demands, and maintenance burden can overwhelm in-house teams.

Why it matters: It matters because identity teams still have to decide whether to build, buy, or hybridise control planes for human IAM, NHI governance, and lifecycle operations without underestimating long-term operational cost.

By the numbers:

• The company needed to manage identities and access across 160+ medical facilities in 20+ states.

👉 Read SailPoint's facepalm file on why building IAM did not work

Context

IAM programmes fail when teams treat identity as a narrow point solution instead of an enterprise control plane. In this case, the organisation was trying to support 160-plus medical facilities, multiple states, and a growing number of disparate systems with an AD-based approach that no longer fit the operating model.

The build-versus-buy question is not just about software procurement. It is about whether the organisation can sustain integration, compliance, support, and lifecycle governance across humans, service accounts, and other non-human identities without creating a programme that never reaches steady state.

Key questions

Q: How should organisations decide whether to build or buy IAM capabilities?

A: Organisations should compare three things: lifecycle coverage, integration burden, and three-year operating cost. If the use case requires broad governance across many applications, access reviews, and offboarding workflows, a custom build usually becomes more expensive and slower to sustain than a mature platform.

Q: Why do custom IAM projects often stall after early design work?

A: They stall because the programme must solve many dependencies at once: directories, business applications, approvals, evidence generation, and exception paths. Early design discussions can hide that complexity, but delivery exposes it. Once the integration and governance backlog grows, progress slows and the original timeline becomes unrealistic.

Q: What do security teams get wrong about IAM total cost of ownership?

A: They often count licence costs or initial development effort but ignore support, maintenance, testing, compliance work, and the business cost of delayed access. In IAM, the cheapest path at procurement time can become the most expensive path once the system has to run every day.

Q: What should identity leaders do when a custom IAM build is already consuming time without results?

A: They should stop measuring progress by meetings completed and start measuring it by working lifecycle controls, successful integrations, and reduced business friction. If those outputs are not improving, the organisation should reassess whether the custom path still makes sense.

Technical breakdown

Why custom IAM programmes stall under integration load

A custom IAM build has to connect to directories, applications, entitlements, approval flows, and reporting layers before it can deliver meaningful governance. Each new system multiplies data model mismatches, exception handling, and test cycles. In a large healthcare environment, that work is not linear. It expands as facilities, domains, and compliance requirements multiply. The result is a programme that can consume months without producing durable control.

Practical implication: map integration count and governance dependencies before committing to a build, then compare that burden to a productised control plane.

IAM total cost of ownership is bigger than licence fees

Total cost of ownership in IAM includes engineering time, change management, operational support, audit evidence, onboarding, and ongoing remediation. Custom builds often look cheaper at day one because they hide those costs inside existing staff capacity. Once the programme starts failing or slowing access, the hidden cost becomes visible through lost productivity, duplicated effort, and delayed access delivery. That is especially true when the organisation must support many facilities or business units.

Practical implication: model three-year operating cost, not just year-one delivery cost, before approving any IAM build decision.

Lifecycle governance is the real test of make-or-buy decisions

The hard part of IAM is not authentication alone. It is provisioning, change, recertification, offboarding, and maintaining authoritative access decisions over time. Those lifecycle functions become more complex as the identity estate grows across human users, service accounts, and workload identities. A build that can demonstrate a workflow demo may still fail as a governance platform if it cannot sustain reviews, exceptions, and offboarding at scale.

Practical implication: judge any IAM option by lifecycle coverage and operating durability, not by whether it can automate a single access flow.

NHI Mgmt Group analysis

Build-versus-buy is an identity governance decision, not a software preference. The central failure in this story was not a missing feature. It was a programme decision that underestimated how much organisational context IAM must absorb before it can govern access reliably. In practice, custom IAM efforts fail when leaders treat identity as something engineering can assemble after the fact. The lesson for practitioners is to evaluate IAM as a governance operating model, not a coding exercise.

IAM customisation creates integration debt that compounds faster than teams expect. Every additional system, domain, and access pathway adds coordination overhead, testing effort, and exception handling. That is why projects stall even when the underlying team is capable. The organisation in this post was not unusual in facing that burden once its environment expanded beyond a simple directory. Practitioners should read this as a warning that scale changes the economics of identity control.

Total cost of ownership is where custom IAM programmes are most often defeated. The post shows that the first-year estimate did not capture the real cost of engineering time, operational friction, and lost productivity. That gap matters because identity programmes are judged on continuity, not just launch. Once access delays start affecting business operations, the build path stops being a technical choice and becomes a governance liability.

Lifecycle processes are the difference between a demo and a defensible identity platform. Provisioning and access approval are only the visible surface. The harder problems are recertification, offboarding, exception handling, and long-term support when the estate keeps changing. A custom build that cannot sustain those processes at enterprise scale is not a complete IAM programme. Practitioners should insist that lifecycle governance be proven before any build decision is accepted.

NHI and human IAM face the same structural lesson: control planes must survive growth. Whether the identities are employees, service accounts, or workload identities, the programme fails when governance depends on heroic manual effort. That makes the build-versus-buy decision a test of operating resilience, not technical pride. Practitioners should benchmark how a proposed approach behaves after expansion, not just at pilot size.

From our research:

• The company needed to manage identities and access across 160+ medical facilities in 20+ states, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For practitioners: Review the NHI Lifecycle Management Guide to align provisioning, rotation, and offboarding with operating reality.

What this signals

Build-versus-buy pressure is really lifecycle pressure. When identity programmes expand faster than the organisation can sustain reviews, offboarding, and entitlement governance, custom builds tend to reveal their limits first. The practical signal for practitioners is to measure whether your current IAM model can survive expansion without relying on manual intervention. For a governance baseline, compare your operating model with the NHI Lifecycle Management Guide and the NIST Cybersecurity Framework 2.0.

Integration debt becomes visible as business friction, not just technical backlog. In this case, the cost showed up in lost productivity and delayed access for clinical staff. That pattern is common when identity work is treated as a one-time project instead of an always-on control function. If your IAM programme is creating more tickets than trust, the architecture needs reassessment.

Identity programmes should be judged on resilience after scale, not pilot success. The build may look workable in a narrow environment, but once application count, compliance scope, and identity types grow, the real operating model emerges. Teams should use that inflection point to validate whether their governance design still fits human IAM, NHI governance, and workload identity at enterprise scale.

For practitioners

• Model three-year IAM operating cost before committing to build Include engineering time, support effort, compliance evidence, access reviews, and remediation work. Compare that against the cost of buying a mature platform and the business impact of delayed delivery.
• Test lifecycle coverage before approving any custom design Require proof for provisioning, recertification, offboarding, and exception handling across the identities you actually run, including service accounts and other non-human identities.
• Quantify integration burden across every source system Count directories, applications, stateful exceptions, and manual dependencies. If the build team cannot explain how each integration will be maintained after go-live, the architecture is under-scoped.
• Use business disruption as a decision criterion Track whether access delays, ticket backlogs, or staff workarounds are already affecting operations. If identity friction is hurting the business before the programme is complete, the implementation model is wrong.

Key takeaways

• Custom IAM projects often fail because identity governance is broader than engineering teams anticipate.
• The true cost of IAM includes integration, support, compliance evidence, and business disruption, not just delivery effort.
• Practitioners should judge build-versus-buy decisions by lifecycle durability and operating resilience at scale.

Key terms

• Identity Governance: The set of processes used to decide who or what should have access, approve it, review it, and remove it when no longer needed. In practice, it is the control layer that keeps identity permissions aligned with business change, audit expectations, and operational reality.
• Total Cost of Ownership: The full cost of running an identity capability over time, including build effort, support, maintenance, testing, compliance, and business disruption. It is the measure that usually exposes whether a custom IAM approach can survive beyond the pilot phase.
• Lifecycle Management: The ongoing governance of identities from creation through change, review, and removal. For IAM, the term covers more than onboarding. It includes recertification, offboarding, and exception handling, which determine whether access remains defensible as the environment grows.
• Integration Debt: The operational burden created when a system must connect to many applications, directories, and workflows but lacks a durable way to maintain those connections. In identity programmes, integration debt often shows up as stalled delivery, manual workarounds, and fragile governance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by SailPoint: Blog Facepalm Files, why buy when we can build, and why it failed. Read the original.