Give every cryptographic key an owner, purpose, lifetime, and recovery rule

Bottom line: encryption and signatures are only as operable as the key lifecycle behind them. A key needs a defined purpose, authorized users and systems, protection level, active period, rotation trigger, recovery decision, compromise response, retention rule, and destruction evidence.

Source fact: what NIST provides

NIST SP 800-57 Part 1 Revision 5 provides general guidance and practices for cryptographic keying material. NIST discusses security services and key types, the protection required for different keys and related information, key-management functions, and issues that organizations should address when using cryptography. Parts 2 and 3 of the series address policy and planning for U.S. Government agencies and guidance for cryptographic features in current systems.

The source supports distinguishing key purposes and lifecycles rather than managing all “secrets” as an interchangeable set.

What the source does not establish

The publication does not certify a vault, hardware module, cloud key service, certificate system, or algorithm implementation. Storing a key in a designated product does not prove correct authorization, isolation, backup, audit, or deletion. Recovery can protect availability while also creating additional copies and custodial risk.

The appropriate practice depends on key type, algorithm, security service, data lifetime, system architecture, legal and contractual requirements, module validation needs, and the consequences of loss or compromise.

Applicability questions

What security service and system use does each key support?

Is the material secret, private, public, symmetric, a trust anchor, or another type with different protection needs?

Which identities and processes can create, export, activate, use, rotate, disable, recover, or destroy it?

What data or service becomes unavailable if the key is lost, and what becomes exposed if it is copied?

How will compromise, algorithm transition, ownership change, and system retirement affect the key and protected data?

DSE recommendation: operate a key lifecycle

The following steps are DSE recommendations based on the cited source.

Maintain a register with key identifier, type, purpose, algorithm and parameters, owner, systems, custody location, creation source, state, dates, dependencies, and recovery rule. Do not record secret key values in the register.

Authorize use by purpose and system, not merely by access to a vault. Separate key administration, routine use, recovery, and audit where risk warrants it.

Define generation, activation, rotation, overlap, revocation, archival, and destruction procedures. Include dependent services, cached material, replicas, and recovery environments.

Protect and test recovery only where required. Use controlled ceremonies or multi-person actions when justified, and verify that recovered material functions without leaving untracked copies.

Monitor unusual administrative and use events. Treat suspected compromise as an incident affecting both the key and everything that relied on it.

Review cryptographic transition guidance and vendor support before changing algorithms or formats.

Verification and evidence

Sample keys of different purposes and trace approval, generation, storage, use policy, rotation, logs, recovery decision, and retirement. Test one non-production rotation and one recovery path, recording dependent-system validation and confirming that temporary copies were controlled or removed.

Official references

NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management: General — National Institute of Standards and Technology; finalized May 4, 2020