NIST SP 800-57 and SP 800-131A in the Web3 Key Management Policy

I have been writing a Web3 Cryptographic Key Management Policy for the validator infrastructure I run. The policy has 18 sections and an OSCAL catalog, and both are built to trace back to NIST key management guidance rather than restate it informally. This post covers how that guidance is actually used, and where the mapping is still incomplete.

Which NIST publications the policy cites

Section 18 of the policy names five publications as its informing baseline:

Part 1 is the one that shapes the most sections. Its scope, the classification, lifecycle, protection, and inventory language in Sections 6 through 14 of the policy, tracks Part 1’s structure closely: generation, protection, backup, rotation, revocation, and destruction are all present as named lifecycle states in both documents.

SP 800-131A’s role is narrower but load-bearing. It governs Section 9’s requirement that the Cryptographic Baseline distinguish acceptable, deprecated, legacy-use, and disallowed mechanisms, and that deprecated mechanisms carry a time-bound risk acceptance rather than silent continued use.

Reference versus monitoring-input

The OSCAL catalog metadata makes a distinction that the Markdown policy text doesn’t spell out as explicitly: it separates reference links from monitoring-input links.

reference          NIST SP 800-57 Part 1 Rev. 5
reference          NIST SP 800-57 Part 2 Rev. 1
reference          NIST SP 800-57 Part 3 Rev. 1
reference          NIST SP 800-130
reference          NIST SP 800-131A Rev. 2
monitoring-input   NIST SP 800-57 Part 1 Rev. 6 (Initial Public Draft, December 2025)
monitoring-input   NIST SP 800-131A Rev. 3 (Initial Public Draft, October 2024)

The reference publications are the finalized revisions the policy is actually built against. The monitoring-input publications are the initial public drafts of the next revisions, both already downloaded into source/markdown/ as full text, but not yet adopted as the governing baseline.

This maps directly onto Section 18’s review requirement: the Security Approval Authority reviews the policy “at least annually and after a material incident,” and that review must “consider new, revised, superseded, withdrawn, or draft NIST publications.” Keeping the IPDs in the repository as monitoring-input rather than reference is how that requirement gets enforced instead of just stated. When Part 1 Rev. 6 or SP 800-131A Rev. 3 go final, the change is a link reclassification with a documented reason, not a rewrite from scratch.

What the policy does not take from NIST

Section 17, “Web3-Specific Key Management Principles,” is explicitly carved out from this mapping. Its own opening clause states the boundary directly:

“The following controls address Web3 and protocol-specific risk. They are not represented as direct NIST requirements unless separately mapped as such.”

Validator signing safety, slashing-protection state, threshold/MPC/multisig design, and protocol-mandated cryptography have no NIST equivalent. NIST SP 800-57 was not written with proof-of-stake validators or on-chain authority in mind, so extending it there by implication would misrepresent the source. The OSCAL catalog encodes this as a distinct source-classification value, web3-specific, rather than folding it into the NIST-derived category.

References

• kms-policy repository
• NIST SP 800-57 Part 1 Rev. 5, final
• NIST SP 800-131A Rev. 2, final
• NIST SP 800-57 Part 1 Rev. 6, initial public draft
• NIST SP 800-131A Rev. 3, initial public draft