Secure Credential Sharing for MSPs and IT Support
Best practices for managed service providers and IT support teams handling client credentials securely.
Managed Service Providers (MSPs) and IT support teams handle some of the most sensitive data in any organization: administrator passwords, API keys, database credentials, and root access tokens. A single leaked credential can compromise an entire client's infrastructure. This guide covers how to share these credentials securely while maintaining operational efficiency.
The MSP credential challenge
MSPs face a unique security paradox: they need access to everything to do their job, but that access creates enormous risk. A typical MSP might manage domain admin credentials for dozens of clients, cloud console access (AWS, Azure, GCP) with root privileges, database credentials for production systems, API keys for critical integrations, SSL certificates and private keys, and VPN and firewall configurations.
Each of these credentials needs to be shared with team members, documented for emergency access, and sometimes delivered to clients. Traditional methods like email or shared documents create unacceptable risk.
Common credential sharing scenarios
Client to MSP. Clients need to provide initial access credentials when onboarding. This often includes domain admin, cloud console access, and existing service accounts.
MSP to client. After provisioning services, MSPs deliver new credentials back to clients: new user accounts, application passwords, or API keys.
Internal team sharing. Technicians need to share credentials for escalations, shift handoffs, or collaborative troubleshooting.
Emergency access. Critical credentials need to be accessible during emergencies when the primary administrator isn't available.
Best practices for MSP credential security
Never email credentials
This seems obvious, but email remains the most common way credentials are shared. Emails persist in sent folders, inboxes, and backups indefinitely. Email threads get forwarded, exposing credentials to unintended recipients. Email isn't encrypted by default in transit. Compromised email accounts expose historical credentials.
Instead, use one-time links for all credential sharing. Send the link via email if needed—the actual credential is encrypted and auto-deletes after viewing.
Use passphrase protection for high-value credentials
For domain admin, root, or cloud console credentials, add an extra layer. Create the one-time link with a passphrase, send the link via the primary channel (email, ticket), and communicate the passphrase via a different channel (phone, SMS, video call). This ensures that even if one channel is compromised, the credential remains protected.
Verify credential receipt
Always confirm that the intended recipient accessed the credential. With one-time links, if the recipient says they didn't receive it but the link has been viewed, you know it was intercepted.
Document without storing credentials
Your documentation should reference that credentials exist and how to obtain them, not the credentials themselves. For example: "Domain admin credentials stored in password manager under Client X folder" or "AWS root access: request from security team, 2FA via john@company.com." Never write the actual password in documentation.
Workflow: Secure client onboarding
When collecting credentials from new clients:
- Send the client a link explaining how to create a secure one-time link at burnthesecret.com
- Have the client create separate links for each credential type (domain admin, cloud console, etc.)
- Retrieve each credential and verify it works before the link expires
- Immediately transfer to your secure credential storage
- For highly sensitive access, rotate the password after secure storage
Workflow: Delivering credentials to clients
After provisioning new services:
- Generate a secure link for each credential you need to deliver
- Set appropriate expiration times (24-72 hours gives clients time to retrieve)
- Include the links in your service delivery email with clear labeling
- Note in the ticket that credentials were delivered via one-time link
- Follow up to confirm the client successfully retrieved the credentials
API integration for automation
For MSPs with high volume credential sharing, Burn the Secret's API enables automation. You can integrate with PSA tools to auto-generate credential links during provisioning, automatically include secure links in onboarding email templates, and create links programmatically when scripts generate new credentials.
See our API documentation for integration details.
Compliance considerations
One-time links help MSPs meet various compliance requirements. For SOC 2, they demonstrate secure credential handling with an audit trail. For HIPAA, they protect PHI-adjacent credentials with encryption and auto-deletion. For PCI DSS, they ensure payment system credentials aren't stored insecurely. For GDPR, they minimize data retention of credential communications.
Ready to secure your MSP's credential sharing? Create a secure link on Burn the Secret.