Moonpig’s CIAM conversion strategy and what it means for IAM

At a glance

What this is: This is a CIAM case study showing how Moonpig used Ory to improve conversion with a personalised account strategy while keeping security and scale in view.

Why it matters: It matters because customer identity programmes fail when IAM teams optimise only for login friction or only for security, instead of aligning identity assurance, access control, and customer experience.

👉 Read Ory's Moonpig case study on customer conversion and CIAM

Context

Customer identity and access management is not just about authentication. In consumer journeys, registration, sign-in, account recovery, and profile growth all influence conversion, fraud exposure, and the quality of the identity record that the business depends on.

Moonpig’s case sits in a familiar IAM tension: organisations want higher conversion without weakening trust, and they want global scale without losing control over account lifecycle, access policy, or customer data handling. That makes this a CIAM problem first, and a product story only second.

Key questions

Q: How should organisations balance CIAM conversion with security?

A: Use a shared decision model that treats conversion, fraud resistance, and identity assurance as one programme. Remove friction only where the assurance method still supports the journey, and keep recovery, linking, and session controls strong enough to preserve trust across the customer lifecycle.

Q: Why do customer identity programmes fail when they focus only on sign-up?

A: Because sign-up is only the first moment in a longer identity lifecycle. If recovery, profile change, consent state, and session governance are weak, the organisation ends up with unreliable identities that create support burden and downstream security risk.

Q: How can security teams tell whether a CIAM migration is actually working?

A: A migration is working when active users are moving without repeated login failures, support tickets are falling, and the legacy system is shrinking on schedule. If users keep falling back to the old platform or the support desk remains overloaded, the migration is only partially complete. Success is measured by continuity and decommission progress, not by the launch date.

Q: What is the difference between customer convenience and weak identity assurance in CIAM?

A: Customer convenience reduces unnecessary friction, while weak assurance removes controls that are still needed to prove identity, manage sessions, or recover accounts safely. The test is whether the user experience can improve without making identity records less trustworthy over time.

Technical breakdown

How personalised CIAM changes the identity journey

Personalised CIAM means the identity flow adapts to the customer journey rather than forcing every user through the same friction profile. That can include progressive registration, contextual sign-in choices, and recovery paths that preserve account continuity without exposing the organisation to weak verification. The architectural issue is not just login; it is how identity proofing, session management, and account linking are sequenced so that conversion improves without creating inconsistent assurance levels across the estate.

Practical implication: map every customer journey step to the assurance level it actually needs, then remove unnecessary friction only where identity risk remains controlled.

Customer identity, permissions, and lifecycle control

CIAM maturity depends on more than authentication success rates. It also depends on how profile data, consent, session state, and linked permissions are governed over time. When account creation is easy but lifecycle controls are weak, organisations accumulate stale profiles, orphaned sessions, and inconsistent consent states. That creates operational noise for support teams and governance risk for privacy and security teams because the identity record stops being reliable as the customer relationship changes.

Practical implication: treat customer identity lifecycle management as part of the CIAM design, not as an afterthought handled only by support or compliance.

Global scale and security control consistency

At global scale, CIAM architecture has to keep policy consistent across regions, devices, and identity journeys. That means the organisation needs stable rules for authentication, session handling, account recovery, and access policy even when the customer experience is localised. Scale also increases the cost of mistakes: a weak control pattern replicated across markets becomes a systemic exposure, while an overreaching control pattern can suppress conversion at enterprise scale. The challenge is governance consistency with experience flexibility.

Practical implication: standardise the security baseline across regions first, then allow only the customer-experience layers to vary by market.

NHI Mgmt Group analysis

CIAM conversion is now an identity governance problem, not a marketing side issue. When customer journeys are built to maximise conversion, the identity team still owns the security and lifecycle consequences of those choices. That means registration, account recovery, and profile growth have to be governed as one identity system, not separate product motions. Practitioners should treat conversion goals as part of CIAM design review, not as a reason to weaken identity discipline.

Personalisation without lifecycle control creates brittle customer identity records. A smoother sign-up flow is not automatically a safer or better one if profile change, linking, recovery, and consent state are not governed over time. The result is an identity layer that looks efficient at acquisition but becomes unreliable during support, fraud review, or data-rights operations. Practitioners should measure identity quality after onboarding, not only conversion at first touch.

CIAM scale only works when security policy is stable and experience is flexible. Global customer platforms fail when every market or channel improvises its own authentication and recovery logic. The stronger pattern is a single policy baseline with controlled local variation. Practitioners should separate what can differ by region from what must remain uniform across the identity stack.

Moonpig’s case reinforces that customer identity design is a lifecycle discipline. Account creation, login, recovery, and ongoing profile management are all part of the same governance surface. That is where customer trust, operational scale, and revenue performance intersect. Practitioners should manage CIAM as an ongoing identity programme, not a one-time implementation.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which shows how often policy intent fails at execution.
• For a broader control lens, see OWASP NHI Top 10 for identity and privilege risks in modern AI and machine workflows.

What this signals

Customer identity programmes are becoming lifecycle programmes. The real signal in this case is that conversion work cannot be separated from account governance, recovery trust, and profile integrity. Teams that only optimise first-touch registration will keep discovering that identity quality degrades after onboarding, which is where most operational pain actually appears.

With 43% of security professionals already concerned about AI systems learning and reproducing sensitive information patterns from codebases, identity teams should expect more pressure to prove that customer data, identity flows, and session controls are governed consistently across channels. The practical response is to align CIAM policy with NIST AI Risk Management Framework thinking where AI-adjacent customer experiences are in play.

For practitioners

• Define conversion guardrails for CIAM Set explicit thresholds for acceptable friction, assurance, and recovery strength before customer experience changes are approved. Tie those thresholds to business and security owners so that sign-up optimisation cannot silently weaken identity assurance.
• Review customer identity lifecycle controls Check how profile updates, account linking, recovery, and consent changes are tracked after onboarding. If the identity record becomes unreliable after first login, conversion gains will be offset by support and governance risk.
• Standardise the security baseline across regions Keep authentication, session, and recovery policy consistent globally, then allow only the presentation and journey layers to localise. This reduces control drift while preserving a tailored customer experience.
• Measure identity quality beyond acquisition Track duplicate accounts, recovery failures, profile inconsistency, and support-driven identity fixes alongside registration completion. Those signals show whether CIAM is producing durable customer identities or just short-term conversion.

Key takeaways

• CIAM succeeds when conversion, assurance, and lifecycle control are designed together rather than traded off in isolation.
• Customer identity quality has to be measured after onboarding, because weak recovery and profile governance erase early conversion gains.
• Global identity consistency with local experience flexibility is the operating model that keeps CIAM scalable without diluting trust.

Key terms

• Customer Identity And Access Management: Customer Identity and Access Management is the discipline of governing how external users sign in, recover access, and move through digital services. It combines authentication, profile management, and lifecycle control so organisations can deliver secure, low-friction experiences at scale.
• Identity Assurance: The confidence an organisation has that a person or system is truly who it claims to be before access or action is granted. In modern IAM, assurance depends on evidence quality, channel trust, and the strength of verification around high-risk decisions.
• Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.

What's in the full article

Ory's full blog post covers the operational detail this post intentionally leaves for the source:

• The account strategy choices behind the Moonpig implementation, including how customer journeys were shaped for conversion.
• The practical CIAM design trade-offs that were considered for security, scale, and personalised identity experiences.
• The implementation details that matter once teams move from programme design to production rollout.
• The broader context for teams evaluating customer identity patterns in their own environments.

👉 The full Ory post covers the account strategy, implementation context, and customer identity design details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.