Customer Identity and Access Management

An online insurer lets customers see policies and claims, so it must recognise the right person, prevent one customer from seeing another customer file and provide a workable recovery path when a phone is lost. CIAM covers that journey rather than only the login screen.

For owners, CIAM is the front door and access map for customer services, so identity and permissions should match the harm a wrong access could cause while keeping ordinary use possible. Define account types, since a consumer, business administrator and delegated employee may need different access, and a shared business account can be convenient but makes accountability and revocation difficult.

Plan registration with minimal necessary data, collecting what is needed to create the account, verify a contact route and deliver the service, because asking for sensitive documents at the first screen when they are not needed can deter customers and increase risk. Microsoft describes CIAM for external customer applications through self-service registration, sign-in, account management and access controls, and its platform example separates customer identities from employee administration and supports different sign-in methods.

NIST digital identity guidance distinguishes identity proofing, authentication and federation, so creating a password does not prove legal identity. Choose the level of identity assurance based on the actual risk of the service, and give customers usable authentication options, since passwords, passkeys, one-time codes and federated identities have different tradeoffs.

Apply multifactor authentication where risk warrants it, because a customer viewing public product information needs less assurance than someone changing a bank destination, and step-up checks can protect a sensitive action without making every visit difficult. Authorisation should be scoped: a business buyer may see orders for one company but not a sister company, so test permissions at the API and data layer, not only by hiding a button on the page.

Design recovery as carefully as sign-in, because an attacker may target the 'forgot password' flow or convince support to change an email address, and use verified channels and a record of consequential account changes. Handle session life and device changes so that a customer can sign out of lost devices or revoke sessions, remembering that very long sessions increase exposure while very short ones frustrate legitimate users.

Respect privacy choices separately, since acceptance of service terms or creation of an account is not automatic permission for all marketing, and store the purposes and dates of choices distinctly from authentication credentials. Protect identity data such as password hashes, recovery factors, tokens and profile attributes with appropriate technical controls and limited staff access, and avoid putting secrets in support notes or analytics logs.

Federated login can reduce the number of credentials a customer manages but creates a dependency on another identity provider, so plan what happens if that provider is unavailable or a customer loses access to it. Watch suspicious sign-ins and account changes such as a new device, impossible travel or repeated recovery attempts, which can trigger a check, but signals can be wrong, so offer a fair route for a legitimate customer who is blocked.

An illustrative successful-sign-in rate is completed legitimate sign-in attempts divided by legitimate attempts observed, so 950 of 1,000 gives 95%, though failures and fraud should be investigated separately and a high success rate alone says little about safety. Test the whole lifecycle of registration, consent, entitlement changes, recovery, account closure and data retention, because a secure login does not fix an old employee retaining access to a former customer business account.