Best practice for moving users away from institutional email domains while avoiding duplicate/impersonation accounts

I run an independent Discourse community https://physicswithethan.discourse.diy which previously allowed institutional email addresses and external SSO.

I now want to move toward ordinary local Discourse accounts using personal email addresses, and avoid relying on institutional SSO or institutional email domains for new registrations.

The issue I am trying to handle safely is account continuity and impersonation risk:

  • many existing users have an institutional email address as their primary email;
  • I would like new users to use personal email addresses instead;
  • I want to avoid people registering accounts using someone else’s name or institutional email address;
  • I also want to avoid unsafe or manual account merges unless there is clear evidence the same person controls the relevant accounts/emails.

What is the recommended Discourse-native approach here?

For example, is the best pattern:

  1. re-enable local logins;
  2. disable the external SSO provider;
  3. add the institutional domain to blocked email domains for new registrations;
  4. add a site notice asking existing users to update their primary email to a personal address;
  5. use manual approval / review for suspicious new accounts;
  6. only merge accounts where the user has verified control of both accounts or email addresses?

I am especially interested in avoiding a setup where a user can trigger emails to someone else’s institutional mailbox, or create a misleading account in another person’s name.

Are there existing settings or workflows that people recommend for this kind of transition?

Do you mean that you have SSO with one particular institution (e.g., whatever.edu) and you want people to stop using that email address?

There isn’t any way to trigger emails to an institutional account (other than an email validation request) in any scenario.

Isn’t the best way to keep people from impersonating someone to require them to use their instutional email address? There’s nothing to stop anyone from creating albert.einstein123@gmail.com and look like they are that person.

Yes, that is the tension I am trying to handle.

Technically I agree that an institutional email address is stronger identity assurance than a personal email address. My reason for moving away from institutional email/SSO is not that personal email is better proof of identity, but that I want the community to be clearly independent and not rely on an institution’s identity system or email domain for ongoing access.

Since my opening post I have made the current transition state clearer on the site itself:

  • the splash/login page now states that Physics with Ethan is independent and not affiliated with or endorsed by any university, school, or department;
  • it also explains that sign-in currently uses Microsoft work or school account verification for onboarding;
  • existing users can now add a personal email address after logging in, via Profile → Preferences → Emails;
  • I have also added wording asking users not to register using another person’s name, email address, or identity.

So I think the current position is a transitional one:

  • Microsoft work/school verification is still useful for reducing impersonation risk during onboarding;
  • but I would like existing users to add personal email addresses;
  • and I want to avoid making institutional email/SSO the long-term dependency of the community.

The practical Discourse question I am still trying to answer is:

For a community that wants to move from institutional email/SSO toward local accounts and personal email addresses, is the safest pattern to keep the transition manual/admin-reviewed rather than attempting automatic account merging?

For example:

  1. allow existing users to add a personal email while logged in;
  2. keep the splash page clear about the current onboarding method;
  3. discourage misleading registrations/impersonation;
  4. avoid automatic account merges;
  5. only merge accounts where there is clear evidence the same person controls the relevant accounts/emails.

Does that sound like the right Discourse-native direction?