1. Create named access
Invite the person through the product’s official sharing or team controls. Give each person an account they control, and turn on multifactor authentication when the service supports it. Named access makes removal and activity review possible without guessing who has a copied secret.
If a service offers no supported way to delegate access, treat that as a product constraint. Do not disguise shared credentials as a normal team workflow.
2. Limit the role and the time
Choose the smallest role that can complete the task. A person preparing a report may need read access, not billing or user administration. Temporary work should have a review or expiry date so old access does not quietly become permanent.
Separate approval from execution for high-impact actions when the service allows it. The goal is not bureaucracy; it is to keep one compromised account from having every capability.
3. Test removal and recovery once
Before the access is urgent, confirm that an administrator can remove the member and that the account has a documented recovery path. Keep recovery contacts current and avoid leaving recovery dependent on a former teammate’s personal device.
A password manager can help create and store unique credentials for accounts that still use passwords. It does not turn a shared master login into named, auditable access.
What usually goes wrong
- Sending a shared password through chat and never rotating it.
- Giving administrator or billing access for a task that only needs viewing.
- Relying on one person’s phone or private email as the only recovery path.
- Confusing storage in a vault with proper user-level delegation.
Try this checklist
- Does every person have named access rather than a copied shared login?
- Is the assigned role limited to the work that person must perform?
- Is multifactor authentication enabled where the service supports it?
- Can an administrator remove access and complete recovery without the departing user?