Evidence-of-design crosswalk. Not legal advice. Not a NIST-administered certification. Per-deployment conformance depends on operator implementation choices.

SAIHM × NIST SP 800-88 Rev. 2 crosswalk

NIST Special Publication 800-88 Revision 2: Guidelines for Media Sanitization (Chandramouli & Hibbard; published September 2025; DOI 10.6028/NIST.SP.800-88r2) is the canonical NIST guidance for sanitizing data on information storage media (ISM). It supersedes Rev. 1 (December 2014) and elevates Cryptographic Erase (CE) as a first-class logical purge sanitization technique (Section 3.2).

SAIHM’s saihm_forget operation is designed to operate as a Cryptographic Erase. It destroys the per-cell data-encryption key (DEK), publishes a tombstone, blacklists the content identifier (CID), and anchors an audit receipt on chain. The mechanism is designed to align clause-for-clause with SP 800-88 Rev. 2 §3.2 (CE) and §4.5/4.6 (assurance and documentation). This crosswalk is intended as an RFP-ready evidence-of-design artefact, subject to operator review.

SP 800-88 Rev. 2 Section 3.1 — sanitization methods

SP 800-88 Rev. 2 defines three sanitization methods (§3.1): Clear, Purge, Destroy. Cryptographic Erase (§3.2) is classified as a logical purge technique: it makes recovery of target data infeasible using state-of-the-art laboratory techniques while preserving the ISM in a reusable state.

SP 800-88 R2 methodSAIHM applicability
Clear (§3.1.1) — logical overwrite via standard host interfaces; impractical for cloud / logical-storage abstractions where the operator (not the holder) controls the interface.Not applicable. SAIHM cells are encrypted-at-rest from inception; the operator never holds plaintext to overwrite.
Purge (§3.1.2) — logical or physical techniques that make recovery infeasible while preserving ISM reusability. Logical purge can include overwrite, block erase, or cryptographic erase.Primary method. saihm_forget is designed to perform Cryptographic Erase on the per-cell DEK. The operator’s ciphertext remains storable but becomes computationally infeasible to recover.
Destroy (§3.1.3) — physical destruction (disintegrate, incinerate, melt, pulverize, shred).Out of scope at the protocol layer. Operators may apply Destroy to the underlying physical media independently as a complementary control.

SP 800-88 Rev. 2 §3.1.2 explicitly notes: “For an ISM that takes the form of logical/virtual storage (e.g., cloud storage), cryptographic erase may be the only viable purge sanitization technique option.” SAIHM operates in exactly this regime — cells live on distributed object storage where physical sanitization is operator-mediated and infeasible for the holder to verify.

SP 800-88 Rev. 2 Section 3.2 — Cryptographic Erase, clause by clause

