Customer Identity

Customer Identity and Access Management (CIAM) governs the full lifecycle of external, self-service user identities — from the moment a stranger signs up to the moment their account and data are permanently removed. It differs from workforce identity in almost every threat assumption: registrants are anonymous until proven otherwise, there is no HR process vouching for who they are, the population is orders of magnitude larger, there is no help desk relationship to fall back on, and privacy regulation (GDPR, CCPA, and equivalents) directly governs what can be collected, how long it can be kept, and how it must be erased. This article covers the lifecycle end to end: registration, verification, ongoing authentication, profile and consent management, account recovery, and de-registration.

For concrete guidance on the credentials themselves, this article defers to and cross-references the existing Passwords and Multi-Factor Authentication articles rather than repeating them — this article covers what happens around the credential across the account's lifetime.

The Lifecycle

Customer Identity Lifecycle

Each stage is covered below, followed by the threats specific to a customer-facing (as opposed to workforce) identity population.

1. Registration

Registration is the highest-risk moment in the lifecycle from a fraud perspective (anyone on the internet can attempt it) and the highest-leverage moment from a security posture perspective (decisions made here — password strength, MFA enrolment, verified contact channel — determine the account's baseline security for its entire life).

Credential Collection

Apply the full guidance in Passwords at the point of registration — minimum length, banned/breached password checks, Argon2id/bcrypt storage, no forced complexity rules. Do not weaken these requirements "to reduce sign-up friction"; a weak password accepted at registration is a weak password for the life of the account, since mandatory rotation is not the current NIST recommendation.

Prefer a passwordless registration path where the product supports it — passkey/FIDO2 registration at sign-up avoids creating a password at all. Where a password is collected, treat MFA enrolment as part of the same flow rather than a later, optional step (see below).

Prompt for MFA enrolment during registration, not as a post-signup nag screen most users dismiss. Use the ranked guidance in Multi-Factor Authentication to decide which factor to offer by default:

Offer passkeys/FIDO2 as the primary option where the platform supports it (most modern mobile OSes and browsers do).
Fall back to authenticator app with number matching as the realistic baseline where hardware-backed options aren't available.
Avoid defaulting to SMS OTP as the only offered factor — per the MFA article, it is the weakest widely-deployed option and should be a fallback, not the default.
Require at least two registered recovery paths (e.g. a registered MFA factor plus backup codes) before the account is considered fully enrolled — a single point of failure at enrolment becomes a support burden and a security gap later.

Contact Channel Verification

Verify the registrant controls the email address or phone number provided before granting full access. This is one of the accepted exceptions to the general prohibition on email-delivered authentication links described in Magic Links — enrolment/verification is explicitly called out there as a legitimate use case, since the entire purpose of the flow is proving control of the channel. Apply the hardening controls from that article regardless: single-use, short-lived, hashed-at-rest tokens, an interstitial confirmation step to defeat email-scanner pre-fetch, and rate limiting on link issuance.

Bot and Fraud Prevention

Registration endpoints are a primary target for fake-account creation, promo/referral abuse, and building an inventory of accounts for later credential-stuffing or fraud campaigns. Apply the WAF guidance from Web Application Firewall and Advanced Web Application Firewall specifically to /register:

Control	Purpose
CAPTCHA / frictionless challenge (see HTTP User Agents for Challenge vs Block guidance)	Raise the cost of scripted mass account creation
Disposable/temporary email domain detection	Blocks the most common fake-account pattern
Velocity limiting per IP / device fingerprint	Caps the rate of accounts a single source can create
Duplicate/similar-identity detection	Flags likely sockpuppet or fraud-ring registrations for review, not automatic rejection
Phone number reputation/VOIP detection	Reduces SMS-verification abuse and toll fraud

Data Minimisation and Progressive Profiling

Collect only what is required to create the account and satisfy the immediate verification step. Defer optional profile data (marketing preferences, demographic details, address) to a later, explicitly optional step. This reduces the impact of a breach of the registration database, reduces regulatory exposure under data-minimisation principles (GDPR Art. 5(1)(c)), and reduces sign-up abandonment.

Where registration triggers any data processing beyond strict account creation (marketing communications, analytics, third-party sharing), capture consent as a distinct, unbundled action — not a pre-ticked box or a condition of completing sign-up. Record what was consented to, the policy version presented, and the timestamp; this record is itself evidence required to demonstrate compliance later.

2. Identity Verification (Proofing)

Not all customer identities need the same assurance level. NIST SP 800-63A defines three Identity Assurance Levels (IAL) that scale proofing rigor to the risk of a false claim:

Level	Requirement	Typical Use
IAL1	No requirement to link the account to a real-world identity; self-asserted attributes only	Most consumer accounts — content, community, e-commerce browsing
IAL2	Evidence supporting real-world existence of the identity, verified remotely or in person	Financial services, healthcare, anything handling regulated PII or payment instruments
IAL3	In-person or supervised-remote proofing with an authorised representative verifying attributes directly	High-value government, financial, or legal use cases

Most customer registration flows should target IAL1 with a verified contact channel — do not impose IAL2/IAL3 proofing (government ID upload, in-person verification) on a use case that doesn't require it; this adds friction, cost, and its own data-handling risk (storing scanned ID documents) without a corresponding risk reduction. Reserve stronger proofing for the specific actions that need it (e.g. verifying identity before releasing funds), applied as step-up verification at that point rather than a universal registration gate.

3. Authentication (Ongoing)

Day-to-day login is governed by Passwords and Multi-Factor Authentication — apply that guidance directly rather than a customer-specific variant of it. Two considerations specific to customer populations:

Risk-based / adaptive authentication. Since customer accounts are accessed from a huge diversity of legitimate devices and locations (unlike a managed workforce fleet), a rigid "always challenge" or "never challenge" policy either frustrates legitimate users or misses risk. Score sign-ins on signals such as new device, impossible travel, and IP reputation, and step up to MFA (or an additional factor if none is registered) only when the score is elevated — see the ATO detection guidance in Advanced Web Application Firewall.
Step-up authentication for sensitive actions. A session authenticated at login should not be sufficient, on its own, to change the registered email/phone, disable MFA, add a payment method, or initiate account deletion. Require re-authentication or a fresh MFA challenge immediately before these actions.

4. Session Management

Issue session tokens with ≥128 bits of entropy from a CSPRNG; regenerate the session identifier on privilege change (e.g. immediately after login) to prevent session fixation.
Give customers visibility into their own active sessions/devices and a self-service "sign out of all other devices" action — this is both a security control and a common support-deflection feature (users who suspect compromise can act immediately without contacting support).
Apply idle and absolute session timeouts appropriate to the sensitivity of the application (a banking app and a content site have very different acceptable exposure windows).
Invalidate all sessions server-side on password change, MFA factor change, or detected account compromise — do not rely on client-side cookie expiry alone.

Customers need durable, self-service control over their own data — both because it is good practice and because it is a legal requirement in most jurisdictions the account may be subject to.

Self-service data access and export. Provide a mechanism for the user to view and export their stored data (GDPR Art. 20 — data portability). This also reduces support load from manual data-access requests.
Re-verification on contact-channel change. Changing the registered email or phone number is functionally equivalent to changing the account's recovery path — require the same step-up authentication as MFA changes, verify the new channel before it becomes active, and notify the old channel that a change occurred (see the second-channel notification pattern in Magic Links) so a legitimate owner can intervene if the change wasn't theirs.
Consent preference centre. Let users view and withdraw consent for optional processing independently of deleting the account outright — withdrawing marketing consent should not require account deletion, and account deletion should not be the only way to exercise data rights.

6. Account Recovery

Recovery is where account-takeover risk concentrates, because by definition the user cannot authenticate through the normal path. Apply the password-reset guidance already established:

Follow the Magic Links hardening controls for the reset link itself: single-use, short-lived, hashed token, interstitial confirmation, second-channel notification, and rate limiting on issuance.
Do not confirm or deny whether a given email/phone is registered on the "forgot password" endpoint — a differing response for existing vs non-existent accounts is an account-enumeration vector that also aids credential-stuffing reconnaissance.
Issue backup/recovery codes at MFA enrolment for the case where the user loses their primary factor, store them the same way as passwords (hashed, not plaintext), and treat their use as a high-risk event that triggers a notification.
Route recovery requests for accounts with elevated risk indicators (recent MFA disablement, recent contact-channel change, active fraud flags) to manual review rather than fully automated reset — the same properties that make automated recovery convenient make it valuable to an attacker who has partially compromised an account.

7. De-registration

De-registration is the least-designed part of most CIAM systems, and the part most directly governed by regulation (GDPR Art. 17 "right to erasure", CCPA deletion rights, and equivalents elsewhere). It is not a single action — it is a sequenced process with legal, security, and operational constraints that pull in different directions.

User-Initiated Deletion

Verify identity before executing the request. Account deletion is itself an attack — a hijacked session or a social-engineered support request can be used to destroy a legitimate user's account and data. Require re-authentication (password + MFA, not just an active session) immediately before processing a deletion request.
Immediately revoke access, defer permanent purge. On request, invalidate all sessions, disable login, and revoke API tokens/OAuth grants tied to the account immediately. The underlying data can move into a time-boxed soft-delete / grace period (commonly 14–30 days) before permanent purge, disclosed clearly to the user, so an accidental or coerced deletion request can be reversed. The account must not be usable during this window even though the data has not yet been purged.
Notify downstream processors. Where customer data was shared with third-party processors (analytics, email providers, support tooling), propagate the deletion request to them within the timeframe required by the applicable regulation and any data processing agreements in place.
Purge from backups on a defined schedule. Immediate purge from backups is often technically impractical; document a maximum retention period after which backups containing the deleted record are themselves rotated out, and treat that period as part of the organisation's stated deletion SLA.

Data That Must Be Retained Despite a Deletion Request

Not everything can be deleted on request. Legal, tax, fraud-prevention, and security obligations frequently require retaining specific records past an erasure request — this is an accepted and lawful exception (e.g. GDPR Art. 17(3)), not a loophole, provided it is scoped and documented:

Data Category	Reason for Retention	Typical Retention Period
Financial transaction records	Tax and accounting law	6–7 years (jurisdiction-dependent)
Fraud investigation records tied to the account	Legitimate interest / legal obligation to combat fraud	Duration of investigation, then defined retention
Security/audit logs referencing the account (login events, admin actions)	Security monitoring and incident response	Aligned to the organisation's log retention policy
Records of the deletion request itself	Evidence of compliance with the erasure obligation	Duration required to demonstrate compliance

When data is retained under one of these exceptions, minimise it to what the specific legal basis requires, isolate it from data used for any other purpose (it should not resurface in marketing, personalisation, or general analytics), and inform the user which categories are being retained and why.

Involuntary De-registration

Fraud or Terms-of-Service violation. Suspend rather than immediately delete, preserving evidence needed for investigation, dispute handling, or law enforcement referral. Define a retention period for this evidence distinct from standard account data.
Dormancy. Where a policy disables or deletes accounts after a period of inactivity, notify the user through their verified contact channel before acting, with a clear reactivation path within a defined threshold before the account is treated as eligible for deletion.

Deletion Audit Trail

Log that a deletion request was received, verified, and completed — including timestamps and the verification method used — as evidence of compliance. The audit log entry itself should not retain the deleted personal data beyond an identifier sufficient to prove the record existed and was actioned (e.g. a hashed account ID), to avoid the audit trail becoming a second copy of the data the user asked to have erased.