Invalidating sessions after losing permissions?

[mudge]

While https://thecopenhagenbook.com/sessions#session-invalidation states:

All sessions of the user should also be invalidated when they gain new permissions (email verification, new role, etc) or change passwords.

Should the same be said when a user loses permissions, e.g. disabling 2FA (including indirectly by using a recovery code), or changing role from an administrator to a lower privilege?

[alp1n3-eth]

This section could probably be updated to add a distinction between just invalidation vs. renewal, as @pilcrowonpaper references the OWASP Cheat Sheets to be used alongside it. The section says:

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 though in some cases still not yet the authorized state. Common scenarios to consider include; password changes, permission changes, or switching from a regular user role to an administrator role within the web application. For all sensitive pages of the web application, any previous session IDs must be ignored, only the current session ID must be assigned to every new request received for the protected resource, and the old or previous session ID must be destroyed.

It's located within the cheat sheet for Session Management. It looks like the usage of just session invalidation is reserved for times like session expiration (automatic), logout functionality used (manual), etc.