How to share temporary access with vendors safely

Temporary access is a permanent security problem — unless you handle it right

Every business eventually needs to give an outside party access to an internal system. A vendor configuring a software integration. A specialist auditing your infrastructure. A contractor completing a specific deliverable. A consultant reviewing your data.

Temporary access, handled carelessly, becomes permanent exposure. The vendor finishes their work, the engagement ends, but the credential you shared via email is still sitting in your sent folder and their inbox. Months later, when that vendor has a breach, your systems are at risk from credentials they should no longer have.

The four principles of secure vendor access

1. Least privilege: Give vendors access only to what they need for the specific task. A developer integrating an API does not need admin access to your billing system. Define the minimum access required before creating any credentials.

2. Time-bounded credentials: Where possible, create credentials that expire automatically. Many platforms allow creating temporary API tokens, time-limited admin accounts, or guest access with a defined end date. Use these instead of sharing your permanent admin credentials.

3. Secure delivery: Whatever credential you create, deliver it via a one-time encrypted link rather than email or chat. This ensures the credential does not persist in communication channels beyond the moment of delivery.

4. Mandatory rotation after engagement ends: When the vendor's work is complete, change any passwords that were shared. Do not rely on the vendor to "not use" credentials they still technically have. Rotate the credential and the risk disappears.

A step-by-step vendor access workflow

1. Define the access scope before creating any credentials — write down exactly what systems and permissions the vendor needs
2. Create a dedicated account or token for the vendor where possible, rather than sharing an existing admin account
3. Send the credential via a one-time link with an expiry window aligned to when the vendor expects to begin work (24–48 hours is typical)
4. Confirm the vendor received access — a brief message ("Did you get in? Any issues?") creates a record and catches scanner-consumption problems early
5. Set a reminder to rotate the credential on the engagement end date — put it in your calendar or task system now, not later
6. Rotate and confirm revocation — after rotation, optionally verify with the vendor that they can no longer access the system

What to do if you have skipped these steps in the past

Many businesses share credentials with vendors informally for years without incident. If you are now tightening up your practices, the priority order is:

1. Identify current active vendor access — who has credentials to what systems right now?
2. Rotate any credentials that were shared via email or chat
3. Remove vendor accounts for engagements that have ended
4. Implement the workflow above for all future vendor access

This is not a one-time cleanup but a habit to build into every future vendor engagement.

The documentation piece

Keep a simple log of vendor access: vendor name, systems accessed, credentials created, date shared, expected end date, date credentials were rotated. This does not need to be sophisticated — a shared spreadsheet or a field in your project management tool is sufficient.

This log is valuable if you ever face a security incident and need to understand your attack surface, or if you are subject to a security audit.

Share vendor credentials securely with PassTransfer →