OpenTech ConsultingLet’s talk
Insights

Shared Passwords: How to Delegate Access Safely

By OpenTech Consulting · · 3 min read

Updated

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:

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.

Sources and references

  1. Microsoft: About shared mailboxes

    Shared mailbox access, permissions, and sign-in considerations.

  2. NIST SP 800-63B: Authentication and authenticator management

    Password blocklists, authenticator types, phishing resistance, and recovery requirements within the guideline’s scope.

  3. Microsoft: Revoke user access

    Account disabling, session and token behavior, and application-specific access revocation.

← All insights