Access control
How to Revoke Access After You've Already Shared a Link or Credential
You can't un-send a message, but you can revoke the access it pointed to. Kill the whole link, cut off a single recipient, rotate a leaked passcode, and rotate the credential itself if the secret was exposed. Make revocation the last step of every project.
You can't un-send a message, but you can revoke the access it pointed to. Kill the whole link so it stops working for everyone, which is safer than removing one person because links get forwarded. Cut off a single recipient if only they should lose access, rotate the passcode if the code may have leaked, and rotate the underlying credential if the secret itself was exposed. Make revocation the last step of every project, and check that the access is actually gone.
Why letting it expire isn't enough
An expiry date and a view limit are useful, but they're passive. When a link was forwarded, a laptop was lost, or a contractor's engagement ended early, waiting for the link to lapse leaves a window open. Revocation is the active version: you decide access ends now. The mistake most people make is removing one person from a shared link and assuming that's the end of it. If the link was forwarded, that person is gone but the link still works for whoever else has it.
Match the method to the situation
| Method | Stops everyone? | Stops one person? | When to use it |
|---|---|---|---|
| Kill the whole link | Yes | Yes | The link may have been forwarded, or the exchange is done |
| Deny-list a recipient | No | Yes | One named person should lose access, link stays live |
| Rotate the passcode | No | No | The code leaked but the link should stay open (gates new opens only) |
| Rotate the credential | Yes | Yes | The secret itself was exposed, or someone's already in and must be removed |
How to revoke, step by step
- Decide the blast radius. If the link may have been forwarded, kill the whole link. If one named person should lose access, cut off that recipient.
- Kill the link to stop it for everyone before its expiry.
- Revoke a single recipient by denying their address, which works when the request uses email one-time-code authentication.
- Rotate the passcode if the code may have leaked but the link should stay live. This gates only new opens, so anyone already in keeps their session until it ends.
- Rotate the underlying credential if the secret was exposed, or if someone has already opened the link and you need them out now. A passcode change alone won't remove them.
- Verify and log it. Confirm the person is locked out, and record the revocation as part of project closure.
Where doconvoy fits
doconvoy lets you revoke without resharing a new link to everyone else. Kill a live request or share instantly, deny-list a specific recipient when email verification is on, and rotate the passcode for a client's project, with expiry and view limits acting as automatic cut-offs. Every access sits in the audit trail, so you can prove the revocation happened. One thing to keep in mind: rotating a passcode blocks only new opens, so to remove someone who's already inside, kill the link or rotate the credential.
Kill links, deny recipients, and rotate passcodes with a full audit trail.
Keep control after you shareRelated: How to standardize security on external links · Sharing client credentials across an agency team · Access Controls · Audit Trail · For operations teams
Common questions
Can you disable a shared link after you've sent it?
Yes. Disabling the whole link is the safest move, because links get forwarded and killing the link stops everyone at once. Removing one person only helps if you're certain the link wasn't passed on.
Does changing the passcode lock out someone who already opened the link?
No. Rotating a passcode only gates new opens. Anyone who already got in keeps their access. To remove someone who's already opened the link, kill the link or rotate the underlying credential.
How do you revoke access for just one person?
Cut off that recipient rather than the whole link. In doconvoy you add their address to the deny list, which applies when the request uses email one-time-code authentication. Killing the whole link removes everyone.