Service accounts, API keys, tokens, certificates and AI agents hold some of the most powerful access in any estate, and the tools sold to secure them differ far more than their marketing suggests. Dedicated NHI security vendors, secrets management providers, identity governance and PAM platforms, cloud security posture tools and identity visibility platforms all claim NHI capabilities. They differ in what they discover, how well they understand each identity, and whether they only report risk or actually help you fix it. This vendor-neutral buyer's guide is for IAM, cloud security, security operations and platform engineering teams writing requirements, running an RFP or replacing spreadsheets and scripts. It covers requirements, capability areas, weighted evaluation criteria, vendor questions, red flags and a proof of concept with measurable pass criteria.
Key takeaways
- Five capabilities, rarely equal: NHI security platforms combine discovery and inventory, context (ownership, usage, privilege), posture and risk, remediation and lifecycle, and threat detection. Few are equally strong at all five, so weight them to your priority problems.
- Breadth and correlation beat dashboards: coverage of clouds, SaaS, identity providers, code, CI/CD, secrets managers and directories, plus the ability to link a leaked secret to the identity and permissions behind it, matters more than visual polish.
- Usage context prevents the costliest mistake: an identity wrongly believed to be unused is the one that never gets rotated. Demand evidence of last use, consuming workload and permissions used versus granted.
- Remediation is the return on investment: prefer platforms that rotate, right-size, reassign and decommission through your own secrets manager and ticketing, staged safely, not only platforms that list findings.
- AI agents and the platform itself are in scope: check how agents, AI API keys and MCP servers are discovered, and treat the platform's own read and write access to your estate as a privileged NHI.
Define your requirements first
Write requirements before you watch a demo. Start from where your NHIs live and which problems hurt most.
- Estate: which clouds, SaaS applications, identity providers, on-premises directories, secrets managers, CI/CD systems, code repositories, Kubernetes clusters and AI platforms hold service accounts, keys, tokens and certificates? Rank them by business criticality.
- Priority problems: unknown NHIs, leaked secrets, over-privilege, orphaned or ownerless identities, third-party OAuth risk, long-lived credentials, rotation backlog, humans using service accounts, or AI agents with standing access. The OWASP NHI Top 10 gives a shared vocabulary for these risks.
- Users and owners: who will act on findings: security operations, IAM, cloud security, developers, GRC? A platform nobody outside security can use will produce a backlog, not fixes.
- Integrations: IGA, PAM, secrets managers, SIEM and SOAR, ticketing, CMDB and chat tools. Note which must be read and which must be written to.
- Constraints: deployment model (SaaS, self-hosted or hybrid), data residency, whether secret values may leave your environment, and the scale you expect in three years.
- Maturity: a team with no inventory needs discovery and ownership first; a mature team needs automated lifecycle and detection. See the NHI Governance Maturity Model.
Map requirements to the frameworks you report against
Tying each requirement to a control makes the business case and the audit evidence easier. The mappings below were checked against the framework texts.
| Requirement | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 | OWASP NHI Top 10 (2025) |
|---|---|---|---|---|
| Complete NHI inventory with owners | PR.AA-01 | AC-2, IA-4, CM-8 | Control 5 | NHI1, NHI10 |
| Credential rotation and protection | PR.AA-01 | IA-5 | Control 5 | NHI2, NHI7 |
| Least privilege and privilege review | PR.AA-05 | AC-6, AC-6(7) | Control 6 | NHI5 |
| Disable inactive and expired identities | PR.AA-01 | AC-2(3) | Control 5 | NHI1 |
| Detect atypical NHI use | DE.CM-03 | AC-2(12), SI-4 | Control 8 | NHI10 |
| Third-party integrations and OAuth grants | GV.SC-07 | SA-9 | Control 15 | NHI3 |
Capability areas
Use this table to decide which capabilities are mandatory and which are nice to have. The final column shows which OWASP NHI Top 10 risks each capability helps address.
| Capability | What good looks like | OWASP NHI risks |
|---|---|---|
| Discovery and inventory | Finds service accounts, service principals, IAM roles and users, API keys, OAuth apps, tokens, certificates and secrets across all your platforms; correlates the same identity across systems; continuous, not a one-off scan | NHI1, NHI9 |
| Context | Owner, consuming workload, last activity, permissions granted versus used, credential age, environment and where each secret is stored | NHI1, NHI5, NHI8 |
| Posture and risk | Explainable prioritisation by privilege, exposure, staleness and data sensitivity; flags weak or deprecated authentication and shared credentials | NHI4, NHI5, NHI9 |
| Secret detection | Finds secrets in code, CI/CD, collaboration tools and images; validates whether they are live without storing values; links them to the identity they unlock | NHI2, NHI6 |
| Third-party and OAuth risk | Inventories OAuth grants and SaaS-to-SaaS integrations with scopes, vendor, consenting user and last use | NHI3 |
| Remediation and lifecycle | Guided or automated rotation, right-sizing, ownership assignment, disabling and decommissioning, with workflow into ticketing and staged rollback | NHI1, NHI5, NHI7 |
| Threat detection | Baselines NHI behaviour; alerts on use from new locations, unusual APIs, human-style interactive use and credential misuse; integrates with SIEM and SOAR | NHI10 |
| Governance | Ownership attestation and NHI access reviews, natively or through your IGA platform | NHI1, NHI5 |
| AI agents | Discovers AI agents, AI API keys and MCP servers; links each agent to its credentials, permissions and human owner | NHI2, NHI5, NHI7 |
Threat detection should be judged against the techniques attackers actually use against NHIs. MITRE ATT&CK describes adversaries creating long-lasting additional credentials on compromised cloud accounts to keep access, searching files for insecurely stored credentials, including service account credentials in cloud and container configuration files, and stealing application access tokens from Kubernetes containers and CI/CD pipelines. See the Service Account Security Guide, the API Key Management Guide and the MCP Security Guide.
Evaluation criteria
Score each shortlisted platform from 0 to 5 per criterion in your own environment, multiply by the weight and add up. The weights below suit a typical first purchase; move weight towards detection or AI agents if those are your priority problems.
| Criterion | Weight | What good looks like |
|---|---|---|
| Coverage and correlation accuracy | 20% | Every required connector available today; a leaked secret traced to the cloud role or service principal it grants; low false positives and few missed identities against seeded test cases |
| Remediation and lifecycle | 20% | Clear split between automated, guided and advisory fixes; rotation through your secrets manager; staged disable, observe, delete; tickets routed to the right owner |
| Depth of context | 15% | Last-used evidence per credential, consuming workload, permissions used versus granted, and owner inference that shows its reasoning |
| Risk prioritisation | 10% | Scores you can explain to an auditor; mapping to OWASP NHI Top 10 and your control framework |
| Threat detection | 10% | Behavioural baselines for NHIs, alerts with context, export to SIEM and SOAR, tested against realistic misuse |
| Third-party and AI agent coverage | 10% | OAuth grants with scopes and vendors; AI agents, AI API keys and MCP servers linked to owners and credentials |
| Security of the platform | 10% | Read-only by default, write access scoped and justified, no secret values stored, federated or short-lived credentials to your estate, full audit log |
| Operations and cost | 5% | Deployment and residency fit, performance at your scale, predictable pricing (per identity, per connector or per environment) |
Ownership and usage deserve extra scrutiny. In the Cloudflare Thanksgiving Breach 2023, one service token and three service accounts exposed in the Okta support system breach were not rotated because Cloudflare mistakenly believed they were unused, and that was how the attacker got in. A platform that shows real last-use evidence closes exactly that gap.
The platform's own access is a credential like any other. NIST IR 8587, written for agencies and cloud service providers, recommends enhancements to key management, token verification and life cycle controls to protect tokens and assertions from forgery, theft and misuse, and stresses continuous monitoring. Apply the same standard to every token and key the NHI platform holds for your clouds, SaaS tenants and repositories. See the NHI Ownership Guide.
Questions to ask vendors
- Show us an API key found in a repository and trace it to the cloud identity it belongs to, the permissions it grants, where else it is used and its owner.
- How do you distinguish a service account used by a workload from one used interactively by a person, and how do you alert on human use of an NHI?
- How is "last used" established for each credential type, and how far back does the evidence go?
- What percentage of findings could be remediated automatically in our environment, and what happens if a rotation breaks a workload?
- How do you discover OAuth apps and their scopes across our identity provider and SaaS platforms, including grants made by individual users?
- How do you discover AI agents, AI API keys and MCP server configurations, and link them to owners?
- Do you store secret values? If you validate secrets, how, and from where?
- What permissions does your platform need in each environment, which are write permissions, and how are your own credentials to our estate protected and rotated?
- Which OWASP NHI Top 10 risks do you address, and how would we verify each claim in the proof of concept?
Red flags
- Discovery limited to one cloud or one platform, presented as full coverage.
- Risk scores with no explanation of what drives them.
- "Unused" or "dormant" labels with no last-activity evidence behind them.
- No path from finding to remediation, only reports and exports.
- Broad write permissions or long-lived static keys required to connect, without justification.
- Secret values copied into the vendor's cloud to "validate" them.
- AI agent or MCP support that turns out to be a roadmap item or a keyword search.
- Roadmap features presented as available.
Running a proof of concept
- Agree pass criteria first: write the success metrics below into the PoC plan and share them with every vendor before connecting anything.
- Connect a representative slice: at least one cloud, your identity provider, a key SaaS platform, source code, CI/CD and your secrets manager, using read-only access where possible.
- Seed known test cases: a leaked test key in a repository, an orphaned service account, an over-privileged role, a dormant OAuth app, a credential shared across two environments and a test AI agent with its own API key.
- Measure discovery and context: record which seeded cases each platform finds, how quickly, how accurately it infers owners and how many false positives it raises.
- Test end-to-end remediation: rotate a secret through your secrets manager, remove unused permissions from a role and decommission the orphaned account in stages, with a ticket raised to the owner.
- Test detection: use a test credential from an unusual location or interactively, and confirm the alert reaches your SIEM with enough context to act.
- Review the platform's own access: list every permission it was granted and every credential it holds, and confirm the audit log captures its actions.
- Involve the people who will use it: IAM, cloud security, security operations and at least one development team should score usability.
| Success criterion | What it shows | Example target |
|---|---|---|
| Seeded test cases found | Discovery coverage | All seeded cases found within the agreed window |
| Owner inference accuracy | Usefulness of context | Most sampled identities assigned to the right owner, checked by hand |
| False positive rate | Analyst workload | Low enough that owners accept the tickets |
| Time to first useful inventory | Time to value | Days, not months |
| Remediations completed end to end | Real risk reduction | At least one rotation, one right-sizing and one decommission without outage |
| Detection alert in SIEM | Operational fit | Alert with identity, owner and permissions attached |
Keep these measures after go-live as programme metrics. See the Identity Security Metrics Guide and the Service Account Inventory Template.
How NHI platforms fit with other tools
Decide what the NHI platform must own and what it should feed or consume, so you do not pay twice or leave gaps.
- Secrets managers store and rotate secrets; NHI platforms find secrets outside them and govern the identities they belong to. See the Secrets Management Buyer's Guide.
- IGA governs access and reviews; some NHI platforms feed IGA, others provide their own governance. See the IGA Buyer's Guide.
- PAM vaults privileged credentials and controls sessions. See the PAM Buyer's Guide.
- IVIP and ISPM provide cross-identity visibility and posture across human and non-human identities. See the IVIP and ISPM Buyer's Guide.
- ITDR detects identity attacks, increasingly including NHI misuse. See the ITDR Buyer's Guide.
- AI agent identity tools focus on agents and MCP. See the AI Agent Identity Security Buyer's Guide.
Third-party OAuth tokens are where these boundaries most often fail. In the Klue OAuth Breach 2026, a long-disused but still active GitHub personal access token let an attacker add code that collected customers' Salesforce OAuth tokens. Ask which tool in your stack would have inventoried both the token and the grants. See the SaaS and OAuth App Governance Guide and the NHI Lifecycle Management Guide.
Standards and references
- OWASP: Top 10 Non-Human Identities Risks 2025
- OWASP: Non-Human Identities Top 10
- NIST: The NIST Cybersecurity Framework (CSF) 2.0
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
- NIST: IR 8587 Protecting Tokens and Assertions from Forgery, Theft, and Misuse
- CIS: The 18 CIS Critical Security Controls
- CIS: Critical Security Control 5: Account Management
- MITRE ATT&CK: T1078.004 Valid Accounts: Cloud Accounts
- MITRE ATT&CK: T1552.001 Unsecured Credentials: Credentials In Files
- MITRE ATT&CK: T1528 Steal Application Access Token
How NHI Mgmt Group can help
We provide independent market analysis, requirements definition, RFP and proof of concept support for NHI security programmes. Browse vendors in our NHI and AI products directory or contact us.
Related NHI Mgmt Group resources: Ultimate Guide to Non-Human Identities · Secrets Management Guide · Leaked Credential Response Playbook · Shadow AI Discovery Guide · NHI Governance Maturity Model