What should IAM teams do when cloud and data centre workloads use different identity primitives?

Standardise the governance model even if the token formats differ. Use a common identity policy, logging, and lifecycle approach across environments, then translate into the credential type each platform accepts. That prevents environment-specific exceptions from becoming permanent overprivilege paths and makes workload identity governable at enterprise scale.

Why This Matters for Security Teams

When cloud and data centre workloads rely on different identity primitives, IAM teams often end up with two governance models instead of one. That creates policy drift, inconsistent logging, and exceptions that quietly become permanent. The operational risk is not the token format itself, but the fact that the same workload can be treated as a first-class identity in one environment and a loosely managed secret holder in another.

The issue is common enough to be measurable: the 2024 Non-Human Identity Security Report from NHI Management Group found that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge, and 88.5% say non-human IAM still lags behind or only matches human IAM maturity. In practice, that gap is where overprivilege, weak rotation, and inconsistent offboarding take hold.

Security teams should therefore treat identity primitives as an implementation detail, not the governance boundary. The boundary should be the workload, its purpose, and the policy applied to it, regardless of whether the environment uses certificates, JWTs, cloud metadata tokens, or a legacy service account model. In practice, many security teams encounter environment-specific exceptions only after a workload has already been overprovisioned, rather than through intentional design.

How It Works in Practice

The practical answer is to standardise the control plane and translate only at the credential layer. That means defining one enterprise policy model for workload identity, access approval, logging, rotation, and revocation, then mapping those controls to the identity primitive each platform supports. For example, a cloud workload might authenticate with an OIDC-based token, while a data centre service may still rely on a certificate or host-bound secret. The governance decision, however, should be the same: who or what is allowed to act, for how long, and under what conditions.

Current best practice is increasingly aligned with workload identity standards such as the SPIFFE workload identity specification, which separates the identity of the workload from the transport or secret format used to prove it. That approach helps teams issue cryptographic identity to services, attach policy to that identity, and avoid binding authorisation to a specific platform’s credential mechanics. NHI Management Group’s Guide to SPIFFE and SPIRE is useful here because it shows how identity can be normalised across heterogeneous runtime environments.

• Define a common workload identity schema, naming convention, and ownership model across cloud and on-premises systems.
• Use one lifecycle process for issuance, renewal, rotation, and revocation, even when the underlying token differs.
• Centralise policy decisions and logs so every environment produces comparable audit evidence.
• Translate policy into platform-native credentials only at enforcement time, not as separate governance rules.
• Prefer short-lived credentials and automatic expiry where the platform allows it, especially for service-to-service access.

Frameworks such as NIST Zero Trust Architecture reinforce this pattern because they require continuous evaluation rather than trust based on network location. This is also where the Ultimate Guide to NHIs becomes practical: workload identity, lifecycle discipline, and visibility matter more than whether the identity lives in a cloud control plane or a data centre vault. These controls tend to break down when a legacy environment cannot support short-lived credentials and teams compensate with long-lived shared secrets.

Common Variations and Edge Cases

Tighter standardisation often increases migration effort, because older platforms may not support modern token exchange, automated revocation, or consistent telemetry. Organisations have to balance the security benefit of one governance model against the operational constraint of mixed runtime support. That tradeoff is especially visible in mainframe-connected applications, older Kubernetes estates, and vendor-managed appliances that only accept static keys or bespoke certificates.

Best practice is evolving, but the current guidance suggests not letting those exceptions define the enterprise model. Instead, isolate them, document compensating controls, and set a path to converge on the common policy layer. That may include token brokering, secret brokers, or certificate issuance services, but the key is that exceptions remain temporary and observable. Where possible, align those controls with the broader NHI lifecycle and offboarding discipline described in the Ultimate Guide to NHIs — Standards.

One important edge case is cross-boundary integration between cloud-native workloads and internally hosted services. In those environments, identity translation layers can become a new trust choke point if they are not monitored like privileged infrastructure. Another is third-party access: if an external system consumes your services, it should inherit the same governance model even if its token format differs. Otherwise, environment-specific exceptions become an invisible privilege pathway.

Related resources from NHI Mgmt Group

• How do IAM teams decide whether to use cloud-native identity or an external auth layer?
• How should teams use cloud asset management data in IAM programmes?
• How should teams manage Google Cloud IAM permissions when allow and deny policies use different formats?
• How should security teams normalize cloud logs for identity investigations?