A cryptographic key stored in a way that allows signing operations but prevents export of the raw private material. In browser-based DPoP, this is the practical control that keeps a stolen script from simply copying the proofing key and replaying access.
Expanded Definition
A non-extractable key is a cryptographic key that can be used inside a trusted execution environment, browser keystore, hardware module, or platform API for signing, while the raw private material remains unavailable for export. In NHI and agentic systems, that distinction matters because possession of the key handle does not equal possession of the key material. Standards and implementations vary, but the security goal is consistent: reduce the chance that an attacker can steal a reusable secret and move it elsewhere. That makes non-extractable keys especially relevant to browser-based proof flows, device-bound credentials, and ephemeral agent sessions, where key lifecycle and containment are as important as authentication strength. For broader identity governance context, NHI programs described in the Ultimate Guide to NHIs emphasize that credential handling, rotation, and offboarding must be treated as operational controls, not just cryptographic details. The closest external baseline is the identity assurance and lifecycle discipline in NIST Cybersecurity Framework 2.0, which frames identity protection as part of broader governance and access control. The most common misapplication is calling any stored private key non-extractable, which occurs when the application can still export it through debug paths, insecure backups, or misconfigured platform permissions.
Examples and Use Cases
Implementing non-extractable keys rigorously often introduces portability and recovery constraints, requiring organisations to weigh stronger theft resistance against harder migration, backup, and disaster recovery workflows.
- A browser creates a proof-of-possession key for DPoP so the client can sign requests without exposing the private material to JavaScript.
- An AI agent uses a platform-backed key to sign outbound tool calls, reducing the value of token theft if the runtime is compromised.
- A managed service account binds to a hardware-backed key so the key cannot be copied into another host during lateral movement.
- An enterprise session broker issues a key pair for short-lived access, then revokes the handle at logout instead of exporting a reusable file.
These patterns align with the containment-first guidance in the Ultimate Guide to NHIs, especially where secret sprawl and credential reuse create avoidable exposure. They also fit the access-control and lifecycle emphasis in NIST Cybersecurity Framework 2.0, which expects identity-related protections to be built into system design rather than added later. In practice, the right implementation depends on whether the key must survive device loss, be portable across sessions, or remain bound to one browser profile or hardware root of trust.
Why It Matters in NHI Security
Non-extractable keys reduce the blast radius of script injection, browser compromise, and agent runtime theft because attackers cannot simply copy the private key and replay it elsewhere. That makes them a practical control for proof-of-possession schemes, delegated access, and other NHI patterns where a stolen token alone should not be enough. They do not eliminate risk, though. If the signing surface is abused while the key is in use, or if the application accepts weak session binding, the control can still be bypassed operationally. This is why NHI governance needs to treat key storage, use, and revocation as a single lifecycle. The Ultimate Guide to NHIs reports that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which shows how often exposed credentials become real incidents rather than theoretical concerns. In the same vein, NIST Cybersecurity Framework 2.0 reinforces identity protection as part of resilient access control and incident readiness. Organisations typically encounter the importance of non-extractable keys only after a browser compromise or agent token theft, at which point copying the credential is no longer the problem, but replaying it is.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Non-extractable keys limit secret export and support stronger NHI credential containment. |
| NIST CSF 2.0 | PR.AC-1 | Access control depends on binding credentials to approved use, not transferable copies. |
| NIST Zero Trust (SP 800-207) | SC-28 | Zero Trust requires protecting the confidentiality of credential material at rest and in use. |
Use non-exportable key storage for NHI signing keys and verify no alternate export path exists.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
