The 45-to-1 Problem
If you asked a CISO five years ago how many identities their organization had, most would have quoted the number in their IAM system: employees, contractors, and a handful of shared service accounts. Today, that answer is off by nearly two orders of magnitude.
Modern enterprises operate a hidden identity population that dwarfs the human one. Service accounts in Active Directory. Kubernetes ServiceAccounts. IAM roles assumed by Lambda functions. OAuth client credentials that call vendor APIs. Personal access tokens on shared repositories. SSH keys in home directories on legacy VMs. Workload identities in service meshes. And, of course, X.509 certificates — the oldest form of machine identity, and still the most widely deployed.
Industry surveys through 2025 and early 2026 have converged on a rough ratio: for every human identity in a large enterprise, there are approximately 45 non-human identities (NHIs). Some organizations report ratios of 80-to-1 or higher. The number continues to grow as microservices, ephemeral compute, and AI agents multiply the entities that need to authenticate to something.
The governance problem is straightforward to state and hard to solve: the identity discipline the industry spent 30 years building was designed for humans. Provisioning workflows, access reviews, role-based access control, quarterly certifications — none of it maps cleanly to NHIs. Which is why 45-to-1 is not just a statistic. It is a growing attack surface that most organizations do not measure, do not review, and cannot fully see.
This article defines the NHI problem, walks through the categories of NHIs enterprises need to govern, explains why traditional IAM tools fall short, and lays out a practical governance program that treats certificates as first-class NHIs alongside tokens, keys, and secrets.
What Counts as a Non-Human Identity
NHI is an umbrella term. To govern them, you first need to enumerate them. The categories most enterprises need to inventory include:
- X.509 certificates: TLS certificates on servers, mTLS certificates between services, code-signing certificates, document-signing certificates, SSH host certificates.
- Service accounts: Active Directory service accounts, database service users, application-specific accounts.
- Cloud IAM roles and identities: AWS IAM roles, Azure managed identities, GCP service accounts.
- Kubernetes identities: ServiceAccounts, workload identities via SPIFFE/SPIRE, per-pod certificates managed by cert-manager.
- OAuth clients and API keys: Client credentials for machine-to-machine calls, third-party SaaS integrations, webhook signing keys.
- SSH keys: Host keys, user keys, deployment keys, forwarded agent keys.
- Tokens and secrets: Bearer tokens, HMAC signing keys, database connection strings, encryption keys.
- Workload attestations: TPM-backed attestations, Nitro Enclave attestation documents, Google Cloud Workload Identity Federation credentials.
Each category has its own lifecycle, its own attack patterns, and its own governance surface. What ties them together is that they all authenticate something that is not a human — and they all fail in similar ways: unowned, unexpired, over-privileged, and unmonitored.
Why Traditional IAM Doesn't Cover NHIs
The workflows that govern human identity are anchored in HR events. A person is hired, joins a department, is granted access based on their role, is reviewed quarterly, changes teams, and is offboarded when they leave. Access certifications happen because someone is accountable for a human.
NHIs have none of that structure:
- No HR event triggers creation. An engineer creates a service account when they need one, often as part of building a new feature. There is no gate.
- No accountable owner over time. The engineer who created the identity may leave the company. The service the identity supports may be renamed, migrated, or decommissioned without any update to the identity record.
- No natural review cadence. Quarterly certifications work for a handful of accounts per manager. When a manager has 500 service accounts in their scope, meaningful review breaks down.
- No universal directory. Humans live in the corporate directory. NHIs live in dozens of places: cloud IAM, Kubernetes API, HashiCorp Vault, GitHub, PKI databases, secret managers, custom application databases.
- Ephemeral by design. Modern NHIs are increasingly short-lived — pods that live for minutes, functions that execute for seconds. Traditional periodic review cannot keep up.
The result is that the same enterprise that has a mature, audited process for provisioning a new employee has no comparable process for provisioning a new service account, certificate, or workload identity. And the same organization that revokes access within an hour of an employee's departure may have expired service accounts, orphaned certificates, and abandoned tokens that persist for years.
The Attack Surface NHIs Create
Attackers understand the NHI governance gap. High-profile breaches in the past several years have leaned heavily on NHI compromise:
- Cloud provider incidents where compromised OAuth tokens gave attackers access to customer environments.
- Software supply chain attacks where compromised code-signing keys enabled malware to masquerade as legitimate updates.
- Enterprise breaches where stolen service account credentials enabled months of undetected lateral movement.
- Repository compromises where leaked personal access tokens exposed source code across thousands of projects.
The common thread is that NHIs are typically over-privileged, long-lived, and lightly monitored — the opposite of what defenders want. Once compromised, they provide durable, low-signal access that is harder to detect than a compromised human account because there is no user to notice unusual login patterns.
The Six Governance Failures to Address
A functional NHI governance program is built around fixing six specific failure modes:
1. Unknown inventory
You cannot govern what you cannot see. The first requirement is complete discovery of all NHIs across cloud accounts, on-premises directories, PKI databases, secret managers, and code repositories.
2. Missing ownership
Every NHI must have a documented owner — ideally a team or service, not an individual. Owners are the accountability point for lifecycle decisions.
3. Unbounded lifetime
NHIs without expiration dates persist indefinitely. Every NHI should have a maximum lifetime, enforced by the platform, with automated rotation before expiry.
4. Excessive privilege
NHIs often accumulate permissions over time. Regular privilege review — automated where possible — is required to right-size access.
5. Absent monitoring
Login patterns, API call patterns, and geographic origins of NHI usage should be baselined and monitored. Anomalies should generate alerts.
6. Manual revocation
When an NHI is compromised, revocation must be immediate and complete. Manual revocation processes that require ticket queues, approvals, and multi-system updates guarantee a slow response.
Certificates as First-Class NHIs
Certificates are among the oldest NHIs and, for many enterprises, the largest population by count. A large financial services organization may operate a few thousand human identities and hundreds of thousands of TLS and mTLS certificates. Yet certificate governance is often treated as a PKI operations concern rather than as an identity governance concern.
Treating certificates as first-class NHIs means:
- Inventory parity: Certificates appear in the same NHI inventory as service accounts and tokens, with the same required metadata (owner, purpose, review date, expiration).
- Ownership at scale: Certificate ownership is assigned to a service or team, not to whoever happened to request it. When a service is decommissioned, its certificates are decommissioned with it.
- Lifetime governance: Certificates use the shortest lifetime compatible with the deployment. Short-lived certificates (hours or days) are preferred where automation supports it.
- Privilege review: Certificate scope — wildcard vs. specific hostname, EKU restrictions, name constraints — is reviewed periodically and tightened.
- Behavioral monitoring: Certificate usage patterns are baselined. Sudden appearance of a certificate on an unexpected host or unusual TLS handshake volume triggers investigation.
- Automated revocation: When compromise is suspected, certificates are revoked and reissued through automation with no manual steps required.
Governance parity between certificates and other NHIs is the operational bridge between PKI teams and identity governance teams. In most organizations, that bridge does not yet exist.
Building an NHI Governance Program
Practical NHI governance programs share a common structure:
Phase 1: Discovery
Deploy discovery tooling across cloud, on-premises, PKI, secret managers, and code repositories. Establish a unified inventory that includes:
- Identity type (certificate, service account, token, key, etc.)
- Location (cloud account, cluster, directory, vault)
- Purpose (documented rationale for existence)
- Owner (team or service, not individual)
- Creation date
- Expiration or rotation date
- Last used date
- Privilege scope
Discovery is never done. The inventory must refresh continuously as new NHIs are created and old ones decommissioned.
Phase 2: Ownership assignment
Assign every NHI in the inventory to a team. NHIs without an owner after a defined grace period should be flagged as candidates for decommissioning. This is the hardest phase of a governance program, because organizational knowledge about what a given NHI is for is often lost.
Phase 3: Lifecycle policy
Define lifecycle policies by NHI category:
- Maximum lifetime by type (e.g., "TLS certificates: 90 days maximum; API keys: 90 days; service account passwords: 180 days")
- Rotation requirements
- Review cadence
- Decommissioning criteria (e.g., "no observed usage in 60 days triggers review")
Policies are enforceable only through automation. Manual enforcement fails at scale.
Phase 4: Automation
Deploy automation to enforce policy:
- Automatic rotation before expiry
- Automatic revocation on decommissioning
- Automatic disabling of unused NHIs after a review grace period
- Automatic escalation when an owner fails to respond to a review request
Phase 5: Continuous monitoring
Instrument NHI usage. Behavioral baselines, anomaly detection, and integration with SIEM enable detection of compromised NHIs.
Phase 6: Incident response
Define playbooks for NHI compromise. What is the revocation process? Who is notified? How is the replacement provisioned? Tabletop these scenarios with the same rigor as human account compromise scenarios.
Metrics That Matter
Effective NHI governance programs report on a small number of high-signal metrics:
- Total NHI population and growth rate by category
- Percentage of NHIs with documented owners
- Percentage of NHIs within policy lifetime
- Number of expired or overdue-rotation NHIs
- Number of decommissioned NHIs per quarter
- Time to revoke a compromised NHI (mean and 95th percentile)
- Number of unused NHIs (no activity in defined window)
These metrics translate NHI governance from a compliance exercise into an operational discipline.
How TigerTrust Fits Into NHI Governance
TigerTrust addresses the certificate slice of NHI governance with the same operational discipline that identity teams apply to human accounts:
- Unified certificate inventory: Discovery across cloud providers, Kubernetes clusters, on-premises appliances, and CDN configurations produces a single source of truth for every certificate.
- Ownership metadata: Certificates carry owner, purpose, and review metadata that integrate with your identity governance platform.
- Lifetime policy enforcement: Configure maximum lifetimes and rotation cadences by certificate class; TigerTrust enforces the policy automatically.
- Automated rotation and revocation: End-to-end certificate lifecycle with no manual steps, including immediate revocation on compromise.
- Behavioral monitoring: Baseline where certificates are deployed and how they are used; detect anomalies that indicate compromise or misuse.
- API surface for NHI platforms: Feed certificate inventory into broader NHI governance tools so certificates are governed alongside tokens, keys, and service accounts.
The 45-to-1 ratio only grows from here. Treat certificates as the first-class NHIs they are and bring them under governance with TigerTrust at tigertrust.io.