Notifications
Clear all
Topic starter
25/06/2026 1:12 am
TL;DR: McDonald’s McHire breach exposed a legacy admin account with default credentials, no MFA, and an unauthenticated API endpoint, leaving roughly 64 million records accessible, according to Defakto Security. The incident shows that API security fails when non-human identities are treated as internal by default, not when teams lack more AI or more tooling.
NHIMG editorial — based on content published by Defakto Security: McDonald's McHire breach and the case for non-human identity in API security
By the numbers:
- Roughly 64 million records were exposed.
Questions worth separating out
Q: How should security teams protect APIs that expose non-human identity risk?
A: Security teams should require authentication on every exposed API, eliminate anonymous access, and bind each call to a specific workload or service identity.
Q: Why do default credentials still create major breach risk?
A: Default credentials are still dangerous because they create a predictable standing privilege path that attackers can test immediately.
Q: What breaks when organisations treat APIs as internal by default?
A: When APIs are treated as internal by default, teams skip authentication, rely on network trust, and overlook how outside parties can reach the same interfaces.
Practitioner guidance
- Remove unauthenticated production endpoints Inventory externally reachable APIs and require authentication on every request path, including internal admin and partner interfaces that can be reached from the internet.
- Eliminate default administrative credentials Find legacy admin accounts, replace vendor or inherited defaults, and revoke any credentials that cannot be mapped to an accountable owner and current business use.
- Replace static secrets with workload identity Move API and service-to-service access toward cryptographic workload identity so access is based on verifiable identity rather than reusable shared secrets.
What's in the full article
Defakto Security's full article covers the operational detail this post intentionally leaves for the source:
- The specific McHire breach sequence, including the weak admin account and unauthenticated endpoint.
- The API security implications of applicant ID exposure and direct record retrieval.
- The vendor's explanation of why machine-facing identity needs a different control model than human access.
- The broader commentary on SPIFFE and non-human IAM for production systems.
👉 Read Defakto Security's analysis of the McHire API identity breach →
McHire and the API identity gap teams are missing?
Explore further
25/06/2026 10:27 am
API identity is now a first-class governance problem, not an implementation detail. The McHire incident shows what happens when machine-to-machine access is treated as infrastructure convenience instead of an identity domain with its own controls. Once APIs can be reached without authentication, the organisation has already lost the ability to govern who or what is calling. The practitioner conclusion is that API identity needs the same policy rigor as human IAM, with stronger ownership and lifecycle discipline.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- Another finding from our research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
A question worth separating out:
Q: Who is accountable when a machine-facing account exposes production data?
A: Accountability should sit with the system owner and the team that governs the credential lifecycle, not with the identity type itself. If an API, service account, or admin account remains active without review, the programme has failed its lifecycle obligation. Frameworks such as the NIST Cybersecurity Framework 2.0 reinforce ownership, access control, and recovery discipline.
👉 Read our full editorial: McHire exposed the API identity gap in non-human access
