How should a Storage Root Key (SRK) be stored and protected?

What does it mean to keep an SRK inside a trusted boundary?

The Storage Root Key is the top-level trust anchor for a storage design, so its protection model has to be stronger than the data it protects. The practical rule is simple: keep the key where the platform can use it, but ordinary software, backup tools, and administrators cannot freely extract it. That preserves the boundary the design depends on.

An SRK should be treated as a non-exportable root of trust unless the architecture explicitly requires portability. If it can be moved like a normal secret, every downstream protection that relies on it becomes easier to defeat through theft, replay, or unauthorised reuse.

How should access and authorisation around an SRK be controlled?

Access should be limited to the trusted platform functions that actually need the key, not to broad operating-system or operator accounts. Where the design uses authorisation data, such as policy objects, provisioning metadata, or hardware permissions, that material needs the same care as the key itself because it can expand or weaken who can exercise the SRK.

The control objective is to make use of the SRK provable and narrow. That means separating legitimate system use from general administrative convenience, and ensuring the entity that requests SRK use is the same entity the design expects to trust. For this reason, the surrounding authorisation path matters almost as much as the key storage location.

What operational safeguards help preserve SRK trust over time?

Protect the hardware boundary or enclave that stores the key, and watch for changes that indicate the trust anchor is being replaced, reset, or re-enrolled outside process. For storage roots, the failure is often not a dramatic key dump, but a quiet change in platform state that allows a new root of trust to be introduced.

Good protection also includes change control around provisioning, physical access, firmware or module reset paths, and any recovery workflow that could reinitialise the trust boundary. If a process can reset the environment without strong approval and logging, it can often recreate the conditions needed to bind a different key or bypass the intended root of trust.

Risk and Threat Considerations

An SRK is a high-value target because compromise of the root key can undermine the confidentiality or integrity of everything beneath it. The most material risks are extraction, unauthorised export, boundary reset abuse, and privilege misuse around the control plane that governs key use.

Failure mechanism: An attacker or insider who gains control of the trusted hardware, enclave, or provisioning path can use legitimate management actions to replace, expose, or abuse the root trust material, even if the key itself is never copied out in plain form.

Impact: Once the SRK trust boundary is broken, encrypted storage, sealed secrets, and any subordinate protections that depend on that root can become recoverable, forgeable, or impossible to trust.

Practitioner Guidance

What to verify: Confirm that the SRK is non-exportable by default, that any exception is explicitly designed and approved, and that recovery or reset paths cannot silently mint a new trust root without review.

What to measure: Track provisioning resets, hardware attestation failures, unexpected changes to authorisation data, and any administrative action that could alter key residency or trust anchor state. Those signals tell you whether the control is protecting the root, not just storing it.

Common mistake: Treating the SRK like an ordinary secret and focusing only on encryption at rest. The real control problem is preserving the trust boundary, because once the boundary is weak, storage encryption becomes a downstream detail.

Practitioner takeaway: An SRK is only safe when the platform can use it without turning it into an extractable secret, so design for bounded use, controlled recovery, and visible trust-boundary changes.

Related resources from NHI Mgmt Group

• Guide: Firmware and Boot Security Guide
• How does Storage Root Key (SRK) work?
• How should a Deploy Key be stored and protected?
• How should a Terraform state file be stored and protected?
• How should an Encrypted File System (EFS) be stored and protected?