Vendor wants permanent remote access? Ask these questions first

TL;DR — If a vendor asks for permanent remote access, treat that as a design choice that needs justification, not a default requirement. In most cases, the safer answer is time-limited, scoped access through a bastion host (a controlled jump server), VPN (private network tunnel), SSO (single sign-on), or ticket-based approval instead of a standing admin account that never expires. Reading time: ~7 min

What it is and where it sits

"Permanent remote access" usually means a vendor wants an always-available path into your environment: a VPN account, a remote desktop login, an SSH key (server login credential), a database user, an admin seat in your SaaS app, or an API token (machine credential) that does not expire.

From a Privileged Access Management perspective, this matters because the vendor is asking for a standing privilege: access that exists all the time, whether they are actively working or not. Standing privilege is convenient, but it increases the blast radius (how much damage one mistake or compromise can cause).

In a typical setup, the vendor is not part of your normal employee identity flow. Your staff might sign in through your identity provider (the system that handles company logins), use MFA (a second factor like an authenticator app), and get role-based access. A vendor asking for permanent access is often asking to bypass some part of that normal path, or to be added to it indefinitely.

What it replaces:

• Instead of "open a ticket and approve access for 4 hours," it replaces that with "they can log in anytime."
• Instead of "screen-share while your team performs the action," it replaces that with direct control.
• Instead of "temporary database credential for this maintenance window," it replaces that with a long-lived username/password or key.

Where it lives in the request/data flow depends on the type of access:

• Network layer: VPN, allowlisted IPs (only approved internet addresses can connect), private link.
• Host layer: SSH, RDP (Remote Desktop Protocol), remote support agent.
• Application layer: admin user in your CMS, ERP, CRM, or cloud dashboard.
• Data layer: database user, storage bucket access, backup console access.

A common pattern looks like this:

[Vendor User] ---- 1. login request ----> [Access Gateway]
[Access Gateway] ---- 2. MFA + policy ----> [Identity Provider]
[Access Gateway] ---- 3. approved session ----> [Target System]
[Target System] ---- 4. logs/events ----> [Audit Log]

The risky version removes the gateway and approval step:

[Vendor User] ---- direct permanent login ----> [Target System]
[Target System] ---- partial/no logs ----> [Audit Log]

That is the core question: do they need a controlled path for occasional support, or are they asking for an always-open door?

How it actually works

Here is one realistic end-to-end example.

Example: a software vendor says they need permanent database and server access for support

You run a web application for your business. It has:

• a public website,
• an application server,
• a Postgres database,
• a cloud dashboard where backups and instances are managed.

The vendor says: "To support you properly, we need permanent SSH access to the server and a permanent database admin user."

A safer design would work like this instead:

1. The vendor opens a support ticket describing the task: for example, "apply a hotfix" or "investigate failed background jobs."
2. Your team approves a time window: for example, today from 2:00 PM to 4:00 PM.
3. Access is granted through a controlled entry point:
   • either a VPN account enabled only for that window,
   • or a bastion host that records sessions,
   • or a temporary admin role in your cloud dashboard,
   • or a temporary database credential.
4. The vendor authenticates with MFA using their named account. Not a shared "support" login.
5. They reach only the systems needed:
   • maybe SSH to one app server,
   • read-only database access first,
   • no access to production backups unless the task requires it.
6. Their actions are logged:
   • login time,
   • source IP,
   • commands run or admin actions taken,
   • who approved the session.
7. Access expires automatically at the end of the window.
8. If they need recurring access, you review the pattern. If they need weekly access to one admin page, that may justify a narrow permanent role there. It does not automatically justify permanent server and database admin.

The questions to ask before you approve anything

Ask these in plain language:

1. What exact task requires this access? Ask for a list: server shell, database, cloud console, application admin, file transfer, logs.
2. Why must it be permanent rather than time-limited? Good answers are rare. "For convenience" is not enough.
3. What is the minimum access level needed? Read-only, one server, one database schema, one admin area, one environment.
4. Is this for production, staging, or both? If they can work in staging, start there.
5. Will they use named user accounts with MFA? Reject shared accounts like support@vendor used by multiple people.
6. Can access go through our SSO or VPN? If yes, you keep control when staff changes or the contract ends.
7. How will activity be logged and reviewed? If there is no audit trail, assume you will not know what happened during an incident.
8. What happens when the contract ends or a vendor employee leaves? You want a simple offboarding step: disable account, remove group, revoke key.
9. What data could they see or export? Customer records, financial data, health data, secrets, backups.
10. What safer alternative did they consider? Screen-share, temporary access, break-glass account (emergency account), monitored session.

If they cannot answer these clearly, the request is not ready for approval.

When to use it (and when not to)

Permanent vendor access is sometimes justified, but much less often than vendors imply.

You probably don't need permanent remote access if:

