How to share credentials safely, by credential type

Most access does not need to be sent anywhere. It needs to be granted. Nearly every serious business system lets you invite a person by email and give them a role, and when you do that, three things improve at once.

• The other side signs in as themselves, with their own password and their own second factor. Nothing of yours is copied.
• Revoking is one click, and it works immediately — no rotating, no wondering who else has the password.
• The audit log names a person. When something changes at 3am, “who did this” has an answer instead of “the shared account”.

Sharing a login instead throws all three away, and the reason it happens is almost always that nobody checked whether an invite existed. Check first. It usually does.

For these, there is a correct route that does not involve a secret leaving your side at all. If you find yourself typing one of these into a message, stop — there is a better path.

• Anything that connects over OAuth — a CRM, an accounting tool, a spreadsheet, a mailbox. The integration is authorised from your account by clicking through a consent screen. You approve the connection; you never reveal the password behind it.
• Platforms with role-based invites: Google Workspace and Google Analytics, Google Ads, Meta Business Manager, Slack, HubSpot, and almost every modern SaaS. Send an invitation with the smallest role that does the job.
• Server access over SSH. The other side generates a key pair and sends you the public half, which is meant to be public. A private key that travels has stopped being a private key.
• Banking, payment processors and anything that moves money. This is not a matter of finding a safe channel — it is the line an automation project does not need to cross. If a workflow has to touch payments, it goes through the platform's API with scoped credentials, never through a login.

Some things cannot be granted, only copied. These are real secrets and they need real handling — but the handling starts before the sending, with how the secret is created.

• API keys and access tokens. Create a dedicated key for the integration rather than reusing an existing one, give it only the permissions the workflow needs, and set an expiry if the vendor offers one. A key nobody else uses can be revoked without breaking anything else.
• Service-account key files — the JSON files Google Cloud and similar platforms issue. These are files, not strings, and they carry whatever the service account can do. Create a new service account for the project and grant it the narrowest role that works.
• Webhook signing secrets. These verify that an incoming notification really came from the system it claims to — the mechanism described in types of webhooks and how to use them. Treat them exactly like keys.
• Database credentials. Make a separate user, read-only where reading is all that is needed, and restrict it by IP address if the database supports it. The application's main user should never be the one handed over.
• A shared password, when the system genuinely has no multi-user support. This is the worst case, not the default one — and it is worth checking the vendor's pricing page before accepting it, because multi-user access is often a plan away rather than genuinely absent.

Once you have accepted that something must travel, the channel matters more than the ceremony around it. In order of preference:

• A shared vault in a password manager — 1Password, Bitwarden, or whatever the business already runs. The secret lives in one place, access to it is granted and revoked like any other permission, and both sides can see what was shared.
• A one-time secret link that self-destructs after being opened and expires on its own. Good when there is no shared vault yet, because the secret does not sit in anyone's history afterwards.

And the list that matters more: never email, WhatsApp, a Slack DM, a shared Google Doc, a spreadsheet, a screenshot, or a comment on a ticket. Every one of those persists indefinitely, gets forwarded, gets backed up, and survives the person leaving the company. A password sent over chat in March is still sitting in that thread in December, readable by anyone who later gains access to either account.

One habit worth dropping: splitting a secret across two channels — the password in email, the code over WhatsApp — is theatre unless the two channels have genuinely different security. Two apps on the same unlocked phone are one channel.

Sharing a TOTP seed — the QR code or the string behind an authenticator app — is the quietest mistake in this whole subject. It does not grant temporary access. It clones the second factor permanently, into an app you cannot see and cannot revoke without resetting the whole thing.

In order of preference:

• Use the vendor's real multi-user support, so each person has their own second factor. This is the only option that keeps two-factor meaning what it says.
• Store the seed in a shared vault that generates the codes, so at least the access is revocable and visible.
• Share the seed directly — a last resort, and one worth naming honestly: from that moment the account has one factor, not two.

SMS-based two-factor is its own problem at handover, because the code arrives on somebody's personal phone. That person becomes a dependency for every login, including the ones that happen while they are on holiday.

Some values look like secrets and are not. Publishable client-side keys, Google Analytics measurement IDs, public webhook endpoints and most tracking identifiers are designed to sit in a page's source code where anyone can read them.

Knowing the difference is not pedantry. Wrapping public values in ceremony wastes everyone's time, and it does something worse: it teaches a team that the ceremony is noise. The people who insist on a secure channel for a measurement ID are usually the same ones who eventually paste a real API key into a chat, because by then the process has stopped meaning anything.

Keep a short record of what was granted. Not a security document — a few columns that answer the questions you will actually need answered later.

• Which system, and which account or key inside it.
• What level of access it carries.
• When it was granted, and by whom.
• Whether it was an invitation or a secret that travelled — because those are undone differently.

Without this, revocation is guesswork, and guesswork at revocation time means access quietly persisting for years. It is also the same list a build needs anyway: the integration checklist covers the questions to ask about a system before connecting it, and this record is where those answers end up.

A project ends, a contractor moves on, someone changes roles — and the access stays. This is not an unusual failure; it is the normal outcome, because nothing prompts anyone to undo what was set up months earlier.

When an engagement closes, work through the record:

• Remove the invitations and the user accounts, and confirm they are gone rather than assuming.
• Rotate every secret that travelled. A key that was sent once exists forever in somebody's message history, so revoking their account does not retire the key.
• Delete service accounts created for the project, along with their key files.
• Remove the entries from the shared vault, so the next person who opens it sees only live credentials.
• Check for tokens the integration itself created — OAuth connections, webhook subscriptions, app passwords. These outlive the person who set them up and are the ones most often missed.

The one that surprises people is the rotation. Removing someone's access feels like the job is done, but the secrets they were sent are still valid, still copied, and still sitting wherever they were delivered.

Access is one of the three things that decide whether a process can be automated at all — which is why it is a question in the automation fit assessment rather than a detail left to the build. A workflow whose systems nobody can open is not a scoping problem; it is a blocker no budget solves.

Doing the handover properly also pays back later, in a way that is easy to miss at the start. Credentials expire, get rotated, and get revoked by someone who did not know what depended on them — and each of those breaks an automation at an hour nobody is watching. Knowing exactly which credential is where turns that from an outage into a five-minute fix, which is the practical side of building failure-ready automations.

None of this needs to be heavy. A shared vault, invitations instead of shared logins, a dedicated key per integration, and a list of what was granted will cover almost every project — and it can be agreed in the first conversation, which is how our process treats it.