Workforce SSO procurements often fail because the RFP asks "do you support SAML, MFA and conditional access?", every identity provider answers yes, and the gaps in phishing-resistant enrolment, connector depth and admin separation only surface during rollout. This template is a ready-to-issue request for proposal for a workforce single sign-on and access management platform (often called an identity provider or IdP). It covers federation protocols, MFA and passkeys, conditional access, lifecycle connectors, the administrative model, platform security, services and commercials, with mandatory and scored criteria, a weighted scoring model and a proof of concept plan. It is vendor-neutral and written for IAM leads, security architects, procurement and evaluation panels. For the selection process itself, read the Security Vendor Evaluation and RFP Guide; for hardening the platform you choose, the Identity Provider and SSO Security Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [number] and [HR system], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example SSO-FED-02) and a type: M mandatory (pass or fail; a fail eliminates the bid), S scored (0 to 5, weighted) or I informational (not scored). Keep mandatory items to the few you would genuinely walk away over.
- Weights, volumes and timings in brackets are illustrative. Set them from your own risk, scale and audit findings before issue, and do not change them once responses arrive.
- Issue sections 1 to 8 to bidders. The Implementation guidance section is for your panel only.
- Ask for responses in a spreadsheet, one row per requirement ID, with an "evidence" column pointing to documentation, so answers compare line by line.
1. Purpose and scope
[Organisation] invites proposals for a workforce identity and access management platform providing single sign-on, multi-factor and passwordless authentication, policy-based access decisions and lifecycle provisioning for employees, contractors and partners, plus associated implementation services.
- In scope: federation to [number] SaaS and internal applications; MFA and passkeys; conditional or risk-based access; directory and HR integration; SCIM and API provisioning; self-service password and authenticator recovery; administrative delegation; audit logging and SIEM integration.
- Out of scope: [customer identity (CIAM)]; [full identity governance, certifications and SoD, covered by a separate IGA procurement]; [privileged session management].
- Contract term: [three] years with an option to extend by [two] years.
- Drivers: [phishing-resistant MFA mandate]; [consolidation of multiple identity providers]; [leaver access audit findings]; [cyber insurance requirements]; [zero trust programme].
2. Organisation background and current state
| Item | [Organisation] value |
|---|---|
| Identities (employees, contractors, partners, frontline or shared-device users) | [number], [number], [number], [number] |
| Authoritative sources | [HR system], [contractor system] |
| Current directories and identity providers | [on-premises directory], [existing cloud IdP], [legacy web access management] |
| Applications by integration type | [number] SAML 2.0; [number] OpenID Connect; [number] header-based or legacy; [number] with SCIM; [number] with no federation support |
| Authenticators in use today | [passwords, SMS, OTP apps, push, smart cards, security keys] |
| Device estate and management | [Windows, macOS, iOS, Android, Linux counts; MDM or UEM tooling] |
| Regulatory and assurance drivers | [NIST SP 800-63-4 AAL targets, PCI DSS, DORA, ISO/IEC 27001] |
| Hosting and data residency | [SaaS in named regions / hybrid components acceptable] |
3. Instructions to bidders
- Timetable: clarification questions by [date]; responses by [date]; shortlist demonstrations [week]; proof of concept [weeks]; award [date].
- Format: the requirements spreadsheet plus a narrative of no more than [30] pages. Answer each requirement as Yes (generally available today), Roadmap (with date), Partner (named third party) or No. Configuration or custom code must be stated.
- Evidence: link public product documentation for every Yes. Claims that cannot be shown in documentation or the proof of concept score 0.
- Assurance documents: current ISO/IEC 27001 certificate and Statement of Applicability, SOC 2 Type II report or equivalent, penetration test summary, sub-processor list.
4. Functional requirements
4.1 Federation and SSO protocols
| ID | Type | Requirement |
|---|---|---|
| SSO-FED-01 | M | Act as SAML 2.0 identity provider (OASIS Standard) with per-application signing certificates, SHA-256 signatures, signed assertions and optional assertion encryption. |
| SSO-FED-02 | M | Act as OpenID Connect provider conforming to OpenID Connect Core 1.0, supporting the authorization code flow with PKCE (S256) for all client types, in line with RFC 9700. Describe how the implicit flow and resource owner password credentials grant can be disabled tenant-wide. |
| SSO-FED-03 | S | Emit authentication context in assertions and ID tokens (SAML AuthnContext, OIDC acr and amr), so applications can require a phishing-resistant method for sensitive actions. |
| SSO-FED-04 | S | Describe which NIST SP 800-63C-4 federation assurance level (FAL1, FAL2, FAL3) each integration pattern can meet, including protection against assertion injection and support for holder-of-key or bound-authenticator assertions. |
| SSO-FED-05 | S | Inbound federation from partner identity providers, with attribute mapping and per-partner policy. |
| SSO-FED-06 | S | Support for legacy applications: header-based, Kerberos or reverse proxy integration. State whether an on-premises component is required. |
| SSO-FED-07 | S | Single logout and session revocation: describe front-channel, back-channel and token revocation behaviour, and maximum time from revocation to session end in a federated app. |
| SSO-FED-08 | I | Size and maintenance of the pre-integrated application catalogue, and the process for adding an application not in it. |
4.2 MFA, passkeys and authenticator lifecycle
| ID | Type | Requirement |
|---|---|---|
| SSO-MFA-01 | M | Support FIDO2/WebAuthn passkeys, both device-bound (security keys, platform authenticators) and synced, with policy to restrict by authenticator type or AAGUID. |
| SSO-MFA-02 | M | Enforce phishing-resistant authentication per application and per group. Policies must be able to meet NIST SP 800-63B-4 AAL3 for named populations, which excludes syncable authenticators. |
| SSO-MFA-03 | S | Support smart card or certificate-based authentication (for example PIV or CAC) where [Organisation] uses it. |
| SSO-MFA-04 | S | Phishing-resistant onboarding: describe how a new joiner obtains a first strong authenticator without a password or SMS code (temporary access pass, verified identity proofing, in-person issuance). |
| SSO-MFA-05 | S | Authenticator recovery: describe help desk and self-service recovery flows, the identity verification used, and controls against social engineering of support staff. |
| SSO-MFA-06 | S | Ability to disable weaker methods (SMS, voice, email OTP, push without number matching) per population, with reporting on who still uses them. |
| SSO-MFA-07 | S | Configurable reauthentication and session lifetimes, for example 12 hours overall and 15 minutes inactivity for AAL3 populations as described in SP 800-63B-4. |
See the NIST SP 800-63B-4 Authenticator Assurance Levels Guide and the MFA Fatigue and Bypass Guide.
4.3 Conditional access and session security
| ID | Type | Requirement |
|---|---|---|
| SSO-CA-01 | M | Policy engine evaluating user, group, application, device compliance, network location and risk, with block, require-MFA, require-phishing-resistant and session-limit outcomes. |
| SSO-CA-02 | M | Report-only or simulation mode, and a "what if" tool showing which policies apply to a given sign-in. |
| SSO-CA-03 | S | Device trust signals from [UEM or EDR tools], and device-bound session or token protection to reduce replay of stolen session cookies. |
| SSO-CA-04 | S | Transmit and receive Shared Signals events, including OpenID CAEP 1.0 events such as session-revoked, credential-change and device-compliance-change. |
| SSO-CA-05 | S | Built-in detection of impossible travel, password spraying, anomalous token use and MFA fatigue, with automated response. |
See the Conditional Access Guide.
4.4 Directory, lifecycle and provisioning connectors
| ID | Type | Requirement |
|---|---|---|
| SSO-LC-01 | M | Inbound provisioning from [HR system] driving joiner, mover and leaver events, with attribute transformation and a preview of changes. |
| SSO-LC-02 | M | Outbound provisioning as a SCIM 2.0 client (RFC 7643, RFC 7644) including PATCH and group push, plus deprovisioning that disables accounts and revokes sessions within [15] minutes of a leaver event. |
| SSO-LC-03 | S | Synchronisation with [on-premises directory], including the number and location of agents, their privileges and how they are updated. |
| SSO-LC-04 | S | Reconciliation reporting: accounts in applications with no matching identity, and identities with access not granted through the platform. |
| SSO-LC-05 | S | Basic access requests and time-bound group membership, with integration to [IGA or ticketing system]. |
| SSO-LC-06 | I | Roadmap and conformance for the OpenID IPSIE profiles (SSO, lifecycle, entitlements, risk signals, logout, token revocation). |
See the Joiner-Mover-Leaver Guide.
4.5 Administrative model and non-human identities
| ID | Type | Requirement |
|---|---|---|
| SSO-ADM-01 | M | Granular built-in and custom administrative roles, with delegation scoped to groups, applications or business units. |
| SSO-ADM-02 | M | Phishing-resistant authentication enforceable for all administrators, plus just-in-time elevation with approval and expiry. |
| SSO-ADM-03 | S | Protection of federation trust: alerting on new or changed identity provider trusts, signing certificates and federation settings. |
| SSO-ADM-04 | S | Inventory of API tokens, service accounts, OAuth client credentials and workload identities created in or trusted by the tenant, with owner, scope, last use and expiry. |
| SSO-ADM-05 | S | Configuration as code: export, version and promote configuration between tenants via API or infrastructure-as-code tooling. |
Administrative and machine credentials in the identity provider are a prime target. See the Golden SAML and Federation Trust Abuse Defence Guide and the Identity Provider Tenant Compromise Playbook.
5. Platform security and non-functional requirements
| ID | Type | Requirement |
|---|---|---|
| SSO-NF-01 | M | Availability commitment of at least [99.99]% with service credits, published status page and documented regional failover. |
| SSO-NF-02 | M | All administrative and authentication events retained for at least [90] days in the product and streamable to [SIEM] in near real time. |
| SSO-NF-03 | S | Signing key management: key storage, rotation, customer-managed keys where offered. |
| SSO-NF-04 | S | Data residency for identity data and logs in [regions], and the sub-processor list. |
| SSO-NF-05 | S | Break-glass access to the tenant when federation, MFA or the vendor's own authentication is unavailable. |
| SSO-NF-06 | S | Vulnerability disclosure, customer notification time for security incidents affecting the tenant, and history of such notifications in the last [three] years. |
6. Implementation, services and support
- SSO-SV-01 (S): implementation plan by phase, named roles and the effort [Organisation] must supply.
- SSO-SV-02 (S): migration approach from [existing IdP], including bulk application migration tools and coexistence.
- SSO-SV-03 (S): support tiers, severity definitions and response times, and access to security engineering during incidents.
- SSO-SV-04 (I): three customer references of similar size and sector.
7. Commercials
- SSO-CM-01 (M): price per licence metric for years 1 to [5], with caps on annual increases.
- SSO-CM-02 (S): state which requirements in section 4 need a higher edition or add-on. Security features such as phishing-resistant MFA, SSO for all applications and audit log export should not sit behind a premium tier without being priced here.
- SSO-CM-03 (S): exit terms: configuration and log export formats, transition assistance and data deletion certificate.
8. Evaluation method and proof of concept
Responses failing any M requirement are excluded. Scored items are marked 0 (absent) to 5 (fully met, generally available, shown in the PoC), multiplied by section weight.
| Section | Illustrative weight |
|---|---|
| 4.1 Federation and SSO | [20]% |
| 4.2 MFA and passkeys | [20]% |
| 4.3 Conditional access | [15]% |
| 4.4 Lifecycle and provisioning | [15]% |
| 4.5 Admin model and NHIs | [10]% |
| 5 Platform security | [10]% |
| 6 and 7 Services and commercials | [10]% |
The proof of concept runs for [three] weeks per shortlisted bidder in a non-production tenant:
- Federate [one SAML app, one OIDC app, one legacy app] and show
acror AuthnContext reaching the application. - Enrol a new joiner end to end from [HR system] to a passkey with no password or SMS step.
- Enforce phishing-resistant MFA for an admin group and show the policy blocks an OTP or push attempt.
- Run a conditional access policy in report-only mode for a pilot group, then enforce it, then roll it back.
- Trigger a leaver event and time account disablement and session revocation in two SCIM-connected applications.
- Recover a lost authenticator via the help desk flow and show what evidence the agent sees.
- Stream logs to [SIEM] and confirm sign-in, policy decision and admin change events arrive with the fields needed for detection.
Implementation guidance
- Keep mandatory items few. Five to eight M items is typical; every extra one narrows the field without telling you who is better.
- Score demonstrations, not answers. Any score of 4 or 5 should be confirmed in the PoC or a documentation link.
- Watch edition creep. Map every requirement to an edition before comparing prices, because the cheapest headline price often excludes conditional access, lifecycle or log export.
- Small organisations can merge sections 4.3 and 4.5, drop legacy integration and weight commercials higher. Large or regulated organisations should keep FAL and AAL requirements explicit and add a separate IGA procurement for certifications.
- Plan the measures now. After award, track: share of applications behind SSO, share of users with a phishing-resistant authenticator, share of sign-ins using one, leaver-to-revocation time and number of standing admin roles.
| Requirement area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Federation and MFA | IA-2, IA-2(1), IA-8 | PR.AA-03 | 8.5 Secure authentication |
| Authenticator lifecycle | IA-5 | PR.AA-01 | 5.17 Authentication information |
| Lifecycle and provisioning | AC-2 | PR.AA-01, PR.AA-05 | 5.16 Identity management, 5.18 Access rights |
| Sessions and revocation | AC-12 | PR.AA-03 | 8.5 Secure authentication |
| Logging | AU-2 | DE.CM-03 | 8.15 Logging |
Standards and references
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- NIST: SP 800-63C-4 Federation and Assertions
- OASIS: SAML V2.0 Assertions and Protocols
- OpenID Foundation: OpenID Connect Core 1.0
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- IETF: RFC 7644 SCIM Protocol
- OpenID Foundation: Continuous Access Evaluation Profile 1.0
- FIDO Alliance: Passkeys
Related NHI Mgmt Group resources: Identity Provider and SSO Security Guide · IGA RFP Template · NIST SP 800-63C-4 Federation Assurance Levels Guide · Security Vendor Evaluation and RFP Guide