- Machine identities outnumber human identities by 45:1 in enterprise environments, yet most security teams have inventoried only a fraction of them
- Service accounts, API keys, TLS certificates and OAuth tokens are each a potential entry point if unmanaged
- Certificate expiry causes outages; exposed API keys cause breaches; orphaned service accounts enable lateral movement
- Secrets management tools solve the storage problem, but inventory must come before rotation
- Zero Trust architecture only holds if machine-to-machine trust is as tightly governed as user access
What counts as a machine identity
Machine identities are credentials that systems use to authenticate with each other. A user logs in with a username and password. A machine uses something else: a TLS certificate, an API key, an SSH key, an OAuth token, a service account, or a Kubernetes service account token.
Cloud infrastructure, microservices, containers, CI/CD pipelines and third-party API integrations have multiplied machine-to-machine connections in most organisations by an order of magnitude over the past decade. Each connection needs authentication. Organisations have formal processes for user accounts. Almost none have equivalent processes for machines.
Why the numbers got out of hand
It accumulates in small, unremarkable steps. A DevOps team creates a service account to run a deployment pipeline. An engineer creates an API key to connect two SaaS tools. A developer adds credentials to a test environment configuration file. A container image carries a hardcoded secret from a developer's machine into production.
None of it looks like a security event at the time. By the time your security team runs its first inventory, machine credentials outnumber staff by a factor that surprises most teams.
User accounts have a natural deprovision trigger: the person leaves. Machine credentials have no equivalent. Service accounts accumulate. API keys get shared between teams and never rotated. TLS certificates expire on the day an engineer is on leave. Kubernetes tokens from a deployment two years ago stay valid, and no one knows what they were for.
How attackers exploit this
The Verizon DBIR finds compromised credentials in the majority of breaches. Machine credentials account for a large and underdefended share of that exposure.
An attacker who finds an API key in a public GitHub repository has immediate access to whatever that key authorises. A compromised CI/CD pipeline lets an attacker inject credentials into build artefacts. On a Kubernetes cluster without secrets encrypted at rest, an attacker can read them directly from etcd. A service account with excessive permissions gives an attacker a vehicle for lateral movement the moment they have it.
Detection tools built around human behaviour patterns will not flag a service account doing what service accounts normally do. That is why compromised machine credentials often go undetected for months.
User sessions expire. Machine credentials, unless someone explicitly rotates or revokes them, tend to stay valid indefinitely. An API key from a service that no longer exists may still work. A service account from a completed project two years ago may still carry domain admin rights.
Four controls that matter
Rotating secrets in bulk before you have a complete inventory creates new problems. Services that depend on credentials you didn't know about will break. Inventory first, rotate second, with automated rollback for any service that fails to pick up the new credential.
Where to start
Start with service accounts in Active Directory and Azure AD. The audit costs nothing and surfaces the highest-risk items immediately: privileged accounts with no clear owner and no recent use. Once you know what systems are in scope, API key and certificate discovery follows.
Pull credential inventory from your cloud providers early. AWS IAM Credential Reports, Azure AD App Registrations and GCP Service Account lists will not catch secrets hardcoded in repositories or third-party SaaS tools, but they give you a measurable baseline.
NIS2, ISO 27001 and most internal audit frameworks flag credential and access management as a core control area. If machine identities appear in your audit findings, a structured assessment is the fastest path to closing that gap.
How Cyvra helps
Cyvra conducts machine identity assessments, establishes secrets management capabilities, and integrates certificate lifecycle automation into existing cloud and CI/CD environments. If your last audit flagged credential management, that is where we start.