How to Secure Third-Party Remote Access to Data Centers (Without SSH Keys)

Whether it’s vendors diagnosing GPU driver failures or network technicians troubleshooting switch configurations, organizations are often ready to do whatever it takes to get their infrastructure back to normal.

For some, that may mean defaulting to the fastest access path available for third-party access, such as shared SSH keys, VPN credentials, or screen-sharing sessions. But in critical data center environments, these workarounds create credential sprawl and identity fragmentation that attackers can exploit.

---

Challenges of third-party remote access to data center infrastructure

Native cloud identity and access stops at the cloud

Cloud has native identity. On-premises infrastructure does not.

This means that when a third-party needs access to a cloud account, they can be assigned a role tied to their identity. AWS, GCP, and Azure can all bind API calls, permissions, and audit logs to these authenticated identities.

On-premises infrastructure has no equivalent for third-party access. SSH uses long-lived keys to access servers, baseboard management controller (BMC) web interfaces sit behind VPNs or on flat management networks, Windows servers use shared service accounts — even database access uses connection strings with embedded credentials. Handing any of these over to an external user creates significant risk.

Shared credentials create risk and identity blindspots

Credentials like SSH keys don’t expire on their own, and are not bindable to a specific task or time period. So while a third-party user who accesses an AWS resource might assume a temporary role, a vendor who accesses hardware in your data center may be authenticating through whatever static credentials they’ve been handed, resulting in persistent access and untraceable audit logs.

This risk can significantly increase your attack surface. In Teleport’s 2026 Infrastructure Identity Survey, 67% of organizations report high reliance on static credentials (such as passwords, API keys, long-lived tokens) — with those same organizations reporting a 20-percentage-point higher incident rate than organizations with low reliance on static credentials (67% vs. 47%).

VPNs grant network access, not resource-level access

A VPN places a third-party user on the network, but it does not restrict what they can reach once connected. This means that any vendor who needs access to a single switch or database server is instead handed an entire network segment. From there, lateral movement is only constrained by whatever internal controls exist downstream.

Third-party VPN profiles are also not always scoped appropriately per engagement. For example, the credentials and tunnel configuration used for last quarter's maintenance window might be reused for next quarter's, regardless of whether the task requires it. And because VPN authentication is session-based rather than identity-based, audit logs may only capture that a tunnel was established, not which resources were accessed or what commands were executed within the session.

---

How to secure third-party access without SSH keys, VPNs, or standing privileges

The risks above share a common root: credentials that outlive the task, and identities that can't be traced back to a specific individual or action. Teleport solves both by bringing the same model cloud infrastructure already enforces — every session tied to a verified identity, scoped to a specific task, and time-limited by default — to every on-prem resource a vendor needs to touch.

Just-in-time (JIT) access with explicit approval workflows

The default state for external remote access to production or customer-owned infrastructure should be zero standing privileges. This means that third-party users should never have access to resources or elevated privileges until it is specifically requested.

Instead, remote access to on-prem resources should always begin with a request, pass through an approval gate, and expire when the task ends. This just-in-time (JIT) access model follows the same pattern as the cloud model where a customer grants a cross-account IAM role for a support engagement.

Teleport makes zero standing privileges and JIT the default state for third-party access, which means that all privileges are scoped to the requested resource, automatically expire when the task ends, and that every session is attributed to a cryptographic identity in the audit log.

Authenticate third parties through their own identity provider

Rather than provisioning internal accounts in your directory, authenticate third parties and vendors through their own corporate SSO, or through a supported external identity provider such as Okta, Entra ID, Google Workspace, or GitHub. This approach has several benefits, including eliminating the overhead associated with creating, managing, and deprovisioning internal accounts for every vendor engagement.

Authenticating third parties this way also allows you to map third-party or vendor IdP groups to specific access rules using role-based access control (RBAC) or attribute-based access control (ABAC). These allow you to granularly define what hardware or network resources the external user’s group membership can access without creating internal accounts.

Teleport is identity-provider-neutral and supports SAML, OIDC, JWT, and SCIM, ensuring vendor identity is always owned by the vendor and not your team. SCIM keeps access current automatically as people join, change roles, or leave the vendor's organization, with no manual cleanup on your side.

Issue short-lived certificates instead of long-lived credentials

