Hi! We are using the hosted Medplum backend and recently reviewed the behavior of

UserSecurityRequest

for invite and password reset flows. It looks like a

UserSecurityRequest

becomes invalid after it is successfully used, but we did not observe time-based expiration for the

auth/setpassword

endpoint. And when multiple password reset requests are generated for the same user, older reset links may still remain valid until they are used. I wanted to confirm whether this is the expected behavior. Some thoughts: - A reset link expires after a short period of time, such as 15mins or 1 hour, (the invite type may need to grant longer expiration time) - When a new password reset request is generated, previous unused reset requests for the same user are invalidated. Are there any planned Medplum features to support expiration for

UserSecurityRequest

, or to make newer password reset requests supersede older unused ones? If this behavior is not currently supported, do you have a recommended approach for hosted Medplum users who want to enforce stricter password reset security while still using

auth/setpassword

? Thanks!

Hello @Guoyi Z (Empallo)! This is a valid concern–I appreciate you bringing it to our attention. I've created a [GitHub issue](https://github.com/medplum/medplum/issues/9190) and we will get some changes out to update this logic. With that being said, as a temporary workaround you should still have the ability to delete

UserSecurityRequests

as an admin in a project. In light of this, you could implement some bots to: 1) Delete all prior created

UserSecurityRequests

upon issuing a new one (old links become invalid) 2) Run a cron job that deletes requests that have exceeded an expiration window (e.g. 1 hour after creation) Hope this helps and thanks for reaching out!

Thank you, @Andy . I really appreciate the quick response and support here. The workaround make sense, and I’ll also keep an eye on the ticket for updates.