What happens when password-sharing happens over email or chat instead of a password manager?

Why email or chat is the wrong place for shared credentials

When a password moves through email or chat, it stops behaving like a secret and starts behaving like a message. That creates extra copies, search indexes, notification previews, retention archives, and forwarding paths. A password manager is designed to reduce those copies and keep access controlled without exposing the credential in ordinary conversation channels.

The practical difference is not just convenience. A password manager supports deliberate sharing, revocation, and visibility around who can reach the secret, while email and chat spread the credential into systems built for communication rather than secret handling. That is why organisations should treat message-based sharing as an exposure event, not a harmless shortcut.

What changes when the secret lives in a thread

Email and chat create a wider and less predictable blast radius than a dedicated vault. The password may be visible to the original recipient, anyone with mailbox or workspace access, anyone who can search the archive, and sometimes anyone with access to synced devices or exports. If the thread is forwarded or copied into another channel, the original owner loses track of where the secret now exists.

That also weakens accountability. In a password manager, access can usually be granted to specific people or groups and then removed later. In a message thread, the organisation often has no clean way to prove who saw the password, when they saw it, or whether a past participant still has access through retained copies. If you need a broader overview of choosing and operating a vault, the Password Manager Buyer's Guide is the most direct starting point.

It also creates lifecycle problems. A password sent in chat is hard to recover from cleanly because you cannot easily rotate the thread itself, only the credential. That is why shared-secret handling needs to be treated as a governance issue, not just an etiquette issue, especially when the same account is used across teams or vendors.

What good practice looks like instead

Use a password manager when multiple people must reach the same account, because it preserves the secret in a controlled vault and reduces the number of accidental copies. If the real requirement is collaboration, choose a tool that supports delegated access, shared vaults, or role-based sharing rather than revealing the password itself.

For teams that still rely on shared accounts, the first question is whether the password is being used because the process is weak or because the account design is weak. A shared credential is often a symptom of missing role separation, poor offboarding, or an application that still depends on a single login for too many people. If you are setting a policy baseline, use the Password Policy Template to align shared-account handling with stronger password and MFA expectations.

When people use chat to exchange secrets, they often do it because it feels faster than opening the vault. That shortcut is usually the wrong trade-off. If the account matters enough to protect, it matters enough to handle through a system that supports access control, traceability, and revocation.

Risk and Threat Considerations

Message-based sharing increases the chance that a password is exposed beyond the intended recipient and retained in places the account owner does not control. It also makes later cleanup harder, because the secret may have been copied into archives, forwarded threads, mobile notifications, or synced backups before anyone notices.

Failure mechanism: The credential is stored in a communication system that replicates content by design, so the secret can be intercepted, searched, forwarded, or recovered from retained message data after the original exchange.

Impact: Unauthorised access becomes more likely, and incident response becomes slower because the organisation has to assume the password may have leaked into multiple uncontrolled copies that must be found and rotated.

Practitioner Guidance

What to verify: Confirm whether the account is being shared because the application lacks proper delegated access, or because the team has chosen convenience over control. If the second is true, the fix is process change, not just a reminder to “be careful.”

Decision rule: If a password has already been sent through email or chat, treat it as potentially exposed and rotate it before trusting the account again. If the thread also contained MFA recovery codes, backup codes, or other secret material, treat those as exposed too.

What good looks like: Shared access is granted through a vault or approved workflow, the secret itself is never posted in conversation tools, and revocation can be done without chasing down every copy of a thread.

Practitioner takeaway: The key question is not whether the password was sent in a “private” message, but whether the channel preserves secrecy, limits copies, and supports revocation. Email and chat generally do not.

Related resources from NHI Mgmt Group

• Password Sharing
• What breaks when login sharing happens through messaging apps or email instead of a controlled vault?
• What happens when a managed service provider relies on user memory instead of a password manager and authentication controls?
• What happens when organisations rely on password sharing instead of controlled access?