McHire exposed the API identity gap in non-human access

At a glance

What this is: This analysis argues that the McHire incident exposed a basic identity failure in API access, where unauthenticated calls and legacy credentials left applicant data broadly exposed.

Why it matters: IAM, PAM, and NHI teams should treat every API call as an identity decision, because unchecked machine access can create the same exposure as a weak human account.

By the numbers:

• Roughly 64 million records were exposed in the McHire incident.

Context

APIs are no longer internal-only interfaces hidden behind a firewall. They now connect services, workflows, bots, and jobs across modern infrastructure, which makes identity and access controls part of API security rather than an add-on.

In the McHire case, Defakto Security points to default credentials, missing MFA, and an unauthenticated endpoint as the failure chain. That is a familiar governance gap for non-human access, where systems still rely on static secrets or trust-by-location instead of verifiable identity.

The underlying issue is not unique to one hiring platform. It reflects a broader pattern in which non-human access is still managed as an operational convenience instead of a governed identity surface.

Key questions

Q: What breaks when an API endpoint does not require authentication?

A: When an API endpoint does not require authentication, every control that depends on knowing the caller becomes unreliable. Roles, ACLs, and session policies only work after identity is established, so an open endpoint bypasses the access hierarchy rather than merely weakening it. In practice, the flaw turns a platform into a publicly reachable data path.

Q: Why do default credentials on non-human accounts create such a large risk?

A: Default credentials keep privileged access alive without a real governance trail. When a legacy admin or service account is never re-owned, rotated, or retired, the access path persists far beyond its intended purpose and can expose production data even if the rest of the environment is well managed.

Q: How can security teams tell whether workload identity is missing from API security?

A: The warning signs are reusable secrets, IP-based trust, shared service accounts, and API traffic that is accepted without a verifiable workload identity. If the team cannot point to a consistent identity for each caller, then authorization is being inferred from context rather than enforced on the request.

Q: Who should own non-human access decisions for APIs and service accounts?

A: Ownership should sit with the team that can explain the business purpose, approve the privilege scope, and retire the access when the job ends. That accountability matters because API access without a clear owner becomes orphaned access, which is how legacy credentials and stale privileges survive into production.

Technical breakdown

Why unauthenticated API calls become identity failures

An API that accepts requests without authentication has no basis for deciding who or what is calling it. In identity terms, that means the request is treated as intrinsically trusted, often because the system assumes network placement or obscurity is enough. For non-human access, that assumption breaks immediately. Machines, scripts, and services need verifiable identity just as much as people do, but the control must exist at the API boundary, not only in downstream application logic. Once unauthenticated requests are allowed, there is no effective entitlement model to enforce, no meaningful audit trail, and no reliable way to scope access to the task.

Practical implication: require authentication and authorization on every API endpoint that handles non-human access.

What default credentials reveal about non-human identity governance

Default credentials are not just a password hygiene problem. In non-human environments, they show that account lifecycle controls are not tied to ownership, rotation, or offboarding. A legacy admin account with static credentials can survive long after the original operational need has disappeared, which means the access path outlives the business justification. That is especially dangerous when the account has privileged access to production systems or data sets. The issue is not simply that the password was weak. It is that the identity was allowed to persist without governance, leaving an unmanaged entry point in the production environment.

Practical implication: inventory legacy accounts, remove defaults, and bind every privileged non-human account to an owner and lifecycle process.

How modern workload identity changes API trust

Workload identity replaces brittle shared secrets with cryptographic identity bound to the workload itself. Standards such as SPIFFE let systems verify what is calling an API and issue short-lived credentials tied to that identity, rather than relying on long-lived tokens or IP allowlists. That matters because non-human access is dynamic: workloads start, stop, scale, and move. A static secret cannot express that reality cleanly. Strong workload identity also supports policy decisions based on attributes and context, so access can be limited to the task and environment that actually require it.

Practical implication: move high-value API traffic toward workload identity and away from reusable static secrets.

Threat narrative

Attacker objective: The objective was to retrieve large volumes of applicant data through weak API and admin access controls.

