NHI Proof of Value (PoV) Plan Template

Most non-human identity (NHI) platform trials end with an impressive dashboard and no answer to the question the buyer actually had: does this tool find, explain and help fix our machine identities better than what we already do? A proof of value (PoV) differs from a proof of concept because it is judged against measurable outcomes agreed before the trial starts, not against a feature demonstration. This template gives you a reusable PoV plan for NHI security, secrets and machine identity platforms: scope, environments, test cases tied to the OWASP Non-Human Identities Top 10, success criteria, data handling, timeline and the decision record. It is written for identity, cloud security and platform teams running an evaluation, and for procurement leads who need a defensible selection. Use it after you have built a shortlist with the NHI Security Platform Buyer's Guide.

How to use this template

Replace text in square brackets, such as [Organisation], [Platform A], [PoV Lead] and [date], with your own values. Delete guidance notes in italics once completed.
"Must" marks content every PoV plan needs; "should" marks content you can shorten for a single-vendor or low-value trial.
Agree sections 3 to 5 (scope, test cases, success criteria) with every vendor in writing before any connector is enabled. Changing criteria mid-trial is the most common reason PoV results are challenged later.
Any figures shown (counts, percentages, durations) are illustrative placeholders, not benchmarks. Set your own thresholds from your baseline in section 2.
Run the same plan, the same data scope and the same scoring sheet for every vendor. If one vendor needs a different environment, record why in section 9.

1. Purpose and decision

State in two or three sentences what decision the PoV supports and who makes it.

Item	Entry
Decision to be made	[Select one NHI security platform for a [three]-year contract, or decide not to buy]
Decision owner	[CISO or Head of IAM]
PoV lead	[Name, role]
Vendors in scope	[Platform A], [Platform B], [incumbent or do-nothing baseline]
Problems the purchase must solve	[Unknown service accounts and keys; secrets in code and CI/CD; over-privileged cloud roles; orphaned NHIs after leavers; third-party OAuth grants]
Decision date	[date]

Include a "do nothing or extend current tools" option. It keeps the evaluation honest, in the same way the HM Treasury Green Book requires business as usual to be carried through to the shortlist as a benchmark.

2. Baseline: what you know today

A PoV can only show value against a baseline. Before the trial, record what your current tools and processes report for the in-scope environments. Where you have no number, write "unknown": that is itself a finding.

Baseline measure	Current value	Source
Service accounts, service principals, IAM roles and users in scope	[n or unknown]	[Directory export, cloud IAM report, CMDB]
API keys and access keys older than [90] days	[n]	[Cloud credential report]
NHIs with a named, current human owner	[%]	[Inventory or service account register]
Known secrets in code repositories and CI logs	[n]	[Existing secret scanner]
Third-party OAuth applications with tenant-wide or high-risk scopes	[n]	[IdP or SaaS admin report]
Time to answer "who owns this key and what can it reach?"	[hours or days]	[Timed tabletop with a real key]

See the Service Account Inventory Template and the NHI Discovery Guide for how to build these numbers.

3. Scope and environments

Environments (must): list each connector the vendor will use, for example [AWS Organisation, two Azure subscriptions and Entra ID tenant, Google Cloud project], [GitHub organisation], [CI/CD platform], [secrets manager], [on-premises Active Directory], [two SaaS applications]. Choose a scope that includes at least one messy, real environment, not only a clean test tenant.
Out of scope (must): production environments that hold regulated data unless the data protection review in section 7 approves them; write actions such as rotation or disabling unless section 6 allows them.
Identity types (must): service accounts, cloud workload identities, API keys and tokens, OAuth apps, certificates, and AI agent credentials and MCP server configurations if they are in your roadmap. See the Non-Human Identity (NHI) Guide for the full taxonomy.
Volume (should): state the approximate number of identities in scope so vendors can confirm they can process it within the timeline.
Access granted to the vendor (must): list each read-only role, application registration or token you will issue, its scope and its expiry date (no later than [PoV end date + 7 days]).

4. Test cases

