Third-party data center access fails when credentials outlive tasks

At a glance

What this is: This is a practical analysis of third-party remote access to data centers, showing that SSH keys, VPNs, and standing privileges leave persistent, hard-to-audit access paths.

Why it matters: It matters because IAM and PAM teams need governance patterns for external operators that preserve task-level access, attribution, and revocation across on-premises infrastructure.

By the numbers:

• 67% of organisations report high reliance on static credentials, and those organisations report a 20-percentage-point higher incident rate than low-reliance organisations, according to Teleport's 2026 Infrastructure Identity Survey.

👉 Read Teleport's blog post on secure third-party remote access to data centers without SSH keys

Context

Third-party remote access becomes an identity governance problem when the access method is built around shared secrets or network reach rather than a verified person, a specific task, and a bounded time window. In data centers, that gap is especially visible because there is no native cloud-style identity layer to bind every action to a named external operator.

The article describes a common operational failure mode: teams restore service by handing vendors SSH keys, VPN access, or shared accounts that persist beyond the engagement. That model creates credential sprawl, weak auditability, and an expanded attack surface across infrastructure that should be tightly scoped.

For IAM and PAM programmes, the issue is not whether a vendor needs access, but whether that access can be issued, constrained, observed, and revoked as cleanly as internal privileged access.

Key questions

Q: What breaks when infrastructure access still depends on a VPN and direct private keys?

A: The control boundary becomes too wide. Users can reach the network before access is scoped to a specific server or database, which makes entitlement review, session audit, and least privilege harder to enforce. The result is broad connectivity with weak task scoping, which is exactly where infrastructure access becomes difficult to govern.

Q: Why do static third-party credentials increase security risk in data centers?

A: Static credentials increase risk because they outlive the engagement and are not naturally tied to a specific operator, resource, or time window. That means one handed-over secret can become recurring access, weak audit evidence, and a larger attack surface. The control problem is not just authentication, but lifetime and scope.

Q: How do security teams know whether outsourced access is actually controlled?

A: Look for evidence of time-bound access, documented ownership, regular entitlement reviews, and clean offboarding. If external users retain access after milestones close, or if logins and file activity diverge from expected patterns, controls are not working. Effective programmes can show when access was granted, why, and when it was removed.

Q: What is the difference between just-in-time access and a VPN for external vendors?

A: Just-in-time access is a governed privilege model that grants only the needed resource and time-bound authority, while a VPN mainly creates network presence. A VPN can place a vendor on the network without restricting what they can reach. JIT narrows the privilege itself, which is the control that matters for third-party infrastructure access.

Technical breakdown

Why shared SSH keys and VPNs create identity blind spots

SSH keys, VPN credentials, and shared passwords are durable credentials, not task-scoped identities. Once issued, they can be copied, reused, or left active after the original work is done, which makes attribution and revocation difficult. VPNs add another problem: they grant network adjacency rather than resource-level access, so the operator can often reach far more than the job requires. In on-prem environments, that combination creates a control gap between authentication and actual authorization at the resource boundary.

Practical implication: replace shared access paths with identity-bound controls that tie each session to a named external operator and a specific resource.

How just-in-time third-party access changes the control model

Just-in-time access changes third-party access from a standing entitlement into a request-driven privilege grant. The access request, approval, and expiry boundaries matter more than the login event itself, because the privilege should exist only for the task duration. In a strong model, the operator authenticates through their own identity provider, receives a short-lived certificate or equivalent credential, and is limited by role- or attribute-based rules that define exactly which resources are in scope. This is a governance pattern, not just a tooling pattern.

Practical implication: define third-party access as an approval-bound workflow with automatic expiry, not as a reusable account or static network tunnel.

Why session recording and dynamic scoping are the real audit controls

Session recording closes the visibility gap left by connection-level logs. If a vendor opens a tunnel or starts an SSH session, that alone does not show what commands were run, what data was touched, or whether child processes performed additional actions. Kernel-level recording and dynamic resource labels solve different parts of the problem: one captures the evidence, the other constrains where the operator can go. Together they move auditability from a coarse access record to an action-level record tied to the individual session.

Practical implication: require per-command recording and dynamic scoping for any external access to production or customer-owned infrastructure.

Threat narrative

Attacker objective: An attacker wants persistent, hard-to-trace access to infrastructure through credentials that outlive the maintenance task and blur accountability.

