Give a vendor temporary access safely and remove it afterward

TL;DR — The safest way to give a vendor temporary access is to create a separate account for them, give it the smallest role that can do the job, set an expiry reminder, and remove it as soon as the fix is confirmed. Do not share your own login or turn off security controls; use your provider's user-management screen first, and only use direct server access if the fix truly requires it. Reading time: ~5 min

Goal

When you finish, the vendor will have their own temporary account with only the permissions needed to fix the issue, you will know exactly where to remove that access, and you will be able to confirm afterward that the access has been revoked.

Prerequisites

• Your admin login for the affected system or hosting/dashboard account
• Permission to manage users, team members, or collaborators in that system
• The vendor's email address for a named person, not a shared mailbox
• A short written scope of work, for example: "fix 500 error on checkout" or "update DNS for email delivery"
• An end time for access, for example: "remove by 2026-10-31 17:00 local time"
• If server access is truly required: the server provider login or SSH public key (a public half of a login key) from the vendor
• If database access is truly required: the database admin screen or connection details and permission to create a read/write user

Steps

Step 1: Write down exactly what the vendor needs to touch

Create a short note in your ticket, email, or internal doc with these exact lines and fill in the values:

System: <app/admin/hosting/database>
Task: <exact fix requested>
Access needed: <viewer/editor/admin/server/database>
Start: <YYYY-MM-DD HH:MM timezone>
End: <YYYY-MM-DD HH:MM timezone>
Vendor user email: <name@vendor.com>
Owner who will remove access: <your name>

You should see a single clear scope with a named person and a removal time.

Step 2: Create a separate vendor account in the dashboard

In the affected product's admin area, open the user management screen in your provider's dashboard, for example:

Dashboard → Settings → Users
Dashboard → Team → Members
Admin → Access Control → Invite User

Use these literal values when available:

Email: <vendor person's email>
Name: <vendor person's full name>
Role: Viewer, Support, Developer, or the lowest role that can do the task
Access expiration: <your end date/time>
MFA required: On

If your dashboard has no expiration field, create a calendar reminder with this exact title:

Remove vendor access for <system name> — <vendor email> — <YYYY-MM-DD HH:MM timezone>

You should see the vendor listed as "Invited", "Pending", or "Active" with a role lower than full owner/admin whenever possible.

Step 3: Restrict access to only the needed project, site, or environment

Open the scope controls in the same dashboard, for example:

Dashboard → Projects → <project name> → Members
Dashboard → Sites → <site name> → Access
Dashboard → Environments → Staging → Team Access

Apply these literal choices:

Project access: Only <project/site name>
Environment access: Staging only
Production access: Off
Billing access: Off
User management access: Off
API key management: Off

If the vendor must work in production, set:

Environment access: Production only
Billing access: Off
User management access: Off

You should see the vendor attached only to the specific project/site/environment, not your whole account.

⚠️ Server or database access can cause downtime or data loss if the wrong commands are run. Use the dashboard-user method above unless the vendor explicitly needs direct infrastructure access.

Step 4: If direct server access is required, add a temporary SSH key instead of sharing a password

In your server provider's dashboard, open the SSH key or instance access screen, for example:

Provider Dashboard → Compute/Servers → <server name> → Access → SSH Keys

Paste the vendor's public key exactly as provided, for example:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleOnlyReplaceThis vendor-name@laptop

Label it with this exact pattern:

vendor-<company>-<person>-expires-<YYYY-MM-DD>

If you only have shell access, add the key to a separate user account, not your own:

sudo adduser vendorfix
sudo mkdir -p /home/vendorfix/.ssh
sudo chmod 700 /home/vendorfix/.ssh
sudo bash -c 'cat >> /home/vendorfix/.ssh/authorized_keys' <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleOnlyReplaceThis vendor-name@laptop
EOF
sudo chmod 600 /home/vendorfix/.ssh/authorized_keys
sudo chown -R vendorfix:vendorfix /home/vendorfix/.ssh

You should see the new key or user account listed separately from your own account.

Step 5: If database access is required, create a separate limited user

Open your database control panel first, for example:

Hosting Dashboard → Databases → <database name> → Users → Add User

Use these literal values:

