Doesn't look like the TFA module currently does this, but it seems like an emerging best practice that any other sessions for a user should be invalidated when they enable MFA.
See, for example:
https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_...
The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios must also be considered, such as password changes, permission changes or switching from a regular user role to an administrator role within the web application. For all these web application critical pages, previous session IDs have to be ignored, a new session ID must be assigned to every new request received for the critical resource, and the old or previous session ID must be destroyed.
I have not tested this exhaustively with other services, but I did a quick test with an ordinary gmail account and my parallel session was killed when I enabled MFA in another browser.
Active
2.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I view this as a good feature to add in order to increase account security.
We may even wish to take this a step further and when a plugin/method is disabled/reset that invalidate the sessions as well.
Moving this to 2.x to centralize feature requests in the latest dev branch.