If a colleague needs to answer a shared inbox or cover an absence, give them delegated access through their own account where the application supports it. Handing over a personal password makes it harder to see who did what and harder to remove access later.
Some older applications still require a shared login. Treat that as an exception with an owner, a limited audience, and a documented way to change the credential.
Start with the task, not the password
Ask what the other person actually needs to do. Reading a mailbox, approving an invoice, and administering a system require different permissions.
Look for shared mailboxes, application roles, or delegated permissions before sharing a secret. Give each person a named identity and only the access required for the task. This keeps activity attributable to the person who performed it, subject to the application's logging capabilities.
For example, someone covering customer enquiries may need access to a team inbox. They do not need the owner's entire email account, administrator role, or recovery codes.
When a shared credential cannot be avoided
Use a business password manager with access controls appropriate to the account. Keep a record of:
- The system and the person responsible for it.
- Who can retrieve or use the credential.
- Why a shared account is necessary.
- Which MFA method is used and how recovery is controlled.
- When access expires and what happens when a participant leaves.
Do not assume that removing someone from a password vault invalidates a password they already know. Rotate the credential when needed, revoke active sessions where supported, and review recovery methods as part of offboarding.
Keep passwords out of ordinary work messages
Email and chat messages can be forwarded, searched, retained, or accessed by someone who takes over the mailbox. Those are reasons to avoid putting reusable passwords in them; it is inaccurate to say that all email is unencrypted.
Use an approved credential-sharing or enrollment process. For a new account, prefer a provider's invitation or password-setup flow to a message containing a permanent password. Never ask someone to send you their MFA codes as a substitute for proper delegation.
Lock the workstation as well
A named login does little for accountability if other people can use the same unlocked session. Set an inactivity lock appropriate to the work environment and have staff lock their screens when stepping away. Plan for shared desks and reception areas where several people may use the same equipment.
Check application sessions too. Signing out of Windows does not necessarily revoke a session on a different device.
Write a policy people can follow
Keep it specific: how to request access, who approves it, where approved shared secrets belong, and how to report accidental disclosure. Make the approved process practical enough that people can use it during an absence or urgent handover.
For password-system design, NIST SP 800-63B covers controls such as screening new passwords against commonly used or compromised values. Its requirements have a defined scope; citing NIST does not establish that every business follows the same legal or insurance obligations.
Pair these access rules with an MFA rollout and recovery plan and a contractor offboarding checklist.
Let’s talk