Most requests for proposal for non-human identity security ask whether a platform "discovers service accounts" and get a yes from every bidder, which tells the panel nothing about coverage, accuracy or whether anything gets fixed. This template is a ready-to-issue RFP for an NHI security platform, with numbered requirements that can each be verified in a proof of concept and scored. It covers discovery and inventory, ownership, posture and risk, secret exposure, rotation and remediation, offboarding, third-party and OAuth integrations, AI agents, identity threat detection and response for machine identities, the security of the platform itself, services and commercials. It is vendor-neutral and written for IAM, cloud security and NHI programme leads, procurement and evaluation panels. For how the market is shaped, read the NHI Security Platform Buyer's Guide; for the selection process itself, the Security Vendor Evaluation and RFP Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [cloud providers] and [number], with your own details. Delete requirements that do not apply to your estate.
- Each requirement has an ID (for example NHI-DSC-02) and a type: M mandatory (pass or fail, a single fail excludes the bid), S scored (0 to 5, weighted) or I informational (not scored, used for planning).
- Weights, volumes and timings in brackets are illustrative, not benchmarks. Set them from your own risk and scale before issue and do not change them after responses arrive.
- Issue sections 1 to 8 to bidders. The Implementation guidance section is for your panel only.
- If you are also buying PAM, secrets management or ITDR, align requirement IDs with the PAM RFP Template, the Secrets Management RFP Template and the ITDR RFP Template so that overlapping capability is evaluated once and its owner is decided.
1. Purpose and scope
[Organisation] invites proposals for a non-human identity security platform and implementation services. The platform must give [Organisation] a continuously updated inventory of machine identities and their credentials, an accountable owner for each, a prioritised view of risk, and the means to remediate, rotate, decommission and detect misuse of those identities across the environments listed below.
- Identities in scope: service accounts (directory and local); cloud IAM users, roles, service principals, managed identities and service accounts in [cloud providers]; Kubernetes service accounts; API keys and personal access tokens; OAuth applications and grants in [SaaS platforms]; certificates and SSH keys used by workloads; CI/CD and automation identities; AI agents and MCP server credentials.
- Environments in scope: [identity providers]; [cloud accounts, subscriptions and projects]; [SaaS applications]; [code repositories and CI/CD platforms]; [secrets managers and vaults]; [on-premises directories and servers].
- Out of scope: [workforce human identity governance, already covered by IGA]; [customer identity]; [storing secret values, if an existing secrets manager remains the vault of record].
- Drivers: [unknown count of machine identities]; [audit findings on shared or ownerless service accounts]; [leaked credentials in code]; [third-party OAuth integration incidents in the sector]; [AI agent adoption].
- Contract term: [three] years with an option to extend by [two] years.
2. Organisation background and current state
| Item | [Organisation] value |
|---|---|
| Cloud estate | [providers]; [number] accounts, subscriptions or projects; [number] Kubernetes clusters |
| Identity providers and directories | [for example, Entra ID, Okta, on-premises Active Directory]; [number] domains |
| SaaS applications with admin or integration access | [number]; priority list: [CRM, collaboration, ticketing, code hosting] |
| Code and pipelines | [platforms]; [number] repositories; [number] pipelines |
| Known machine identities | [number, or "unknown, discovery required"]; estimated ratio to human identities [ratio] |
| Secrets managers in use | [products and number of instances] |
| Existing tooling to integrate | [IGA, PAM, SIEM, SOAR, ticketing, CMDB, CNAPP] |
| AI agents and MCP servers | [known deployments, platforms, or "discovery required"] |
| Hosting and data constraints | [SaaS acceptable; data residency region; metadata only or secret values permitted] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; responses due [date, time, time zone]; demonstrations [dates]; proof of concept [dates]; decision [date].
- Single point of contact: [name, email]. Contact with other [Organisation] staff about this RFP may lead to disqualification.
- Response scale: for each requirement state one of: available now; available with configuration; custom development; third-party product required (name it); roadmap (committed date); not supported. Roadmap answers score zero unless the date is written into the contract.
- Connector evidence: for every environment in section 2, state whether the connector is generally available, in preview or planned, and link the product documentation for it.
- Architecture: include a diagram showing every connection the platform makes into [Organisation] environments, the permissions each connector requires, and where collected data is stored and processed.
- Demonstration script: bidders shortlisted for demonstration will be asked to run the scenarios in section 8 live, on their own test data, before the proof of concept.
4. Functional requirements
4.1 Discovery and inventory
| ID | Requirement | Type |
|---|---|---|
| NHI-DSC-01 | Discovers the identity types in section 1 across every environment in section 2 using read-only connectors, on a schedule of [daily or better] and on demand. | M |
| NHI-DSC-02 | Correlates the same identity and its credentials across systems (for example, a secret found in a repository to the cloud role it grants and the workloads that use it) and shows the chain. | S |
| NHI-DSC-03 | Records for each identity: type, location, credential type, creation date, credential age, last authentication or last use, permissions granted and permissions used. | M |
| NHI-DSC-04 | Detects new machine identities and credentials created outside approved provisioning within [hours] and raises a finding. | S |
| NHI-DSC-05 | Exports the full inventory through an API and in bulk to [CMDB or data lake]. | M |
See the NHI Discovery Guide and the NHI Inventory Reconciliation guide.
4.2 Ownership and accountability
| ID | Requirement | Type |
|---|---|---|
| NHI-OWN-01 | Assigns an accountable human owner and a business service to each identity; suggests owners from evidence (creator, repository committers, cloud tags, application registration) and shows the evidence. | M |
| NHI-OWN-02 | Runs ownership attestation campaigns with reminders, escalation and an outcome for unattested identities (flag, disable after [days], or ticket). | S |
| NHI-OWN-03 | Reassigns ownership automatically when the owner leaves, using [HR system or IdP] leaver events. | S |
| NHI-OWN-04 | Reports the percentage of identities with a confirmed owner, per environment and business unit. | S |
See the NHI Ownership Guide.
4.3 Posture and risk
| ID | Requirement | Type |
|---|---|---|
| NHI-POS-01 | Identifies over-privileged identities by comparing granted with used permissions over a configurable window of [90] days, and proposes a reduced policy. | S |
| NHI-POS-02 | Flags long-lived and unrotated credentials against [Organisation] policy thresholds per credential type. | M |
| NHI-POS-03 | Flags identities used by humans interactively, identities reused across applications or environments, and production identities reachable from non-production. | S |
| NHI-POS-04 | Scores risk using privilege, exposure, staleness and data sensitivity, explains each score, and maps findings to the OWASP Non-Human Identities Top 10 (2025). | S |
| NHI-POS-05 | Detects secrets in code, pipeline logs, container images and [collaboration tools], validates whether each is live, and links it to its identity. | S |
See the NHI Risk Scoring Guide and the Top 10 NHI Risks.
4.4 Rotation and remediation
| ID | Requirement | Type |
|---|---|---|
| NHI-REM-01 | Rotates credentials through [secrets managers] or native provider APIs, on schedule and on demand, and verifies the consuming workload still authenticates afterwards. | S |
| NHI-REM-02 | Recommends and, where supported, applies replacement of static secrets with short-lived or federated credentials (cloud workload identity federation, SPIFFE SVIDs, OAuth client credentials with short token lifetimes). | S |
| NHI-REM-03 | States, per remediation type, whether it is automated, guided (one-click with approval) or advisory only; automated actions require approval rules set by [Organisation]. | M |
| NHI-REM-04 | Creates and tracks remediation tickets in [ticketing system] routed to the identity owner, and closes them only when the platform observes the fix. | S |
| NHI-REM-05 | Every automated change is logged with before and after state and can be rolled back. | M |
See the NHI lifecycle automation guide and the Cloud Workload Identity Guide.
4.5 Offboarding and decommissioning
| ID | Requirement | Type |
|---|---|---|
| NHI-OFF-01 | Identifies dormant identities (no use for [90] days) and orphaned identities (no owner, owner departed, or application retired). | M |
| NHI-OFF-02 | Supports staged decommissioning: disable, observe for [days] with alerting on attempted use, then delete and revoke all credentials, with rollback during the observation window. | S |
| NHI-OFF-03 | Triggers review of all identities and grants linked to a vendor, application or project when it is retired. | S |
See the NHI Offboarding and Decommissioning Guide.
4.6 Third-party integrations and AI agents
| ID | Requirement | Type |
|---|---|---|
| NHI-3PT-01 | Inventories OAuth applications, grants and SaaS-to-SaaS integrations in [SaaS platforms] with publisher, scopes, consenting user, token type and last use. | M |
| NHI-3PT-02 | Flags high-risk scopes, unverified publishers, unused grants and integrations whose vendor has disclosed a breach, and supports revocation. | S |
| NHI-AIA-01 | Discovers AI agents, AI service API keys and MCP servers in [platforms], links each agent to the credentials and permissions it uses, and assigns an owner. | S |
| NHI-AIA-02 | Distinguishes actions an agent takes on its own identity from actions taken on behalf of a user, where the source logs allow. | I |
The 2025 Salesloft Drift breach showed why NHI-3PT-01 and NHI-3PT-02 matter: stolen OAuth tokens from one integration opened customer Salesforce data across many organisations. See the SaaS Integration Security Questionnaire Template and the AI Agent Identity Security Buyer's Guide.
4.7 Threat detection and response for machine identities
| ID | Requirement | Type |
|---|---|---|
| NHI-TDR-01 | Baselines each identity's normal behaviour (source networks, user agents, APIs called, times, volumes) and alerts on deviation, for example use of a credential from a new network or a token replayed from an unexpected location. | S |
| NHI-TDR-02 | Detects patterns aligned to MITRE ATT&CK techniques including T1528 Steal Application Access Token, T1550.001 Application Access Token, T1078.004 Cloud Accounts and T1552 Unsecured Credentials; state which detections ship by default. | S |
| NHI-TDR-03 | Streams findings and alerts to [SIEM] and supports response actions (disable, revoke, rotate) from [SOAR] or the platform, with approval. | M |
| NHI-TDR-04 | Supports investigation: timeline of an identity's activity, related identities and the blast radius of its permissions. | S |
See the ITDR Guide and the Honeytokens and Canary Credentials Guide.
5. Security of the NHI platform
An NHI platform holds read access to every environment and often the ability to rotate or revoke credentials, so its own security is scored as heavily as its features.
| ID | Requirement | Type |
|---|---|---|
| NHI-SEC-01 | Connectors use the least privilege needed, documented per connector; read-only by default, with write permissions separated and enabled only for remediation features [Organisation] turns on. | M |
| NHI-SEC-02 | State whether the platform stores secret values, hashes or metadata only. Where secret values are processed for validation, describe where, for how long and how they are protected. | M |
| NHI-SEC-03 | Connectors authenticate with federated or short-lived credentials where the target supports it; list every credential the platform holds for [Organisation] systems and how each is rotated and revoked. | M |
| NHI-SEC-04 | Platform administrators authenticate through [Organisation] SSO with phishing-resistant MFA; roles are granular; all administrative actions are logged and exportable. | M |
| NHI-SEC-05 | Bidder staff have no standing access to customer data; describe support access, approval and logging, and data residency options. | M |
| NHI-SEC-06 | Provide a current independent assurance report, a [SIG or CAIQ] response, a published vulnerability disclosure policy and security incident history for the last three years. | M |
| NHI-NF-01 | Full export of inventory, findings, ownership records and audit history at exit, and certified deletion within [days]. | M |
6. Implementation, services and support
- Phasing: propose phases with acceptance criteria, for example [cloud and identity providers first, then code and pipelines, then SaaS integrations, then on-premises and AI agents].
- Ownership bootstrap: describe how the first owner assignment campaign is run at scale and what owner coverage similar customers reached in [90] days.
- Remediation safety: describe how rotation and decommissioning are introduced without outages: dependency evidence, test rotation, staged disable, rollback.
- Team and references: named roles, and [two or three] references of similar size and cloud mix, at least one using automated remediation in production.
- Support: support tiers, severity definitions and targets, release cadence, and notice of connector changes.
7. Commercials
| Cost element | What to state |
|---|---|
| Licence metric | Per identity, per human employee, per cloud account, per connector or other; how discovered identities beyond the estimate are charged |
| Modules | Which section 4 requirements need separate modules (secret detection, ITDR, AI agents, remediation) |
| Implementation and training | Fixed price or day rate with estimated days by phase |
| Growth and renewal | Price for [growth percentage] more identities; renewal price cap |
| Exit | Export format, assistance and any charges |
8. Evaluation method, demonstration and proof of concept
| Criterion | Weight | Evidence |
|---|---|---|
| Coverage and accuracy (4.1, 4.6) | [25%] | Connector evidence, proof of concept against a seeded estate |
| Ownership, posture and remediation (4.2 to 4.5) | [25%] | Demonstration, proof of concept |
| Threat detection and response (4.7) | [10%] | Proof of concept scenarios, SIEM integration |
| Platform security (5) | [15%] | Assurance reports, architecture and permission review |
| Implementation approach and references (6) | [10%] | Section 6, reference calls |
| Life-cycle cost (7) | [15%] | Three-year cost at expected identity growth |
Scored requirements use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration or partly demonstrated; 5 met fully and demonstrated. A mandatory requirement not met excludes the bid. The proof of concept of [number] weeks will run on [named test accounts or a production read-only scope] and cover at minimum:
- Seeded discovery: [Organisation] plants a known set of identities (an unused cloud role, an ownerless service principal, a live test key in a repository, an over-scoped OAuth grant, an AI agent key). Measure what was found, what was missed and false positives.
- Correlation: trace the planted repository secret to the identity and permissions it grants.
- Ownership: run a small attestation campaign with [number] real owners and measure response.
- Remediation: rotate one credential with a dependent workload and decommission one dormant identity in stages, including a rollback.
- Detection: use a test credential from an unexpected network and confirm an alert reaches [SIEM] within [minutes].
- Platform permissions: review the exact permissions each connector was granted against NHI-SEC-01.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Seed the test estate: vendor demonstrations use curated data. The planted identities in the proof of concept are the only reliable measure of discovery accuracy, so record them before the proof of concept starts and do not share the list.
- Weight remediation, not dashboards: a platform that finds 50,000 identities but cannot assign owners or fix anything creates a backlog. Weight NHI-OWN and NHI-REM by what your team can absorb.
- Decide the system of record: agree in advance whether the NHI platform, the secrets manager, IGA or the CMDB owns the identity record, so that NHI-DSC-05 and NHI-REM-01 do not create competing sources of truth. See the Secrets Management Buyer's Guide.
- Control proof-of-concept access: connectors granted during the proof of concept are themselves non-human identities. Create them with expiry, record them and revoke them at the end, including for unsuccessful bidders.
- Benchmark maturity: score where you are today so that weights reflect your next step, not an idealised end state. See the NHI Governance Maturity Model.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | OWASP NHI Top 10 (2025) |
|---|---|---|---|---|
| Discovery and ownership (4.1, 4.2) | AC-2 | PR.AA-01 | A.5.16 Identity management | NHI1, NHI10 |
| Posture and least privilege (4.3) | AC-6, IA-9 | PR.AA-05 | A.5.18 Access rights | NHI5, NHI8, NHI9 |
| Credentials and rotation (4.3, 4.4) | IA-5 | PR.AA-01 | A.5.17 Authentication information | NHI2, NHI4, NHI7 |
| Offboarding (4.5) | AC-2(3) | PR.AA-05 | A.5.18 Access rights | NHI1 |
| Third-party integrations (4.6) | SA-9 | GV.SC-07 | A.5.19 Information security in supplier relationships | NHI3 |
| Detection and response (4.7) | AU-6, SI-4 | DE.CM-09 | A.8.16 Monitoring activities | NHI2, NHI3 |
| Platform security (5) | SR-6 | GV.SC-07 | A.5.21 Managing information security in the ICT supply chain | NHI6 |
Standards and references
- OWASP: Non-Human Identities Top 10 (2025)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-161 Rev. 1 Cybersecurity Supply Chain Risk Management Practices
- SPIFFE: Overview
- MITRE ATT&CK: Steal Application Access Token
Related NHI Mgmt Group resources: NHI Security Platform Buyer's Guide · Non-Human Identity (NHI) Guide · PAM RFP Template · Secrets Management RFP Template · Security Vendor Evaluation and RFP Guide