Write test cases as tasks with an expected result, not as features. Map each to the risk it addresses so the scoring shows which risks the platform really reduces. Seed known items (a planted test key, a deliberately orphaned account) so detection can be verified, and record them only in the PoV lead's sealed list.

ID	Test case	Expected result	Risk addressed
TC-01	Produce an inventory of all NHIs in scope with type, platform, creation date and last use	Count reconciles to baseline within [x]%; every seeded identity found	NHI1 Improper Offboarding
TC-02	Find a planted canary secret in a repository, a CI log and a chat or ticket export	Found within [24] hours, validated live or not, linked to the identity it unlocks	NHI2 Secret Leakage
TC-03	Trace one real API key from where it is stored to the cloud identity, the permissions it grants and the workload that uses it	Complete chain shown without manual lookup	NHI5 Overprivileged NHI
TC-04	List permissions granted versus used for [20] high-privilege service identities over [30] days	Unused permissions identified with evidence of the data source	NHI5 Overprivileged NHI
TC-05	Identify credentials past the rotation policy and NHIs with no expiry	Matches cloud credential reports; no false "rotated" results	NHI7 Long-Lived Secrets
TC-06	Identify the same identity or secret used across development and production	Cross-environment reuse flagged	NHI8 Environment Isolation; NHI9 NHI Reuse
TC-07	Inventory third-party OAuth grants and vendor-held credentials with scopes	High-risk grants listed with vendor and consent date	NHI3 Vulnerable Third-Party NHI
TC-08	Detect interactive human sign-in using a service account	Alert or finding raised for the seeded event	NHI10 Human Use of NHI
TC-09	Propose an owner for [50] unowned NHIs and route attestation to them	Suggested owner accuracy measured against your sample check	Governance
TC-10	Run one guided remediation end to end in a non-production environment (rotate, right-size or disable)	Change completed with ticket, approval and rollback recorded	Remediation

Add TC-11 onwards for your priorities, for example AI agent discovery, certificate expiry or Kubernetes service accounts. Remove any test case you will not score. The OWASP risk names above follow the OWASP Non-Human Identities Top 10 (2025). See the Top 10 NHI Risks.

5. Success criteria and scoring

Each criterion must state a threshold that would cause a fail. Weight criteria before the trial; the weights below are illustrative only.

Criterion	Measure	Pass threshold	Weight
Discovery coverage	Seeded and baseline identities found / total	[all seeded items; at least [x]% of baseline]	[25]%
Accuracy	False positives in a random sample of [100] findings, checked by your team	[no more than x]	[15]%
Context depth	TC-03 and TC-04 chains completed without manual work	[all sampled chains]	[15]%
Remediation	TC-10 completed safely, with approval and rollback	[completed]	[15]%
Time to value	Days from connector approval to first reconciled inventory	[within x days]	[10]%
Integration	Findings delivered to [SIEM], [ticketing] and [IGA] in your format	[working in PoV]	[10]%
Platform security	Answers in section 7 accepted by security architecture	[no open high findings]	[10]%

Score each criterion 0 (fails threshold), 1 (meets), 2 (exceeds, with evidence). Any 0 on a criterion marked as mandatory, typically platform security and discovery coverage, excludes the vendor regardless of total score.

6. Rules of engagement

Read-only by default: connectors use read-only roles. Any write action (rotation, disabling, permission change) needs written approval from the [system owner] and runs only in [named non-production environment].
Change control: raise a standard change for each connector and for TC-10, with a named rollback step, for example re-enabling the account or restoring the previous secret version.
Vendor staff access: named individuals only, through [your access method], with MFA and session recording where you require it. No shared accounts.
Communication: a weekly 30-minute checkpoint, one shared issue log and one named contact on each side.
Stop conditions: the PoV lead may suspend a connector at any time if performance, rate limiting or unexpected access is observed.

7. Data handling and platform security

The platform will see the most sensitive metadata you have: where your keys are and what they can reach. Treat the PoV tenant as a third party under your supplier risk process (NIST CSF 2.0 GV.SC-07; NIST SP 800-53 SA-9 External System Services).

