Non-Human Identity & Machine Identity Management

The core technical object: what a non-human identity actually is

A non-human identity (NHI), or machine identity, is a digital credential and identity lifecycle assigned to a workload, service, device, application, process, or automation—rather than to an individual human employee or consumer. NIST’s key-management guidance describes the lifecycle of the cryptographic key material that underpins these identities: key generation, activation, active use, suspension, revocation, and destruction (NIST SP 800-57 Part 1 Rev. 5, DOI: 10.6028/NIST.SP.800-57pt1r5, May 2020; accessed 2026-05-09). RFC 5280 defines the X.509 certificate profile and revocation mechanisms used for many machine identities (RFC 5280, May 2008; rfc-editor.org ).

The important distinction is not “human vs. robot,” but what is being authorized and how the credential is bound. RFC 8705 specifies two machine-identity mechanisms for OAuth 2.0: mutual-TLS client authentication with X.509 client certificates, and certificate-bound access tokens that bind a token to the client’s certificate (RFC 8705, February 2020; rfc-editor.org ). This is a Tier 1 standards document and is useful because it separates NHI authentication from human single sign-on.

A machine identity therefore includes at least the following credential classes:

• X.509 certificates for TLS server/client authentication, code signing, email/S/MIME, documents, and IoT device attestation.
• OPC UA, SSH keys, and service-account passwords for machine-to-machine access.
• Cloud workload-identity tokens such as AWS IAM roles, Google service-account OIDC tokens, Azure managed identities, and SPIFFE SVIDs.
• API keys and OAuth 2.0 client credentials for service-to-service automation.
• Secrets that protect those credentials: private keys, database passwords, HMAC keys, and cloud access keys.

The common technical requirement across all of these is credential lifecycle management: issuance, rotation, revocation, inventory, and binding to a specific workload or device. NIST’s certificate-management guidance for federal agencies frames certificate misconfiguration and missed expiration as an availability and integrity problem, not only a confidentiality problem (NIST SP 1800-16, July 2018; nccoe.nist.gov ).

Standards and technical foundations

The strongest source-tier evidence for NHI management comes from standards bodies, not marketing materials.

2.1 NIST SP 800-57, RFC 5280, RFC 8705

• NIST SP 800-57 Part 1 Rev. 5: key-management lifecycle, including the need to rotate and revoke keys before compromise and to maintain key chains of custody (DOI: 10.6028/NIST.SP.800-57pt1r5, May 2020; accessed 2026-05-09).
• RFC 5280: X.509 certificate profile, revocation lists (CRLs), and certification-path validation (rfc-editor.org ).
• RFC 8705: mutual-TLS client authentication and certificate-bound OAuth access tokens; this is the closest standards-body definition of machine identity authentication for application-to-application traffic (rfc-editor.org ).

These three are independent source lineages: NIST and IETF are different institutions, so technical claims based on both are cross-verified for standards support.

2.2 FIPS 140-3 and cryptographic modules

FIPS 140-3 sets the security requirements for cryptographic modules used by machine identities and hardware-backed roots of trust (NIST, FIPS 140-3 final, March 22, 2019; csrc.nist.gov ). This matters because many machine identities are protected by HSMs, TPMs, or cloud KMS/HSM services. A software credential without a validated hardware or software cryptographic module is not the same security control as a credential generated and stored inside a FIPS 140-3 module.

2.3 SPIFFE/SPIRE for workload identity

SPIFFE is a Cloud Native Computing Foundation project that defines workload identity as a URI in a trust domain, such as spiffe://example.com/payments/checkout-service. The SPIFFE ID standard is a named standards-style specification, even if not an ISO/IEEE document (SPIFFE ID specification; github.com ; accessed 2026-05-09). SPIRE is the reference implementation that issues SVIDs; it is a Tier 2 engineering document because it is vendor/community-maintained code and docs.

2.4 Cross-source technical claim

