CIAM Maturity Model: Five Levels and Self-Assessment

Most customer identity programmes cannot say how mature they are, so investment follows the loudest complaint, whether that is sign-in friction, fraud losses or a regulator's letter. This model describes five levels of customer identity and access management (CIAM) maturity, from Ad hoc to Optimised, across eight dimensions: registration and proofing, authentication, account recovery, sessions and tokens, consent and privacy, fraud and bot signals, B2B and delegated access, and operations and measurement. Each dimension has observable indicators per level and self-assessment questions, and the roadmap section says what to fix first. It is written for CIAM product owners, identity architects and the executives who fund them. For the discipline itself (threats, design patterns and controls) see the Customer IAM (CIAM) Guide; this page assumes that background and focuses on staged maturity.

Key takeaways

Maturity is uneven by design. Most organisations sit at different levels per dimension; a single overall score hides the weak dimension attackers will use, usually account recovery.
Level 3 is the baseline for any consumer service at scale. It means a defined standard (mapped to NIST SP 800-63-4 assurance levels), a phishing-resistant option offered to customers, breached-password checks, and consent records you can produce on request.
Recovery sets the real assurance level. A passkey-protected account that can be recovered by an emailed link is only as strong as the mailbox. Mature programmes design recovery to the same assurance as sign-in.
Fraud and identity must share signals. Levels 4 and 5 are defined by risk signals flowing between sign-in, recovery, payments and support, not by more authentication prompts.
Measure conversion and compromise together. A programme that tracks only sign-in success or only fraud losses will optimise one at the expense of the other.

The five levels

Level	Name	Description
1	Ad hoc	Each product or brand built its own sign-in. Passwords are the main factor, MFA is optional or SMS-only and lightly used, recovery is by emailed link or help desk judgement, and consent is a checkbox in the terms. Nobody owns customer identity as a capability.
2	Developing	A CIAM platform or shared identity service exists for the main channels. MFA is available, basic rate limiting and CAPTCHA protect sign-in, and some consent choices are stored. Policies differ by channel and incidents are handled case by case.
3	Defined	A documented customer identity standard sets assurance levels per journey (aligned to NIST SP 800-63-4 IAL, AAL and FAL), passkeys or another phishing-resistant option are offered, passwords are screened against breach lists, recovery has defined assurance, consent is granular and recorded, and APIs follow the OAuth 2.0 Security Best Current Practice.
4	Managed	Risk-based authentication uses device, network and behaviour signals; step-up is triggered by risk and transaction value; fraud, identity and support share a signal pipeline; B2B customers self-manage organisations and federation; metrics on conversion, account takeover and recovery abuse drive decisions.
5	Optimised	Passwordless is the default for most customers, recovery is passkey or verified-identity based, signals are exchanged with partners and relying parties (for example through Shared Signals events), controls are tuned continuously from attack telemetry, and privacy choices propagate automatically to every downstream system.

The level names follow the NHI Mgmt Group five-level scale used in the Identity Security Maturity Model and the Fraud Prevention Maturity Model, so results can be compared across programmes.

The eight dimensions

Score each dimension separately. The indicators below describe Levels 1, 3 and 5; Levels 2 and 4 sit between them.

Dimension	Level 1 indicators	Level 3 indicators	Level 5 indicators
Registration and proofing	Email and password only; no fake-account controls	Proofing level chosen per product risk (IAL); email or phone verified before sensitive actions; sign-up velocity limits	Progressive proofing tied to value at risk; reusable verified credentials accepted; fake account rates measured per channel
Authentication	Passwords with composition rules; SMS OTP as the only second factor	Passkeys offered; breached-password screening; length-based password policy; MFA enrolment prompted	Passwordless by default; phishing-resistant step-up for high-value actions; password optional or removed
Account recovery	Emailed reset link or security questions; agents decide ad hoc	Recovery assurance defined per journey; cooling-off and notification on recovery; agents follow a scripted verification	Recovery through a second passkey, verified identity or trusted contact; recovery abuse monitored as a fraud vector
Sessions and tokens	Long-lived sessions; implicit flow or stored passwords in mobile apps	Authorization code with PKCE; refresh token rotation or sender-constraining; customers can see and end sessions	Continuous session evaluation; revocation on risk events propagated to every app and API within minutes
Consent and privacy	Consent bundled into terms; no record of what was agreed	Granular, opt-in consent per purpose; timestamped records; withdrawal as easy as giving	Consent and preference changes propagated automatically to downstream systems and partners; periodic refresh
Fraud and bot signals	IP blocking after incidents; fraud team works separately	Bot management on sign-in and sign-up; device fingerprinting; alerts on unusual sign-in followed by failed MFA	Shared risk engine across identity, payments and support; signals exchanged with partners; models retrained from outcomes
B2B and delegated access	Business customers share one login or get admin accounts created by support	Organisations modelled in the CIAM; customer admins invite users; enterprise SSO via SAML or OIDC	Self-service federation and SCIM provisioning; delegated administration with scoped roles; partner access reviewed
Operations and measurement	No owner; metrics limited to user counts	Named product owner; conversion, MFA and passkey adoption, and account takeover tracked monthly	Experiments balance friction and risk; metrics reported to executives with targets; regular red-team of journeys

