Certificate vs Federated vs Secret Based Machine Identity: When to Use Each Model

Every workload that calls another system must prove who it is, and the credential model you choose decides what an attacker gets when one workload is compromised, how fast you can recover, and how much of your team's time goes on rotation. There are three models in practice: a shared secret (API key, client secret, password or static access key), a certificate whose private key the workload holds (mutual TLS, X.509-SVIDs, certificate-based token exchange), and federation, where the workload's own platform vouches for it with a signed short-lived token that a relying party exchanges for access. This page is a decision guide, not a glossary: for each model it sets out the trust root, the threat model, rotation, blast radius and platform fit, then gives a selection matrix, worked scenarios and a migration plan. It is for platform engineers, identity architects and NHI programme owners. Cloud platforms are listed alphabetically; order is never a ranking.

Key takeaways

• The real question is where trust is rooted. Secrets root trust in whoever can read a string; certificates root it in a CA and a private key; federation roots it in an external issuer's signing keys and the claim conditions you write.
• Default to federation where the platform can issue a token. CI/CD systems, Kubernetes clusters and cloud compute can all vouch for workloads, so no credential needs storing and access expires on its own.
• Use certificates where the connection itself must be authenticated or no token issuer exists. Service-to-service mTLS, on-premises servers reaching cloud APIs, devices and sender-constrained tokens are certificate territory.
• Secrets are the fallback, not the default. Keep them for third parties and legacy systems that accept nothing else, and contain each one with scope, expiry, vaulting and monitoring.
• Each model fails differently. Secrets leak; certificates expire and revocation is patchy; federation fails through over-broad subject conditions or a compromised issuer. Your controls must match the failure mode of the model you pick.

The short answer

Pick federation whenever the workload runs on a platform that can sign an identity token the relying party trusts: GitHub Actions, GitLab CI, Azure Pipelines, Kubernetes service account tokens, cloud instance identities, or a SPIFFE deployment. Pick certificates when you need mutual authentication of a network connection (service mesh, east-west traffic, mTLS APIs), when an on-premises or edge workload must reach a cloud with no token issuer available, or when tokens must be bound to a key holder. Pick secrets only when the counterpart accepts nothing else, and treat each one as a documented exception with an owner and an expiry. In many estates the answer is layered: a certificate or platform token proves the workload to a federation broker, which then issues short-lived credentials, so no long-lived secret exists anywhere in the chain.

The three models side by side

Secret based machine identity

Threat model

Whoever reads the secret becomes the workload, from any network, for as long as it stays valid. Google Cloud's guidance on service account keys lists the risks: credential leakage, privilege escalation, information disclosure, weakened non-repudiation where a key is shared, and malicious credential configurations. It also notes that leaked keys can go unnoticed for days or weeks. The Codecov breach shows the pattern: a leaked cloud storage key let an attacker alter a CI script, which then harvested customer CI secrets for about two months.

Architecture in words

A secret is generated once, stored in a vault or CI secret store, injected into the workload at start-up and presented on every request. The relying party compares it with a stored value or hash. Security depends on every copy: source, CI variables, logs, crash dumps, backups and developer laptops.

Controls when you must use one