Username: vendor_fix_<yyyymmdd>
Password: generate a new random password in the dashboard
Privileges: Read/Write on <application database only>
Drop/Delete schema privileges: Off
Admin/Superuser: Off

If you must use PostgreSQL CLI, run:

psql "$DATABASE_URL" <<'SQL'
CREATE USER vendor_fix_20261030 WITH PASSWORD 'REPLACE-WITH-LONG-RANDOM-PASSWORD';
GRANT CONNECT ON DATABASE appdb TO vendor_fix_20261030;
GRANT USAGE ON SCHEMA public TO vendor_fix_20261030;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO vendor_fix_20261030;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO vendor_fix_20261030;
SQL

You should see a new database user with access only to the intended database and no superuser/admin rights.

Step 6: Send the access details and the expiry in one message

Send this exact template to the vendor by email or in your ticket system:

You have temporary access to: <system/project/environment>
Purpose: <exact task>
Account: <vendor email or username>
Access starts: <YYYY-MM-DD HH:MM timezone>
Access ends: <YYYY-MM-DD HH:MM timezone>
Restrictions: <staging only / no billing / no user management / no production shell>
Please confirm when the fix is complete so access can be removed.

You should see one message that states what they can access and when it ends.

Step 7: Remove access when the fix is done

In the same dashboard where you added the user, go back to the user/member list:

Dashboard → Settings → Users → <vendor user> → Remove
Dashboard → Team → Members → <vendor user> → Revoke Access

If you added an SSH key, remove that exact key label:

Provider Dashboard → Compute/Servers → <server name> → Access → SSH Keys → Delete vendor-<company>-<person>-expires-<YYYY-MM-DD>

If you created a Linux user, run:

sudo pkill -u vendorfix || true
sudo userdel -r vendorfix

If you created a PostgreSQL user, run:

psql "$DATABASE_URL" -c "DROP USER vendor_fix_20261030;"

You should see the vendor no longer listed in users/members, and any temporary key or account removed.

Verify it works

Check all three of these:

1. In the dashboard, the vendor user is gone or marked revoked:

Dashboard → Settings → Users

Expected result: the vendor is not listed as Active.

1. If server access was granted, the old account no longer works. From your shell:

id vendorfix

Expected result:

id: 'vendorfix': no such user

1. If database access was granted, the temporary user no longer exists:

psql "$DATABASE_URL" -c "\du"

Expected result: vendor_fix_20261030 is not in the role list.

[You] ---- 1. invite limited user ----> [System]
[Vendor] <---- 2. accepts invite ---- [System]
[Vendor] ---- 3. fixes issue ----> [System]
[You] ---- 4. revoke access ----> [System]

Common pitfalls

Giving the vendor your own login

Mistake: sharing your username, password, or one-time code instead of creating a separate account.

Symptom: you cannot tell who changed what, and you cannot remove only the vendor later.

Fix: create a new named user in Dashboard → Settings → Users and change your own password if you already shared it.

Granting owner/admin when editor/support would do

Mistake: selecting the highest role because it is faster.

Symptom: the vendor can see billing, users, secrets, or unrelated projects.

Fix: edit the user and change Role to the lowest role that still allows the task, then restrict them to one project/environment.

Forgetting the removal date

Mistake: inviting the vendor and planning to "remove it later" without a date.

Symptom: the account stays active for weeks or months after the fix.

Fix: set the dashboard expiry if available, or create the calendar reminder in Step 2 before sending the invite.

Adding access to the whole account instead of one project

Mistake: inviting the vendor at the top account/team level.

Symptom: they can open other sites, apps, or environments unrelated to the issue.

Fix: remove the broad membership and re-add them under Projects/Sites/Environments → <specific item> → Members.

Sharing a server password instead of an SSH key

Mistake: sending the root or admin password by email or chat.

Symptom: the password may be reused, forwarded, or impossible to rotate cleanly without affecting others.

Fix: change the shared password now, then add the vendor's public SSH key to a separate user as shown in Step 4.

Leaving temporary database users behind

Mistake: creating vendor_fix_* and never dropping it.

Symptom: old credentials continue to work even though the ticket is closed.

Fix: run DROP USER <temporary_user>; after the fix and verify with \du that the role is gone.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.