Build vs buy for IGA: what practitioners should weigh

At a glance

What this is: This is a build-versus-buy analysis arguing that homegrown identity governance becomes expensive and hard to sustain as identity sprawl grows.

Why it matters: It matters because IAM teams must decide whether to spend engineering capacity on governance plumbing or on controls that reduce risk across NHI, autonomous, and human identities.

👉 Read ConductorOne's analysis of build versus buy for identity governance

Context

Identity governance is the discipline that decides who or what should have access, under what policy, and for how long. In practice, the build-versus-buy question is less about software preference and more about whether security teams want to own a permanently expanding control plane for access, lifecycle, and review.

The article frames that trade-off around the rising complexity of enterprise identities, including human users, service accounts, and AI-enabled actors. That makes the decision relevant to NHI governance as much as classic IAM, because the same policy, visibility, and offboarding problems reappear every time the identity model expands.

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 custom identity governance break down as identity sprawl grows?

A: Custom IGA breaks down because every new application, entitlement pattern, and identity type adds more schema, policy, and integration work. As the environment expands, review cycles slow down and exceptions multiply. The result is a control plane that becomes harder to maintain than the risk it is meant to reduce.

Q: What should security teams evaluate in an IGA platform before adoption?

A: They should test whether the platform can model relationships across identities, resources, and entitlements, and whether it can enforce policy across the systems that matter most. Connector depth, offboarding speed, and policy flexibility matter more than feature lists. If the platform cannot govern real access paths, it will not reduce real risk.

Q: How does identity governance change when AI identities enter the mix?

A: AI identities force governance teams to manage more subjects, more access paths, and more change than human-only programmes were designed for. That means data models, approvals, and automation have to scale beyond workforce assumptions. Organisations should plan for identity diversity now, because AI growth will expose governance designs that were built for a smaller world.

Technical breakdown

Why custom IGA platforms become expensive to operate

A homegrown identity governance platform is not a one-time engineering project. It needs connector development, schema maintenance, policy logic, testing, infrastructure, bug fixes, and continuous adaptation as applications change. That creates a standing operational burden that competes with product engineering and security work. The hidden cost is not just code creation, but long-term ownership of every integration and exception path. Practical implication: if governance is not a core software product capability, teams should treat build plans as an enduring operating model, not a finite project.

Practical implication: treat homegrown governance as a permanent operating model, not a finite build project.

Purpose-built policy models for identity governance and least privilege

Identity governance depends on a data model that can represent users, applications, resources, entitlements, and nested relationships without flattening context. A purpose-built policy engine uses that model to express least privilege, orphan detection, inactive account handling, and approval logic without hard-coding every workflow. The architecture matters because policy becomes unmanageable when every business rule is embedded in custom code. Practical implication: architecture decisions should favor policy abstraction over bespoke logic wherever access decisions must scale across many identity types.

Practical implication: prefer policy abstraction over bespoke access logic when governance must scale.

Automation and connector coverage as governance multipliers

Governance speed depends on how many systems you can connect and how consistently you can automate actions like offboarding, conditional approvals, and access revocation. Pre-built connectors reduce the cost of each new integration, while workflow automation shortens the time between detection and enforcement. In IGA, this is a structural issue, not just an efficiency feature: if a platform cannot reach the managed system quickly, the control exists only on paper. Practical implication: evaluate whether your governance stack can actually execute policy across your real application estate.

Practical implication: validate whether governance controls can execute across your actual application estate.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Build-versus-buy in IGA is really a control ownership decision, not a procurement preference. Once an organisation builds its own governance layer, it inherits the full burden of connectors, policy maintenance, exception handling, and lifecycle upkeep. That burden grows as identity types multiply across humans, service accounts, and AI-enabled systems. The implication is that governance maturity is constrained by the organisation’s appetite to own a long-lived control surface.

Purpose-built identity data models matter because access is relational, not flat. The article’s core point is that visibility depends on mapping users, applications, resources, and entitlements in a structure that can answer who has access to what and why. That is the same governance problem that appears in NHI programmes when service accounts and tokens are scattered across systems. Practitioners should recognise that weak data modelling turns least privilege into an approximation.