1. Entry occurs when a third party is given a shared SSH key, VPN credential, or shared account to restore infrastructure quickly.
2. Escalation follows when that credential is reused beyond the original task and opens access to more systems than the vendor actually needs.
3. Impact is expanded attack surface, weak attribution, and lateral movement potential across data center resources that were never meant to be broadly reachable.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared third-party credentials are not a convenience problem, they are a governance failure. Once access is handed out as a reusable key or tunnel, the organisation loses task scoping, operator attribution, and clean revocation. That is why external access to data centers behaves more like uncontrolled entitlement drift than controlled privileged access. The practitioner conclusion is simple: if the credential can outlive the task, the governance model is already broken.

Identity-bound access is the only model that makes on-premises third-party access auditable. Cloud platforms already bind actions to authenticated identities, but data centers often still rely on static secrets and network paths. That mismatch creates an identity blind spot between approval and action. The implication is that external access must be anchored in verified identity, not in possession of a shared secret or a VPN profile.

Third-party access without session evidence creates a permanent accountability gap. Connection logs tell you that a tunnel existed, but not what the operator did inside it. Kernel-level session capture changes the evidentiary standard from connection presence to command execution. Practitioners should treat missing session evidence as a control deficiency, not a logging preference.

Dynamic scoping is the named concept this article exposes: access should shrink to the live resource state, not expand to the whole maintenance boundary. A vendor supporting one faulty node should not see an entire fleet, and a maintenance window should not turn into a standing entitlement. When resource labels change, access should follow the state change. The practitioner conclusion is to govern third-party privilege by live resource state, not by static engagement assumptions.

Zero standing privilege for third parties is becoming a baseline expectation for critical infrastructure. The article shows that organisations can no longer justify persistent vendor access when short-lived, approved, identity-bound sessions are available. That does not remove the need for operational support. It raises the bar for how support is granted, recorded, and revoked. The practitioner conclusion is to design third-party access as a time-bounded exception, not as a durable operating mode.

From our research library:

• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: Third-Party, B2B and Contractor Access Guide

What this signals

Dynamic scoping is the control shift most data center teams still miss: external access should follow the live resource state, not the vendor’s historical maintenance relationship. When a node leaves a vendor-relevant state, the access path should disappear with it, or the programme is still operating with lingering entitlement assumptions.

The access model needs to move from reusable credentials to identity-bound sessions because auditability is lost the moment the organisation cannot say which human performed which command. That is especially true where third parties touch SSH, RDP, databases, and Kubernetes in the same operational workflow.

Third-party exposure remains a board-level concern because organisations expose NHIs to third parties at scale, and the control failure usually begins with convenience-based access decisions rather than with the breach itself.

For practitioners

• Use zero standing privilege for vendors Require every external session to begin with a request and approval, then expire automatically when the task ends. Do not let vendors retain reusable access between maintenance windows.
• Replace shared credentials with identity-bound certificates Issue short-lived certificates tied to the vendor’s own identity provider so commands, queries, and access grants can be attributed to a named individual.
• Scope access by resource state and ownership Use labels for hardware state, customer ownership, or partner role so each vendor sees only the nodes or systems relevant to the current task.
• Record every third-party session at the command level Capture SSH, RDP, database, and Kubernetes activity with recordings that show what actually happened inside the session, not just that the session existed.
• Revoke access when the maintenance state changes Tie access expiry to time limits and to resource-state changes so a system leaving vendor-relevant status immediately drops out of the vendor’s view.

Key takeaways

• Third-party access to data centers is risky when SSH keys, VPNs, and shared accounts persist beyond the task and blur accountability.
• The article’s core control pattern is short-lived, identity-bound access with approval, resource scoping, and session evidence, not broader network reach.
• The main governance lesson is to treat external access as a time-bounded exception that must expire, be attributed, and shrink with the live resource state.

Key terms

• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Session Recording: Session recording is the capture of user activity during a privileged session, such as commands, queries, or administrative actions. It gives security and audit teams a verifiable record of what happened after authentication, which is essential when access itself is not enough to prove control.
• Identity-bound access: Access that is issued to a specific human, workload, or agent and can be traced back to that identity in logs and audit evidence. In NHI governance, this is the difference between knowing a credential was used and knowing exactly who or what performed the action.

What's in the full article

Teleport's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step configuration patterns for JIT approvals across SSH, RDP, Kubernetes, and databases
• Implementation examples for label-based RBAC that scope external access by hardware state and ownership
• How short-lived x.509 certificates replace shared SSH keys and VPN credentials in practice
• Kernel-level session recording details using eBPF for command capture and attribution

👉 The full Teleport post covers JIT workflows, short-lived certificates, and kernel-level session recording in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.