BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

8.4 Destroyed Phase

NIST platform security: roots of trust, firmware and secure enclaves SP 800-57 Part 1 Rev. 5 against SP 800-57 Part 1 Rev. 4
All changes in this version
modified 8 Transition: A transition plan should be developed and followed so that the changeover part of 8

Title

Destroyed Phase

Control changed

Before · SP 800-57 Part 1 Rev. 4

The keying material is no longer available. All records of its existence may have been deleted, though this is not required. Some organizations may require the retention of certain key metadata elements for audit purposes. For example, if a copy of an ostensibly destroyed key is found in an uncontrolled environment or is later determined to have been compromised, records of the identifier of the key, its type, and its cryptoperiod may be helpful in determining what information was protected under the key and how best to recover from the compromise. In addition, by keeping a record of the metadata of both destroyed and compromised keys, one will be able to track which keys transitioned through a normal lifecycle and which ones were compromised at some time during their lifecycle. Thus, protected information that is linked to key names that went through the normal lifecycle may still be considered secure, provided that the security strength of the algorithm remains sufficient. However, any protected information that is linked to a key name that has been compromised may itself be compromised.

After · SP 800-57 Part 1 Rev. 5

The keying materialkey is no longer available. All records of its existence may have been deleted, thoughalthough this is not required. Some organizations may require the retention of certain key metadata elements for audit purposes. For example, if a copy of an ostensibly destroyed key is found in an uncontrolled environment or is later determined to have been compromised, records of the identifier of the key, its type, and its cryptoperiod may be helpful in determining what information was protected under the key and how best to recover from the compromise. In addition, by keeping a record of the metadata of both destroyed and compromised keys, one will be able to track which keys transitioned through a normal lifecycle and which ones were compromised at some time during their lifecycle. Thus, protected information that is linked to key names that went through the normal lifecycle may still be considered secure, provided that the security strength of the algorithm remains sufficient. However, any protected information that is linked to a key name that has been compromised may itself be compromised.