LeBonCoin: When Product Security Breaks the User Experience

Recently, while logging back into my account on the LeBonCoin app, the platform asked me to confirm whether my email and phone number were still correct.

A great security practice.

It's reassuring:

• data stays up to date,
• accounts are more secure,
• it limits fraud and stolen accounts.

But when I tried to update my phone number, I ran into a pretty interesting product problem.

To change the number, LeBonCoin sends a code… to the old number.

What if you no longer have access to that number?

You're stuck.

The security vs. recovery paradox

From a security standpoint, the logic is clearly understandable:

• verify that the current account owner is authorizing the change,
• prevent an attacker from replacing the number,
• limit account takeovers.

The problem is that a phone number is probably the piece of information most likely to change (switching carriers without keeping the number).

The result: you have to open a support ticket if you want to change your number.

The real product problem

The problem isn't the verification itself — quite the opposite. The problem is the absence of a fallback, a failure to account for edge cases.

In product management, a good flow must always anticipate:

• the nominal case,
• but also real-world scenarios, alternative cases.

And "I no longer have access to my old number" is not an edge case.

It's a potentially common scenario.

What a better flow could look like

Several options exist to maintain a strong security level without blocking the user.

Multi-factor verification

• old number or email,
• old number or a known device (I really like this one),
• old number or ID document — they already do this for verified profiles, they could have reused the same process.

Security delay

Allow the change after 48 hours or 7 days with a notification:

"Your number will be updated shortly if this request was made by you."

This is what many banking services and sensitive platforms already do.

Contextual risk analysis

The security level could depend on context:

• device already used,
• usual location,
• known active session,
• account history.

A user who has been logging in from the same device for 5 years doesn't carry the same risk profile as an unknown connection from another country.

A good product lesson

This kind of detail seems minor.

But it's exactly the type of friction that:

• generates support tickets,
• frustrates users,
• can lock out legitimate accounts,
• erodes trust.

The best products aren't just "secure." They're capable of handling human exceptions without breaking the experience.

And often, that's where all the difficulty of product management lies:

Finding the right balance between security requirements and UX.