How to share passwords with a team without losing control

Sharing a business access should never mean emailing a password or dropping a spreadsheet into a shared folder. The real issue is organisation: who can view it, who can change it, who decides, and how quickly can access be removed?

This guide gives small and medium-sized businesses a practical method for sharing secrets when necessary, while keeping named accounts whenever the service allows it. It is not a substitute for an audit or your organisation’s contractual requirements.

1. Separate the types of access

Classify each access as one of these:

• Named: one person has their own account and MFA. Prefer this for email, business tools, and administration.
• Delegated: a person receives a role or delegation without learning the primary secret. Use this when the service supports it.
• Shared technical: the service requires a common account, such as a support mailbox, legacy device, or provider account. Limit it and document why it exists.

For each entry, record the service, owner, privilege level, authorised people, MFA status, last review date, and maximum revocation time. Do not put the secret in this record.

2. Use a simple permissions matrix

A matrix makes decisions visible without copying passwords. Adapt this model to your organisation:

Three rules prevent most access drift:

1. Need to know: access for a whole company is not the default for sensitive secrets.
2. Separation of duties: the person using a service every day does not automatically need to administer its permissions.
3. A planned backup: every critical access should remain recoverable if its owner is absent or leaves.

3. Prepare the vault and groups

Create groups that match real work: “Finance”, “Support”, “Administration”, or “Temporary providers”. Avoid broad groups such as “Everyone” for sensitive secrets.

In each shared vault or folder:

• use a clear name without putting the secret in the title;
• record the owner and backup owner in a non-sensitive note;
• separate daily access from emergency and administrator access;
• limit export, copy, and sharing to people who need them;
• enable MFA for the service and vault when available;
• keep recovery codes in a protected location with an emergency procedure.

An encrypted local vault such as Soclyde helps generate unique secrets, avoid copies in unprotected documents, and share only the required entries with authorised devices. It does not replace MFA, service account management, or permission reviews.

4. Onboarding procedure

Onboarding should create useful access, not automatically reproduce a predecessor’s permissions.

1. The team lead requests access based on the role and matrix.
2. Each service owner approves the scope and duration.
3. The security or IT lead creates a named account and MFA before granting data access.
4. Shared vaults are added by group with the minimum required privilege.
5. The manager confirms that access works and that the person knows how to report loss or suspicion.
6. Keep the request and next review date, but never keep the password in the ticket.

For a provider, set an expiry date when access is created. Temporary access without an end date often becomes permanent through neglect.

5. Role-change and offboarding procedure

Start the procedure as soon as the change date and time are known. For a sensitive departure, coordinate revocation with management, HR, and the technical lead.

• disable the named account and revoke sessions, devices, and tokens;
• remove the person from groups and shared vaults;
• transfer ownership of services, vaults, and recovery codes;
• check provider access and emergency accounts;
• rotate shared secrets if the former member knew or could export them;
• review email forwarding rules and connected applications;
• record the time, scope, executor, and remaining gaps.

For a role change, remove permissions that are no longer needed first, then grant the new permissions after approval. Do not let both scopes accumulate by default.

6. Review access on a schedule

A quarterly review often fits business access; administrator, financial, and recovery accounts may need monthly review. For every entry, ask the owner: “Does this person still need this access at this privilege level?”

At minimum, check:

• accounts without owners, inactive accounts, and unjustified shared accounts;
• every group member and administrator permission;
• MFA, open sessions, and authorised devices;
• exposed or reused secrets, and secrets never rotated after a change;
• vault recovery and emergency access;
• one real revocation test on a non-critical access.

Keep short evidence: date, scope, reviewer, decisions, gaps, and remediation owner. Evidence must never contain the secrets.

Sample internal rule

Accounts are named whenever the service allows it. Shared access is a documented exception with an owner, backup owner, authorised group, and review date. Secrets are stored in the company-approved vault and are not sent by email, chat, or unprotected document. A departure or role change immediately triggers removal of unnecessary rights. Suspected compromise triggers secret rotation without waiting for the next review.

Implementation checklist

• [ ] Inventory resources and separate named, delegated, and shared access.
• [ ] Name an owner and backup owner for every critical access.
• [ ] Create role-based groups and apply least privilege.
• [ ] Move secrets out of email, spreadsheets, and unprotected documents.
• [ ] Enable MFA for email, administration, and sensitive services.
• [ ] Formalise onboarding, role-change, and offboarding.
• [ ] Add an expiry date to every temporary access.
• [ ] Schedule reviews and test one revocation before the first deadline.

Sharing becomes manageable when a team shares a clearly defined right, not an indistinct secret. Measure the number of critical accesses with an owner, a current review, and a tested revocation path.