The Identity Imbalance
Your organization probably has a solid handle on human identities. You've deployed SSO, MFA, identity governance, and privileged access management. But for every human identity you manage, there are 45 machine identities that may not receive the same attention.
Machine identities — TLS certificates, API keys, SSH keys, service account tokens, workload identities, IoT device certificates — now vastly outnumber human identities in every enterprise. And they're growing at 30% per year, driven by microservices, cloud-native architecture, IoT, and API-first design.
In 2026, machine identity management isn't a niche concern. It's the largest unmanaged attack surface in most organizations.
What Counts as a Machine Identity
The Machine Identity Landscape
Machine Identities
├── TLS/SSL Certificates
│ ├── Public website certificates
│ ├── Internal service certificates
│ ├── mTLS client certificates
│ └── Wildcard certificates
├── SSH Keys
│ ├── User SSH keys
│ ├── Service account SSH keys
│ └── Host keys
├── API Keys and Tokens
│ ├── Service-to-service API keys
│ ├── Cloud provider API keys
│ ├── Third-party integration tokens
│ └── JWT signing keys
├── Code Signing Certificates
│ ├── Application signing
│ ├── Container image signing
│ └── Driver/firmware signing
├── Workload Identities
│ ├── Kubernetes service accounts
│ ├── Cloud IAM service accounts
│ ├── SPIFFE/SPIRE identities
│ └── Service mesh identities
├── IoT Device Certificates
│ ├── Device authentication
│ ├── Firmware validation
│ └── Data encryption
└── Encryption Keys
├── Data-at-rest encryption
├── Database encryption (TDE)
└── Key encryption keys (KEKs)
Scale by the Numbers
| Identity Type | Typical Enterprise Count | Growth Rate |
|---|---|---|
| TLS certificates | 10,000-100,000 | 25%/year |
| SSH keys | 50,000-500,000 | 15%/year |
| API keys/tokens | 20,000-200,000 | 40%/year |
| Service accounts | 5,000-50,000 | 35%/year |
| IoT certificates | 10,000-1,000,000+ | 50%/year |
| Code signing certs | 100-1,000 | 20%/year |
Why Machine Identities Are Hard to Manage
The Challenges at Scale
1. No Central Authority
Human identities typically flow through a single identity provider (Okta, Azure AD, Google Workspace). Machine identities are created across dozens of systems with no single source of truth:
- Cloud providers issue service account keys
- Developers generate SSH keys on laptops
- CI/CD pipelines create API tokens
- Kubernetes auto-provisions service accounts
- CAs issue certificates through various channels
- Applications generate their own JWT signing keys
2. No Natural Lifecycle
Human identities have clear lifecycle events: onboarding, role change, offboarding. Machine identities often lack these natural checkpoints:
- When should an API key be rotated? When it "expires" (if it even has an expiration)?
- When should a service account be decommissioned? When someone notices it's unused?
- When should an SSH key be revoked? When the person who created it leaves?
3. No Owner Accountability
Every human identity has an owner — the human. Machine identities frequently have unclear or absent ownership:
- The developer who created the API key left the company
- The service account was provisioned by a Terraform script that's been modified since
- The certificate was issued by a team that was reorganized
- Nobody remembers why the SSH key exists or what depends on it
4. Sprawl Across Environments
Machine identities span:
- Multiple cloud providers (AWS, Azure, GCP)
- On-premises data centers
- Edge locations
- Developer workstations
- CI/CD systems
- Container orchestration platforms
- Third-party SaaS integrations
The Security Implications
Unmanaged machine identities create significant security risks:
Compromised Credentials
- Leaked API keys in code repositories (GitHub secret scanning finds thousands daily)
- SSH keys without passphrases on developer machines
- Service account keys stored in plaintext configuration files
- Expired certificates that bypass revocation checks
Lateral Movement
- Over-privileged service accounts used as pivot points
- Shared credentials across environments (dev keys in production)
- Static credentials that never rotate
Compliance Gaps
- Unaudited machine identity usage
- No inventory of cryptographic assets for PQC migration planning
- Missing rotation policies for regulatory compliance
A Framework for Machine Identity Management
Tier 1: Discovery and Inventory
You cannot manage what you cannot see. Start with comprehensive discovery:
discovery_program: tls_certificates: methods: - network_scanning - ct_log_monitoring - cloud_api_integration - kubernetes_secret_scanning - agent_based_filesystem_scanning frequency: continuous ssh_keys: methods: - host_scanning - authorized_keys_auditing - known_hosts_analysis - git_repository_scanning frequency: daily api_keys: methods: - cloud_iam_audit - secret_manager_inventory - code_repository_scanning - network_traffic_analysis frequency: daily service_accounts: methods: - cloud_iam_listing - kubernetes_rbac_audit - active_directory_service_account_scan frequency: daily
Tier 2: Classification and Ownership
Once discovered, classify each machine identity:
Classification Matrix
| Classification | Criteria | Examples |
|---|---|---|
| Critical | Revenue-impacting, customer-facing | Production TLS certs, payment API keys |
| High | Core infrastructure, internal operations | mTLS certs, database credentials |
| Medium | Supporting services, non-critical | Monitoring API keys, staging certs |
| Low | Development, testing | Dev SSH keys, test API tokens |
Ownership Assignment
Every machine identity needs an owner — a team, not an individual:
ownership_policy: assignment_rules: - type: tls_certificate owner: "platform-engineering" fallback: "security-team" - type: api_key owner: "team-that-created-it" fallback: "service-owner" - type: service_account owner: "team-using-the-service" fallback: "cloud-platform-team" orphan_policy: detection: "no owner identified after discovery" action: "assign to security team for investigation" sla: "72 hours to identify owner or decommission"
Tier 3: Lifecycle Automation
Automate the lifecycle of every machine identity type:
TLS Certificates
- Automated discovery → inventory → renewal → deployment
- ACME-based issuance with multi-CA support
- Policy-driven validity and algorithm requirements
SSH Keys
- Centralized key generation and distribution
- Certificate-based SSH (SSH certificates vs. static keys)
- Automatic rotation on configurable schedules
API Keys
- Automated rotation with zero-downtime key rollover
- Short-lived tokens where possible (OAuth 2.0, STS)
- Automatic revocation on team/personnel changes
Service Accounts
- Just-in-time provisioning with automatic expiration
- Least-privilege enforcement with regular access reviews
- Workload identity federation to eliminate static credentials
Tier 4: Governance and Compliance
Establish policies that scale:
governance_policies: rotation: tls_certificates: "aligned with CA/B Forum validity (200 days max)" ssh_keys: "90 days" api_keys: "90 days" service_accounts: "annual review, rotate keys quarterly" access: principle: "least privilege" review_frequency: "quarterly" unused_threshold: "90 days → flag for decommission" cryptography: minimum_key_size_rsa: 2048 minimum_key_size_ec: P-256 prohibited_algorithms: ["SHA-1", "3DES", "RC4"] pqc_readiness: "inventory all algorithms for migration planning" compliance: audit_logging: "all identity creation, usage, rotation, revocation" reporting: "monthly summary to security leadership" exceptions: "documented, time-limited, approved by security team"
Tier 5: Monitoring and Response
Continuous monitoring catches issues before they become incidents:
Key Metrics
| Metric | Target | Alert Threshold |
|---|---|---|
| Identity inventory coverage | > 95% | < 90% |
| Credentials expiring in 7 days | 0 (all auto-renewed) | > 0 |
| Orphaned identities | < 5% | > 10% |
| Average credential age | < policy max | > 80% of policy max |
| Failed rotation attempts | < 1% | > 3% |
| Unused credentials (90+ days) | < 10% | > 20% |
The Convergence of Machine Identity and Zero Trust
Machine Identity as Zero Trust Foundation
Zero trust architecture is built on the principle of "never trust, always verify." For machine-to-machine communication, this means:
- Every service must prove its identity (mTLS, SPIFFE/SPIRE)
- Every API call must be authenticated and authorized
- Network location doesn't confer trust
- All communications are encrypted
Machine identity management is the operational foundation that makes zero trust work. Without reliable, automated machine identity provisioning and rotation, zero trust degrades to "sometimes trust" — which is worse than no trust model at all.
SPIFFE and Workload Identity
The SPIFFE (Secure Production Identity Framework For Everyone) standard is gaining traction for workload identity:
SPIFFE ID: spiffe://example.com/service/payment-api
Certificate: X.509 SVID (short-lived, auto-rotated)
Lifetime: 1 hour
Rotation: Automatic by SPIRE agent
Trust Domain: example.com
SPIFFE provides cryptographic identity for workloads without relying on network-based trust. Combined with service mesh (Istio, Linkerd), it enables automatic mTLS between all services.
How TigerTrust Addresses Machine Identity
TigerTrust provides comprehensive machine identity management:
- Multi-source discovery across TLS certificates, cloud credentials, Kubernetes secrets, and more
- Automated lifecycle management for certificates with ACME, policy-based renewal, and deployment automation
- Cryptographic inventory showing every algorithm, key size, and certificate type in your environment
- Ownership tracking with team-based assignment and orphan detection
- Compliance reporting for PCI DSS, SOC 2, and industry-specific requirements
- PQC migration planning with algorithm inventory and readiness assessment
Machine identities are your largest identity surface. Start managing them at tigertrust.io.