TL;DR
- Below maturity level 2 the answer is neither. A platform hands an unprepared organisation a well-organised list of problems it cannot act on, at six-figure annual cost.
- Worth buying: cross-platform discovery, ownership attribution, and remediation workflow. All three are expensive to build and dull to maintain.
- Rarely worth buying: policy definition, the inventory system of record, and anything your cloud provider already does.
- Compare against the honest build cost, which includes maintenance, on-call and integration drift, not just initial engineering.
- A POC that runs on vendor data decides nothing. Run it on your estate and record two numbers.
Ask the maturity question first
Build versus buy assumes the organisation is ready to operate either. Score yourself against the maturity model before anything else.
Below level 2, meaning no maintained inventory and no ownership model, the correct answer is neither. A platform will discover thousands of identities you cannot attribute, cannot prioritise and cannot remediate, and the programme stalls while the licence renews. The work that unblocks it is organisational: enumerate by issuer, attribute owners, and set a credential lifetime policy. See the discovery methodology.
This is not a delay tactic. Organisations that spend a quarter on inventory and ownership before procuring consistently get more from the platform and negotiate better, because they know their real identity count before pricing is set.
Three capabilities worth buying
- Cross-platform discovery. Connectors to cloud IAM, SaaS admin APIs, CI/CD, directories and secret stores, each maintained against an API that changes without notice. Building this is achievable. Maintaining twenty connectors is a permanent staffing commitment that produces no differentiation.
- Ownership attribution. Inferring an accountable human from commit history, deployment metadata and call graphs, with a confidence model when signals conflict. This is the hardest problem in the category and the one where vendor investment is most visible.
- Remediation workflow. Ticketing, approvals, staged revocation and rollback. Straightforward to build badly and time-consuming to build well, and it is where an internal tool usually stalls at read-only.
What is not worth buying
- Policy definition. Your credential lifetimes, review cadence and exception rules encode your risk appetite. A vendor default is a starting point and not a decision. See the policy template.
- The system of record. If your identity inventory lives only in a vendor platform, your audit history is hostage to a renewal. Keep the authoritative record somewhere you control and let the platform feed it.
- What your cloud provider already does. Access analysers, key age reporting and unused permission findings are included in what you pay for. Teams routinely buy a platform to surface findings their cloud console already produces.
- Agent governance, for now. Vendor agent capability is immature and the standards are unratified. Buying discovery and posture today is reasonable; buying an agent governance model locks you to one vendor's guess. See agent identity standards.
Running the numbers honestly
Most build-versus-buy models understate build cost by counting initial engineering only. A defensible comparison includes:
| Cost | Build | Buy |
|---|---|---|
| Initial | Engineering to first useful inventory. Usually underestimated by a factor of two because connectors are individually easy and collectively slow. | Licence, plus integration effort that is rarely zero |
| Ongoing | Connector maintenance against changing APIs, on-call, and the drift that appears when the original author moves team | Renewal, plus true-up risk if priced per identity |
| Opportunity | The platform work those engineers are not doing | Lock-in, and the audit history question on exit |
| Risk | Single-maintainer risk. Internal NHI tools are frequently one person deep. | Vendor viability. The category consolidated in 2026 and independence is no longer a given. |
One number decides most cases: how many platforms you need to discover across. Under about four, building is usually defensible. Above eight, connector maintenance dominates and buying wins on cost alone.
Designing a POC that produces a decision
A POC on vendor-prepared data tells you the product demos well. Four rules make it decisive:
- Run on your estate, including at least one system you consider messy. The clean environment is not the test.
- Record two numbers. Recall against identities you already knew about, and net new. Net new is the product.
- Test ownership attribution on leavers. Sample identities whose creator has left. This is where products separate, and it is routinely demoed on clean data.
- Attempt one real remediation end to end. Not a recommendation, an executed revocation with confirmed loss of access and a rollback. Many platforms are strong at discovery and thin at the last step.
Set the success threshold before you start and write it down. A POC without a pre-agreed pass mark becomes a negotiation about impressions. The RFP question bank covers the commercial evaluation that follows.
Frequently asked questions
Should we build or buy non-human identity tooling?
Ask the maturity question first. Below level 2, meaning no maintained inventory and no ownership model, the answer is neither: a platform will surface thousands of identities you cannot attribute or remediate, at six-figure annual cost, and the programme stalls. Above that threshold, the deciding number is usually how many platforms you need to discover across. Under about four, building is defensible; above eight, connector maintenance dominates and buying wins on cost.
What NHI capabilities are worth buying rather than building?
Three. Cross-platform discovery, because maintaining twenty connectors against APIs that change without notice is a permanent staffing commitment with no differentiation. Ownership attribution, because inferring an accountable human from commit history, deployment metadata and call graphs is the hardest problem in the category. And remediation workflow, which is easy to build badly and slow to build well.
What should you not buy?
Policy definition, because credential lifetimes and exception rules encode your risk appetite rather than a vendor default. The system of record, because an inventory living only in a vendor platform makes your audit history hostage to a renewal. Anything your cloud provider already includes, such as access analysers and key age reporting. And agent governance for now, since the standards are unratified and buying locks you to one vendor's guess.
How do you design an NHI proof of concept that actually decides?
Run it on your own estate including at least one system you consider messy, record recall against identities you already knew about alongside net new discoveries, test ownership attribution specifically on identities whose creator has left, and attempt one real remediation end to end with confirmed loss of access and a rollback. Set the pass mark in writing before starting, or the POC becomes a negotiation about impressions.
What is usually wrong with build-versus-buy models for NHI?
They count initial engineering and omit the rest. A defensible comparison includes connector maintenance against changing APIs, on-call, the drift that appears when the original author changes team, and single-maintainer risk, since internal NHI tools are frequently one person deep. On the buy side it should include true-up risk where pricing is per identity and the exit question about who holds the audit history.
Want this pressure-tested against your estate?
HumanAudit runs vendor-neutral NHI reviews: a measured baseline, a staged remediation plan, and a build-versus-buy recommendation with the numbers behind it. We take no vendor fees.