Guide: How to Unify Identity Across Cloud and Data Center Infrastructure

Organizations that operate servers across data centers, cloud accounts, and colocated environments face a problem that grows with each site they add: identity fragmentation.

If an engineer needs access to infrastructure in ten locations, it's highly likely that the identity and access systems governing those locations exist in ten separate configurations. Each new site or cloud deployment also creates thousands of new credentials, adding new paths and additional attack vectors.

What causes identity fragmentation in cloud and data center environments

As organizations grow, employees (human and non-human) and infrastructure scales, it becomes harder and harder to understand who has access to what infrastructure — let alone reduce the complexity of access paths to key critical infrastructure resources.

Cloud providers create identity silos

A single cloud provider gives you one identity domain. For example, AWS IAM governs who can do what across your AWS accounts; Azure Entra ID does the same for Azure. This means that credentials, policies, and logs are siloed within each cloud environment.

Organizations that run infrastructure across AWS, a private data center, and a colocation facility now operate three identity systems with no shared trust root. An engineer who needs to patch a server in AWS, restart a process on a bare-metal node in Indianapolis, and check logs on a GPU host in Amsterdam must now authenticate three times through three different systems.

On-prem infrastructure has no default identity framework

Cloud providers like AWS assign identity to every resource through IAM, which ensures that each EC2 instance, Lambda function, and RDS database has an Amazon Resource Name (ARN), belongs to a role, and participates in a policy evaluation chain.

Bare-metal servers in a private data center have none of this. A server that boots from a PXE image and runs an OS from RAM has no identity until someone installs an agent, distributes a key, or configures a certificate. GPU hosts, baseboard management controllers (BMCs), data processing units (DPUs), and network switches all expose access endpoints. None of them participate in a shared identity system by default.

This forces infrastructure teams to create identities manually for on-prem resources using static credentials that persist and drift, such as SSH keys.

Static credentials sprawl in hybrid environments

These static, manually distributed credentials create significant risk — particularly as infrastructure expands.

In Teleport's 2026 Infrastructure Identity Survey, 67% of organizations polled reported a heavy reliance on static credentials such as passwords, API keys, and long-lived tokens. Those same organizations also reported a 20-percentage-point increase in security incidents compared to those with low static credential reliance.

Hybrid, multi-site environments typically have a higher reliance on static credentials (such as SSH keys or database passwords) than cloud-native environments. As a result, these environments carry a higher risk of security incidents, often stemming from:

• Engineers sharing SSH keys (.pem files) because managing individual keys to thousands of servers is operationally challenging.
• Service accounts using long-lived tokens because short-lived issuance requires infrastructure that does not exist on-prem.
• Incomplete offboarding, requiring revoking credentials on every server that was accessed.

VPNs and bastions address the network, not identity

When static credentials can't be eliminated, network controls become the default protection layer: VPNs to restrict who can reach servers, and bastion hosts to funnel SSH connections through a single chokepoint. But while these tools can reduce the network attack surface, they can also further expand the sprawl and fragmentation of static credentials and identity across systems.

Because a VPN authenticates the user once at the network boundary, the user is then free to move laterally using whatever credentials exist on the servers. VPNs also do not provide visibility into which servers the user accessed, what commands were run, or whether a shared or static credential was used.

How to unify identity across cloud and data center infrastructure

The following sections cover five ways to shift access decisions from the network boundary to the identity layer — hardware-rooted trust, short-lived certificates, SPIFFE for workload identity, reverse tunnels, and protocol-level enforcement — and how Teleport’s Infrastructure Identity Platform implements these practices directly.

Start by anchoring identity to a hardware root of trust

Cloud providers bind identity to infrastructure through their own mechanisms, such as AWS instance profiles, GCP service accounts, or Azure managed identities. On-prem infrastructure needs an equivalent anchor.

There are two mechanisms that can provide this:

1. TPM-based joining: Servers with a Trusted Platform Module (TPM) chip can attest their identity using a hardware-rooted key that cannot be extracted from the chip. A server boots, presents its TPM public key to the certificate authority (CA), and receives a certificate without any static join token distributed in advance.

2. JWT federation for Kubernetes: Kubernetes clusters issue JSON Web Tokens (JWTs) signed by the cluster's service account signing key. A CA that trusts a cluster's signing key can issue certificates to workloads running in that cluster based on their JWT, eliminating static join tokens for Kubernetes-based infrastructure.

Teleport supports TPM joining, Kubernetes JWT joining, and AWS IAM joining methods natively, allowing organizations to enroll on-prem servers, Kubernetes clusters, and cloud resources into a single certificate authority without distributing static join tokens. For AWS resources that need to participate in an on-prem identity system, AWS IAM Roles Anywhere enables X.509 certificates issued by Teleport to assume IAM roles. This bridges the cloud-to-on-prem identity gap in the opposite direction: your on-prem CA becomes a trust anchor for AWS access.