A load-bearing technical claim is:

Machine identity security requires binding a credential to a specific workload or device and rotating or revoking that credential at defined lifecycle events.

This claim is supported by two independent Tier 1 lineages:

1. NIST SP 800-57 Part 1 Rev. 5 requires key-rotation and revocation procedures (DOI: 10.6028/NIST.SP.800-57pt1r5).
2. RFC 8705 requires binding access tokens to the client’s certificate so that stolen tokens are less useful without the certificate (rfc-editor.org ).

That is two independent institutions, so the claim is not [SINGLE-SOURCE].

Patent and peer-reviewed evidence

3.1 Granted patent

• Document: U.S. Patent No. 8,732,455 B2
• Grant date: May 20, 2014
• Access URL: patents.google.com
• Assignee/title/claims: Reported in this pass as a Venafi, Inc. machine-identity/certificate-lifecycle patent; exact title and claim scope were not re-extracted from the full text, so treat the specific assignee/title as needs primary source validation.

The important methodological point: a patent is evidence of recorded claims, not proof of commercial performance, feasibility, or market adoption. It can support a narrow moat argument only if the claims are actually read and mapped to shipping products. This note does not rely on the patent for any technical performance claim.

3.2 Peer-reviewed paper

• Document: “Authentication and Authorization for the Internet of Things”
• Publication venue: IEEE Internet of Things Journal
• DOI: 10.1109/JIOT.2017.2737622
• Access URL: doi.org
• Publication date: 2017
• Access date: 2026-05-09

This paper is adjacent to machine identity rather than a perfect NHI-management paper; it covers device/thing authentication and authorization. It is used here as the required peer-reviewed source for machine-to-machine authentication. If a more current NHI-specific journal article is available, it should replace this in a second pass.

3.3 Contradiction between patent evidence and market evidence

The patent cited above is from 2014. The standards and cloud-native workload-identity mechanisms that now dominate the market—AWS IAM Roles Anywhere, Google Workload Identity Federation, Microsoft Entra Workload ID, and SPIFFE/SPIRE—are all either open specifications or public-cloud services. That is a contradiction for any moat thesis built solely on a 2014 patent family: the patent may cover a specific certificate-lifecycle method, but the ecosystem has standardized around cloud API-accessible credential issuance and open workload-identity protocols. A patent is not evidence that the patent owner currently controls the market or that customers cannot substitute an open-source or cloud-native alternative.

Deployment context and company self-reported claims

4.1 CyberArk/Venafi

CyberArk completed its acquisition of Venafi on October 1, 2024, according to CyberArk’s press release (cyberark.com ; accessed 2026-05-09). CyberArk is a U.S.-listed company; its SEC filings are Tier 2 adoption context. CyberArk markets “machine identity” as part of its identity security platform. The company’s 10-K is the appropriate place to verify revenue mix and customer counts (SEC EDGAR, CyberArk, CIK 0001334575; sec.gov ; accessed 2026-05-09).

Self-reported marketing figure: CyberArk/Venafi materials often state that machine identities outnumber human identities by roughly 45:1. This is a marketing/industry-survey figure, not independently verified in a Tier 1 source. Treat it as self-reported; the exact ratio needs primary source validation.

4.2 HashiCorp

HashiCorp Vault provides secrets management, PKI secret engine, dynamic database credentials, and Kubernetes workload identity integration (HashiCorp Vault docs; developer.hashicorp.com ; accessed 2026-05-09). HashiCorp is a U.S.-listed company; its 10-K risk factors are the correct source for customer concentration, subscription transition, and competitive risk (HashiCorp investor page; ir.hashicorp.com ; accessed 2026-05-09).

Discrepancy worth noting: Vault is sometimes marketed as a “zero trust security” product, but HashiCorp’s 10-K risk factors do not claim that Vault eliminates NHI risk; they warn that customers may misconfigure or fail to adopt the product correctly. The technical documentation also states that Vault does not manage non-Vault identity sources unless explicitly integrated. That is a real distinction between marketing language and filed disclosure.

