Customer identity RFPs fail when they ask whether a platform "supports passkeys" or "scales to millions of users", because every bidder says yes and the differences only show up at the first peak event, the first credential stuffing wave or the first invoice after growth. This template gives you a ready-to-issue request for proposal for a customer identity and access management (CIAM) platform, with numbered requirements written so that answers can be tested in a proof of concept and scored. It covers scale and availability, passkeys and authentication, account recovery, consent and privacy, business customer (B2B) organisations, fraud and bot signals, delegated access for AI agents, platform security and pricing per monthly active user (MAU). It is vendor-neutral and written for CIAM product owners, security architects and procurement. For the market view, read the CIAM Buyer's Guide; for the selection process, the Security Vendor Evaluation and RFP Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [peak sign-ins per second] and [regions], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example CIAM-AU-02) and a type: M mandatory (pass or fail; a fail eliminates the bid), S scored (0 to 5, weighted) or I informational. Keep M items to the few that are truly non-negotiable.
- Weights, volumes and durations in brackets are illustrative. Set them from your own traffic, fraud losses and regulatory needs before issue, and do not change them after responses arrive.
- Issue sections 1 to 9 to bidders. The Implementation guidance section is for your evaluation panel only.
- Ask for responses in a spreadsheet with one row per requirement ID, and a documentation link for every "available now" answer.
1. Purpose and scope
[Organisation] invites proposals for a customer identity and access management platform and associated implementation services, to provide registration, authentication, account recovery, profile and consent management for [consumer / business customer / partner / citizen] audiences across [web, iOS, Android, contact centre, in-store].
- In scope: hosted or embedded sign-in; passkeys and multi-factor authentication; social and enterprise federation; account recovery; profile and consent; B2B organisation management; fraud and bot signals; APIs and SDKs; migration of [number] existing accounts.
- Out of scope: [workforce SSO]; [identity proofing service, procured separately]; [payment authentication].
- Drivers: [account takeover losses]; [conversion drop at sign-in]; [end of life of current platform]; [regulatory requirements such as PSD2 strong customer authentication or privacy law].
- Contract term: [three] years with an option to extend by [two].
2. Organisation background and current state
| Item | [Organisation] value |
|---|
| Registered customer accounts today and in three years | [number] / [number] |
| Monthly active users (MAU), average and peak month | [number] / [number] |
| Peak sign-ins per second and peak registrations per minute | [number], during [event, for example sale launch or ticket release] |
| Applications and channels to integrate | [number] web, [number] mobile, [contact centre platform], [APIs] |
| Current identity store and password hash format | [product or home-grown], [bcrypt / PBKDF2 / other] |
| Business customers and their users | [number] organisations, [number] users, [number] needing federation |
| Fraud, bot and analytics tools | [tools] |
| Data residency requirements | [regions where customer data must be stored and processed] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; answers shared with all bidders by [date]; responses due [date, time, time zone]; demonstrations and proof of concept [dates]; decision [date].
- Single point of contact: [name, email]. Other contact with [Organisation] staff about this RFP may lead to disqualification.
- Response scale: for each requirement state available now, available with configuration, requires custom code, third-party product required (name it), roadmap (committed date) or not supported. Roadmap answers score zero unless the date is contractual.
- Evidence: cite the product documentation page for each answer and state any plan or edition the feature requires.
4. Functional requirements
4.1 Authentication and passkeys
| ID | Type | Requirement |
|---|
| CIAM-AU-01 | M | Passkey (WebAuthn) registration and sign-in as a primary, passwordless method on web, iOS and Android, including synced passkeys and passkey autofill in the browser. |
| CIAM-AU-02 | S | Users can register more than one passkey and at least one other strong method; the platform prompts for a second method after first sign-in. |
| CIAM-AU-03 | S | Fallback methods (email or SMS one-time code, password) can be enabled per application and per risk level, and disabled entirely. |
| CIAM-AU-04 | S | Risk-based step-up for sensitive actions (payout change, address change, high-value order), configurable by policy and by API. |
| CIAM-AU-05 | S | Password policies follow NIST SP 800-63B-4: length over complexity, screening against breached-password lists, no stored hints and no security questions. |
| CIAM-AU-06 | S | Social login and enterprise federation with OpenID Connect and SAML 2.0, with account linking that requires proof of control of both accounts. |
4.2 Registration, recovery and profile
| ID | Type | Requirement |
|---|
| CIAM-RC-01 | M | Account recovery does not bypass enrolled MFA or passkeys (OWASP ASVS 5.0 V6.4.3), and supports stronger re-verification for high-value accounts. |
| CIAM-RC-02 | S | Full re-authentication before changes to email, phone, MFA or recovery data (ASVS V7.5.1), with notification to every known channel and an optional cooling-off period. |
| CIAM-RC-03 | S | Option to terminate all sessions and refresh tokens after a factor change or recovery (ASVS V7.4.3). |
| CIAM-RC-04 | S | Progressive profiling and verified contact attributes, with a hook to call [identity proofing provider] when required. |
| CIAM-RC-05 | S | Support and contact centre staff cannot change recovery details without a verification step recorded in the audit log. |
4.3 Consent and privacy
| ID | Type | Requirement |
|---|
| CIAM-CP-01 | M | Granular consent capture per purpose, with version, timestamp, channel and the text shown, retained and exportable as evidence. |
| CIAM-CP-02 | S | Self-service preference centre and withdrawal of consent with downstream propagation by event or webhook. |
| CIAM-CP-03 | S | Data subject request support: export of a user's profile, consents and activity; erasure with documented retention exceptions. |
| CIAM-CP-04 | M | Customer data stored and processed only in [regions], including backups, logs and support access. |
4.4 B2B organisations
| ID | Type | Requirement |
|---|
| CIAM-BB-01 | S | Organisation entities with members, roles and invitations, and customer-appointed administrators who manage only their own organisation. |
| CIAM-BB-02 | S | Per-organisation federation with the customer's identity provider (OIDC and SAML), configurable by the customer administrator with guardrails. |
| CIAM-BB-03 | S | Inbound SCIM 2.0 (RFC 7644) provisioning per organisation, and organisation context in issued tokens. |
See the B2B CIAM and Organisation Management Guide for design detail.
4.5 Fraud, bot and account takeover signals
| ID | Type | Requirement |
|---|
| CIAM-FR-01 | M | Controls against credential stuffing and password spraying (ATT&CK T1110.004, T1110.003; ASVS V6.3.1): rate limiting by account, IP and device, bot detection and breached-credential detection. |
| CIAM-FR-02 | S | Risk signals (device, network reputation, impossible travel, velocity) available to policies and exported with each event. |
| CIAM-FR-03 | S | Integration with [fraud platform] to send events and receive decisions in the sign-in and registration flow, within [latency] ms. |
| CIAM-FR-04 | S | Detection of fake account creation at scale, including disposable email and SMS pumping protection on one-time code delivery. |
4.6 Delegated and agent access
| ID | Type | Requirement |
|---|
| CIAM-AG-01 | S | OAuth 2.0 delegated access for third-party applications and AI agents acting for a customer, with scoped, short-lived tokens and a consent screen that names the client. |
| CIAM-AG-02 | S | Customers can see and revoke every application or agent with access to their account. |
| CIAM-AG-03 | I | Describe support for proxy access (carers, family members) and for distinguishing agent traffic from user traffic. |
See the Agentic Commerce Identity Guide and Delegated and Proxy Access in CIAM.
| ID | Type | Requirement |
|---|
| CIAM-SC-01 | M | Sustain [peak sign-ins per second] for a single tenant for [duration] with p95 latency under [ms], demonstrated in the proof of concept load test. |
| CIAM-SC-02 | M | Contractual monthly availability of at least [99.95%] for authentication endpoints, with service credits and published status history. |
| CIAM-SC-03 | S | Documented rate limits per endpoint, behaviour when limits are reached, and process to raise them before planned events. |
| CIAM-SC-04 | S | Multi-region deployment and failover within [regions], with stated recovery time and recovery point objectives. |
| CIAM-SC-05 | S | Degradation modes: what continues to work (token validation, existing sessions) if the platform's management plane or a dependency is down. |
| ID | Type | Requirement |
|---|
| CIAM-PS-01 | M | Independent assurance: [ISO/IEC 27001 certificate and SOC 2 Type II report], plus a summary of the latest third-party penetration test. |
| CIAM-PS-02 | S | Token signing keys protected in hardware security modules or equivalent, with customer-triggered rotation and an emergency revoke-all procedure. |
| CIAM-PS-03 | S | Vendor support staff access to the tenant requires customer approval, is time-bound and logged. |
| CIAM-PS-04 | S | Tenant administrators use phishing-resistant MFA; admin roles are granular; management API credentials can be scoped and rotated. |
| CIAM-PS-05 | S | Complete event logs (sign-in, registration, recovery, admin, consent) streamed to [SIEM] in near real time and retained for [days]. |
| CIAM-PS-06 | S | OAuth and OIDC implementation follows current best practice: PKCE for public clients, exact redirect URI matching, refresh token rotation. |
7. Migration, implementation and support
- CIAM-MI-01 (S): bulk import of existing users with password hashes in [format], or just-in-time migration at next sign-in, without forcing a password reset.
- CIAM-MI-02 (S): a passkey enrolment campaign plan and the tooling to prompt existing users.
- CIAM-MI-03 (S): implementation plan, roles, and named staff with CIAM delivery experience; [number] customer references of similar scale.
- CIAM-MI-04 (S): support tiers, severity definitions and response times, including weekend cover for peak events.
- CIAM-MI-05 (M): exit: full export of users, hashes, consents and organisation data in a documented format at no extra charge.
8. Commercials
| Cost element | What to state |
|---|
| Pricing metric | Definition of a monthly active user, how B2B users, machine clients and AI agent tokens are counted, and overage pricing |
| Tiers and add-ons | Which requirements need a higher edition or add-on (for example B2B, fraud signals, enterprise federation) |
| Usage charges | SMS, email, voice and any per-verification costs |
| Growth model | Total cost at [current], [2x] and [5x] MAU over the term; cap on renewal increases |
| Services | Implementation and migration price, day rates and estimated days |
9. Evaluation method and proof of concept
[Organisation] will check mandatory items first, then score the rest with these illustrative weights:
| Criterion | Weight | Evidence |
|---|
| Authentication, recovery and user experience (4.1, 4.2) | [25%] | Demonstration, proof of concept, conversion test |
| Fraud and account takeover defence (4.5) | [15%] | Simulated attack results |
| Scale and availability (5) | [15%] | Load test, availability history |
| Consent, privacy, B2B and agent access (4.3, 4.4, 4.6) | [15%] | Response, demonstration |
| Platform security and integration (6) | [10%] | Assurance reports, questionnaire |
| Three-year cost at growth scenarios (8) | [20%] | Pricing schedule |
Scores: 0 not met; 1 roadmap only; 3 met with configuration; 5 met and demonstrated. Shortlisted bidders run a proof of concept of [number] weeks:
- Build registration, passkey sign-in, step-up for a payout change, recovery and profile update on one web and one mobile app.
- Load test at [peak] sign-ins per second for [duration] and record latency and errors.
- Run an authorised credential stuffing simulation with [number] breached credential pairs and measure blocks and false positives.
- Create two B2B organisations, federate one with a test identity provider and provision users by SCIM.
- Grant and revoke delegated access for a test agent client; confirm the customer can see it.
- Export logs, consent records and all user data, and import a sample of existing password hashes.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Use your own peak: take the highest sign-in rate of the last two years and add growth. Average traffic tells you nothing about the event that breaks the platform.
- Model price at scale: the cheapest bid at today's MAU is often the most expensive at 3x. Make bidders complete the growth table and check how inactive and B2B users are counted.
- Test recovery as hard as sign-in: recovery is where account takeover happens. See the Account Takeover Prevention Guide and Security Questions and KBA.
- Involve privacy and legal early: consent evidence and residency answers are often decisive.
- Control proof of concept credentials: issue time-limited management API credentials to bidders, never real customer data, and revoke them all at the end.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | OWASP ASVS 5.0 |
|---|
| Authentication (4.1) | IA-2, IA-5, IA-8 | PR.AA-03 | V6 |
| Recovery and profile (4.2) | IA-5, IA-11 | PR.AA-01 | V6.4.3, V6.4.4, V7.4.3, V7.5.1 |
| Consent (4.3) | PT-4 | PR.DS-01 | V14 (data protection) |
| Fraud and bots (4.5) | AC-7, SI-4 | DE.CM-03 | V6.3.1 |
| Supplier assurance (6) | SA-9 | GV.SC-05, GV.SC-06 | V10 (OAuth and OIDC), V16 (logging) |
Standards and references
Related NHI Mgmt Group resources: CIAM Buyer's Guide · Customer IAM (CIAM) Guide · Passwordless and Passkeys Guide · Identity Fraud Prevention Guide · Workforce SSO and Access Management RFP Template