TL;DR: C1.ai finds that building identity governance in-house can cost more than three times as much as buying over five years once engineering, integration, maintenance, and infrastructure overhead are counted. The real risk is not just cost inflation but a governance model that lags human, non-human, and AI identity growth.
At a glance
What this is: This is a build-vs-buy analysis for identity governance that argues in-house IGA becomes expensive and operationally brittle once integration, maintenance, and future identity scale are included.
Why it matters: It matters because IAM and IGA teams have to decide whether they are funding a core governance capability or inheriting a long-term engineering burden that can slow coverage across human, NHI, and AI identities.
👉 Read C1.ai's build-vs-buy analysis for identity governance
Context
Identity governance is often framed as a tooling choice, but the real decision is about operating model, not just feature set. Once teams commit to building, they inherit connector development, policy maintenance, infrastructure hosting, and the ongoing work of keeping access models current across changing applications and identity types.
The article argues that a purpose-built platform can reduce the hidden burden of custom governance logic and speed up integration across managed systems. That framing is most relevant to teams that need IGA to scale beyond a small internal environment and across human, non-human, and AI identities.
Key questions
Q: How should teams decide whether to build or buy identity governance?
A: Teams should compare five-year total cost, connector effort, policy maintenance, and the business value of engineering time. Build only makes sense when governance is a true product differentiator or when the organisation can support the platform as a durable internal service. For most enterprises, the burden of ownership outweighs the flexibility of custom code.
Q: Why does in-house IGA become more expensive over time?
A: In-house IGA accumulates cost because every integration, policy exception, bug fix, and platform change requires internal engineering time. The platform also needs hosting, testing, and ongoing updates as applications and identity relationships change. Those recurring costs often outweigh the initial build effort and create a permanent drain on teams.
Q: What breaks when identity governance is coded from scratch?
A: 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.
Q: What happens to IGA programmes when AI and non-human identities grow faster than the workforce?
A: Programmes built only for workforce users tend to run out of model headroom. They may still manage access, but only after repeated redesigns, new rules, and custom workflows for service accounts, workloads, and AI-driven identities. That slows governance and increases the chance that important access paths are missed.
Technical breakdown
Why in-house IGA becomes a permanent engineering load
A homegrown identity governance platform is not a one-time software project. It requires requirements gathering, connector development, testing, bug fixes, enhancements, hosting, and continuous updates as systems change. The cost grows because every new application or policy variation creates more custom code and more maintenance dependencies. In practice, the platform becomes a standing internal product that competes with revenue-generating engineering work for people and time.
Practical implication: Treat build decisions as a long-term product commitment, not a one-off implementation.
Why governance data models matter as much as integrations
Identity governance depends on a data model that can represent users, entitlements, applications, resources, and relationships between them. Without that model, teams struggle to map access paths, identify orphaned accounts, and explain why access exists. The article’s point is that policy without structure becomes brittle, because least privilege and access review logic are only as good as the underlying identity graph. That is especially important when the estate includes nested entitlements and multiple identity types.
Practical implication: Design the data model before policy logic, or governance rules will not scale cleanly.
Why automation changes the value of buy over build
Automation in identity governance is most useful when it can handle offboarding, conditional approvals, and usage-based revocation without custom orchestration for every workflow. Building those paths internally is hard because each decision branch adds more logic to test and support. The article also extends the argument to AI-scale identity growth, saying governance must handle far more identities than traditional workforce counts. That makes repeatable automation a capacity issue, not just a convenience feature.
Practical implication: Prioritise governance automation that can absorb growth without multiplying engineering effort.
Breaches seen in the wild
- Scania insurance portal breach 2025: An attacker used an external user login, likely stolen by infostealer malware, to take insurance claim documents from a Scania portal.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Build-versus-buy is really a governance operating-model decision. The article is not just comparing price tags. It shows that the bigger question is whether identity governance should be treated as a bespoke internal platform or as a managed capability with ongoing lifecycle demands. For practitioners, the decisive issue is whether the organisation wants to own policy engineering forever.
Identity governance breaks down when teams underestimate connector and policy drift. The article’s hidden cost argument is credible because every new application, API change, and policy exception adds maintenance debt. That debt is not only financial. It increases the chance that access paths, orphaned accounts, and inactive users fall outside the governance model. Practitioners should read build plans as drift amplification mechanisms, not just software projects.
Future-proofing now includes NHI and AI identity scale. The article’s strongest forward-looking claim is that governance built for today’s workforce will not cope with a larger mix of human, non-human, and AI identities. That matters because lifecycle, entitlement, and certification processes will be stressed by volume and heterogeneity at the same time. Practitioners need to test whether any planned IGA model can handle that mix without custom re-engineering.
Purpose-built policy engines are becoming the control plane for least privilege at scale. Once access decisions span nested entitlements and multiple identity types, policy logic becomes the hard part of governance, not just the database or connectors. The practical implication is that teams should evaluate whether they are building a policy engine or merely assembling scripts around one.
Identity governance that cannot absorb change will eventually become a shadow control. If policy updates, connector maintenance, and workflow changes depend on scarce internal engineering time, the governance programme will lag the environment it is supposed to control. That is the real risk hidden inside build enthusiasm, and it is the point where audit comfort can diverge from operational reality.
From our research library:
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
- Read next: IGA Buyer's Guide
What this signals
Build-first IGA strategies create governance debt when the identity estate keeps changing. The issue is not whether custom development is possible. It is whether policy, connector, and lifecycle upkeep can keep pace with the organisation’s application churn and identity sprawl without becoming a backlog problem.
Purpose-built identity governance becomes more compelling as the mix of human, NHI, and AI identities expands. The more identity types and entitlement models a programme must govern, the more every custom workflow becomes a maintenance liability instead of a control advantage.
For practitioners
- Map total cost over five years Include engineering labour, connector maintenance, infrastructure hosting, testing, security updates, and the opportunity cost of diverting developers from core products.
- Inventory the identity and application graph first Document the applications, entitlements, nested relationships, and identity types the governance model must represent before you choose build or buy.
- Stress-test policy maintenance against change Model how often new apps, API changes, role exceptions, and certification rules will require code changes in a homegrown platform.
- Evaluate whether automation covers offboarding and revocation Check that governance workflows can remove access, handle conditional approvals, and revoke usage-based rights without custom orchestration for each case.
- Plan for non-human and AI identity growth Test whether your governance model can scale beyond workforce identities to include service accounts, workloads, and AI-driven access patterns.
Key takeaways
- The article’s core warning is that identity governance build projects accumulate hidden work across development, integration, and maintenance.
- Its forward-looking argument is that governance designed around today’s workforce will struggle as non-human and AI identities expand.
- For most teams, the decision point is less about customisation and more about whether they can sustain the operating burden of owning the control plane.
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 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | The article is fundamentally about governance operating-model choice and lifecycle burden. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on entitlement modelling and least-privilege enforcement. | |
| Recommendation — Align the IGA operating model to governance context, ownership, and lifecycle expectations before implementation. Map entitlements and authorizations before you automate access governance decisions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and access lifecycle management is central to the build-versus-buy trade-off. |
| Recommendation — Standardise account lifecycle processes so governance does not depend on bespoke code. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article explicitly discusses instant offboarding and access revocation for non-human and AI identities. |
| NHI-05 — Overprivileged NHI | Least privilege and risky access discovery are part of the article's governance model argument. | |
| Recommendation — Build or buy controls that revoke non-human access cleanly when identities or usage change. Reduce excess NHI access by enforcing policy-based entitlement checks at governance time. | ||
Key terms
- Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
- Connector Maintenance Burden: The recurring operational effort required to keep a custom application integration functioning as the target system changes. This burden includes UI changes, API updates, and permission model shifts, and it often consumes the same resources needed to expand coverage to additional applications.
- Entitlement Relationship Modelling: The process of mapping how identities connect to roles, permissions, exceptions, and downstream systems. It is more than inventory because it shows dependency and inheritance, which makes governance actions more accurate. Without relationship modelling, access reviews often miss why a permission exists or what will break if it is removed.
- Lifecycle Governance: Lifecycle governance is the set of controls that cover creation, assignment, review, rotation, and retirement of identities and credentials. For NHIs, it is the difference between a temporary automation asset and a persistent access risk. Strong lifecycle governance keeps ownership and expiry tied to actual business use.
What's in the full article
C1.ai's full blog covers the operational detail this post intentionally leaves for the source:
- Five reasons the vendor says buying beats building, including development, policy, integration, automation, and AI-scale arguments
- Examples of the connector and workflow burdens that in-house teams inherit when applications and APIs change
- The vendor’s framing of how its data model handles access paths, orphaned accounts, and nested entitlements
- The cost narrative behind the five-year total cost comparison, including the internal labour assumptions behind the build case
👉 The full C1.ai blog expands on the five reasons behind its build-versus-buy case for IGA.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org