Future-ready IGA now has to account for the AI identity explosion. The article argues that agentic AI will expand identity counts beyond traditional workforce scale, which means static governance assumptions will age quickly. That aligns with the broader shift from human-centred access administration to programmes that must govern machine and autonomous actors alongside people. The practical conclusion is that identity architecture must be selected for scale and identity diversity, not just today’s user base.

Continuous integration coverage is now a governance requirement, not a convenience feature. If every new app or API requires custom engineering, access governance becomes slow enough that controls lag behind the business. That is especially problematic for NHI environments where service accounts, APIs, and cloud services change faster than manual review cycles. The implication is that teams need governance reach, not just governance intent.

Identity governance debt: building access controls in-house creates a long-lived backlog of connector, policy, and maintenance obligations that compounds over time. That debt is visible when teams spend more effort keeping the control plane alive than using it to reduce risk. Practitioners should view unresolved governance customisation as an accumulating operational liability.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• The lifecycle lens in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs helps teams connect governance design to offboarding and rotation.

What this signals

Identity governance is moving from a project mindset to a control-plane mindset. The build-or-buy choice increasingly depends on whether the organisation can sustain policy logic, integrations, and lifecycle operations as a permanent capability. Teams that still treat governance as a one-off implementation will struggle to keep pace with NHI growth, especially when service accounts and automation multiply across business units.

NHI programmes should connect governance design to the exposure created by unmanaged secrets. Our research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which means access control and secret hygiene fail together. A useful next step is to align governance architecture with the practical guidance in the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

Identity model expansion will keep putting pressure on static governance designs. As organisations absorb more machine identities and AI-driven access paths, they will need control models that can handle variation without custom rebuilds. That is why architecture decisions made now will determine whether future governance is manageable or simply accumulated technical debt.

For practitioners

• Quantify the true cost of ownership Model engineering time, infrastructure, connector upkeep, testing, and ongoing change management over at least five years. Include opportunity cost for the security and platform teams that would otherwise deliver core business work.
• Inventory identity types before choosing an IGA model Map where human accounts, service accounts, tokens, and AI-driven identities already exist, then test whether the proposed governance approach can represent all of them without special-case code. Use the inventory to expose gaps in the access model.
• Test connector depth against real systems Validate whether the platform can govern your highest-risk applications, cloud services, and on-prem systems without custom engineering for every change. Prioritise systems where access revocation and entitlement visibility must work immediately.
• Measure automation against containment speed Check whether offboarding, access revocation, and conditional approvals happen fast enough to change risk exposure, not just satisfy a workflow checkbox. If the process still needs manual follow-up, the control is too slow for the environment.

Key takeaways

• Homegrown IGA becomes a standing operational commitment, not a one-time engineering win.
• The main risk is not just cost, but governance drift as identity types and integrations expand.
• Teams should choose the control model that can keep pace with real access paths, not just current organisational structure.

Key terms

• Identity governance: Identity governance is the control discipline that defines who or what should have access, who approves it, and when it should be removed. In practice it combines policy, lifecycle, review, and evidence so access remains explainable across human, non-human, and AI-driven identities.
• Connector: A connector is the integration layer that lets an identity governance platform read or act on a target system. Its value is not just connectivity, but the ability to keep entitlement data, approvals, and revocation actions accurate as the system changes over time.
• Policy engine: A policy engine is the decision layer that applies rules to access requests, reviews, and revocation actions. In identity governance, it should express least privilege and lifecycle logic without forcing teams to encode every exception directly into application code.
• Identity governance debt: Identity governance debt is the long-term operational burden created when access controls are built as custom code instead of a maintainable platform. The debt shows up as integration backlog, brittle policy logic, and slow response when new identity types or systems appear.

Deepen your knowledge

Identity governance build-versus-buy decisions and lifecycle design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are shaping governance across service accounts, tokens, and AI-driven identities, it is worth exploring.

This post draws on content published by ConductorOne: Build vs. Buy for IGA: Why C1 Wins Every Time. Read the original.