How do organisations govern hybrid estates that use both SPIFFE and API keys?

They should define SPIFFE as the internal default for verifiable workload identity and treat API keys as governed exceptions for external services that do not yet support it. The key is to document which systems sit outside the internal trust domain, then review those exceptions on a scheduled governance cycle.

Why This Matters for Security Teams

Hybrid estates are common because SPIFFE and api key solve different problems. SPIFFE gives cryptographic workload identity inside a trusted runtime, while API keys still appear where a vendor, legacy app, or external platform has not adopted stronger identity primitives. The governance challenge is not choosing one forever, but preventing the exception path from becoming the default. NHI Management Group’s coverage of machine identity gaps shows why this matters: 57% of organisations lack a complete inventory of machine identities, which makes exception tracking and ownership especially brittle.

For internal services, the SPIFFE workload identity specification supports verifiable identity at runtime, whereas API keys are typically static bearer secrets with no built-in proof of workload possession. That difference changes governance: SPIFFE can be policy-bound and short-lived, while API keys usually require compensating controls such as tight scoping, rotation, and explicit exception review. Current guidance suggests treating those exceptions as temporary risk decisions, not architectural preferences. In practice, many security teams encounter API key sprawl only after a compromise, an outage, or a compliance review exposes how many systems were never brought into the internal trust domain.

How It Works in Practice

The cleanest operating model is to define SPIFFE as the default identity primitive for workloads that run inside your control boundary. Issue SPIFFE IDs to services, tie them to workload attestation, and use runtime policy to decide whether a request should succeed. For systems that still rely on API keys, governance should classify them as external trust-domain exceptions with named owners, approved scope, rotation cadence, and an exit plan.

That means the control set looks different for each identity type. SPIFFE-backed services can be managed with ephemeral credentials, mTLS, and policy decisions based on workload identity. API keys, by contrast, need compensating controls because they are usually static bearer tokens. The important questions are: who owns the key, where is it stored, what can it call, how often is it rotated, and what detection exists for misuse?

• Use SPIFFE for internal service-to-service calls where the platform can attest workload identity.
• Use API keys only where the external service cannot yet accept workload identity or federated auth.
• Record every API key exception in a governance register with business justification and expiry.
• Review exceptions on a fixed cycle and measure whether a stronger identity option now exists.
• Map the overall estate to NIST Cybersecurity Framework 2.0 functions so ownership, protection, detection, and response are explicit.

NHIMG’s Ultimate Guide to NHIs — Standards reinforces the need to catalogue machine identities with clear control boundaries, while its Guide to the Secret Sprawl Challenge highlights how quickly static secrets accumulate when teams lack a formal exception process. These controls tend to break down when API keys are embedded in automation, because the key becomes indistinguishable from legitimate runtime traffic.

Common Variations and Edge Cases

Tighter identity governance often increases operational overhead, so organisations need to balance stronger assurance against integration friction. That tradeoff is real when partner APIs, SaaS platforms, or older internal systems cannot support SPIFFE-based authentication yet. Current guidance suggests that the exception process should reflect this reality without normalising it.

There is no universal standard for when to retire API keys entirely. Some environments can replace them with federated tokens or short-lived credentials; others must keep them for external interoperability. The practical risk is that “temporary” exceptions persist indefinitely unless they are tied to expiry dates and ownership reviews. Hybrid estates also need different monitoring paths: SPIFFE traffic can be evaluated by workload and trust domain, while API key usage often requires secret-scanning, anomaly detection, and rapid revocation readiness.

In high-change environments, a useful rule is to ask whether the system is inside the internal trust domain or not. If it is inside, SPIFFE should be the default. If it is outside, the API key should be documented as an exception with explicit compensating controls and a migration trigger. NHIMG’s reporting on machine identity complexity shows why that discipline matters: manual tracking still dominates many programmes, and that makes exception drift likely unless governance is enforced as an ongoing process rather than a one-time architecture decision.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• What problem does ownership attribution solve for service accounts and API keys?
• What challenges do unmanaged API keys pose within MCP?
• How should organisations govern browser extensions that handle API keys?