Top 10 CIAM Security Risks: What Goes Wrong Most Often and How to Fix It

Customer identity systems are attacked at a scale workforce IAM rarely sees: millions of accounts, anonymous sign-up, every channel public, and customers who reuse passwords and will not tolerate friction. This page ranks the ten CIAM security risks that cause the most harm in practice, from credential stuffing and weak recovery to broken authorisation in customer APIs and over-privileged access to the CIAM platform itself. For each risk it gives a real example where one exists, how to detect it and the fixes that work, mapped to NIST SP 800-63B-4, OWASP ASVS 5.0 and the OWASP API Security Top 10. The ranking is NHI Mgmt Group's editorial judgement from published incidents and standards guidance, not a measured dataset. It is written for CIAM architects, product security and fraud teams. For the full picture of customer identity design, see the Customer IAM (CIAM) Guide.

The Top 10 at a glance

Four themes run through the list:

• Most customer account takeover starts with reused passwords and weak recovery, so breached password checks, risk-based MFA and a hardened recovery flow come first.
• Support channels and staff tools are part of the attack surface and need the same verification and least privilege as the sign-in page.
• Tokens, sessions and customer APIs need authorisation checks on every request, not just at sign-in.
• The CIAM platform itself is a high-value target, so its admin roles, signing keys and federation settings need tight control and review.

1. Credential stuffing and password reuse

Attackers replay username and password pairs leaked from other sites (MITRE ATT&CK T1110.004 Credential Stuffing) and, at lower volume, try common passwords across many accounts (T1110.003 Password Spraying). Because the credentials are valid, every successful login looks legitimate.

Example: the 23andMe Breach 2023 began with credential stuffing against more than 18,000 accounts, where MFA was optional; a relatives-matching feature then exposed profile data on almost 7 million people. Over one million login attempts in a single day were among the warning signs.

• Detect: login failure ratio per IP range, ASN and device fingerprint; spikes in successful logins from new devices; many accounts per device; credential checks hitting the API rather than the web form.
• Fix: check new passwords against compromised-password lists (NIST SP 800-63B-4 requires a blocklist; ASVS V6.2.4); allow long passwords and require at least 15 characters for single-factor passwords; apply graduated rate limits, bot detection and connection fingerprinting as the OWASP Credential Stuffing Prevention Cheat Sheet describes; challenge risky logins with MFA. Limit what one account can see about others, so a single takeover does not become a mass exposure.

See the Credential Stuffing Attack Response Playbook.

2. Optional or phishable MFA

Most consumer services make MFA optional and low adoption leaves the majority exposed. Where MFA is used, SMS and one-time codes can be phished in real time, intercepted through SIM swap, or bypassed by push fatigue (T1621 Multi-Factor Authentication Request Generation).

• Detect: MFA enrolment rate by segment; share of sign-ins completed with each factor type; phone number changes followed by sign-in from a new device; repeated MFA prompts denied then approved.
• Fix: NIST SP 800-63B-4 treats authentication over the public telephone network as restricted, requires an alternative to be available, and requires at least one phishing-resistant option to be offered at AAL2. Offer passkeys as the default, keep SMS as a fallback with risk checks (SIM change, number porting), treat a phone number change as binding a new authenticator, and require step-up for payment, payout and contact-detail changes. ASVS V6.6.1 covers PSTN one-time passwords.

See the Passkey Rollout Guide and the SIM Swap Fraud Guide.

3. Weak account recovery

Every strong sign-in method is undone by a reset flow that accepts an email link from a compromised mailbox, knowledge questions or a support call. Attackers go straight to recovery because it is designed to work without the authenticator.

• Detect: resets followed within minutes by contact-detail or payout changes; resets from devices never seen on the account; reset volume per destination email domain.
• Fix: recovery must not bypass enabled MFA (ASVS V6.4.3). Offer saved recovery codes and multiple registered passkeys so customers can recover without support; notify the old email and phone on every recovery and contact change; add a cooling-off period before high-risk actions after recovery. NIST SP 800-63B-4 section 4.2 sets out recovery methods.

See the Passkey account recovery guide.

4. Support channel and insider abuse

Customer support tools can view and change any account. That makes support agents and outsourced contractors targets for bribery and social engineering, and makes the support line a recovery channel attackers can talk their way through.

Example: in the Coinbase Insider Breach 2025, criminals paid a small group of overseas support agents and contractors to copy data on 69,461 customers from internal support tools, then used it to impersonate the company and persuade customers to move funds. The agents used legitimate, authenticated accounts within their granted permissions, so MFA did not stop it.

• Detect: records viewed per agent per shift compared with peers; lookups without a linked ticket; screenshots or exports from support consoles; bulk access to identity document images.
• Fix: scope each agent's view to the record attached to the current case, mask sensitive fields by default, require a second approver for contact or payout changes, and govern contractor identities as third-party privileged access. Verify callers with in-app confirmation rather than knowledge questions.

See the Account Recovery and Help Desk Security Guide.

5. Fake account creation

Open sign-up lets bots create accounts in bulk for promotion and referral abuse, spam, money mule networks and later fraud. Fake accounts also pollute analytics and consent records.

• Detect: sign-ups per device, IP range and email pattern; disposable email domains; accounts that redeem an offer and never return; graph links between accounts sharing devices or payment instruments.
• Fix: score sign-up risk using device, network and behavioural signals; challenge only risky sign-ups; verify email or phone before granting value; apply identity proofing only where regulation or risk requires it, so friction stays proportionate.

See the Fake Account Creation and Sign-up Fraud Guide and the Bot Management Guide.