4.3 Public-cloud workload identity

• AWS IAM Roles Anywhere: allows non-AWS workloads to obtain temporary role credentials using X.509 certificates (AWS Docs, IAM Roles Anywhere; docs.aws.amazon.com ; accessed 2026-05-09).
• Google Cloud Workload Identity Federation: allows external identities, including OIDC and SAML sources, to impersonate Google service accounts without static keys (Google Cloud IAM docs; cloud.google.com ; accessed 2026-05-09).
• Microsoft Entra Workload ID: supports workload identities such as service principals, managed identities, and workload-identity federation (Microsoft Learn; learn.microsoft.com ; accessed 2026-05-09).

These are three independent public-cloud vendors, so the claim that cloud workload identity has shifted toward temporary, federated credentials and away from static access keys is cross-verified by three separate Tier 2 institution sources.

4.4 Pricing source for worked calculation

AWS public Certificate Manager TLS certificates are issued at no additional charge for use with AWS services (AWS Certificate Manager FAQ; aws.amazon.com ; accessed 2026-05-09). By contrast, AWS Private CA publishes a price for private end-entity certificates; the public list price has been $0.75 per private certificate per month in the AWS Private CA pricing page, equivalent to $9.00 per certificate-year (AWS Private CA pricing; aws.amazon.com ; accessed 2026-05-09). AWS Secrets Manager publishes pricing of $0.40 per secret per month plus $0.05 per 10,000 API calls (AWS Secrets Manager pricing; aws.amazon.com ; accessed 2026-05-09). These are Tier 2 self-reported vendor list prices, not independently benchmarked prices.

This is itself a contradiction for unit economics: public TLS certificates are effectively free, so the monetizable unit is not the certificate itself but the managed private PKI, rotation, discovery, inventory, provisioning automation, audit, and policy enforcement.

Cross-reference against company filings: where the moat narrative weakens

5.1 Marketing vs. 10-K disclosure

Marketing claim: “Machine identity is the largest unmanaged attack surface; enterprises need specialized NHI management.”

Filing reality: Public company 10-Ks tend to describe identity and secrets management as one competitive category, not as a separate fully defensible moat. CyberArk’s 10-K risk factors include competition from large cloud providers and from open-source alternatives; HashiCorp’s 10-K similarly highlights competition and customer adoption risk. This matters because if a public-cloud provider or open-source SPIFFE/SPIRE can issue and rotate credentials natively, the standalone machine-identity management vendor’s value proposition is mainly governance, audit, inventory, and multi-cloud policy—not raw credential issuance.

5.2 Patent portfolio vs. current architecture

A 2014 patent family may predate the current workload-identity models used by AWS, Google, Microsoft, and SPIFFE. A second-pass should retrieve the patent claims and compare them to SPIFFE/SPIRE and cloud workload-identity implementations. For now, the patent is evidence of recorded claims only, not evidence of current architectural control.

Unit economics / business model

Who monetizes this technology, and how

Companies monetize NHI/machine-identity management primarily through:

1. SaaS subscriptions — per-workload, per-machine-identity, or per-license recurring charges. CyberArk’s business has shifted toward subscription/annual recurring revenue, which is visible in its SEC filings (CyberArk SEC EDGAR page; sec.gov ; accessed 2026-05-09).
2. Cloud consumption pricing — AWS Private CA at about $0.75/certificate/month, AWS Secrets Manager at $0.40/secret/month plus API fees (AWS pricing pages; aws.amazon.com and aws.amazon.com ).
3. Open-core model — HashiCorp Vault has an open-source core with paid enterprise features and support subscriptions (HashiCorp Vault docs; developer.hashicorp.com ).
4. Professional services and audit support — certificate lifecycle assessment, PKI health checks, migration from static keys to temporary credentials.

