Non-human identity management is the discipline of governing every credential that authenticates a machine, process or automated agent rather than a person: service accounts, API keys, X.509 certificates, CI/CD pipeline tokens, container runtime credentials and the OAuth 2.0 client secrets used in machine-to-machine flows. In regulated environments subject to NIS-2, DORA and GDPR, these identities have quietly become the dominant attack surface, and their governance has not kept pace with the obligations that now apply to them.
The Scale of the Non-Human Identity Problem
Non-human identities outnumber human accounts by a ratio of roughly 45 to 1 in enterprise environments, according to CyberArk’s Identity Security Threat Landscape Report (2024). Despite that numerical dominance, most governance frameworks in regulated organisations were built around human users: joiners-movers-leavers workflows, quarterly access reviews and privileged-access workstation policies that simply do not map onto a service account that was provisioned by a developer three years ago and never reviewed since.
The reasons for this governance gap are structural. Service accounts are typically created by engineering teams under time pressure, assigned permanent passwords or long-lived API keys, and granted excessive permissions because scoping them tightly requires knowledge of the application’s exact runtime requirements. CI/CD tokens are generated per pipeline and accumulate across repositories. Container images are often shipped with embedded credentials that persist across restarts and environment promotions. None of these identities trigger the leaver process when a project ends or a container image is deprecated.
For organisations subject to NIS-2 Article 21(2)(i), which mandates access-control measures as part of mandatory risk management for essential and important entities, or to DORA Article 9, which requires financial entities to maintain ICT security policies covering access management, this governance gap is not a theoretical concern. It is a directly auditable deficiency.
Centralised Secrets Management Without US-Jurisdiction Exposure
A sovereign organisation must not route machine credentials through any SaaS vault operated by a provider subject to US jurisdiction, because the CLOUD Act (18 U.S.C. § 2713) allows US authorities to compel disclosure of data held by US-incorporated entities regardless of where the data is physically stored. The only architecturally sound answer is an on-premises secrets management platform under the organisation’s own control.
HashiCorp Vault open-source edition, deployed on-premises on sovereign infrastructure, provides the core capabilities needed: dynamic secrets with configurable TTLs, an audit log exportable to a sovereign SIEM, policy-based access control, and a secrets engine that integrates with Active Directory, PKI, databases and Kubernetes. The governance wrapper around Vault matters as much as the software itself. The organisation must define a secrets taxonomy, assign ownership per secret class, configure the audit backend to an immutable log store, and integrate Vault’s lease-expiry events into incident-response runbooks so that a breached secret triggers automated revocation rather than a manual ticket.
Organisations that prefer a fully open-source alternative without HashiCorp’s Business Source Licence considerations can evaluate OpenBao, a community fork maintained after HashiCorp’s 2023 licence change, which retains API compatibility with Vault while remaining under the Mozilla Public Licence.
Regulatory Obligations That Apply Directly to Machine Credentials
| Regulation | Specific provision | Obligation as it applies to non-human identities |
|---|---|---|
| NIS-2 | Article 21(2)(i) | Access-control policies must cover all identity types, with documented controls for provisioning, review and revocation of machine accounts |
| DORA | Article 9 ICT security policies | Financial entities must maintain policies that govern authentication of ICT systems and automated processes, including credential lifecycle and rotation schedules |
| GDPR | Article 32(1)(b) | Ongoing confidentiality and integrity of processing systems requires that machine credentials cannot be permanently valid; short-lived credentials or rotation schedules are a direct technical measure |
During an audit, a CISO must be able to produce: a complete inventory of non-human identities and their associated permissions; evidence of periodic access reviews covering service accounts; rotation logs showing that credentials were rotated within the defined schedule; and vault audit logs showing which process accessed which secret and when. The inventory alone is frequently the weakest point. Organisations that have not yet instrumented their CI/CD pipelines, Kubernetes clusters and legacy application servers for credential discovery will find that they cannot pass an Article 21 audit on access controls without first completing that discovery exercise.
SPIFFE/SPIRE Workload Identity for Container and Microservice Environments
SPIFFE (Secure Production Identity Framework for Everyone) and its reference implementation SPIRE, both hosted by the Cloud Native Computing Foundation (CNCF), solve the specific problem of issuing verifiable identities to container workloads running on sovereign infrastructure without requiring static API keys embedded in images or environment variables.
SPIRE attests each workload by examining node and workload selectors (kernel-level attributes, Kubernetes pod annotations, process metadata) and issues a SPIFFE Verifiable Identity Document (SVID), which is an X.509 certificate bound to a SPIFFE URI of the form spiffe://trust-domain/workload-path. SVIDs are short-lived, typically with a TTL of one hour or less, and are automatically rotated by the SPIRE agent before expiry. When a container is rescheduled or terminated, its SVID expires and is not reissued unless the workload successfully re-attests on the new node.
This architecture directly replaces the long-lived API key model that makes breach response so expensive. With a static API key, the response to a compromise requires identifying every system that holds a copy of the key and rotating it simultaneously; with SPIFFE/SPIRE, the blast radius is bounded to the SVID’s remaining TTL and no manual rotation is required. Service meshes such as Istio and Linkerd can be configured to use SPIRE as their identity backend, enabling mutual TLS between microservices with no static credentials in the application code.
Post-Quantum Migration for Machine-to-Machine Certificates
Machine-to-machine TLS in high-frequency internal service meshes presents a specific post-quantum challenge. A sovereign PKI that issues ML-DSA certificates under FIPS 204 (Module-Lattice-Based Digital Signature Algorithm, standardised by NIST in August 2024) provides quantum-resistant authentication, but the operational consequences for API gateways must be planned carefully.
An ML-DSA-65 signature is approximately 3,309 bytes, compared with roughly 72 bytes for an ECDSA P-256 signature. A certificate chain of three certificates using ML-DSA-65 can therefore exceed 10 kilobytes before the TLS handshake payload is considered, which creates fragmentation issues on links with a standard 1,500-byte MTU and increased latency at gateways processing thousands of connections per second. The sovereign PKI team must address this through a combination of: configuring TLS session resumption to reduce full-handshake frequency; using OCSP stapling to avoid repeated certificate-chain fetches; and where constrained gateways cannot be upgraded, deploying hybrid certificates that pair an ECDSA key with an ML-DSA signature so that classical clients continue to function during the transition period.
OAuth 2.0 client-credentials flow (RFC 6749, Section 4.4) is the standard grant type for machine-to-machine authorisation. When the authorisation server and resource server both operate on sovereign infrastructure, the client-assertion variant (RFC 7523) allows the client to prove its identity using a signed JWT rather than a shared secret, and that JWT signature can use ML-DSA once the token library is updated. Organisations should audit every internal OAuth deployment to confirm that client secrets are stored in Vault rather than in application configuration files, and plan the JWT-signature algorithm migration as part of the broader post-quantum PKI roadmap.
Differentiating Identity Classes in IAM Governance
A sovereign organisation’s IAM governance framework must treat human privileged accounts, service accounts and ephemeral workload identities as three distinct identity classes, each with its own review cadence, policy controls and breach-response runbook.
Human privileged accounts are governed through the standard privileged-access workstation policy: dedicated hardware, no internet browsing, session recording and just-in-time elevation with approval workflow. Access reviews run quarterly or after every role change. Breach response involves immediate account suspension, session termination and forensic review of the recorded session log.
Service accounts require a separate ownership register in which a named human account owner is responsible for each service account’s continued necessity and permission scope. Reviews run at least annually, with automated alerting if a service account authenticates from an unexpected source IP or at an unexpected time. Breach response for a service account involves immediate password rotation or key revocation via Vault, notification to the application owner, and review of the audit log for lateral movement indicators going back to the credential’s last rotation date.
Ephemeral workload identities issued by SPIRE require no manual review cadence because their short TTL makes the concept of a standing review largely redundant. The governance focus shifts to the attestation policy: which node and workload selectors are permitted to receive an SVID for a given trust domain, and who can modify those policies. Changes to SPIRE registration entries must go through change management and be logged to the same audit infrastructure as human privileged-account changes, so that an auditor can trace any SVID-scope expansion back to an approved change request.
FAQ
What counts as a non-human identity in a regulated on-premises environment?
Non-human identities include service accounts in Active Directory or LDAP, API keys issued to backend integrations, X.509 certificates authenticating microservices, CI/CD pipeline tokens, container runtime credentials, database connection strings and SSH keys used by automation scripts. Any credential that authenticates a process rather than a person falls into this category.
Can HashiCorp Vault open-source edition meet DORA and NIS-2 audit requirements when deployed on-premises?
Yes, when deployed on sovereign infrastructure Vault provides the audit log, secret lease, dynamic credential and policy engine features needed to demonstrate compliance. The organisation must configure audit backends, enforce TLS everywhere, integrate Vault with its SIEM and document the governance procedures that surround it. The open-source edition does not include enterprise features such as HSM auto-unseal or performance replication, so those gaps must be addressed through compensating controls or by evaluating alternative licensing.
How long does a SPIFFE SVID remain valid and what happens when a workload is rescheduled?
A SPIFFE Verifiable Identity Document is typically issued with a TTL of one hour or less, configurable per workload class. When SPIRE re-attests the workload after rescheduling it issues a fresh SVID bound to the new node attestation, meaning the old credential expires automatically rather than needing manual revocation. This short-lived model eliminates the orphaned-credential problem common with long-lived API keys.
What is ML-DSA and why does it cause certificate-size inflation at API gateways?
ML-DSA (Module-Lattice-Based Digital Signature Algorithm), standardised as FIPS 204 by NIST in 2024, produces signatures significantly larger than ECDSA P-256. An ML-DSA-65 signature is approximately 3,309 bytes versus roughly 72 bytes for ECDSA P-256. At high-frequency API gateways this inflates TLS handshake payloads. Mitigations include session resumption, OCSP stapling and hardware offload for signature verification.
Does GDPR Article 32 explicitly require rotation of machine credentials?
Article 32 requires appropriate technical and organisational measures to ensure ongoing confidentiality and integrity of processing systems. While it does not name credential rotation by term, supervisory authorities and the EDPB have consistently interpreted this obligation to include measures that limit the impact of a compromised credential, of which automated rotation and short credential lifetimes are the most direct technical controls available.