Protecting Non-Human Identities: Why Workload MFA and Dynamic Identity Matter Now

We’ve normalized multi-factor authentication (MFA) for human users. In any secure environment, we expect login workflows to require more than just a password — something you know, something you have, and sometimes something you are. This layered approach is now foundational to protecting human identities.

But today, the majority of interactions in our infrastructure aren’t human-driven. They’re initiated by non-human entities — services, microservices, containerized workloads, serverless functions, background jobs, and AI agents. Despite this shift, most of these systems still authenticate using a single factor: a secret.

According to CyberArk’s 2025 Identity Security Landscape, machine identities now outnumber humans 82 to 1, and 42% of them have privileged access to critical systems. Identity-based attacks on cloud infrastructure grew 200% in 2024, with 87% of organizations experiencing multiple identity-centric breaches, most involving compromised credentials.

It’s no longer viable to treat non-human identities as second-class citizens in our security architecture. These entities perform high-impact tasks and need the same protection we give to people. That starts with moving beyond static secrets.

The Limits of Static Secrets in Microservices

In a modern microservices architecture, dozens or even hundreds of independently deployed services each need access to sensitive resources — databases, APIs, message queues, and more. Each microservice typically requires its own set of secrets: API keys, database credentials, encryption keys, and certificates. As organizations scale, so does the number of secrets, leading to what’s known as secrets sprawl.

Secrets sprawl occurs when secrets are scattered across countless repositories, configuration files, deployment templates, and cloud environments. Without centralized management, secrets are often duplicated, orphaned across environments, or embedded in legacy systems. This dramatically increases the attack surface and makes it nearly impossible to track, scope, or revoke them in real time.

Recent industry reports highlight the scale of the problem:

• GitGuardian’s 2025 State of Secrets Sprawl Report found nearly 23.8 million new hardcoded secrets in public GitHub commits in 2024 — a 25% increase from the previous year.
• ByteHide notes that over 10 million secrets were identified in public code repositories in 2023, a 67% year-over-year increase.
• Akeyless reports that 96% of organizations have secrets sprawled in code, configuration files, and infrastructure tooling — and 70% have experienced a secret leak in the past two years.

When a secret is leaked — even accidentally — it can be reused by anyone who finds it, often with no expiration, no attribution, and no context. Rotating secrets becomes a manual, error-prone process, requiring teams to hunt down every instance across environments and codebases. The result is operational friction and a vastly expanded attack surface.

Redefining Workload Authentication: MFA for Systems

What would it look like if workloads were treated as first-class identities and authenticated like humans?

Workload MFA doesn’t mean giving systems phones or fingerprints. It means verifying multiple contextual signals to assert identity:

• Identity: What is this system? (e.g., spiffe://internal.myorg.dev/ns/payment/sa/service-a)
• Attestation: Where is it running? (e.g., namespace, node fingerprint, cloud instance ID)
• Provenance: What launched it? (e.g., container image hash, verified build pipeline)

These three factors — who, where, and what — combine to create a cryptographically verifiable trust boundary. Instead of relying on possession of a secret, you validate the origin, location, and role of the system.

This model aligns with zero-trust principles: trust nothing by default and verify everything continuously. It also supports the emerging practice of Workload Identity and Access Management (WIAM), which treats system identity with the same rigor we apply to user identity (CybersecurityTribe, WIAM Primer).

Real-World Example: Uber’s SPIFFE/SPIRE Deployment

Uber uses SPIRE, the reference implementation of SPIFFE, to issue workload identity across multiple environments, including GCP, AWS, OCI, and on-premise data centers. These identities apply to stateless services, storage systems, batch workloads, and infrastructure services.

SPIRE issues short-lived, cryptographically verifiable identities (SVIDs) to each workload. These identities are then used for mutual TLS authentication, replacing traditional secrets-based access. Certificates are rotated frequently and automatically. This model allows Uber to enforce zero-trust security at a massive scale without relying on any cloud-specific identity mechanism.

How SPIFFE Identity Works

SPIFFE, or Secure Production Identity Framework for Everyone, defines a uniform identity format for non-human systems. These identities are issued by SPIRE and scoped based on workload attributes.

Instead of injecting secrets into environments, workloads are issued SPIFFE IDs and certificates at runtime:

spiffe://internal.myorg.dev/ns/payment/sa/service-a

This identity is tied to a specific namespace and service account, and is issued only after SPIRE verifies environmental attributes like:

• Container image signature
• Pod metadata or node labels
• Cloud instance fingerprint
• Runtime selectors

The issued certificate is valid for a few minutes, rotates automatically, and is revoked if the workload no longer matches the trust policy.

Identity Issuance Flow:

[Workload/Software Process Starts]
       ↓
[SPIRE agent attests environment]
       ↓
[Workload receives SPIFFE ID and certificate]
       ↓
[Certificate used for mutual TLS or API authentication]
       ↓
[Certificate expires and rotates automatically]

This model removes static secrets entirely. Access is now based on verified identity.

Why Attestation Is the Second Factor

Secrets offer no context. Attestation enforces it.

SPIRE supports attestation mechanisms for both the host (node) and the workload (container, process, or function). Before an identity is issued, SPIRE checks:

• Is the workload running in a trusted environment?
• Does it originate from a trusted image or deployment?
• Is it operating under a trusted identity scope?

These determinations are made using attestation signals such as Kubernetes namespaces, node fingerprints, container image hashes, or metadata selectors defined in policy. If any of these checks fail, identity is not granted.

This is the second factor — context as proof.

Industry Standards Are Converging on Workload Identity

The IETF WIMSE Working Group is formalizing SPIFFE-style identity for global adoption:

• Token exchange: Mapping SPIFFE IDs to OAuth claims
• Transaction chaining: Enforcing JWT-based call-chain integrity
• Federation: Supporting cross-cloud identity federation

In parallel, OAuth 2.0 Attestation-Based Client Authentication allows trusted clients like serverless functions to authenticate without shared secrets. This future replaces bearer tokens with environment-bound, signed assertions of identity.

Together, these efforts are creating an ecosystem where non-human identities are first-class, portable, and verifiable.

Final Thought: Time to Protect Non-Human Identities Like We Protect People

In 2025, the majority of systems operating in cloud and enterprise environments are not human — they’re services, functions, microservices, batch jobs, and ephemeral containers. These non-human identities perform critical tasks: processing payments, managing infrastructure, handling sensitive data, and securing communications.

Yet most are still authenticated with long-lived secrets — copied across environments, hardcoded into configurations, or rotated on a manual schedule.

That’s no longer sustainable.

If humans require MFA, real-time verification, and identity-aware access, the systems acting on their behalf must meet the same bar. Identity — not static secrets — must become the foundation of trust.

With SPIFFE, SPIRE, and global standards like WIMSE now in place, we have the foundation to treat non-human identities as first-class entities in our infrastructure.

Non-human identity is no longer a niche concept. It is the new baseline for trust.