The value capture is not in the raw certificate, because public TLS certificates are free. The value is in the automation software, policy engine, audit trail, and the labor avoided during rotation and outage response.

Typical margin shape

Software subscription businesses in this category typically have high gross margins. CyberArk’s exact fiscal-year gross margin should be pulled from the 10-K; until then, any precise margin figure is needs primary source validation. The unit economics below do not depend on the vendor’s gross margin; they depend on customer-side labor and cloud-consumption costs.

Who captures the value

The customer captures the largest share of value through avoided manual labor and avoided certificate-related outages. The vendor captures recurring subscription revenue that is much smaller than the total avoided manual labor cost, which is why the economics can be compelling even when the vendor’s list price feels high.

Worked calculation: manual vs. automated machine-identity management

Formula

\[

C_{\text{manual}} = N \times R \times L \times W

\]

\[

C_{\text{automation}} = N \times P + F

\]

Where:

• \(N\) = number of machine identities managed.
• \(R\) = renewal events per identity per year.
• \(L\) = labor hours per renewal/discovery event.
• \(W\) = loaded labor cost per hour.
• \(P\) = automated per-identity annual cost.
• \(F\) = fixed annual automation platform or subscription cost.

Base-case inputs

Base-case calculation

\[

C_{\text{manual}} = 50{,}000 \times 1.0 \times 3.0 \times 85 = 12{,}750{,}000

\]

Manual annual cost: $12.75 million.

\[

C_{\text{automation}} = 50{,}000 \times 9 + 200{,}000 = 450{,}000 + 200{,}000 = 650{,}000

\]

Automated annual cost: $650,000.

Annual savings:

\[

12{,}750{,}000 - 650{,}000 = 12{,}100{,}000

\]

Baseline estimated savings: $12.1 million/year, before accounting for avoided outage costs.

Sensitivity

If \(L\) falls to 1.5 hours per identity:

\[

C_{\text{manual}} = 50{,}000 \times 1.0 \times 1.5 \times 85 = 6{,}375{,}000

\]

Savings = \(6{,}375{,}000 - 650{,}000 = \$5.725\text{ million/year}\).

If \(L\) rises to 6.0 hours per identity:

\[

C_{\text{manual}} = 50{,}000 \times 1.0 \times 6.0 \times 85 = 25{,}500{,}000

\]

Savings = \(25{,}500{,}000 - 650{,}000 = \$24.85\text{ million/year}\).

The model is highly sensitive to \(L\), the assumed manual effort per identity. That assumption is not Tier 1 sourced and must be validated against a real time-study or customer audit before relying on the result.

Parameter table

Disconfirming Evidence

The NHI/machine-identity thesis would be materially weakened if:

1. Human accounts remain the dominant attack path. If incident data show that MFA-protected human accounts, not machine credentials, account for most successful cloud intrusions, then standalone NHI management may be over-prioritized relative to identity and access management generally.
2. Public-cloud native rotation and SPIFFE/SPIRE become good enough at near-zero marginal cost. If AWS, Google, and Microsoft ship native automated rotation, discovery, inventory, and audit that satisfy enterprise auditor requirements, the standalone machine-identity vendor’s economic moat contracts.
3. Free public TLS certificates and 90-day certificate lifecycles reduce certificate-outage frequency. If short-lived-cipher and automatic renewal via ACM/Let’s Encrypt-style integrations make outage-driven certificate management purchases unnecessary, the breach/outage cost argument weakens.
4. Auditor and regulator requirements do not extend to NHI inventory or revocation. If regulatory bodies require only human-access review and no machine-credential inventory, adoption may plateau inside compliance-driven buyers.
5. The worked calculation’s labor assumption is too high. If independent time-study data show manual certification renewal takes 15–30 minutes, not 3 hours, the manual-vs-automation savings fall dramatically; the model is explicitly sensitive to this assumption and the assumption is currently needs primary source validation.