Prefer systems over messages
The strongest workflow lets the receiving workload obtain a credential without a person copying it. Cloud workload identity, short-lived federation, deployment-platform secret stores, and dedicated secrets managers reduce the number of humans and devices that ever see plaintext.
Manual delivery is still common during client onboarding, incident recovery, and integration setup. Treat it as a temporary exception with an owner and a rotation deadline.
Minimize the credential before sharing
Create a new credential specifically for the recipient and environment. Then reduce its blast radius:
- Grant only the API operations and resources that are required.
- Restrict source networks, redirect URLs, or application identities when supported.
- Set an expiry or rotation date.
- Use separate production, staging, and development credentials.
- Give the credential a descriptive owner and purpose in the issuing system.
Use an encrypted delivery path
Put only the minimum secret and context in the Relay. Do not bundle unrelated credentials. Use a one-time link with a short expiry, add a passphrase for production access, and deliver that passphrase through a verified secondary channel.
Avoid sending the secret beside its account URL, username, customer name, and full operational context. Separating those pieces makes a single intercepted message less useful.
Complete the handoff
The recipient should move the secret directly into an approved secrets store, not a local notes file or shell history. Confirm access, remove unnecessary copies, and rotate promptly if the link was retrieved by the wrong party or forwarded outside the intended channel.
Finally, monitor use at the issuing service. One-time delivery reduces storage exposure; provider-side audit logs are what tell you whether the credential is being used as intended.