Why these dimensions

Registration and proofing: sets how much the organisation knows about who opened the account. NIST SP 800-63A-4 defines identity assurance levels; most consumer services need proofing only for regulated or high-value features. See the Identity Proofing and KYC Guide.
Authentication: NIST SP 800-63B-4 requires verifiers at AAL2 to offer at least one phishing-resistant option, sets a 15-character minimum for passwords used alone (8 when part of multi-factor), and prohibits composition rules and periodic forced changes. It also states that syncable authenticators must not be used at AAL3. See the Passkey Rollout Guide.
Account recovery: 800-63B-4 does not treat codes sent by email as authentication, so an email-only recovery path caps real assurance at the strength of the customer's mailbox. See Passkey account recovery.
Sessions and tokens: RFC 9700 (OAuth 2.0 Security Best Current Practice, January 2025) requires PKCE for public clients, prohibits the resource owner password credentials grant, discourages the implicit grant and requires exact redirect URI matching.
Consent and privacy: under UK and EU GDPR, consent must be freely given, specific, informed and unambiguous (Article 4(11)), the controller must be able to demonstrate it (Article 7(1)), pre-ticked boxes do not count (Recital 32), and withdrawal must be as easy as giving it. See the Identity Data Privacy and Consent Guide.
Fraud and bot signals: OWASP's Credential Stuffing Prevention Cheat Sheet ranks MFA as the strongest defence and recommends layered device and connection fingerprinting, breached-password checks and user notification of suspicious events. Credential stuffing is ATT&CK T1110.004 and password spraying T1110.003.
B2B and delegated access: business customers expect to bring their own identity provider and manage their own users. See the B2B CIAM and Organisation Management Guide.
Operations and measurement: the dimension that keeps the others from decaying after the platform project ends.

Dimension to framework mapping

Dimension	NIST SP 800-63-4	NIST CSF 2.0	NIST SP 800-53 Rev 5
Registration and proofing	SP 800-63A-4 (IAL)	PR.AA-02 Identities are proofed and bound to credentials	IA-12 Identity Proofing
Authentication and recovery	SP 800-63B-4 (AAL, recovery)	PR.AA-03 Users, services and hardware are authenticated	IA-8 Identification and Authentication (Non-organizational Users)
Sessions and tokens	SP 800-63B-4 (session management), SP 800-63C-4 (FAL)	PR.AA-03	AC-12 Session Termination
Consent and privacy	SP 800-63-4 privacy requirements	GV.PO-01 Policy established	PT-4 Consent
Fraud and bot signals	SP 800-63B-4 throttling	DE.CM-03 Personnel activity and technology usage monitored	SI-4 System Monitoring
B2B and delegated access	SP 800-63C-4 (federation)	PR.AA-01 Identities and credentials are managed	IA-8

The NIST SP 800-63 Digital Identity Guidelines Guide explains the assurance levels in detail. Payment services in the UK and EU also need to meet strong customer authentication rules: see the PSD2/PSD3 Strong Customer Authentication Guide.

Self-assessment questions

Answer yes only if you can show evidence. Three or more "no" answers in a dimension place you below the level named.

Registration and proofing (Level 3)

Is the required identity assurance level documented for each product and feature?
Do you measure fake or abusive account creation by channel, and act on it?
Are contact details verified before they can be used for recovery or notifications?

Authentication (Level 3)

Can every customer enrol a passkey or another phishing-resistant authenticator on web and mobile?
Are new and changed passwords screened against breached and common password lists, with no composition rules or forced rotation?
Is SMS OTP restricted to a fallback, with its use measured?

Account recovery (Level 3 to 4)

Is the assurance of each recovery path documented and at least equal to sign-in for high-value accounts?
Are customers notified on every recovery, contact change and new authenticator, through a channel other than the one changed?
Do support agents follow a scripted verification that cannot be overridden without a second approver?

Sessions and tokens (Level 3)

Do all public clients use the authorization code flow with PKCE, with no implicit or password grant left in production?
Can customers see active sessions and devices, and end them?
When a password or authenticator is reset, are all sessions and refresh tokens revoked?

Consent and privacy (Level 3)

Can you produce, for any customer, what they consented to, when, and the notice version shown?
Is withdrawal available in the same place and with the same effort as giving consent?
Do consent changes reach marketing, analytics and partner systems, and is this tested?

Fraud and bot signals (Level 4)

