An Endorsement Key should be generated and kept inside trusted hardware so it never needs to be exposed in normal use. Protect it with hardware-backed controls, restricted administrative access, and tamper-resistant storage, and monitor for attempts to copy or reuse it. If the key is compromised, device identity and trust can be undermined.
What an Endorsement Key is and why storage matters
An endorsement key is the device-root key that anchors trust for a hardware platform, so the storage question is really about preserving that trust boundary. The right model is simple: the private key should stay inside trusted hardware, with the platform performing the needed cryptographic operations without revealing the key material in normal use.
This matters because the Endorsement Key is not just another secret. If it can be copied, exported, or reused outside the intended hardware boundary, the device can no longer prove that its identity is bound to genuine hardware rather than a cloned credential.
That is why secure storage is usually paired with tamper resistance, access restriction, and hardware-backed protection mechanisms. The goal is not convenience, it is to make key extraction materially harder than ordinary administrative access or software compromise.
How the key should be protected in practice
Protection starts with keeping the private portion non-exportable and limiting who can interact with the hardware that holds it. Administrative access should be tightly controlled, because anyone who can alter firmware, policy, or provisioning workflows may be able to weaken the trust model even if they never see the raw key.
In operational terms, the key should be treated as device-root material, not as a file to back up or move between systems. Where the platform supports it, use hardware-backed storage and attestation features so the key remains bound to the device and the surrounding trust evidence stays consistent.
Monitoring also matters. Attempts to duplicate, misuse, or unexpectedly reuse the key are warning signs that the trust anchor may be under stress, especially in fleets where provisioning, repair, or reimaging processes are handled at scale. The storage control is only effective if the organisation can detect abnormal handling around it.
What to do if exposure is suspected
If an Endorsement Key may have been copied, the issue should be treated as a trust compromise rather than a simple secret-handling incident. The concern is not only the key itself, but any device identity, attestation, or trust decisions that were built on that key.
Because the key is foundational, remediation often has to focus on containment and re-establishing trust in the affected device, not just on changing one value. Where platform design allows, investigators should verify whether the key ever left protected hardware, whether provisioning records are reliable, and whether the same identity artifacts were reused elsewhere.
When the device is part of a larger authentication or attestation workflow, rotate or invalidate dependent trust material where appropriate. The practical question is whether any external system might still be trusting a key that should no longer be considered authoritative.
Risk and Threat Considerations
The main risk is not ordinary data loss, it is trust substitution. If an attacker can extract or clone the Endorsement Key, they may be able to impersonate the device or undermine downstream attestation and identity decisions that assume the key is hardware-bound.
Failure mechanism: The protection model fails when the key is exportable, the hardware boundary is bypassed, or administrative pathways allow copying, reuse, or unauthorized re-provisioning of the key material.
Impact: Device identity can be spoofed, trust decisions can be polluted, and systems that rely on the key for provenance or attestation may accept a device that is no longer authentic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-3 — Device Identification and Authentication | The key anchors device identity and authentication trust. |
| IA-5 — Authenticator Management | Endorsement Key handling depends on restricted lifecycle and non-exportable credential control. | |
| AC-6 — Least Privilege | Administrative access to the hardware and provisioning path must be tightly limited. | |
| Recommendation — Bind device trust to protected hardware and authenticate devices through hardware-backed identity evidence. Keep the key non-exportable and manage its lifecycle as protected authenticator material. Restrict who can administer the hardware and provisioning workflow to the minimum required set. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | The subject concerns protecting a cryptographic trust anchor in hardware. |
| A.8.9 — Configuration management | Secure storage depends on controlled device and firmware configuration. | |
| Recommendation — Protect the key with approved cryptographic and hardware-backed controls. Lock down platform configuration so the trust anchor cannot be weakened by ad hoc changes. | ||
| CIS Controls v8 | CIS-5 — Account Management | Administrative access to the key and its hardware must be tightly governed. |
| Recommendation — Limit and review administrative access to systems that can affect the key or its trust boundary. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity management, authentication and access control are implemented and managed across the enterprise | The key is part of identity and access trust for the device. |
| Recommendation — Implement hardware-backed device identity controls and manage access tightly. | ||
Practitioner Guidance
What to verify: Confirm that the key is generated and retained in hardware, that export is blocked, and that administrative workflows cannot silently duplicate or migrate it. If the platform claims hardware protection, test the actual handling path, not just the policy wording.
What to measure: Watch for provisioning exceptions, abnormal re-enrollment, unexpected reuse across devices, and any process that requires manual access to the trust anchor. Those are the indicators that the storage model may be degrading in practice.
Practitioner takeaway: Treat the Endorsement Key as the root of device trust, which means the real control objective is preserving hardware binding and preventing silent reuse, not merely storing a secret securely.