TL;DR: Machine identities now outnumber human users 45:1 and are growing 44% year over year, while shorter certificate lifetimes increase renewal pressure and make manual governance unsustainable, according to AppViewX. Certificate management has become an operational resilience problem, not just an inventory problem.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on AppViewX's blog post: Machine identities are growing faster than manual certificate governance can handle, and expired or compromised credentials create direct operational and revenue risk.
Why it matters: IAM, IGA, PAM, and platform teams need to treat certificate lifecycle governance as business continuity work because machine credentials sit on critical transaction and deployment paths.
By the numbers:
- Machine identities outnumber human users 45:1 in modern enterprises.
- Machine identities are growing 44% year over year as cloud, AI, and containerization accelerate.
Context
Non-human identities are the machine credentials that let applications, workloads, devices, and services authenticate without a person in the loop. In this space, certificates matter because they sit at the protocol layer and prove identity for HTTPS, APIs, and service-to-service traffic.
The governance gap is that traditional IAM models were built around people who can reset passwords, approve prompts, or complete an access review. Machine identities operate continuously, at scale, and across environments, so certificate ownership, rotation, and discovery become a lifecycle problem rather than a login problem. Non-human identities are the right lens for that problem.
The article’s starting position is typical for modern infrastructure, not exceptional: the same credential patterns now span cloud, containers, APIs, and automation platforms, which makes certificate management a baseline discipline rather than a specialist edge case.
Key questions
Q: How do certificates support machine-to-machine authentication?
A: Certificates support machine-to-machine authentication by proving a workload or service owns a private key linked to a trusted public certificate. During mutual TLS or similar handshake flows, the peer verifies the certificate chain, validity period and revocation status before trusting the connection. That binds the machine identity to the protocol layer.
Q: Why do expired certificates cause wider outages than expired API tokens?
A: Expired certificates often cause wider outages because they are embedded in many services, clusters and deployment pipelines, so one missed renewal can break many connections at once. API tokens are usually scoped to a single integration or caller, so expiry is often more localised. Certificate expiry also stops mutual TLS and other key-based trust checks.
Q: How should teams discover hidden service accounts and certificates?
A: Teams should discover hidden service accounts and certificates by combining automated scanning of cloud accounts, directories, repositories, container images and certificate stores with inventory reconciliation. Look for orphaned principals, embedded secrets, unmanaged private keys and certificates that are not tied to an owner, workload or renewal process. Discovery should feed a current identity register.
Q: When should machine identity governance move from manual to automated?
A: Machine identity governance should move from manual to automated when the number of service accounts, API keys, tokens and certificates exceeds what teams can track reliably by hand, or when rotation, expiry and ownership checks must happen continuously. Automation then enforces lifecycle events, policy checks and revocation at scale, reducing missed renewals and orphaned credentials.
Technical breakdown
Why certificates are the identity layer for machine-to-machine trust
Digital certificates provide cryptographic proof that a server, service, or workload is who it claims to be at the protocol layer. That matters because HTTPS, API calls, Kubernetes pod-to-pod traffic, and many cloud service interactions depend on certificate validation before encrypted communication can begin. Unlike a password, the certificate is not just a login secret; it binds identity to a public key and a trust chain. When that binding fails, the service may stop trusting itself or its peers even if the application logic has not changed. Read Guide to SPIFFE and SPIRE.
Practical implication: Treat certificate inventory and expiry as core service availability controls, not as a background PKI task.
Why certificate expiry breaks services differently from API token expiry
An API token usually fails at the application boundary, affecting a specific service call or workflow. A certificate failure can cascade through load balancers, websites, deployment pipelines, internal service meshes, and automated provisioning flows because the trust check happens before the session starts. That is why certificate expiry creates a broader blast radius than many other non-human credentials. The failure is structural: the infrastructure itself stops accepting authenticated traffic, which is why certificate governance must include discovery, dependency mapping, and timed renewal. Read Guide to NHI Rotation Challenges.
Practical implication: Map which systems depend on each certificate so renewal failures do not become multi-service outages.
Why traditional IAM tools miss machine identity sprawl
Traditional IAM assumes a bounded population of human users and a manageable login cadence. Machine identities do not fit that model because they are created by pipelines, cloud services, containers, and application teams that often do not register them in one authoritative directory. The result is blind spots: orphaned certificates, duplicate credentials, unmanaged service identities, and renewal ownership that no single team can see end to end. Discovery becomes the first control because you cannot govern what you cannot enumerate.
Practical implication: Build automated discovery and ownership mapping before trying to standardise rotation or policy enforcement.
Threat narrative
Attacker objective: The attacker’s goal is to obtain trusted machine access that unlocks production systems, data flows, and deployment paths.
- entry: Attackers can enter through compromised machine credentials such as certificates, API tokens, or SSH keys that the environment already trusts.
- escalation: A valid certificate lets the attacker blend into service traffic and reach systems that would block an untrusted account.
- impact: Once trusted access is established, the attacker can move through production services and data paths without triggering the same friction as a human login.
- impact: Expired or mismanaged certificates can also halt legitimate traffic, creating business disruption even without an attacker present.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Certificate lifecycle is now operational resilience infrastructure: The article is right to treat machine identity as a business continuity issue, not a narrow security task. When certificates touch customer transactions, APIs, and deployment pipelines, expiry becomes an outage mechanism as much as a trust failure. The practitioner takeaway is to govern certificate lifecycle with the same seriousness as production uptime.
Standing machine credentials create a different exposure model from human accounts: A certificate or token can remain trusted long after the application, workload, or service relationship has changed. That makes orphaning and delayed offboarding structurally dangerous in a way human access review processes do not fully capture. The implication is that identity governance must follow the workload lifecycle, not the employee lifecycle.
Discovery is the named concept here: credential visibility debt: The article shows that unmanaged certificates accumulate faster than manual processes can inventory them. Once that happens, rotation policy and compliance reporting both become partial truths. Practitioners need to understand that the control failure begins with incomplete visibility, then compounds through unmanaged renewal and ownership gaps.
Machine identity pressure now collapses the old assumption that credentials can be governed one at a time: That assumption was designed for a slower, human-paced environment. It fails when cloud build systems, containers, AI workloads, and APIs create and consume credentials continuously across distributed platforms. The implication is that governance has to move from individual certificate handling to policy-driven lifecycle control at scale.
Crypto-agility is becoming part of identity governance, not just cryptography planning: The article ties shorter certificate lifespans and post-quantum readiness to operational identity work. That means algorithm migration, renewal automation, and certificate policy now sit inside the same governance conversation. The practitioner conclusion is that cryptographic change management belongs in the machine identity programme, not beside it.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs
What this signals
Credential visibility debt: When certificates are provisioned by pipelines, cloud services, and containers, the main risk is not just expiration. The real problem is that no single directory gives teams a complete view of what exists, who owns it, and what depends on it.
Access reviews do not solve machine identity sprawl because the subject is not a person who can be recertified on a cadence. The practical shift is toward issuance-time policy, dependency mapping, and automated renewal, with service-level ownership attached to every credential.
The pressure will intensify as certificate lifetimes shorten and distributed systems keep multiplying credential footprints. Teams that still manage machine identities as ad hoc tasks will keep discovering outages at the point of failure instead of at the point of governance.
For practitioners
- Map every machine credential to an owner and dependency chain Create an authoritative inventory of certificates, keys, and API tokens across cloud, containers, and on-premises systems, then record which service each credential supports and who is accountable for renewal.
- Automate renewal before certificate validity windows shrink Replace spreadsheet-driven renewals with policy-based workflows that request, issue, deploy, and validate certificates before expiration across all production environments.
- Separate discovery from remediation Run agentless scans to find hidden credentials first, then prioritise the highest-risk certificates for rotation, revocation, or replacement based on service criticality.
- Build certificate policy enforcement into issuance Validate key lengths, algorithms, and issuance rules before a certificate enters production so non-compliant credentials never reach critical services.
- Plan for post-quantum migration now Inventory the algorithms in use, identify which services cannot tolerate cryptographic change, and establish a migration path that does not rely on manual certificate replacement at the last minute.
Key takeaways
- Machine identities are now a scale problem, not a niche infrastructure detail, because the volume of machine credentials has outgrown manual governance.
- Certificate failures and compromised machine credentials both create direct business impact, from outages to trusted access abuse.
- The control boundary has moved to discovery, ownership, and automation, which means identity teams must govern machine credentials as a lifecycle discipline.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs · Guide to NHI Rotation Challenges
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Certificate and key leakage is the attack path when trusted machine credentials are exposed. |
| NHI-05 — Overprivileged NHI | The article links unmanaged machine identities to excessive trust and broad service access. | |
| NHI-07 — Long-Lived Secrets | Short renewal windows and manual processes make long-lived certificates a direct governance risk. | |
| Recommendation — Scan for exposed machine credentials and revoke anything discovered before attackers can reuse it. Reduce machine credential scope so each identity can reach only the services it needs. Shorten secret and certificate lifetimes and automate renewal before expiry becomes operational failure. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Machine credentials need entitlement governance because they grant access to production services and APIs. |
| Recommendation — Apply entitlement governance to machine identities so access is granted, reviewed, and removed on policy. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificate renewal, rotation, and revocation are authenticator lifecycle duties covered by IA-5. |
| Recommendation — Use authenticator management to track, rotate, and revoke machine credentials on a defined schedule. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Compromised machine credentials enable trusted access and movement through production systems. |
| Recommendation — Hunt for credential theft and restrict lateral movement paths exposed by trusted machine 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.
- Digital certificate: A cryptographic credential issued for a defined period that can be used to prove identity during authentication. It supports stronger, time-bound access control, but only when issuance, renewal, and revocation are managed as part of the identity lifecycle.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
- Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
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.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org