SP 800-88 R2 clauseSAIHM mechanism
§3.2 — CE definition. “CE is based on the sanitization of keys used to encrypt data or to prevent access to the keys that encrypt data.”saihm_forget(cellId) sanitizes the per-cell DEK and blacklists the cell’s content identifier (CID), simultaneously sanitizing keys and preventing access to the ciphertext.
§3.2.1 — Strength of Cryptography. ISO/IEC 27040 requires algorithm strength ≥ 128 bits and entropy in key-generation random sources ≥ the number of bits of cryptographic keys. ECB mode prohibited. Federal use requires FIPS-140-validated modules.Cells encrypted with AES-256-GCM (FIPS-197 / NIST SP 800-38D); 256-bit key strength exceeds the ≥ 128-bit floor. Per-cell DEK derived via HKDF-SHA-256 (RFC 5869) from the holder’s wallet-bound identity key, itself produced through the canonical chain MPS-PQC-KEY-GEN-v1 → MPS-AGENT-IDENTITY-v1 with the per-cell DEK info-context MPS-CELL-DEK-v1 per the protocol specification. No ECB mode anywhere in the cryptographic envelope. Conformant implementations targeting federal deployments use a FIPS-140-3-validated cryptographic module.
§3.2.2 — Applicability of CE. Precondition: “no sensitive data has previously been stored on the ISM in plaintext form (i.e., not encrypted) as CE can only sanitize keys related to encrypted data.”SAIHM enforces encryption-before-egress: cell plaintext never leaves the holder process. Operator-tier storage receives ciphertext only. The §3.2.2 precondition is satisfied by construction.
§3.2.2 — CE on backed-up / escrowed keys. “Sanitization using CE should not be trusted on ISM that have been backed up or escrowed unless the organization has a high level of confidence regarding how and where the keys were stored and managed outside of the ISM.”SAIHM DEKs are wallet-bound and never escrowed to operator infrastructure. Holder-side backups (if any) are the holder’s own responsibility per the sovereignty contract; operator-side key escrow is structurally precluded.
§3.2.3 — Sanitization of Keys. Recommended technique: zeroization per ISO/IEC 19790 (overwriting with all zeros, all ones, or random data). All copies of target cryptographic keys must be sanitizable. All hierarchical keys below the target must be eliminated or actively erased.The DEK-destruction step within saihm_forget overwrites the in-memory DEK and removes references atomically (ISO/IEC 19790-style zeroization). The DEK is per-cell with no descendant keys, so the “hierarchical elimination” requirement is complete by construction.
§3.2.3 — Volatile-memory residue elimination. “The elimination of all unwrapped versions of the key must also be assured, preferably by direct key sanitization, but may require a hard reset or powering off the ISM for some period of time.”Holder-side DEK destruction issues explicit overwrite + dereference + garbage-collection trigger. For hostile-OS scenarios, holders should restart the host process after saihm_forget for residual zeroization. Documented in the protocol threat model.
§3.2.4 — Quality of Cryptographic Implementations. Random-entropy quality, encryption algorithm strength and validity, key-sanitization sufficiency, key-wrapping strength commensurate with the encryption operation. Federal use requires FIPS-140 validation. ISO/IEC 19790 + ISO/IEC 24759 test requirements apply.FIPS-140-3 validated cryptographic module is required of conformant implementations targeting federal deployments. AES-256-GCM for cell encryption (FIPS-197 / SP 800-38D). HKDF-SHA-256 (RFC 5869) for key derivation. ML-DSA-65 post-quantum signatures (NIST FIPS-204) bind every audit receipt and tombstone, protecting the traceability chain §3.2.5 relies upon.
§3.2.5 — Traceability of CE Operations. Ten documentation elements: (1) make/model/version/ISM type; (2) key generation; (3) media encryption; (4) key wrapping; (5) ISM areas addressed; (6) key life-cycle management; (7) key sanitization technique; (8) key escrow or injection; (9) error-condition handling; (10) interface clarity.SAIHM publishes a signed tombstone receipt and an on-chain audit anchor for every saihm_forget operation. Receipt schema documents: protocol version (1); DEK derivation context (2); cell encryption algorithm (3); key-wrapping path, if any (4); cell scope (5); DEK lifecycle (6); zeroization technique (7); escrow assertion = none (8); operation outcome status (9); MCP tool name and version (10). The 10-element matrix maps to the receipt fields documented in the protocol specification.

SP 800-88 Rev. 2 Section 4 — Media Sanitization Program alignment