• Prevent creation by default: Google Cloud recommends the organisation policy constraints to disable service account key creation and key upload at the organisation root, with overrides only for projects that have no alternative.
• Vault and inject: store in a secrets manager, inject at runtime, never in code or images. See the Secrets Management Guide.
• Scope and constrain: least privilege, network or IP conditions where the provider supports them, one secret per consumer so revocation is surgical.
• Rotate on a schedule and on suspicion: a practised rotation process is what lets you respond quickly to a leak.
• Detect exposure: secret scanning in repositories and CI logs, and provider leak response where offered (Google Cloud's key exposure response constraint can automatically disable detected keys).

Certificate based machine identity

Threat model

The workload holds a private key and presents a certificate signed by a CA the relying party trusts. Theft requires the private key, not just a value seen in transit, and the proof is bound to the connection, so replay is hard. The risks move to the CA and the lifecycle: a compromised or over-trusted CA can mint any identity, expired certificates cause outages, and revocation checking is often weak. RFC 8705 warns that subject-based matching is open to spoofing unless the server limits which CAs it trusts. Attackers who obtain signing material can forge certificates, which ATT&CK tracks as T1649 Steal or Forge Authentication Certificates.

Architecture in words

A private or public CA issues end-entity certificates to workloads, ideally through automated enrolment so keys are generated where they are used. In SPIFFE, the Workload API hands each workload its SPIFFE ID, a private key, an X.509-SVID and the trust bundle, and the SPIFFE documentation states that private keys and certificates are short-lived and rotated frequently and automatically. Certificates can also be exchanged for cloud credentials: AWS IAM Roles Anywhere validates an X.509 certificate against a configured trust anchor and returns temporary credentials for a role, and RFC 8705 lets OAuth servers authenticate clients by certificate and bind access tokens to it through the cnf claim's x5t#S256 thumbprint.

Failure modes and controls

• Over-broad trust anchors: AWS notes the IAM Roles Anywhere trust boundary is the account, so any trust anchor can assume any role whose trust policy does not add conditions. Condition role trust on the trust anchor ARN and certificate attributes such as aws:PrincipalTag/x509SAN/URI.
• Revocation gaps: IAM Roles Anywhere does not use OCSP; it supports imported CRLs, which it keeps using after their next update date, and automatic CRL distribution point checking, which is off by default. Short certificate lifetimes reduce dependence on revocation.
• Expiry outages: manual renewal at scale fails. Automate issuance and alert on certificates nearing expiry. See the Short-Lived vs Long-Lived Certificates guide.
• Keys exported to files: a private key copied to a shared disk is a secret with extra steps. Generate keys in place, in a TPM or HSM where possible.

Federated machine identity

Threat model

The workload asks its own platform for a signed token and presents it to the relying party, which validates the signature against the issuer's published keys and checks claims before issuing a short-lived credential. Nothing is stored, so there is nothing to leak at rest. The risks become the trust conditions and the issuer. Microsoft documents that a federated identity credential must match issuer, subject and audience, case-sensitively. A condition that trusts every repository in an organisation, or every service account in a cluster, hands access to anyone who can run a job there. A compromised issuer, or an attacker able to run code in a trusted pipeline, can mint valid tokens. Bearer tokens stolen in flight are replayable until expiry, which ATT&CK covers under T1528 Steal Application Access Token.

Architecture in words

Microsoft's description is typical: the workload requests a token from the external identity provider, sends it to the Microsoft identity platform using the client credentials flow with a federated credential, the platform validates it against the trusted issuer, and an access token is returned. Supported sources include Kubernetes clusters, GitHub Actions, Google Cloud, AWS, SPIFFE and Azure Pipelines. AWS and Google Cloud offer equivalent exchanges, and the Workload Identity Federation Guide gives per-platform setup.

Failure modes and controls

• Wildcard subjects: pin subject conditions to repository, branch or environment, or to namespace and service account.
• Audience reuse: use a unique audience per relying party so a token for one cannot be replayed to another.
• Issuer key handling: Microsoft notes Entra stores only the first 100 signing keys from an issuer's discovery endpoint; self-hosted issuers need disciplined key rollover.
• Trusting a weak issuer: a self-hosted CI runner or cluster issuer is now part of your identity perimeter; protect it like a CA. See Securing the workload identity platform.

Selection matrix: when to use each

Small vs large organisations: a small team gets most of the benefit from federation in CI and cloud compute, and from vaulting the few secrets that remain; running a private CA is often not worth it until there is mTLS or on-premises demand. A large estate usually needs all three: federation as the default, a managed PKI or SPIFFE for service-to-service and on-premises workloads, and a governed exception register for secrets.

Decision checklist

1. Can the workload's platform issue a signed identity token the relying party accepts? If yes, use federation.
2. Must the network connection itself be mutually authenticated, or must tokens be bound to a key? If yes, use certificates, alone or under the token.
3. Is there no issuer at all, but you can run a CA? Use a certificate and exchange it for short-lived credentials.
4. Does the counterpart accept only a static secret? Use a secret as a registered exception with owner, scope, expiry and monitoring.
5. Can you name who controls the trust root? Whether it is the vault, the CA or the issuer, that system now needs tier 0 protection.

Worked scenarios

Scenario 1: a deployment pipeline

A team deploys from a CI platform to two clouds using static keys stored as pipeline variables. A malicious dependency in the build prints environment variables to a log. Under the secret model the keys work from anywhere until someone notices. Under federation, each job requests a token whose subject names the repository and environment, the clouds issue credentials valid for about an hour, and the log contains no reusable credential. Migration effort is mostly writing precise trust conditions, then deleting the keys. The Workload Identity Federation vs Static Cloud Keys guide covers that migration step by step.

Scenario 2: a payments service mesh with on-premises dependencies

A payments platform runs services in Kubernetes that call each other and an on-premises ledger. Shared API keys between services mean one compromised pod can impersonate any service. Moving to SPIFFE X.509-SVIDs gives each service a distinct, short-lived identity, mTLS authenticates every connection, and authorisation policy is written against SPIFFE IDs. The ledger servers receive certificates from the same trust domain. For cloud API calls from the ledger, certificates are exchanged for temporary cloud credentials through a conditioned trust anchor. The remaining secret is a card scheme API key, held in a vault as a registered exception.

Where governance fits

Whatever the model, every machine identity needs an owner, a purpose, a scope and a review date. Federation trust relationships and CA trust anchors are entitlements in their own right and belong in access reviews alongside service accounts and keys. The Machine Identity Management vs Secrets Management guide explains how the disciplines divide the work, and the Ephemeral Credentials vs Secretless Access guide covers the bootstrap trust that remains even in secretless designs.

Migration plan

1. Inventory: list every machine credential by model, owner, age and consumer. Flag static secrets with cloud or production rights.
2. Prevent new secrets: apply provider guardrails against key creation, with an exception process.
3. Move CI/CD and cloud compute to federation: run federation alongside existing keys, confirm via audit logs that the new path is used, then disable (not delete) keys for a soak period before deleting. Rollback is re-enabling the key.
4. Introduce certificates where needed: stand up automated issuance for mesh and on-premises workloads, with short lifetimes, then condition any certificate-to-cloud trust on attributes.
5. Register the remainder: each surviving secret gets an owner, scope, expiry, vault location and rotation date.
6. Review trust roots: quarterly review of issuers, trust anchors, subject conditions and CA hierarchies.

Detection and measurement

• Static secret share: percentage of machine credentials that are long-lived secrets; target a falling trend.
• Federation coverage: percentage of CI/CD and cloud compute workloads authenticating by federation.
• Median credential lifetime: across all machine identities, by model.
• Over-broad trust count: federation conditions or trust anchors without subject or attribute constraints; target zero.
• Certificate expiry incidents: outages or near misses from expired certificates per quarter.
• Time to revoke: measured time from decision to effective revocation for each model, tested in drills.

Log and alert on creation of new static keys, changes to federated credentials and trust anchors, token exchanges from unexpected subjects, and certificate issuance outside automated enrolment.

Common failure patterns

• Federation with wildcard subjects: any repository or namespace can assume a production role.
• Certificates treated as fire-and-forget: multi-year certificates, no inventory, renewal discovered at outage time.
• Private keys distributed like secrets: copied to shared storage, losing the possession guarantee.
• Revocation assumed, not tested: CRLs imported once and never refreshed.
• Keys kept "just in case" after federation: old secrets remain valid beside the new path, as the Codecov breach illustrates for CI-held credentials.
• Trust roots outside tier 0: CI issuers, CAs and vaults run with ordinary admin access.

Framework mapping

Practitioner checklist

• Classify every machine credential as secret, certificate or federated, with an owner.
• Make federation the default for CI/CD, Kubernetes and cloud compute.
• Pin federation trust to issuer, audience and exact subject.
• Use short-lived, automatically issued certificates for mTLS and on-premises workloads.
• Condition certificate-to-cloud trust on trust anchor and certificate attributes.
• Block new static keys by policy and register every exception.
• Protect vaults, CAs and token issuers as tier 0.
• Test revocation for each model and record the time it takes.

Standards and references

• IETF: RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
• SPIFFE: SPIFFE concepts
• AWS: What is IAM Roles Anywhere
• AWS: IAM Roles Anywhere trust model
• Google Cloud: Best practices for managing service account keys
• Microsoft Learn: Workload identity federation
• NIST: SP 1800-16, Securing Web Transactions: TLS Server Certificate Management

Related NHI Mgmt Group resources: mTLS Guide · SPIFFE and SPIRE Guide · Secrets Zero Problem Guide · Non-Human Identity (NHI) Guide