Is there a single risk score used by sign-in, recovery, payments and support?
Do you alert on a correct password followed by failed MFA, and on bursts of failed sign-ins across many accounts?
Are fraud outcomes fed back to tune identity controls at least monthly?

B2B and operations (Level 4)

Can business customers connect their own identity provider and provision users without a support ticket?
Is there a named CIAM product owner with targets for conversion and account takeover?
Are journeys tested by an internal or external red team at least annually?

Moving up a level

Level 1 to 2: consolidate. Pick one identity service for the main channels, appoint an owner, turn on rate limiting and bot protection on sign-in and sign-up, and make MFA available to every customer. Inventory every place customers can sign in, including legacy brands and partner portals.
Level 2 to 3: define and remove the worst risks. Write the customer identity standard with assurance levels per journey; add breached-password screening and length-based rules; launch passkeys with a measured enrolment prompt; redesign recovery so it notifies customers and cannot be completed by a mailbox alone for high-value accounts; replace implicit and password grants with authorization code and PKCE; implement granular consent with records. Pilot each change on a percentage of traffic and keep the old journey available for rollback until conversion is stable.
Level 3 to 4: connect signals. Feed device, network, behaviour and transaction signals into one risk engine; use it to drive step-up rather than prompting everyone; give support agents the same risk view; model B2B organisations and offer enterprise federation; agree joint metrics between identity and fraud teams.
Level 4 to 5: optimise. Make passwordless the default for new customers, retire passwords where adoption allows, exchange risk events with partners and relying parties, and run continuous experiments that balance friction against loss. The OpenID Foundation's Shared Signals work (SSF, CAEP and RISC) provides standard event formats for account takeover and session revocation signals; check the specification status before depending on any detail.

Small organisations can usually reach Level 3 by configuring a commercial CIAM platform well; Levels 4 and 5 need data and staff that only large consumer businesses typically justify. Choose the target level per dimension from the value at risk, not from the model. The CIAM Buyer's Guide covers platform evaluation.

Metrics that show maturity

Metric	What it shows	Typical Level 3 expectation
Sign-in success rate by method	Friction; whether passkeys improve conversion	Tracked monthly per channel
Phishing-resistant authenticator adoption	Share of active customers with a passkey or security key	Target set and trending up
Account takeover rate per 10,000 active accounts	Outcome of authentication and fraud controls	Measured with a consistent definition
Recovery requests later confirmed as fraud	Strength of the recovery dimension	Reviewed monthly; recovery abuse has an owner
Credential stuffing attempts blocked versus reaching password check	Bot defence effectiveness	Reported per attack wave
Consent requests answered with records within the deadline	Consent dimension evidence	All requests answered from system records

The Fraud Metrics and KPIs Guide gives definitions for the fraud-side measures.

Common failure patterns

Optional MFA counted as maturity: offering MFA without driving adoption leaves most accounts on passwords. At 23andMe, MFA was optional and the attacker reused leaked credentials against more than 18,000 accounts. See the 23andMe credential stuffing breach.
Ignoring attack telemetry: the same incident included over a million login attempts in a single day that were not acted on. Volume anomalies must reach someone who can respond. See the Credential Stuffing Attack Response Playbook.
Strong sign-in, weak recovery: passkeys are rolled out while the recovery link or the help desk script stays unchanged, so attackers use recovery instead.
Feature design that multiplies exposure: data shared between accounts (social graphs, family or matching features) means one compromised account exposes many customers. Assess sharing features as part of authentication risk.
Consent without records: a banner exists, but the organisation cannot show what a given customer agreed to or prove that withdrawal reached downstream systems.
Scoring the whole programme at one level: an average hides the dimension at Level 1. Report the minimum alongside the average.

Lessons from incidents

The 23andMe case shows how CIAM weaknesses compound: optional MFA, an eight-character password minimum, missed detection signals and a sharing feature turned roughly 18,000 directly accessed accounts into exposure of data on almost 7 million people. The UK Information Commissioner's Office fined the company £2.31 million in June 2025. In maturity terms the authentication, fraud signal and operations dimensions were all at Level 1 to 2, and the sharing feature had not been assessed as identity risk. Raising authentication to Level 3 alone (breached-password screening and phishing-resistant options with an adoption target) would have changed the economics of the attack.

Practitioner checklist

Score each of the eight dimensions separately and report the lowest score alongside the average.
Document the identity assurance and authenticator assurance level required per customer journey.
Offer passkeys on every channel and set an adoption target.
Screen passwords against breached lists; remove composition rules and forced rotation.
Redesign account recovery to match sign-in assurance, with notification on every change.
Remove implicit and password grants; enforce PKCE and refresh token rotation or sender-constraining.
Keep consent records that show purpose, time and notice version, and test withdrawal end to end.
Connect identity, fraud and support to one risk view and agree joint metrics.
Reassess maturity every 12 months and after any account takeover incident.

CIAM Maturity Model: Five Levels From Ad Hoc to Optimised