SSH keys, VPN credentials, and shared passwords are long-lived by default, and can be shared or stored beyond the scope of the initial task. Replacing these with short-lived certificates that are tied to an authenticated identity ensures that any privileges third-parties are granted automatically expire upon task completion.

Binding certificates to the third party’s SSO identity also ensures that all commands and queries that occurred can trace back to a named individual, rather than a shared account or otherwise unidentifiable user.

Teleport issues short-lived x.509 certificates that are bound to an authenticated identity, replacing SSH keys, VPN credentials, and passwords across SSH, Windows Remote Desktop Protocol (RDP), Kubernetes, and database protocols.

Restrict third-party privileges to the specific resources for the task

Third parties should only be able to access the resources they need for the task they are performing. For example, a GPU hardware vendor should only see nodes in a diagnostic state; a network vendor should only see the switches they maintain.

To do so, use labels derived from hardware properties, software state, or customer ownership to define specific third-party access boundaries. This will ensure a vendor is not granted fleet-wide access for a single-node problem, and prevent potentially exposing thousands of resources that have nothing to do with the task at hand.

Teleport uses label-based RBAC to scope vendor access to only the resources that match their role including hardware traits, resource state, customer ownership, or partner organization. Because labels are dynamic, a vendor's accessible resource list reflects current infrastructure states. This ensures any node that exits a vendor-relevant state drops out of their view and is inaccessible at their next connection.

Automatically revoke/expire third-party privileges

Just-in-time access also requires that privileges are automatically revoked. After being granted, a third-party user’s access should expire without manual intervention through time limits on access grants and removal of vendor access paths when the resource returns to a defined production state.

Teleport automatically expires access based on a Time to Live (TTL) (which can be configured from minutes to days) or resource state changes, like when a node exits a vendor-relevant state.

Record all third-party sessions and commands

Every third-party access session should automatically produce a recording that captures the identity of the operator and all commands executed during the session, including SSH, RDP, and Kubernetes commands.

While standard SSH logging records the connection itself, it does not record what actually happened inside the session. For example, an engineer or contracted technician may run a script that executes dozens of commands as child processes that do not appear in standard connection-level logs. Kernel-level session recordings and logs (captured through eBPF) close this visibility gap by logging actual system calls, not just what was typed into the terminal.

Teleport captures session recordings using eBPF for kernel-level command capture for SSH, RDP, Kubernetes, and database sessions. Each session and command is attributed to a cryptographic identity in the audit log, eliminating the identity and visibility blind spots that shared credentials and anonymous sessions create.

---

How to implement secure third-party access effectively

Each of the best practices above can be implemented independently. However, doing so typically means managing separate tools for session recording, JIT approval workflows, certificate issuance, and resource access across SSH, bastions, RDP gateways, and database proxies.

When all six are in place, every third-party session starts with a verified identity, routes through an approval workflow, issues short-lived privileges scoped to the specific resources required for the task, records every command at the kernel level, and expires automatically when the task ends — with no shared credentials or standing privileges, and every action attributed to a cryptographic identity in the audit log.

Teleport establishes a unified identity layer for infrastructure, eliminating credential sprawl, standing privileges, and anonymous access paths across SSH, RDP, Kubernetes, databases, web applications, and cloud providers. This ensures every vendor session is governed, auditable, and attributed to a unique cryptographic identity.

Learn more about how Teleport unifies identity across on-prem, cloud, and hybrid infrastructure.

---

---

About the author: Mayur Pipaliya (MP) is known for his expertise in trusted computing and identity-first infrastructure for hybrid cloud and AI. Across 19+ years, he has charted a trailblazing path, from being an accidental entrepreneur running a data center company in the pre-cloud era to founding Splunk's Global Forward Deployed Software Engineering (FDSE) team and leading platform engineering, DevRel/DX, CNCF OTel open source, and AI/ML marketplace functions that helped scale data products to $4B in revenue. MP advises enterprises on modernizing data centers and multi-cloud, multi-agent strategy, and volunteers with DEFCON, OWASP, null Security, Columbia's Justice Through Code, and Habitat for Humanity. When not firefighting, he loves trail running and biking in the Bay Area

---

Related resources

→ Guide: How to Unify Identity Across Cloud and Data Center Infrastructure
→ Unified Identity for Your Entire Data Center
→ Privileged Access for Modern Infrastructure: The Top Four Challenges
→ Teleport Use Case: Just-in-Time Access