6. Session and token theft

Infostealer malware and adversary-in-the-middle phishing kits steal session cookies and refresh tokens after the customer has passed MFA (T1539 Steal Web Session Cookie). Long sessions, common in consumer apps, extend the value of each stolen token.

• Detect: one session used from two distant networks; session reuse after logout; refresh token use from a new device fingerprint.
• Fix: verify session tokens on a trusted backend (ASVS V7.2.1) and make termination effective immediately (V7.4.1); for AAL2, NIST SP 800-63B-4 says reauthentication should be required at least every 24 hours overall and after no more than 1 hour of inactivity; rotate refresh tokens on use; revoke all sessions on password change, recovery or risk signals; show customers their active sessions.

See the Session Hijacking and Cookie Theft Guide.

7. Broken authorisation in customer APIs

Mobile apps and single-page applications call APIs that return customer records. If the API checks only that the caller is signed in, not that the record belongs to them, any customer can read others' data (OWASP API1:2023 Broken Object Level Authorization). Without volume controls, one caller can harvest millions of records.

Example: in the T-Mobile API Breach 2023, an unauthorised actor retrieved account data on about 37 million accounts through a single API over roughly six weeks before detection. The root cause was not disclosed; the lesson that holds either way is per-caller authorisation and volume monitoring.

• Detect: distinct customer IDs requested per caller; sequential ID access; response volume per token compared with normal app behaviour.
• Fix: enforce object-level ownership checks on every call (ASVS V8.2.2), tested in CI; rate limit per caller and per business flow (API6:2023 Unrestricted Access to Sensitive Business Flows); return only the fields the screen needs.

8. Account enumeration

Different responses for "unknown email" and "wrong password", or a sign-up form that says "email already registered", let attackers confirm which identities are customers. That sharpens credential stuffing and targeted phishing, and can itself disclose sensitive facts, for example membership of a health or dating service.

• Detect: high volumes of reset or sign-up attempts with few completions; lookups spread across many addresses from one source.
• Fix: return identical messages and similar response times for sign-in, sign-up and reset; send "if an account exists" emails; apply the same rate limits to these endpoints as to sign-in. The OWASP cheat sheet also warns that multi-step login must not reveal whether a user exists.

9. Federation and OAuth misconfiguration

Social login, "sign in with" buttons and partner integrations rely on OAuth 2.0 and OpenID Connect. Loose redirect URI matching leaks authorisation codes, missing PKCE allows code interception in mobile apps, and automatic account linking by unverified email lets an attacker who controls an identity provider account take over a local one.

• Detect: authorisation requests with unregistered redirect URIs; account links created where the provider email is unverified; tokens issued to unexpected clients.
• Fix: validate redirect URIs against a pre-registered allowlist using exact string matching (ASVS V10.4.1); require PKCE for public clients; link accounts only after the customer proves control of both; validate issuer, audience and signature on every ID token.

See the OAuth 2.1, GNAP and FAPI Guide.

10. Over-privileged access to the CIAM platform

The CIAM tenant is a single control point for every customer account. Administrator consoles, management API tokens, signing keys and the service accounts used by provisioning, analytics and marketing integrations can each change or export the whole customer base. These non-human identities are often long-lived and broadly scoped.

• Detect: management API calls from new networks; bulk user exports; changes to sign-in policies, MFA settings or token lifetimes; new admin accounts or new API clients.
• Fix: require phishing-resistant MFA for every administrator; separate configuration, support and read-only roles; scope management tokens to the operations each integration needs, store them in a secrets manager and rotate them; alert on policy changes and exports; back up tenant configuration.

See the Phishing-Resistant MFA Guide and the Secrets Management Guide.

Mapping to OWASP

ATT&CK techniques that recur across the list: T1110.004 Credential Stuffing, T1110.003 Password Spraying, T1621 Multi-Factor Authentication Request Generation, T1539 Steal Web Session Cookie and T1078 Valid Accounts.

Where to start

1. Measure first. Instrument sign-in, sign-up and recovery with failure ratios, new-device rates and factor mix, so you know which of the ten is biting today.
2. Close the mass-takeover risks. Breached password checks, bot and velocity controls and risk-based MFA (risks 1 and 2) give the largest reduction for the least friction.
3. Make recovery as strong as sign-in. Fix reset flows and support verification together (risks 3 and 4); attackers move to them as soon as sign-in hardens.
4. Lock down the platform. Admin MFA, scoped management tokens and alerts on policy changes (risk 10) protect every customer at once.
5. Test authorisation continuously. Add object-level authorisation tests for customer APIs to CI (risk 7) and review OAuth client registrations (risk 9).
6. Track progress with five metrics: account takeover rate per 10,000 active accounts, passkey and MFA adoption, median time to detect a stuffing wave, recovery-initiated takeovers, and admin or API credentials past their rotation date.

Small services can start with a managed CIAM platform's built-in breached password and bot features; large consumer brands need a dedicated fraud signal pipeline feeding sign-in and recovery decisions. See the Account Takeover Prevention Guide and the CIAM Maturity Model.

Standards and references

• NIST: SP 800-63B-4, Authentication and Authenticator Management
• OWASP: Application Security Verification Standard 5.0
• OWASP: API Security Top 10 2023
• OWASP: Credential Stuffing Prevention Cheat Sheet
• MITRE ATT&CK: T1110.004 Credential Stuffing
• MITRE ATT&CK: T1539 Steal Web Session Cookie

Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · Account Takeover Prevention Guide · Passkey Rollout Guide · CIAM Maturity Model