NHI programme cost model: Estimating effort, tooling and savings you can defend

Non-human identity (NHI) programmes are often funded on a tool quote alone, then stall when the real cost turns out to be the engineering time needed to find owners, migrate secrets and change how applications authenticate. A credible cost model counts that effort, the tooling, the run cost and the savings in a way finance can check later. This guide gives a method for building an NHI programme cost model from your own inventory: the cost drivers, how to estimate effort per identity type, how to compare pricing models, how to count savings without inventing breach probabilities, and how to track actuals. It is written for IAM and security leads, cloud platform owners and the finance partners who review their bids. Every number on this page is illustrative: replace it with figures from your own estate.

Key takeaways

• Effort, not licences, is usually the largest cost. Owner discovery, secret migration and authentication changes need application team time, and that time must be in the model.
• Model per identity type. A cloud access key, a database service account and an OAuth grant have very different remediation effort, so one average per identity hides the real cost.
• Start from inventory counts you can defend. Discovery usually raises the count, so build a low, expected and high scenario rather than one number.
• Count savings you can measure. Retired accounts, removed static keys, hours saved on audits and rotations, and licences consolidated are checkable; avoided breach cost is a risk argument and belongs in a separate line.
• Track actuals against the model every quarter. A cost model that is never reconciled loses credibility at the next funding round.

What an NHI cost model must cover

The model should show whole-life cost over the planning period, usually three to five years, split into one-off change cost and recurring run cost. The HM Treasury Green Book is a useful discipline even outside government: carry business as usual through as a benchmark, adjust for optimism bias by raising cost and duration estimates, and test sensitivity on the assumptions that drive the result. For the business case document itself, use the Security Business Case Template; this page covers the numbers behind it.

Step 1: build the volume baseline

The model is only as good as its counts. Pull counts by identity type and platform from authoritative sources: cloud IAM credential reports, Entra ID service principal and managed identity lists, Active Directory accounts flagged as service accounts, CI/CD secret stores, secrets manager inventories, certificate inventories and OAuth grant reports. See the NHI Discovery Guide and the NHI Inventory Reconciliation guide for methods.

1. Count by type: service accounts, cloud workload identities, static access keys, API tokens, OAuth applications, certificates, SSH keys, AI agent credentials.
2. Segment by state: for each type, estimate the share that is active, dormant, unowned, over-privileged and using static credentials. These segments drive remediation effort.
3. Apply a discovery uplift: if you have not run full discovery, set a low, expected and high multiplier on today's counts. Record it as an assumption and replace it once discovery runs.
4. Forecast growth: estimate annual growth from the last 12 months of creation events, and add expected new sources such as AI agents and new SaaS platforms.

Step 2: estimate effort per identity type

Estimate effort as hours per identity for each remediation action, then multiply by the count in each segment. Get the hours from a timed pilot of 20 to 50 real identities, not from a workshop guess. The table below shows the structure; the hours are placeholders only.

Multiply hours by a blended internal day rate per role, and keep application team effort as a visible line even if it is not charged to the security budget. Programmes that hide it end up competing with feature work they did not plan for. See the NHI Offboarding and Decommissioning Guide and the Secrets Rotation Runbook Template for what each action involves.

Step 3: price the tooling

NHI and secrets tooling is priced in several ways, and the cheapest at pilot scale can be the most expensive after discovery. Ask every vendor to price the same volume scenarios from Step 1.

Consumption pricing is published for cloud secrets services and makes a good worked example. AWS Secrets Manager lists USD 0.40 per secret per month and USD 0.05 per 10,000 API calls on its pricing page (checked October 2026). Under those rates, 2,000 secrets cost about USD 800 a month before API calls, and a workload that retrieves a secret on every request instead of caching it can make API calls the larger line. Model retrieval frequency, not only secret count. Prices change: take them from the provider's current page when you build your model.

Step 4: count savings that can be checked

Separate savings into three classes and present them separately, so a reviewer can accept the first two without having to accept a risk argument.

• Cash savings: licences or tools retired after consolidation (for example a standalone secret scanner absorbed into the platform), cloud costs from deleted unused resources found during discovery, reduced consultancy for audit evidence.
• Effort savings: hours saved on manual rotations, on audit sampling and evidence gathering, on investigations that previously had to answer "who owns this key?", and on access reviews. Measure baseline hours before the programme with a short time study, then the same tasks after.
• Risk reduction: fewer static long-lived credentials, fewer unowned and over-privileged NHIs, faster revocation. Express it as a change in exposure counts and in the rating of entries on your risk register. If your organisation uses quantitative risk analysis, use its existing method and loss figures rather than adding new ones in the NHI case. See the FAIR-CAM Controls Analytics Model Guide.

