Machine Identities: Impact on HSM Architecture

As AI agents and automated workloads move into production, they bring a rapidly growing population of non-human identities, each requiring cryptographic credentials. In this blog post, we examine how this shift changes the requirements for (Hardware Security Modules) HSMs and key management, and what to consider when preparing your cryptographic infrastructure.
 

The Machine Identity Shift 

The number of non-human identities in enterprise environments has grown dramatically. Service accounts, automation bots, container workloads, and AI agents now collectively outnumber human users in many organizations by a wide margin; research from Rubrik Zero Labs places the ratio at 82 to 1. While the exact number varies by industry, the directional trend is clear: machines are becoming the primary consumers of cryptographic services. This matters for HSM planning because each of these identities needs cryptographic material to function, keys for signing and certificates for authentication, tokens for authorization. What has changed is the operational tempo. Automated workloads request credentials programmatically. AI agents interacting with APIs and downstream services may require multiple distinct identities per workflow, with shorter credential lifecycles and higher issuance volumes. For organizations relying on HSMs as their root of trust, this creates architectural questions worth addressing before the infrastructure is under pressure.

Where the Pressure Falls

It is important to be precise about where non-human identities actually interact with HSMs. Many machine-to-machine authentication flows rely on software-based token exchange (OAuth, JWT) that may never touch an HSM directly. The HSM’s role is typically upstream: protecting the root keys that sign certificates, generating key material for token issuance infrastructure, and securing the certificate authority the entire trust chain depends on. As the population of non-human identities grows, this upstream infrastructure faces pressure in three areas. 

• Key generation and signing throughput. When hundreds of automated workloads each require regularly rotated certificates, the volume of signing requests to your CA infrastructure , and the HSM backing it, increases proportionally. Organizations that sized their HSM fleet for human-scale issuance may find automated workloads push them toward higher-throughput models.
• Tenant isolation. In environments where multiple teams, business units, or customers share cryptographic infrastructure, each agent population may require its own isolated key domain. Without proper isolation, a compromised credential in one domain could affect another. This is a multi-tenancy challenge, not just an identity management challenge.
• Key lifecycle management at scale. Non-human identities are created and retired more frequently than human accounts. Orphaned machine credentials, keys that remain active after the workload they served has been decommissioned, are a well-documented security risk. Managing this lifecycle centrally, with policy-driven automation, requires a key management system tightly integrated with the HSM infrastructure.
   

Preparing Your HSM Architecture

For organizations evaluating whether their current infrastructure can support growing machine identity volumes, three capabilities matter most. 

Throughput that matches automated demand. Utimaco’s u.trust GP HSM Se-Series scales from the Se100 through to the Se40k, delivering up to 40,000 RSA 2,048-bit signatures per second. The in-field upgrade path between models means organizations can start at their current demand level and scale without replacing hardware.

Multi-tenancy for identity domain isolation. The Se-Series supports up to 31 fully isolated containerized tenants (cHSMs), each functioning as an independent HSM with its own key store, access controls, and audit trail. For a detailed explanation of how this architecture works, see our post on secure multi-tenancy.

Centralized key lifecycle management. HSMs protect individual keys. A Key Management System orchestrates the lifecycle of all keys across the organization; generation, rotation, revocation, and destruction; according to centrally defined policies. Utimaco’s KMS (Key Management System) provides this orchestration across heterogeneous environments. Our recent blog on KMS for AI deployments explains how this applies specifically to automated workloads.

Looking Ahead: Crypto-Agility 

Machine identities deployed today will still be operating when current cryptographic algorithms face deprecation, NIST’s timeline sets RSA and ECC disallowance by 2035, and the Cyber Resilience Act will require quantum-safe upgrade paths from December 2027. Building on HSMs that support in-field algorithm upgrades means your foundation can evolve as requirements change. Utimaco’s Quantum Protect enables activation of NIST standardized post-quantum algorithms on existing hardware, with all algorithms NIST CAVP validated.
 

Getting Started 

The growth of machine identities does not require an immediate infrastructure overhaul. But it warrants an honest assessment of whether your current HSM fleet can handle the demand trajectory , and whether the platform can adapt as both identity volumes and cryptographic standards evolve.
 

Start u.trust 360 Free Trial | Explore Quantum Protect Simulator | Contact Sales
 

Related: Governing AI Trust: Why KMS Are Essential · The Role of GP HSMs in the AI Ecosystem · AI Security Isn’t About Models, it is About Governance · How HSMs Support Secure Multi-Tenancy
 

개요

Amani Karchoud

Product Marketing Manager, Utimaco