- 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.
Tools for Managing Machine Identities at Scale
The tooling category is well-established. These are the platforms UK enterprises and regulated environments use most.
HashiCorp Vault (now IBM) is the dominant open-source secrets manager. Vault generates short-lived credentials, certificates, and API keys on demand and revokes them when the workload ends, removing the need for long-lived secrets. The Enterprise edition adds namespacing and governance controls for larger deployments. UK financial institutions and major tech companies including Shopify and GitHub run it at scale.
CyberArk Secrets Manager extends the company's privileged access management platform to cover machine identities. It produces a full audit trail of credential access and integrates with CI/CD pipelines, making it the standard choice in regulated sectors including financial services and NHS Digital programmes. Pricing is enterprise-tier.
AWS Secrets Manager suits organisations already committed to the AWS ecosystem. It rotates RDS passwords and API keys on a defined schedule. At approximately 90p per secret per month, it is cost-effective for AWS-native workloads, and rotation of AWS-native services carries no additional charge.
Venafi Trust Protection Platform (now CyberArk) addresses certificate sprawl, where organisations accumulate thousands of TLS certificates and lose track of expiry dates. Venafi tracks certificate expiry across the entire estate and auto-renews through integrations with DigiCert and Let's Encrypt. It is purpose-built for organisations where certificate management has outgrown spreadsheets and manual processes.
Microsoft Entra Workload ID is the natural choice for Microsoft-heavy environments. It federates with GitHub Actions and other CI/CD tools without requiring stored secrets, using token-based authentication instead. It fits into organisations already running Entra ID for human identity management.
Tool selection follows cloud commitment: AWS environments suit Secrets Manager, Azure environments suit Entra, and multi-cloud or on-premises estates suit Vault or CyberArk. Run an inventory before committing to any platform. Most organisations discover more machine identities than expected, and that baseline shapes which tooling fits the estate.
How Cyvra helps
Machine identity security is one component of a broader cybersecurity programme. 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.