SP 800-88 R2 program elementSAIHM mechanism
§4.1 — Storage Sanitization Policy. Alignment of data classification with minimum acceptable sanitization methods; documentation of expected outcomes; roles and responsibilities.The SAIHM protocol specification (Internet-Draft draft-saihm-memory-protocol) defines the sanitization contract at the protocol layer. Each implementing organization layers its own classification-to-method mapping on top.
§4.2 — Sanitization Scope. Distinguishes whole-ISM sanitization from selective sanitization (a specific data subset wherever it resides) and partial ISM sanitization (a subset or region of the ISM). Notes that on ISM with integrated encryption, CE provides a unique mechanism for partial-ISM sanitization — encrypting different partitions with different keys, then sanitizing the relevant subset of keys.SAIHM is a natural fit for selective sanitization at the finest meaningful granularity: per cell. Each saihm_remember writes one cell sealed under its own per-cell DEK; saihm_forget(cellId) sanitizes that DEK only. Erasing one cell does not affect any other cell, even ones written by the same holder seconds earlier. Per §4.2’s footnote 13 (verbatim): “An example of selective sanitizing is sanitizing the contents of a single file that is encrypted with a unique key using CE.” — SAIHM is the per-cell instance of that example.
§4.3 — Storage Sanitization and Disposition Decision Framework. Organisational risk-based decision framework that ties sanitization choice to information confidentiality (FIPS 199, SP 800-60r2, CNSSI 1253) rather than to media type. Fig. 1 (Sanitization and disposition decision flow) anchors the framework. Six sub-sections elaborate the inputs: §4.3.1 life-cycle decisions, §4.3.2 categorization, §4.3.3 reuse, §4.3.4 control, §4.3.5 data-protection level, §4.3.6 the decision itself.SAIHM is operator-agnostic at the protocol layer. Operators supply their FIPS 199 / SP 800-60r2 categorization, their reuse and control policies, and their disposal decision; SAIHM provides the uniform purge mechanism (CE on the per-cell DEK with on-chain receipt) that the decision framework selects from. Because CE is the only viable purge technique in the logical-storage regime SAIHM targets (§3.1.2), the framework collapses to: choose CE for any cell whose confidentiality categorization requires purge or destroy.
§4.3.1 — Information Decisions in the System Life Cycle. Sanitization need and method should be identified and developed before the disposal phase; controls developed, documented, deployed when the initial SSP is written.SAIHM bakes the sanitization mechanism into the protocol from the first saihm_remember: every cell is born with a DEK destruction path. The implementing system’s System Security Plan (SSP) may cite this crosswalk and the protocol Internet-Draft as supporting material for the system’s life-cycle sanitization design documentation.
§4.3.2 — Determination of Security Categorization. System categorized per FIPS 199, SP 800-60r2, or CNSSI 1253; categorization revisited at least every three years or on significant change.SAIHM does not pre-judge the holder’s categorization. The wallet-bound holder identity allows the same cell substrate to host content of different categorizations under different holders, with sanitization decisions made per holder rather than per shared bucket.
§4.3.3 — Reuse of Media. If the media is not intended for reuse, destruction is often the simplest cost-effective method.For SAIHM’s logical-storage substrate, physical reuse is the operator’s default state (cloud object storage is reused across many holders). CE is the appropriate purge technique precisely because the ISM continues in service after sanitization; the holder’s cells are made unrecoverable without disturbing other holders’ data.
§4.3.4 — Control of Media. Sanitization decisions are influenced by who has control and access; media leaving organisational control is a sanitization trigger.Wallet-bound sovereignty narrows the “loss of organisational control of ISM” trigger: because the organisation never held decrypt-control of the cell ciphertext (the holder’s wallet-bound key did), an operator change, vendor change, or chain-operator change does not transfer cell-decryption access to a new party. Conversely, the holder can saihm_forget any cell on demand regardless of which operator currently stores the ciphertext.
§4.3.5 — Data Protection Level. Within a single confidentiality categorization, contextual differences (department, role, contractual restrictions) drive different controls; both organisational control and data protection level should be considered.SAIHM’s sharing-contract surface (saihm_share, saihm_revoke_share) is the per-cell expression of this principle. The holder grants TEMPORARY, PERMANENT, or SYNDICATE access at the cell level; differential data-protection levels are enforced cryptographically, not by access-list policy alone.
§4.3.6 — Sanitization and Disposal Decision. Once the assessment is done, the organization records the decision and ensures process and resources are in place to support it.The on-chain receipt emitted by saihm_forget serves as the durable, externally verifiable decision record. The operator’s own records, the holder’s receipt, and the public chain anchor form a three-witness audit trail that survives both holder and operator turnover.
§4.4 — Performing Sanitization. Sanitization performed per selected method in a manner complying with IEEE 2883 (or an organisationally-acceptable standard such as NSA/CSS Policy 6-22 or Policy Manual 9-12). When CE is the chosen purge technique, §3.2 considerations apply. Captures results/outcomes (§4.5), documentation (§4.6), and other relevant information.The protocol-level CE technique is described in this crosswalk’s §3.2 section above. saihm_forget is the single operation; it returns a signed receipt synchronously (§4.5 results); the receipt is anchored on chain as the certificate of sanitization (§4.6 documentation). Operators implementing SAIHM for federal deployments may declare IEEE 2883 alignment (or alignment with another organisationally-acceptable standard such as NSA/CSS Policy 6-22 or NSA/CSS Policy Manual 9-12) in their public operator-deployment documentation.
§4.5.1 — Sanitization Verification. Inspect that the sanitization technique completed successfully; check tools, identify errors, anomalies, ISM health.saihm_forget returns a signed success/failure receipt synchronously. The audit anchor is publicly inspectable on the COTI V2 mainnet block explorer (mainnet.cotiscan.io). Any external party can independently verify that the operation completed.
§4.5.2 — Sanitization Validation. Decide whether target data was effectively sanitized to an acceptable confidentiality level.Validation reduces to two assertions: (a) the holder’s saihm_forget invocation completed and its DEK-destruction step issued the zeroization (per the receipt), and (b) no backup of the DEK exists outside the holder process (the operator-side no-escrow invariant). Both are mechanically checkable.
§4.6 — Documentation. Certificate of sanitization with manufacturer, model, serial number, media type, sanitization method, technique, tool used, verification method, validator identity, date, signature.The on-chain audit receipt is designed to serve as the certificate of sanitization. Schema: cellId, holder identity (wallet address), protocol version, sanitization method (logical purge / cryptographic erase), technique (DEK zeroization), tool (@saihm/mcp-server with semver), verification method (chain receipt), validator (holder signature), timestamp, ML-DSA-65 signature. Maps to the SP 800-88 Rev. 2 Appendix C certificate schema.
§4.7 — Roles and Responsibilities. Program Managers/Agency Heads, CIO, Information System Owner, Information Owner/Steward, SAISO, System Security Manager/Officer, Property Management Officer, Records Management Officer, Privacy Officer, Users.SAIHM is operator-agnostic at the protocol layer. Mapping: holder identity = Information Owner/Steward (the sovereign of the cell); operator = the entity providing CIO / SAISO / Privacy Officer accountability for the storage substrate. Crosswalk consumers are encouraged to use SP 800-88 R2 §4.7 as the operator-side RACI template that wraps the protocol.