• support requests happen a few times per quarter,
• the vendor mainly needs screenshots, logs, or screen-sharing,
• the work can be done in staging first,
• your internal team can perform the action while the vendor guides them,
• the vendor cannot support MFA, named accounts, or audit logging.

Trade-offs

Every benefit has a cost.

• Benefit: faster support response
  Cost: more standing risk if the account is stolen, forgotten, or over-privileged.

• Benefit: less coordination for maintenance
  Cost: weaker change control; work may happen without a ticket, approval, or business context.

• Benefit: vendor can diagnose issues directly
  Cost: broader data exposure, including customer data, secrets, and backups.

• Benefit: fewer delays during emergencies
  Cost: emergency access tends to become permanent unless someone owns periodic review.

• Benefit: simpler for the vendor
  Cost: operational burden shifts to you: account lifecycle, audit review, contract wording, and incident handling.

• Benefit: one account works for everything
  Cost: lock-in and poor separation of duties (different sensitive tasks should not all use one credential).

A good compromise is often: permanent path, temporary privilege. Example: the vendor can always reach your access gateway, but actual production admin rights require approval and expire automatically.

In practice

Below are two practical patterns you can adapt.

Example 1: Time-limited SSH access with an expiring key on a Linux server

⚠️ Editing SSH settings can lock everyone out of a server if done incorrectly. If this is a production server, test on a staging server first or keep an existing admin session open while you validate the new configuration.

If you do manage your own server, avoid a permanent shared password. Add a named vendor key, then remove it after the maintenance window.

# On the server, create a dedicated account for the vendor
sudo adduser vendor_alice

# Create the SSH folder with correct permissions
sudo mkdir -p /home/vendor_alice/.ssh
sudo chmod 700 /home/vendor_alice/.ssh
sudo chown -R vendor_alice:vendor_alice /home/vendor_alice/.ssh

# Paste the vendor's public key into authorized_keys
sudo nano /home/vendor_alice/.ssh/authorized_keys
sudo chmod 600 /home/vendor_alice/.ssh/authorized_keys
sudo chown vendor_alice:vendor_alice /home/vendor_alice/.ssh/authorized_keys

This creates a named account for one person and allows key-based login. The gotcha: if the vendor sends you a private key instead of a public key, stop and ask again; you should only ever receive the public key.

When the window ends, remove the key or lock the account:

# Lock the account immediately
sudo usermod -L vendor_alice

# Or remove the key-based login
sudo truncate -s 0 /home/vendor_alice/.ssh/authorized_keys

This cuts off access without deleting logs tied to that username. The gotcha: locking the account is safer for audit history than deleting it immediately, because you keep a record of who had access.

Example 2: Narrow database access instead of full admin

⚠️ Database privilege changes can expose sensitive data or break applications if applied to the wrong user or database. Double-check the database name and role before running these commands.

If the vendor only needs to inspect one schema in Postgres, create a read-only role instead of giving them a superuser account.

CREATE ROLE vendor_readonly LOGIN PASSWORD 'replace-with-strong-random-password' VALID UNTIL '2026-12-31 23:59:00';
GRANT CONNECT ON DATABASE appdb TO vendor_readonly;
GRANT USAGE ON SCHEMA public TO vendor_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO vendor_readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO vendor_readonly;

This allows login and read-only queries on current and future tables in the public schema. The gotcha: ALTER DEFAULT PRIVILEGES only affects objects created afterward by the role that runs the command, so test with your actual ownership model.

If the vendor no longer needs access, revoke it cleanly:

ALTER ROLE vendor_readonly NOLOGIN;
REVOKE ALL PRIVILEGES ON DATABASE appdb FROM vendor_readonly;

This disables future logins first, then removes rights. The gotcha: if applications or scripts were quietly using this account, they will fail immediately, so do this in a planned window.

Dashboard-first actions to ask your team for

If you do not have shell or database access yourself, ask your provider or agency to use the control panel path first:

• In your cloud provider's dashboard, look for Identity / IAM → Users or Roles and request a named vendor user with an expiry date.
• In your VPN or access tool, look for Users → Groups / Policies and request a vendor group limited to one environment.
• In your SaaS admin panel, look for Settings → Users / Roles and request the lowest role that fits the task, not full owner/admin.
• In your DNS or firewall provider's dashboard (for example, provider dashboard → network access rules), avoid broad allowlisting of the vendor's office IP unless there is no better option; IPs change and do not identify a person.

Further reading

• NIST SP 800-63 Digital Identity Guidelines
• NIST SP 800-207 Zero Trust Architecture
• CIS Controls v8, Access Control Management
• PostgreSQL Documentation, "GRANT" and "ALTER DEFAULT PRIVILEGES"
• OpenSSH Manual Pages, sshd_config and authorized_keys

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