How to run a Non-Human Identity RFP
A non-human identity evaluation involves identity, cloud, security operations and engineering teams, and every shortlisted platform will need read access to some of your most sensitive systems. Agree on scope and connector permissions before vendors get involved. The example schedule in this template runs about 12 weeks from kickoff to contract award; stretch it if the proof of value covers many cloud accounts or business units.
- Define scope and the sources to connect (weeks 1-2). List the cloud accounts, SaaS tenants, identity provider, code repositories, CI/CD platforms, Kubernetes clusters, secrets managers and AI agent platforms in the first phase. Record the numbers vendors will price against. If you don't know how many non-human identities you have, give vendors the counts you do know (accounts, tenants, repositories, clusters) and ask them to price on those as well, so a large discovery result doesn't change the price later.
- Assemble the buying team. Include identity and access management, cloud platform, security operations, DevOps or platform engineering, and the teams building AI agents, plus procurement, legal and privacy. Agree early who will act on findings. If remediation will fall to the engineering teams that own the identities, give them a voice in the evaluation.
- Decide whether you need an RFI (weeks 2-4). Products in this category come from different starting points, such as secrets management, privileged access management, identity governance, cloud entitlement management and dedicated non-human identity platforms. They differ in which sources they cover and whether they fix problems or only report them. If you're unsure which approach fits, whether AI agent governance belongs in this purchase, or your long list has more than five vendors, issue a short RFI first. Ask which sources each vendor covers, what it can remediate, which AI agent platforms it supports today, and how it prices.
- Tailor and issue the RFP (weeks 4-7). Delete requirements that don't apply, adjust priorities, and list your sources and environment details in Section 1. Give vendors three weeks to respond, with a written question-and-answer window in the first week.
- Score the responses (weeks 7-8). Have each evaluator score independently against the rubric before comparing notes, and set aside any vendor that misses a Must-have. Check every 'yes' for whether the feature is generally available today or still in preview or on the roadmap, especially for AI agent features.
- Run a proof of value with two or three vendors (weeks 8-11). Have your security team approve each vendor's connector permissions, then connect the shortlisted platforms read-only to the same set of sources. Compare the inventories side by side: which identities each one found, how accurate the owner suggestions are, and how many findings are real. Test one remediation end to end on a non-production credential, and call references of a similar size.
- Negotiate and award (weeks 11-12). Pin down the license metric and what happens when discovery finds more identities than you estimated. Settle renewal caps, add-on pricing, data deletion and exit assistance before you sign, not after.
Non-Human Identity RFP requirements
Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.
Functional
| ID |
Requirement |
Priority |
| F1 |
Continuous discovery of non-human identities across [cloud providers], SaaS applications, our identity provider, Kubernetes clusters, CI/CD platforms and on-premises directories, including service accounts, service principals, managed identities, IAM roles, access keys, API keys, OAuth applications and tokens, and personal access tokens. |
Must-have |
| F2 |
Detection of secrets (keys, tokens, passwords and connection strings) exposed in code repositories, CI/CD pipelines and configuration files, natively or by ingesting findings from our secrets scanning tool, with each secret linked, where possible, to the identity it belongs to. |
Must-have |
| F3 |
Inventory of certificates and keys used for machine authentication, collected directly or imported from our certificate lifecycle management tool or certificate authorities, with expiry dates and owners. |
Nice-to-have |
| F4 |
Discovery of AI agents built on or running in [AI agent platforms, copilots and automation tools in use], with the identities, API keys and OAuth grants each agent uses and the permissions they carry. |
Must-have |
| F5 |
Inventory of the tools, APIs and Model Context Protocol (MCP) servers each AI agent is configured to call, and the access each one grants. |
Nice-to-have |
| F6 |
One record per identity showing its credentials, its permissions, the resources it can reach, the applications and workloads that use it, when it was created, when it was last used and who owns it. |
Must-have |
| F7 |
Ownership assignment for every identity, with suggested owners drawn from creation events, tags, code ownership and usage, and a workflow for owners to confirm or reassign. Every AI agent must have a named human sponsor who is accountable for its purpose and access. |
Must-have |
| F8 |
Detection of orphaned identities when an owner or sponsor leaves or changes role, based on events from our identity provider or HR system, with a reassignment workflow and an option to disable the identity if no one claims it. |
Must-have |
| F9 |
A risk score for each identity that shows the factors behind it, such as privilege level, credential age, exposure in code, missing owner, dormancy and unusual activity. |
Must-have |
| F10 |
Findings for common hygiene problems: credentials past their rotation date or with no expiry, dormant identities, credentials shared across applications or environments, and third-party OAuth applications with broad scopes. |
Must-have |
| F11 |
Remediation workflows that rotate, revoke, disable or delete a credential or identity, either executed through native integrations after approval or assigned to the owner as a ticket, with each finding tracked to closure. |
Must-have |
| F12 |
Automated rotation that also updates every consumer of the credential, or the secrets manager they read from, and confirms that consumers still authenticate after the change. |
Nice-to-have |
| F13 |
Comparison of granted and used permissions for cloud roles, service accounts and OAuth scopes, flagging unused, excessive and administrative permissions. |
Must-have |
| F14 |
Right-sized permission policies generated from observed usage, applied through cloud APIs or as infrastructure-as-code pull requests, with a preview of which recent actions the new policy would have blocked. |
Nice-to-have |
| F15 |
Detection of anomalous use of non-human credentials, such as use from unexpected networks or locations, unusual API calls or volumes, first-time access to sensitive resources and use of a credential that was due to be retired, with the evidence behind each alert. |
Must-have |
| F16 |
Automated response actions (disable an identity, revoke a token or credential, open an incident) triggered by detections, with optional approval steps, natively or through our SOAR platform. |
Nice-to-have |
| F17 |
Lifecycle policies from creation to decommission: required owner, purpose, environment and expiry at creation; maximum credential lifetime; dormancy thresholds; and a decommission workflow that removes the identity, its credentials and its permissions. |
Must-have |
| F18 |
Periodic reviews in which owners and sponsors confirm that each identity or agent is still needed and its access is still appropriate, run natively or through our identity governance platform, with escalation when owners don't respond. |
Must-have |
| F19 |
For AI agents that act on behalf of a user, a record of the delegating user, the scopes granted and the grant's expiry (for example, through OAuth 2.0 token exchange or on-behalf-of flows), and revocation of those grants when the user leaves. |
Nice-to-have |
| F20 |
Issuance or brokering of scoped, short-lived credentials for AI agents per task or session, so that agents do not hold standing secrets. |
Nice-to-have |
| F21 |
Policy enforcement for which tools, APIs and data each AI agent may access, denying unregistered tools and out-of-scope actions by default. |
Nice-to-have |
| F22 |
An audit trail of AI agent actions that links each action to the agent, its human sponsor or delegating user, the credential used and the resource accessed. |
Nice-to-have |
Technical and architecture
| ID |
Requirement |
Priority |
| T1 |
Agentless discovery through each source's APIs, using read-only permissions by default. List every permission the platform needs for each source, identify which are needed only for remediation, and describe how collection stays within each source's API rate limits. |
Must-have |
| T2 |
A list of supported sources (cloud providers, SaaS applications, identity providers, code repositories, CI/CD platforms, Kubernetes, secrets managers and AI agent platforms), stating for each whether the platform discovers identities, shows their activity, analyzes their permissions or can remediate them. |
Must-have |
| T3 |
Self-hosted collectors or a hybrid option for on-premises sources that cannot be reached from the vendor's cloud. State what data the collector sends to the platform. |
Must-have |
| T4 |
Support for [number] identities across [number] cloud accounts, SaaS tenants and repositories. State how often the inventory refreshes and how quickly new identities and activity appear after they are created. |
Must-have |
| T5 |
Retention of inventory history and activity data for at least [number] months, searchable in the platform and exportable. |
Must-have |
| T6 |
Recognition of federated and short-lived workload identities (for example, OIDC federation from CI/CD platforms, cloud workload identity federation and SPIFFE IDs) in the inventory, and reports on static credentials that could be replaced with them. |
Nice-to-have |
Integration
| ID |
Requirement |
Priority |
| I1 |
Integration with our identity provider: single sign-on for administrators via SAML 2.0 or OIDC, user and group provisioning via SCIM, and joiner, mover and leaver events used to keep ownership current. |
Must-have |
| I2 |
Integration with cloud IAM in [cloud providers] to read identities, policies and activity logs, and to apply approved remediation through native APIs. |
Must-have |
| I3 |
Integration with our secrets managers ([list]) to inventory stored secrets, identify secrets that live outside them, and rotate credentials through them. |
Must-have |
| I4 |
Integration with our ticketing (ITSM) platform for ticket creation, approval routing and two-way status updates on findings and owner tasks. |
Must-have |
| I5 |
Streaming of findings, alerts and the administrator audit log to our SIEM in a documented format (for example, syslog or OCSF), plus a documented REST API and webhooks covering inventory, findings, policies and workflows. |
Must-have |
| I6 |
Integration with our identity governance and privileged access management tools, to share non-human identity inventory and ownership for access certification and to vault privileged non-human credentials. |
Nice-to-have |
Security and compliance
| ID |
Requirement |
Priority |
| S1 |
A current SOC 2 Type II report and ISO/IEC 27001 certification covering the proposed services, available under NDA. |
Must-have |
| S2 |
FedRAMP authorization at the required impact level, or equivalent regional certifications for public-sector use. Make this Must-have if you are a public-sector buyer. |
Nice-to-have |
| S3 |
Collection of credential metadata without storing secret values, except where the platform is explicitly configured to rotate or vault them. State what credential data is stored, in what form (metadata, hash or value) and where. |
Must-have |
| S4 |
Protection of the platform's own access to our environment: least-privilege connector permissions, federated or short-lived credentials where the source supports them, rotation of any static connector credentials, and separation of read and write permissions. |
Must-have |
| S5 |
Isolation of our tenant's data, encryption in transit and at rest, and a choice of hosting region for stored data. State whether customer-managed encryption keys are supported. |
Must-have |
| S6 |
Administrator access through SSO with MFA and role-based permissions, including separate rights for viewing findings and running remediation, plus an audit log of every configuration change and remediation action. |
Must-have |
| S7 |
A data processing agreement, a current list of sub-processors, and a contractual commitment to notify us of security incidents affecting our data within a defined time. State the time. |
Must-have |
| S8 |
Reports and evidence exports that support audits of non-human accounts against the frameworks we follow (for example, SOC 2, ISO/IEC 27001 or PCI DSS). |
Nice-to-have |
Implementation and support
| ID |
Requirement |
Priority |
| M1 |
A phased deployment plan covering source connection, baseline inventory, ownership assignment and remediation, with named roles and the effort expected from both sides. |
Must-have |
| M2 |
Identification of who delivers the implementation (vendor, partner or both) and the relevant experience of the named team. |
Must-have |
| M3 |
A service-level agreement for platform availability, with service credits. State how availability is measured. |
Must-have |
| M4 |
24×7 support for critical issues, with response-time targets by severity. State your targets. |
Must-have |
| M5 |
Advance notice of changes to connectors, detections, risk scoring or automated actions that change what the platform finds or does in our environment. |
Must-have |
| M6 |
Help assigning owners and working through the initial backlog of findings, plus administrator training, documentation and a named customer success contact. |
Nice-to-have |
Commercial and pricing
| ID |
Requirement |
Priority |
| C1 |
Pricing broken down by module, metric and term, showing list price, discount and net price. |
Must-have |
| C2 |
A clear definition of the license metric: what counts as a billable identity (for example, service accounts, keys, tokens, AI agents and short-lived workloads), and how duplicate and ephemeral identities are counted. |
Must-have |
| C3 |
Terms that apply if discovered identity counts exceed the licensed quantity, including when a true-up happens and at what price. |
Must-have |
| C4 |
A cap on price increases at renewal. State the cap. |
Must-have |
| C5 |
A proof of value at no charge, connected read-only to our own environment, with the vendor's engineering support. |
Nice-to-have |
| C6 |
Exit terms covering export of inventory, ownership and history data, deletion of our data, and removal of the platform's access to our systems at the end of the contract. |
Must-have |
Questions to ask Non-Human Identity vendors
These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.
- Connect to our proof-of-value environment and show us the inventory, not a slide. How do you correlate the same identity across cloud IAM, SaaS, code repositories and our secrets manager?
- For each source in our environment, state whether you discover identities, show their activity, analyze their permissions or can remediate them. Which of these need write permissions?
- What permissions does your platform need in our cloud accounts, SaaS tenants and repositories, and how are your own credentials to our environment scoped, stored and rotated?
- Do you ever store secret values? When you scan code, pipelines or vaults, what data leaves our environment and where is it kept?
- How do you suggest an owner for an identity with no tags and no creation record, and what happens when the suggestion is wrong?
- Walk us through rotating a credential used by three applications: who is notified, what changes, and how do you confirm that none of the applications broke?
- In which AI agent platforms can you discover agents today, in a generally available release? For each, what do you see: the agent, its credentials, its OAuth grants, the tools it can call and the user it acts for?
- When an AI agent acts on behalf of a user, how do you show whose authority it is using, and what happens to the agent's access when that user leaves or changes role?
- Can you issue or broker short-lived, task-scoped credentials for agents and workloads, or do you only report on the credentials they already hold? Which standards do you use, such as OAuth 2.0 token exchange, OIDC or SPIFFE?
- Show us an anomaly alert for a service account: what baseline it was compared with, which signals triggered it, and what an analyst can do from the alert.
- How long does initial discovery take for an environment like ours, and how do you help owners work through the first backlog of findings?
- How do you count billable identities, and how does our price change if discovery finds more identities than we estimated?
- Which features in your proposal are generally available today, and which are in preview or on the roadmap? Give dates, especially for AI agent features.
- Provide a reference customer of similar size that uses your platform to assign owners and remediate findings, not only to report them.
Scoring rubric
Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.
| Criterion |
Weight |
What a strong response shows |
| Discovery coverage and accuracy |
20% |
Finds identities in every source you need, including code, CI/CD and AI agent platforms, shown against your own environment in the proof of value, with few duplicates. |
| Ownership, lifecycle and remediation |
20% |
Accurate owner suggestions, enforced lifecycle policies, and remediation that is carried out or tracked to closure, not only reported. |
| Risk scoring, least privilege and threat detection |
15% |
Risk scores with visible factors, granted-versus-used permission analysis, and anomaly alerts that come with evidence and a clear next step. |
| AI agent identity governance |
10% |
Agent discovery in the platforms you use, a human sponsor for every agent, and generally available support for delegated authority, short-lived credentials and agent audit trails. |
| Integration and operations |
10% |
Works with your identity provider, cloud IAM, secrets managers, ticketing and SIEM; documented APIs; little manual effort to run day to day. |
| Platform security and data handling |
10% |
Read-only by default, minimal connector permissions, no stored secret values, and current certifications. |
| Implementation and support |
5% |
A credible phased plan, help with the initial cleanup, and clear SLAs and support targets. |
| Commercials and total cost |
10% |
A clear license metric, predictable true-up terms, a renewal cap and fair exit terms over a three-year view. |
| Total |
100% |
|
Scoring scale
- 5 Exceeds: meets every Must-have and most Nice-to-haves, shown in a demo or proof of concept, with a matching reference customer.
- 4 Strong: meets every Must-have and some Nice-to-haves, with clear evidence.
- 3 Adequate: meets most Must-haves; gaps have a credible workaround or a dated roadmap commitment.
- 2 Weak: misses one or more Must-haves, or the answer is vague.
- 1 Poor: does not meet the requirement, or no answer.
Frequently asked questions
What should a non-human identity RFP include?
Your scope (the cloud accounts, SaaS tenants, code repositories, CI/CD platforms, secrets managers and AI agent platforms to connect); requirements for discovery, ownership, risk scoring, remediation, least privilege, threat detection and lifecycle, marked Must-have or Nice-to-have; AI agent identity requirements; integration, security and data-handling requirements; support terms; a pricing table with a clear license metric; and the rubric you'll score with. This template includes all of them.
What is a non-human identity?
A non-human identity is an identity that software uses to authenticate, rather than a person: service accounts, service principals and managed identities, API keys, OAuth applications and tokens, certificates, workload identities and AI agents. Each one has credentials and permissions, and each needs an accountable owner. Non-human identity management means finding these identities, assigning owners, keeping their credentials and permissions under control, and detecting misuse.
How is AI agent identity different from other non-human identities?
AI agents use the same kinds of credentials as other non-human identities, such as API keys, OAuth tokens and service accounts. The difference is that an agent decides at run time which tools and data to use, and often acts on behalf of a person. That raises questions a service account inventory doesn't answer: who is accountable for the agent, whose authority it is using, and what it actually did. This template makes a named human sponsor a Must-have and treats delegated authority, task-scoped credentials and tool-level authorization as Nice-to-haves; ask vendors which of these are generally available today.
Is non-human identity management the same as secrets management?
No. A secrets manager stores credentials and supplies them to applications that are set up to use it. A non-human identity platform finds identities and credentials wherever they are, including secrets that were never put into a secrets manager, and shows who owns them, what they can reach and how risky they are. The two work together: this template asks the platform to rotate credentials through your existing secrets manager rather than replace it.
How long does a non-human identity RFP take?
The example schedule in this template runs about 12 weeks from kickoff to contract award, including three weeks for vendor responses and three to four weeks for a proof of value in your own environment. Allow more time if your security team needs to review each vendor's connector permissions before anything is connected.
Further reading
Related RFP templates
