A healthtech signup flow can pass its captcha and still leave a dangerous gap: an account is banned in the profile database while an already-issued session keeps working. That is an access-control incident waiting for a clock to run out.
Short answer: model a ban as an auditable profile-state transition, then revoke every session as a separate, explicit lifecycle action. Keep the short-lived access credential and its refresh capability under different risk controls, and make “this device” and “all devices” distinct operations.
The incident lesson: a profile flag is not a kill switch
The operational constraint is immediate shutdown. When abuse review marks a user as banned, the system must stop new work and invalidate existing access without relying on a browser logout button. I have been paged for missed jobs and duplicate deliveries; the same lesson applies here: a state change is only useful if every consumer observes it.
The invariant is simple: every authentication action is a checkable, auditable, recoverable state transition. Signup protection (including captcha verification) is one transition. Session creation, verification, refresh, and revocation are four more. Treating them as one giant “auth request” makes it impossible to answer an audit question such as “which session was active after the ban?”
