Topic starter
13/10/2026 1:21 pm
TL;DR: Teleport argues that third-party access to data centers often relies on shared SSH keys, VPN credentials, and standing privileges that create credential sprawl, weak attribution, and lateral movement risk. The fix is not more access paths but identity-bound, time-limited access that expires with the task and records every session.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport.
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.
Key questions
Q: What breaks when infrastructure access still depends on a VPN and direct private keys?
A: The control boundary becomes too wide.
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.
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.
Practitioner guidance
- Use zero standing privilege for vendors Require every external session to begin with a request and approval, then expire automatically when the task ends.
- 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.
Bottom line: Third-party access to data centers is risky when SSH keys, VPNs, and shared accounts persist beyond the task and blur accountability.
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
👉 Read Teleport's blog post on secure third-party remote access to data centers without SSH keys →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
13/10/2026 1:22 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Third-party data center access fails when credentials outlive tasks