Secret values: does the platform store secret values or only metadata and hashes? If it validates secrets, how, and from where?
Credentials you issue: how are the PoV connector credentials stored, and can they use short-lived federation (for example OIDC workload identity federation) instead of static keys?
Data location and retention: region, sub-processors, and written confirmation of deletion within [30] days of PoV end.
Evidence: current independent assurance reports, penetration test summary and incident notification terms.

See the Third-Party Access Guide for how to govern the vendor credentials you issue.

8. Timeline

An illustrative four to six week plan. Adjust to your change windows.

Week	Activity	Exit evidence
0 (preparation)	Sign plan, NDA and data terms; complete baseline; create read-only roles; seed test items	Signed plan; connector approvals
1	Connect environments; first inventory	TC-01 initial result
2	Discovery and secret test cases	TC-02, TC-05, TC-06, TC-07 results
3	Context, privilege and ownership test cases	TC-03, TC-04, TC-08, TC-09 results
4	Remediation and integration	TC-10; SIEM and ticketing evidence
5	Scoring workshop; reference calls; commercial review	Completed scoring sheet
6	Decision and offboarding of losing vendors	Decision record; deletion confirmations; PoV credentials revoked

9. Roles

Role	Responsibilities
PoV lead [Name]	Owns the plan, sealed seed list, scoring and issue log
Cloud and platform owners	Approve and create connector roles; approve write actions
Security architecture	Reviews section 7 answers; can veto on platform security
IAM and IGA team	Checks ownership and attestation test cases; integration
Procurement	Commercial terms, pricing model comparison, contract
Vendor technical lead	Delivers configuration and evidence for each test case

10. Results and decision record

Scoring sheet per vendor with evidence links (screenshots, exports, ticket numbers) for every test case.
Exceptions: any test case that could not run, with the reason and whether it affected the score.
Pricing compared on the same basis: [per identity, per connector, per environment or platform fee], projected to year three using your own growth assumption. See the Security Budget Template and Cost Model.
Recommendation, residual risks and conditions, signed by the decision owner on [date].
Offboarding confirmation: all PoV roles, tokens and app registrations removed, and vendor deletion confirmation received.

Implementation guidance

Making the PoV fair

Same data, same time: run vendors in parallel on the same scope where possible, so drift in the environment does not favour one of them.
Sealed seeds: canary keys and planted orphan accounts are the only objective test of discovery. Use non-functional or tightly scoped canary credentials, and record where each one was placed.
Your team does the counting: accept vendor reports as input, but compute coverage and false positive rates yourselves from a sample.
Price on your volume: NHI counts usually outnumber employees by a wide margin, and per-identity pricing can change sharply once discovery finds what was hidden. Ask for pricing based on the PoV inventory, not the pre-sales estimate.

Common failure patterns

Clean-room scope: the trial runs in a test tenant with ten identities, so nothing can fail. Include at least one real, untidy environment.
Dashboard as evidence: a risk score is shown but the evidence behind it is not. Require the data source for each finding.
Forgotten PoV credentials: read-only roles and tokens created for the trial outlive it. In the Klue OAuth Breach, a GitHub token issued for a limited 2022 pilot was never revoked and was later used to push malicious code. Put an expiry on every PoV credential and revoke it in week 6.
No remediation test: the platform finds problems but nobody tries fixing one. TC-10 is what separates visibility tools from programme tools.
Criteria changed after results: lock section 5 at sign-off and record any change with a reason and both parties' agreement.

Framework alignment

PoV area	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Inventory and discovery (TC-01)	ID.AM-02	CM-8 System Component Inventory
NHI credential management (TC-02, TC-05)	PR.AA-01	IA-5 Authenticator Management; IA-9 Service Identification and Authentication
Least privilege (TC-04)	PR.AA-05	AC-6 Least Privilege
Account lifecycle and ownership (TC-09)	PR.AA-01	AC-2 Account Management; IA-4 Identifier Management
Vendor and data handling (section 7)	GV.SC-07	SA-9 External System Services

After selection, move straight into delivery with the NHI Programme Roadmap and track maturity against the NHI Governance Maturity Model.

NHI proof of value plan template: Scope, success criteria and evidence for a fair trial