Table of Contents
Hiring a contractor – whether a web developer, a virtual assistant, a bookkeeper, or a social media manager – means sharing access to business systems. And sharing access means sharing credentials. The way you handle this handoff determines whether you maintain security or create vulnerabilities that persist long after the engagement ends. This guide is part of our Password Management for Business & Freelancers series, and it provides step-by-step procedures for securely granting, managing, and revoking contractor access.
Why Contractor Handoffs Are a Security Risk
Every contractor engagement creates a temporary expansion of your attack surface. For the duration of the project, another person has access to your business systems – systems that may contain customer data, financial information, or proprietary content. The risks are specific and measurable:
Credential persistence. When a contractor receives a password via email, that password exists in both your and their email accounts indefinitely. Even after the engagement ends, the credential persists in both inboxes, in email backups, and potentially in search indexes.
Access creep. Projects evolve. A contractor who originally needed access to the staging server might be given production access “just this once.” A virtual assistant who needed the social media login might also receive the analytics password, then the ad account credentials. Without tracking, the scope of shared access grows beyond what is necessary or remembered.
Offboarding gaps. When a project ends, both parties are focused on deliverables, invoicing, and moving on. Revoking credential access is often an afterthought – or forgotten entirely. A study by OneLogin found that 48 percent of organizations take more than a day to deprovision accounts for departing workers, and 20 percent take more than a week.
No audit trail. If you shared the company WordPress password with a contractor three months ago and the site is defaced today, can you determine whether the contractor still had access? Without a system, you probably cannot.
Before the Engagement: Preparation
Security in contractor handoffs starts before you share the first credential.
Inventory What Needs to Be Shared
Before the contractor starts work, list every system and credential they will need access to. Be specific:
- What system? (e.g., WordPress admin, AWS staging environment)
- What level of access? (e.g., editor role, not administrator)
- For how long? (e.g., duration of the two-month project)
- Is a separate user account available, or must you share the existing credential?
This inventory becomes your access control document – a simple spreadsheet or list that you update throughout the engagement and use as a checklist during offboarding.
Prefer Separate Accounts Over Shared Credentials
Whenever a service supports multiple user accounts, create a separate account for the contractor rather than sharing your own credentials. This approach:
- Creates an audit trail of the contractor’s actions (distinct from yours)
- Allows you to revoke access by disabling one account without affecting anyone else
- Prevents the contractor from knowing your personal credentials
- Gives you control over the permission level the contractor receives
Most modern SaaS tools, CMS platforms, and cloud infrastructure services support multiple users with role-based access. WordPress has user roles (Editor, Author, Contributor). AWS has IAM users with granular policies. Slack has guest accounts. Use these features.
For systems that support only a single login – some legacy software, certain social media platforms, shared email accounts – you will need to share the actual credential. In those cases, the secure sharing methods below apply.
Set Up a Contractor KeePass Database
If the contractor will need ongoing access to multiple credentials throughout the engagement, create a dedicated KeePass database (.kdbx file) containing only the credentials they need. This approach:
- Provides all shared credentials in a single, encrypted container
- Allows you to update credentials in one place and have the contractor see the changes
- Creates a clear record of exactly what was shared
- Makes revocation clean: change the database master password, and the contractor loses access to everything at once
Share the .kdbx file through a cloud sync service (a shared folder in iCloud Drive, Dropbox, or Google Drive). Communicate the master password through a separate channel – in person, over a phone call, or via a self-destructing encrypted message. Never send the database file and its password through the same channel.
PanicVault and other KeePass-compatible apps can open this shared database alongside the contractor’s own personal database, keeping the scopes clearly separated.
During the Engagement: Sharing Credentials Securely
Methods for One-Time Credential Sharing
For sharing a single credential or a small number of credentials:
Self-destructing encrypted messages. Several services let you create a link that displays a secret once and then permanently destroys it. Generate the link, send it to the contractor through your normal communication channel (email, Slack), and the actual credential is never exposed in the channel itself – only the link, which becomes useless after the first view.
Phone or video call. For high-sensitivity credentials, communicate them verbally. The contractor types them directly into their password manager during the call. Nothing is written down or transmitted through a digital channel.
In person. For local contractors, sharing credentials face-to-face is the most secure method. The contractor enters the credential into their password manager while you watch, and no digital record of the transmission exists.
Methods to Avoid
Email. Never send passwords through email. Email is stored in plaintext on multiple servers, backed up indefinitely, and searchable. An email from six months ago containing “the staging server password is X” is a breach waiting to happen.
Chat messages. Slack, Teams, Discord, and similar tools store messages indefinitely and make them searchable. Sharing a password in a DM is equivalent to posting it on a bulletin board that anyone with workspace access can read.
Text messages. Stored on carrier servers, backed up in device backups, and vulnerable to SIM swapping attacks.
Shared documents. A Google Doc titled “Passwords” with a list of credentials is one of the most common and most dangerous patterns in small business operations.
Tracking Shared Access
Maintain a simple log of what you have shared with each contractor. In your password manager, you can create a note entry for each contractor with:
- Contractor name and engagement dates
- List of systems/credentials shared
- Method of sharing and date
- Access level granted
- Planned revocation date
This log takes seconds to update and is invaluable during offboarding.
Managing Access During the Project
Monitoring
For systems that provide access logs (cloud platforms, CMS admin panels, analytics tools), periodically review the contractor’s activity. This is not about distrust – it is about maintaining situational awareness and catching potential issues early. If you see login attempts from unexpected locations or actions outside the project scope, you can address them promptly.
Scope Changes
When the project scope changes and the contractor needs access to additional systems:
- Update your access inventory
- Share the new credential through a secure method
- Document the addition in your tracking log
- Set a reminder to revoke this additional access when it is no longer needed
Credential Rotation During Engagement
If you need to rotate a credential that a contractor has access to (due to a suspected compromise, compliance requirements, or regular rotation policy), update it in the shared KeePass database and notify the contractor. If you shared the credential through a one-time method, re-share the new credential through the same type of secure channel.
Ending the Engagement: The Offboarding Protocol
This is the most critical phase. A clean offboarding protects both you and the contractor.
Step 1: Complete the Deliverables
Before revoking access, ensure all deliverables have been received and any final work is complete. Locking a contractor out of systems they still need creates friction and may require re-sharing credentials – which doubles your exposure.
Step 2: Inventory Audit
Review your access tracking log. List every credential and system the contractor had access to. Cross-reference with the original inventory and any additions during the project. This list is your offboarding checklist.
Step 3: Revoke Separate Accounts
For systems where you created a separate account for the contractor:
- Disable or delete the contractor’s user account
- Verify they can no longer log in (test if possible)
- Check for any API keys or tokens associated with their account and revoke those too
- Review the account’s recent activity for anything unexpected
Step 4: Rotate Shared Credentials
For systems where you shared your own credentials:
- Change the password to a new, unique password generated by your password manager
- Update the credential in your vault
- If the credential was in a shared KeePass database, either remove it or update it (the contractor will lose access if you change the database master password)
- Verify the new password works
- If the system supports it, review active sessions and terminate any that the contractor might have open
Step 5: Change the Shared Database Password
If you used a shared KeePass database, change its master password. This instantly locks the contractor out of every credential in the database. Distribute the new master password to any remaining team members who need access.
Step 6: Revoke File Access
If you shared the .kdbx file through a cloud storage folder, remove the contractor’s access to that folder. Remove their access to any other shared files or folders that were part of the project.
Step 7: Confirm and Document
Send the contractor a brief message confirming that the engagement has concluded and that you have rotated all shared credentials. This serves as both a professional courtesy and documentation. Ask them to confirm that they have deleted any credentials they stored locally.
Document the offboarding in your records:
- Date of offboarding
- List of credentials rotated
- List of accounts deactivated
- Confirmation sent to contractor
- Any notes on open items
Step 8: Follow-Up Review
Two weeks after offboarding, review access logs on critical systems to verify no unauthorized access has occurred. This is a simple spot-check that catches any gaps in the offboarding process.
Special Cases
Long-Term Contractors
For contractors you work with repeatedly over months or years, the shared KeePass database approach works well as an ongoing arrangement. Treat the contractor like a part-time team member: include them in credential rotation schedules, update their access when project scopes change, and maintain a current inventory of their access.
Multiple Contractors on One Project
When multiple contractors work on the same project:
- Each contractor gets access only to the credentials they specifically need (principle of least privilege)
- Use the shared database approach with separate databases per access level if needed
- Coordinate offboarding to avoid revoking access that another contractor still needs
- Maintain separate tracking logs for each contractor
Contractors Bringing Their Own Credentials
Sometimes a contractor creates accounts on your behalf – setting up a new service, registering a domain, or creating API keys. Ensure the contract specifies that all accounts and credentials created during the engagement are the property of your business. At offboarding, the contractor should transfer these credentials to you and confirm they have not retained copies.
Emergency Contractor Termination
If you need to terminate a contractor engagement immediately (due to misconduct, suspected breach, or other urgent reasons):
- Change all shared credential master passwords immediately
- Disable all separate accounts the contractor had
- Revoke file sharing access
- Rotate every shared credential (may take hours – prioritize by sensitivity)
- Review access logs for suspicious activity
- Document everything
- Consult with legal counsel if necessary
Building Handoff Procedures Into Contracts
Consider adding a credential management clause to your contractor agreements that covers:
- How credentials will be shared (approved methods only)
- The contractor’s obligation to store credentials securely (encrypted password manager required)
- Prohibition on sharing credentials with unauthorized third parties
- The contractor’s obligation to delete credentials at the end of the engagement
- Your right to audit access and request confirmation of credential deletion
- Ownership of any accounts or credentials created during the engagement
This clause does not need to be lengthy, but putting these expectations in writing protects both parties and prevents ambiguity.
The Right Tool for the Job
PanicVault’s use of the KeePass format makes contractor handoffs practical. The ability to create separate, encrypted database files – each with its own master password, each containing only the credentials relevant to a specific engagement – maps directly to the access control needs of contractor management. The open format means the contractor can use PanicVault, KeePassXC, Strongbox, or any compatible application to access the shared database, regardless of their platform.
For detailed information on structuring your overall approach to business password management, see our pillar guide and the companion article on password policies.
