[blitzegg]

That's pretty obvious to anyone who had to maintain a high traffic site. Just the tip of the iceberg (I haven't included additional legal issues and other):

1.1 Strong protection against account takeover

Email change is one of the most abused recovery vectors in account takeover (ATO).

Eliminating email changes removes:

Social-engineering attacks on support

SIM-swap → email-change chains

Phished session → email swap → lockout of real user

Attacker must compromise the original inbox permanently, which is much harder.

1.2 No “high-risk” flows

Email change flows are among the highest-risk product flows:

Dual confirmation emails

Cooldown periods

Rollback windows

Manual reviews

Fixed email removes an entire class of security-critical code paths.

1.3 Fewer recovery attack surfaces No need for:

“I lost access to my email” flows

Identity verification uploads

Support-driven ownership disputes

Every recovery mechanism is an attack surface; removing them reduces risk.

[MattJ100]

You're very wrong, because account takeover can still happen due to a compromised email account. People can and do permanently lose access to their email account to a third party.

[TheNewsIsHere]

Having worked in security on a fairly high profile, highly visible, largely used product — one of the fundamental decisions that paid off very well was intentionally including mechanisms to prevent issues with other businesses (like Google) from impacting user abilities for us.

Not having email change functionality would have been a huge usability, security, and customer service nightmare for us.

Regardless of anything else, not enabling users to change their email address effectively binds them to business with a single organization. It also ignores the fact that people can and do change emails for entirely opaque reasons from the banal to the authentically emergent.

ATO attacks are a fig leaf for such concerns, because you, as an organization, always have the power to revert a change to contact information. You just need to establish a process. It takes some consideration and table topping, but it’s not rocket science for a competent team.

[cromka]

This is a logical fallacy. That's like saying security of the website is not important because someone can still steal your laptop.

[tzs]

> Attacker must compromise the original inbox permanently, which is much harder

This may need further analysis. I'd guess that a significant fraction of the people that want to change the email address that identifies them to a service want to do so because they have a new email address that they are switching to.

Many of those will be people who lose access to the old email address after switching. For example people who were using an email address at their ISP's domain who are switching ISPs, or people who use paid email hosting without a custom domain and are switching to a different email provider.

A new customer of that old provider might then be able to get that old address. You'd think providers would obviously never allow addresses used by former customers to be reused, but nope, some do. Even some that you'd expect to not do so, such as mailbox.org [1] and fastmail.com, allow addresses to be recycled.

[1] https://kb.mailbox.org/en/private/e-mail/when-is-a-deleted-a...

[2] https://www.change.org/p/stop-fastmail-recycling-email-addre...

[prmph]

Are you using LLMs to do your thinking for you?