1. Entry occurred through an unauthenticated API endpoint that accepted requests without verifying the caller's identity.
2. Credential access was enabled by a legacy admin account using default credentials and no MFA, creating a second path into sensitive records.
3. Impact followed through guessable applicant IDs and open access to names, emails, phone numbers, and other personal data across roughly 64 million records.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

APIs are now identity surfaces, not just transport layers. When an API accepts calls without authentication, the problem is not only exposure but the collapse of the trust boundary itself. Modern infrastructure moves through bots, jobs, containers, and services, so treating API traffic as internal by default is a governance error. Practitioners need to manage API access as non-human identity, not as network plumbing.

The McHire case illustrates identity gap debt. Default credentials, missing MFA, and an unauthenticated endpoint show what happens when non-human access is allowed to persist outside lifecycle control. The exposed condition is not one bad setting but accumulated debt from unmanaged accounts, weak issuance discipline, and no binding between identity and authority. The implication is that governance has to start at issuance and offboarding, not after exposure.

Static trust models fail because machine access is fluid. APIs, jobs, and workloads do not behave like employees with stable login patterns, so human-centric assumptions about session control and review cadence do not fit. Short-lived, verifiable identity is the more durable model, because it aligns access with the runtime task rather than with a reusable secret. Practitioners should stop assuming that static credentials can safely represent operational intent.

Strong API security now depends on authenticating non-human actors consistently. The article points toward a category problem, not a single platform problem: many organisations still lack a dependable way to know what is calling an API, what it may do, and when that authority should disappear. That places NHI governance, workload identity, and authorization policy in the same control plane. The practitioner conclusion is simple: if the caller is not verified, the API is already open.

Identity blast radius is the right concept for this class of failure. Once a privileged legacy account and an unauthenticated endpoint coexist, the blast radius is no longer limited by the intended workflow. It expands to every exposed record, every guessable identifier, and every downstream system that trusts the API. Practitioners should measure where identity failure can turn a single weak control into broad data exposure.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• Read next: NHI Authentication Guide

What this signals

API identity gap: This incident shows that API security and NHI governance now overlap at the boundary where machine calls are accepted. If teams cannot verify the caller, they cannot reliably enforce scope, rotation, or offboarding for the identity behind the request.

The practical shift for identity programmes is to move from secret-centric thinking to caller-centric control. That means identifying every API path that depends on a static token, a shared credential, or a trust-by-network assumption, then deciding whether it should exist at all.

Access reviews alone are not enough when the access path is a machine call rather than a human login. The control has to move earlier, to issuance and authentication, because the exposed identity surface is the API itself.

For practitioners

• Inventory every exposed API endpoint Map which endpoints accept non-human traffic, which ones still rely on network trust, and which ones can be reached without a verifiable identity. Prioritise production paths that return personal or privileged data.
• Remove default and legacy credentials Identify dormant admin accounts, test accounts, and service identities that still use default or shared secrets. Revoke anything that lacks a named owner, recent rotation, or documented business need.
• Bind API access to workload identity Replace static secrets with short-lived, cryptographically verifiable identities for workloads, jobs, and services. Enforce policy at request time so access follows the runtime task rather than the account history.
• Require authenticated access for sensitive records Treat applicant data, customer records, and administrative functions as high-value resources that need explicit authorization on every request. Block any endpoint that can enumerate records through predictable identifiers or unauthenticated calls.
• Review non-human ownership and offboarding Assign owners to every machine identity, service account, and API credential, then define when that access must expire. If the owner or purpose cannot be confirmed, remove the identity from production service.

Key takeaways

• The McHire incident was not a sophisticated exploit, but a governance failure in which unauthenticated API access and legacy credentials exposed a large applicant data set.
• Roughly 64 million records were exposed, which shows how quickly a single weak identity control can widen into broad data access.
• The most relevant preventive control is to verify every non-human caller and remove static trust from production API access.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Unauthenticated Api Path: A public endpoint that accepts requests without verifying the caller first. In identity security terms, this is not just a missing login check. It is a broken trust boundary that can invalidate downstream roles, ACLs, and session controls because the system never establishes who is asking.
• Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.