Avoid quoting industry average breach costs as a saving. They are not specific to your estate and invite challenge. A specific scenario works better: in the Klue OAuth Breach, a token issued for an abandoned 2022 pilot was never revoked. Count how many comparable dormant tokens your baseline found, and show how many the programme removes.

Step 5: assemble scenarios and test sensitivity

1. Build three scenarios: low, expected and high, varying identity count, hours per action and adoption rate.
2. Add optimism bias: apply an uplift to effort and duration in line with your organisation's appraisal guidance. The Green Book asks practitioners to adjust explicitly for optimism bias by raising cost and duration estimates and lowering benefit estimates.
3. Find the switching values: identify the assumptions that would change the decision, such as the hours per secret migration at which a federation-first approach becomes cheaper than vaulting, or the identity count at which per-identity pricing exceeds a platform fee.
4. Phase the spend: align one-off costs to the delivery plan so the model shows cash flow by quarter.
5. State what is excluded: for example AI agent identities not yet in scope, or application team effort charged to product budgets.

A simplified illustrative structure for one identity type:

Decision guidance

• Federation versus vaulting: where the runtime or pipeline supports workload identity federation, removing the secret usually costs more at first but removes rotation run cost entirely. Where it does not, vaulting with automated rotation is the fallback. Model both for your top platforms. See the NHI Authentication Guide.
• Platform versus native tools: a small estate on one cloud may meet most needs with native credential reports, the cloud secrets service and scripts, at the cost of engineer time. Multi-cloud estates with many SaaS integrations usually find cross-platform correlation is where a platform earns its fee. Test the claim in a proof of value with the same volume scenarios.
• Small organisations: keep the model to five or six lines: tool cost, cloud consumption, one engineer's time, application team hours, savings in hours, and contingency.
• Large organisations: model per business unit and per platform, because remediation effort varies far more than tooling cost, and charge-back rules affect who funds application changes.

Measuring cost and value after approval

Report actuals against the model quarterly, and update assumptions with measured values.

• Cost per remediated identity: total effort and tool cost in the period divided by NHIs remediated, by type.
• Actual versus estimated hours per action: from tickets or change records, by action type.
• Static credentials removed: count and share of static keys replaced by federation or managed identities.
• Unowned NHI share: percentage of NHIs with a current owner, as in the NHI Ownership Attestation Campaigns Guide.
• Run cost per 1,000 NHIs: tooling, consumption and operations cost divided by identities under management, to show scale effects.
• Hours saved: measured against the baseline time study for rotations, audits and investigations.

Common failure patterns

• Licence-only budget: the bid covers the platform subscription and nothing for application changes, so findings pile up unresolved.
• Pre-discovery counts: per-identity pricing is agreed on an estimate, then discovery finds several times more identities and the renewal jumps.
• Averages that hide the hard cases: a single hours-per-identity figure makes legacy applications that cannot rotate secrets look cheap.
• Generic breach statistics as savings: the case is challenged and loses the measurable savings along with the unmeasurable ones.
• No reconciliation: actuals are never compared to the model, so the next phase cannot show value delivered.
• Uncosted API usage: applications fetch secrets on every call, and consumption charges exceed the storage cost.

Framework mapping

Practitioner checklist

• Pull identity counts by type and platform from authoritative sources and record the source of each.
• Set low, expected and high discovery uplift factors and replace them after discovery runs.
• Time a pilot of 20 to 50 real remediations per action type before estimating effort.
• Keep application team effort as a visible line in the model.
• Ask every vendor to price the same volume scenarios, including year-three growth.
• Model retrieval frequency for consumption-priced secrets services.
• Present cash savings, effort savings and risk reduction as separate lines.
• Apply an optimism bias uplift and identify the switching values.
• Reconcile actuals against the model every quarter and update assumptions.

Standards and references

• HM Treasury: The Green Book
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• OWASP: Non-Human Identities Top 10
• AWS: Secrets Manager Pricing
• CIS: Control 5 Account Management

Related NHI Mgmt Group resources: Security Budget Template and Cost Model · Business Case Guide · NHI Security Platform Buyer's Guide · NHI Programme Roadmap