Conformance statement

Evidence-of-design statement, not a NIST-administered conformance certification. NIST does not operate a conformance program for SP 800-88. The assertions below describe how a conformant SAIHM implementation maps to the cited clauses; per-deployment conformance depends on operator implementation choices (FIPS-140-3 validation, no-escrow invariant, etc.). Operators seeking formal validation should pursue FIPS-140-3 on the cryptographic module per §3.2.1 and §3.2.4.

SAIHM’s saihm_forget operation, when deployed on an implementing operator that satisfies the wallet-bound encryption-before-egress invariant, is designed to satisfy the SP 800-88 Rev. 2 §3.2 definition of Cryptographic Erase and the §3.1.2 definition of a logical purge sanitization technique.

  • §3.2 CE definition — satisfied by a conformant implementation (per-cell DEK sanitization plus CID blacklist).
  • §3.2.1 cryptographic strength — satisfied subject to operator selection of a FIPS-140-3-validated cryptographic module (AES-256-GCM, RFC 5869 HKDF-SHA-256, no ECB).
  • §3.2.2 applicability precondition — satisfied by construction in a conformant implementation (no plaintext on operator-tier storage).
  • §3.2.3 key sanitization technique — satisfied by a conformant implementation (zeroization per ISO/IEC 19790; per-cell DEK with no hierarchical descendants).
  • §3.2.4 implementation quality — satisfied subject to operator selection of a FIPS-140-3-validated cryptographic module and adherence to the random-entropy / algorithm-validation / wrapping-strength requirements documented in the protocol implementation guidance.
  • §3.2.5 traceability — satisfied by a conformant implementation (signed on-chain receipt; 10-element documentation matrix).
  • §4.2 sanitization scope — satisfied by construction in a conformant implementation (per-cell key, per-cell DEK sanitization).
  • §4.3 decision framework — satisfied by a conformant implementation when the operator supplies FIPS 199 / SP 800-60r2 categorization; SAIHM provides the uniform CE mechanism the framework selects from.
  • §4.4 performing sanitization — satisfied by a conformant implementation; IEEE 2883 (or equivalent acceptable standard) alignment may be declared in the operator’s deployment documentation.
  • §4.5.1 verification — satisfied by a conformant implementation (synchronous signed receipt; public chain inspection).
  • §4.5.2 validation — satisfied subject to the holder-side DEK no-backup invariant.
  • §4.6 documentation — satisfied by a conformant implementation (on-chain certificate of sanitization).

Why SAIHM is well-aligned with SP 800-88 Rev. 2 for AI memory

  • The cloud / logical-storage regime fits. §3.1.2 notes that CE may be the only viable purge technique for logical / virtual storage. AI memory on distributed object storage is exactly that regime; physical destruction is operator-mediated and infeasible for the holder to verify.
  • Per-cell key minimizes blast radius. Erasing one cell does not collide with the next. Multi-tenant operators get cell-scoped sanitization, not bucket-scoped.
  • Operator-honest-but-curious threat model. The holder never trusts the operator with plaintext or with the DEK. §3.2.2’s “high level of confidence regarding how and where the keys were stored” is structurally satisfied: keys are not stored at the operator.
  • Public audit anchor complements operator self-attestation. A supervisory authority can independently verify the sanitization timestamp on COTI V2 mainnet alongside the operator’s own logs.
  • Post-quantum signature on every receipt. ML-DSA-65 (FIPS-204) signatures protect the audit trail beyond classical-PKI lifetimes — relevant to the §3.2.5 traceability obligation when the underlying data is long-lived.

How to cite SAIHM in an SP 800-88 Rev. 2 compliance assessment

  1. Cite this crosswalk URL as evidence-of-design for §3.2 CE alignment.
  2. Cite the protocol specification: Internet-Draft draft-saihm-memory-protocol.
  3. Cite the reference implementation: npx @saihm/mcp-server (Apache 2.0).
  4. Cite the on-chain audit anchor at COTI V2 mainnet (chain ID 2632500) as the certificate-of-sanitization log.
  5. For federal deployments: confirm the operating organization’s FIPS-140-3-validated cryptographic module is in place per §3.2.1 and §3.2.4.

Join SAIHM

Related crosswalks