Short answer. An RFP is only as good as its requirements. This checklist groups CIAM capabilities, gives you requirements you can paste straight into an RFP, and flags the ones buyers often forget.
CIAM capability groups
- Registration and profile: self-service sign-up, invitations, profile management.
- Authentication: passwords, MFA, passwordless and passkeys, social login.
- Federation and SSO: SAML and OpenID Connect, single sign-on across applications.
- Organizations: customer companies, sub-organizations, delegated administration.
- Authorization: roles, permissions and policies per application and API.
- Consent and privacy: consent capture, data access and deletion requests.
- Lifecycle: joining, role changes, leaving, and the end of a customer relationship.
- Security: bot protection, brute-force protection, risk signals.
- Audit and events: records of changes, delivered to your own systems.
- Extensibility: APIs, events and custom logic.
Copy-paste RFP requirements
- The platform must model customer companies as organizations, with sub-organizations.
- Each organization must be able to sign in through its own identity provider over SAML or OpenID Connect, and the organization must be able to make that provider mandatory.
- The platform must offer hosted sign-in, with MFA and passwordless options, for organizations without an identity provider.
- Customer administrators must be able to manage their own organization's users within permissions we assign.
- One person must be able to belong to several organizations and act for one at a time.
- Authorization must be decided in the context of the organization the user is acting for.
- Removing a person from an organization must not remove their access to other organizations.
- The vendor must describe how sessions and tokens end when a person is removed or disabled.
- The platform must record membership, permission and account changes, and deliver those events to our systems.
- The platform must protect sign-up, sign-in, password reset and activation links against bots.
- The platform must provide APIs for every administrative action available in its console.
- The vendor must state its availability commitment and the regions where data is stored.
Capability maturity levels
| Suggested level | What it looks like |
|---|---|
| 1. Basic | Sign-up and password sign-in for individuals |
| 2. Secure | MFA, passwordless, social login, bot protection |
| 3. Organizational | Organizations, per-organization SSO, delegated administration |
| 4. Governed | Policy-based authorization, lifecycle rules, audit events to your own systems |
| 5. Adaptive | Risk-based decisions and agent-specific access controls |
Capabilities buyers forget to ask about
- How open sessions end when someone leaves.
- Hosted sign-in for small partners without an identity provider.
- What a customer administrator cannot do.
- People who belong to several organizations.
- Bot protection on activation and password-reset links, not only on sign-in.
- Migrating existing users and passwords without forcing resets.
- Which events and fields the audit trail actually contains.
Check these requirements yourself in a free SecureAuth trial.
Start your free trialFrequently Asked Questions
What are the four pillars of IAM?
One common grouping: authentication, authorization, user management and audit.
What are the 5 pillars of IAM?
Lists vary. One common fifth pillar is identity governance: reviewing and certifying who has access.
What is the difference between IAM and SSO?
SSO is one capability: signing in once to reach several applications. IAM is the whole discipline: who has accounts, how they sign in, what they may do and how that is recorded.