Access control
How to Make Every External Link Your Team Sends Meet the Same Security Standard
Don't leave link security to whoever creates the link. Set a default standard for external links, who must authenticate, whether a passcode is required, and when it expires, and enforce it so every link starts protected instead of relying on someone to remember.
Don't leave link security to whoever happens to create the link. Set a default standard for the links your team sends to outside parties, who must authenticate, whether a passcode is required, and when the link expires, and enforce it so every link starts protected. Give people room to tighten a link, not to ship one below the bar, and review and rotate on a schedule rather than leaving old links live.
Why per-person discretion fails
An access control only helps if someone remembers to switch it on. When each team member decides link security by hand, some links go out with no authentication, no expiry, and no passcode, and you only find out when something leaks. The mature answer, borrowed from how organizations govern external file sharing, is to set a baseline centrally: default to authenticated recipients rather than anyone with the URL, restrict to approved domains where you can, and expire links by default.
Default beats ad hoc
| Approach | Consistent baseline? | Junior can ship an under-protected link? | Client passcode friction? |
|---|---|---|---|
| Set and locked defaults | Yes | No | Low |
| Left to the person, per link | No | Yes | High |
How to set the standard
- Decide the baseline for external links: who must authenticate (email verification, or an allow list of approved addresses or domains), whether a passcode is required, and a default expiry.
- Set it as the default, per client or project, so every new link starts from it.
- Lock it where the level must be guaranteed, so a member can tighten a link but not drop below the bar.
- Send passcodes on a separate channel from the link, and prefer a strong passphrase.
- Cut client friction: keep one passcode for a set period, then rotate and notify the client once, instead of a new code on every link.
- Review and rotate on a schedule, and let links expire rather than leaving them open.
Where doconvoy fits
In doconvoy, an admin sets the default access controls for a client's project, covering both shares and requests, and can lock them, so every link the team sends for that client meets the same standard. The project can reuse one passcode for a set period before rotating, and carry an email verification allow list of the client's domains, so protection stays consistent and the client isn't handed a new code each time. The baseline is applied for you instead of trusting each person to remember.
Define locked, per-client defaults so every link meets the same standard.
Set your access-control baselineRelated: Access Controls · Workspaces & Projects · Audit Trail · For operations teams
Common questions
How do you stop team members sending under-protected links?
Set the access controls as a default rather than a per-link choice, and lock them where the level has to be guaranteed. A member can then tighten a link but not ship one below the baseline.
What should the default access controls be?
For most external links: require the recipient to authenticate (email verification, or an allow list of approved addresses or domains), add a passcode sent on a separate channel for sensitive items, and set a sensible expiry so links don't stay live indefinitely.
How do you keep passcodes from annoying clients?
Reuse one passcode for a set period, then rotate it and tell the client once, instead of generating a new code for every link. Through that window the client opens each request with a code they already have.