Password sharing in remote teams: where credentials leak

In a remote team, a password is rarely sent once. Someone pastes it into a Slack DM, which is indexed, kept under the workspace’s retention settings and included in exports. Someone else forwards the email it arrived in. A third person reads it out on a recorded call, and the meeting assistant writes it into the notes. Every copy outlives the moment it was needed.

Remote working didn’t create the problem; it made every conversation happen in tools designed to store and search what’s said. The fix is to keep credentials out of those tools: store shared ones in a password manager, hand them over with links that delete themselves, and change any that have already leaked. The rest of this page is about doing that in practice.

Where shared passwords end up

Chat. Slack and Microsoft Teams keep messages for as long as the workspace’s retention settings say, which in many organisations is indefinitely. A password in a channel can be found by anyone in that channel with a search for “password”. Workspace owners can export it, compliance tools such as Microsoft Purview can surface it, and any bot or integration added to the conversation may receive it. In a shared channel with a client (Slack Connect, or a Teams shared channel) the message is also subject to the other organisation’s retention and admins.

Email. A password sent by email can be read by far more people than the one you addressed it to. Everyone in CC and BCC, and everyone on the distribution list if you sent it to one. Anyone the recipient forwards it to, which you can’t control. Colleagues with access to a shared or delegated mailbox. The mail administrators at both organisations. Journaling, archives, backups and eDiscovery exports, some of them kept for years. Every phone and laptop the message syncs to. And whoever compromises any of those accounts later: searching a mailbox for “password” is one of the first things an attacker does, and a forwarding rule can quietly copy everything that arrives afterwards. A one-time link shrinks that list to one person, once, before it expires. Our guide to why not to send passwords over email or Slack goes through each of these in detail.

Tickets and documents. Jira comments, Zendesk tickets, Confluence and Notion pages are visible to everyone with access to the project or space, kept indefinitely and indexed. Support desks have a particular version of this: customers send their own credentials in tickets, and the ticket is then visible to every agent.

Calls. Teams and Zoom recordings, transcripts and AI-generated meeting notes capture whatever is said or shown. A password read aloud ends up in a transcript; a password manager entry shown during a screen share ends up in the recording.

Devices. Notes apps, clipboard history (Windows keeps one, and can sync it across devices), personal phones, and home machines that also belong to someone’s family.

Find the copies that already exist

Before changing how people share credentials, find out what’s already out there. An hour spent searching is usually revealing.

• Slack: search for password, pwd, passcode, login, creds, api key and token. Narrow with in:#channel or from:@person. Look at direct messages with contractors and clients as well as channels.
• Teams and Outlook: search the same terms in chats and in Sent Items. If you have Microsoft Purview, content search can run across mailboxes and chats at once.
• Jira: the JQL query text ~ "password" searches summaries, descriptions and comments. Zendesk and Confluence have equivalent full-text search.
• Code: run a secret scanner such as gitleaks or trufflehog over your repositories, or turn on GitHub secret scanning. Credentials pasted “temporarily” into config files are common.

When you find one, change the credential. Deleting the message is worth doing, but it doesn’t undo exports, notifications, email previews or the copies other people made. Rotation is what makes the leaked copy useless.

A routine that leaves nothing behind

1. Shared credentials live in a password manager. Each item has an owner, responsible for changing it. If people need it repeatedly, this is its only home.
2. Handover to anyone outside the vault is by one-time link. One view, an expiry of hours rather than days, and for anything with admin rights, a passcode sent by a different channel. One-time links vs password managers explains where each tool fits.
3. Credentials coming in are requested, not asked for in chat. When a client or supplier needs to send you a login, a secret request gives them a one-time form and the result lands in your account rather than a DM.
4. Passwords are never read out or shown on a recorded call. If someone needs one during a meeting, send a link and let them open it off screen.
5. When someone leaves, their shared credentials change. The vault tells you which items they could see. Do it on their last day, not when someone remembers.

Contractors and leavers

Remote offboarding has fewer natural checkpoints: there’s no desk to clear and no laptop handed back in person. Disabling someone’s identity provider account removes most of their access in one step, but not to shared logins they knew, accounts registered to their personal email, or authenticator apps on their own phone. Those need a list and an owner. Accounts protected by 2FA are the awkward ones; handing over a shared account that uses 2FA goes through it step by step.

For contractors, give access an end date when you grant it. A one-time link with a 24-hour expiry is a much smaller commitment than a guest seat in your password manager that nobody removes.

Make the safe way the quick way

People paste passwords into chat because it’s the fastest option in front of them, not because they don’t know better. A rule that adds friction loses to a deadline. Two things help:

• Make the right tool one step away. A pinned link to your secret-sharing tool in the team channel, and a short note in the onboarding pack saying what to use for what.
• Set the defaults centrally. If links should expire within a day and need a passcode, configure that once rather than relying on everyone to remember. In ShareShield, organisation policies do this: the send form is pre-filled and locked to your limits, and the API rejects anything outside them.

Then repeat the search above every few months. If it keeps finding passwords, the routine is too slow for the people using it, and that’s the thing to fix.