Eliminate static, long-lived credentials with short-lived certificates

Eliminating the risks of static credentials across hybrid environments at scale requires an equally scalable authentication and authorization — such as issuing short-lived certificates to every user, machine, workload, and AI agent.

To accomplish this, Teleport acts as a certificate authority (CA), issuing short-lived certificates to users and machines that contain the identity of the holder, the permissions granted, and an expiration time. When the certificate expires, access ends without requiring a revocation list or credential rotation. Because Teleport is the single source of trust, a user only needs to authenticate once through an SSO provider (such as Okta, Entra ID, or Google Workspace).

Each certificate also encodes the identity’s group memberships as access permissions, granting appropriate access to servers, Kubernetes clusters, databases, and applications, ensuring no shared or static SSH keys, database passwords, or tokens are being distributed. For machines and workloads, Teleport issues certificates to automation processes, CI/CD pipelines, and service-to-service communication. Teleport's machine identity agent, tbot, handles automatic certificate issuance and renewal for CI/CD pipelines, automation processes, and service accounts without requiring static credentials or human intervention.

Use SPIFFE for workload-to-workload identity

SPIFFE (Secure Production Identity Framework for Everyone) defines a standard for issuing identity documents to workloads. A SPIFFE-compatible certificate authority like Teleport issues SVIDs (SPIFFE Verifiable Identity Documents) as X.509 certificates or JWTs. Workloads then use those SVIDs for mutual TLS (mTLS) authentication between services.

SPIFFE identities are not tied to any cloud provider, making this approach ideal for hybrid environments. Workloads running in AWS, a private data center, and a bare-metal GPU host can all receive SVIDs from the same certificate authority, and can authenticate without cloud-specific credentials.

For example, organizations that run microservices across cloud and on-prem boundaries can use SPIFFE to replace service account tokens, API keys, and shared secrets with certificates that automatically expire and renew without human intervention. Implementations like Teleport Workload Identity handle automatic SVID renewal and workload attestation natively, eliminating bootstrapping secrets without requiring custom tooling.

Eliminate VPNs and bastions with reverse tunnel architecture

Network-layer controls exist to compensate for the absence of strong identity at the infrastructure layer. But once every user and machine has a certificate-based identity, the network boundary becomes less relevant.

Teleport’s reverse tunnel architecture replaces inbound network access with outbound connections. Instead, an agent on each server initiates an outbound connection to a proxy, which does not require opening ports (such as 22, 2220, or 31337) on the server's network or poking holes through the firewall. Instead, users connect to the proxy, the proxy authenticates the user and enforces role-based access control (RBAC), and then routes the connection through the reverse tunnel with a full session log tied directly to identity.

Related Article: Reverse Proxy: How It Works & Example Architecture

Enforce identity at the protocol level instead of the network level

Once inside the network with a VPN, a user can reach any port on any server. Enforcing identity at the protocol-level using short-lived certificates eliminates this risk and allows for more granular access control.

Teleport enforces these protocol-level controls using short-lived certificates and role-based access, giving engineers access only to the specific resources their role permits while producing identity-based audit events for every session. For example:

Teleport multiplexes every protocol (SSH, Kubernetes, databases, Git, web/TCP, and RDP) over a single TLS port using ALPN (Application-Layer Protocol Negotiation) and SNI (Server Name Indication) routing. The proxy inspects the TLS handshake to determine which backend protocol the client wants to speak, then routes the connection accordingly.

Key takeaways for solving identity fragmentation

Unifying identity across hybrid infrastructure requires applying several best practices:

• Using hardware-rooted identity to ensure that access to hybrid and on-prem infrastructure is not reliant on human identity alone, but is combined with unique hardware signatures and identity backed by TPM or JWT.
• Establishing a shared certificate authority that issues short-lived certificates to every user, machine, and workload, and applying SPIFFE for workload identity across cloud and on-prem boundaries.
• Finally, using reverse tunnels to eliminate VPNs and bastion hosts, and protocol-level enforcement to replace network-level access controls.

Organizations that implement these practices can eliminate credential sprawl, simplify engineer access across sites, and produce identity-linked activity logs — regardless of how many data centers or cloud instances they operate.

Discover how Teleport unifies identity across data centers and cloud deployments.

---

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 articles

→ Top Use Cases and Trend in Machine & Workload Identity
→ From Zero Trust to SPIFFE: How to Secure Microservices with Istio and Teleport
→ Privileged Access for Modern Infrastructure: The Top Four Challenges
→ Teleport Use Case: Infrastructure Resiliency for Growth and Scale