NIST SP 800-88 Rev. 2 — what changed, and what you have to do

If your disposal policy cites NIST SP 800-88 Revision 1, it cites a document NIST withdrew. Revision 2 was published on September 26, 2025 and Revision 1 — in force since December 2014 — was withdrawn the same day. Policies, contracts, RFP responses and certificate templates naming Rev. 1 now reference a superseded publication.

Nothing you did last week became unsafe. But the document your paperwork points at no longer exists as current guidance, and that is the sort of thing an auditor or a client’s security team notices.

Four changes matter to an operator.

1. It describes a program, not a list of techniques

Rev. 1 was, in practice, used as a lookup table: find your media type, read off the technique. Rev. 2 steps back from prescribing device-by-device methods and instead sets out a media sanitization program — policy, scope, decision framework, defined roles, assurance and documentation.

The practical effect is that “we follow NIST 800-88” is now a weaker statement than it used to be. What is being asked for is evidence that you run a program: that you decided something, wrote it down, and can show it was followed.

2. Device-level technique guidance moved to IEEE 2883

Rev. 2 aligns with IEEE 2883-2022, which now carries the detailed, media-specific sanitization methods. Multi-pass overwriting — long the folk standard, and long unnecessary on modern media — is retired.

If your procedures document specific techniques, that is where they now come from. Your policy should reference both: NIST for the program, IEEE 2883 for the method.

3. Verification and validation are now separate things

This is the change most likely to catch an operator out, because the two words were previously used loosely and now mean different things.

• Verification is per-device. Did the sanitization actually execute correctly on this piece of media?
• Validation is program-level. Is this method demonstrably effective for this class of media at all — established through testing, vendor documentation, or independent attestation?

You can verify every drive you process and still have no validation. You can have a validated method and still fail to verify that it ran. Both are expected, and they are recorded separately.

4. The certificate itself changed

Rev. 2 formalizes the expectation that every sanitization event produces a durable, traceable record — a certificate of sanitization, physical or electronic, for each piece of media. The guidance points toward records that are automatically generated and tamper-evident, with verification and validation status captured as distinct fields.

For most operators this is the item with real work attached. A certificate that records a batch, or that records a method without recording whether it was verified, no longer reflects what the current guidance describes.

What to update

A short checklist, in the order that costs least:

1. Search your documents for “800-88 Rev. 1”, “Revision 1” and “December 2014”. Policy, procedures, contract templates, RFP boilerplate, the certificate footer, your website. Replace with Rev. 2 and date the change.
2. Add IEEE 2883-2022 wherever techniques are specified. NIST no longer carries that detail.
3. Split verification from validation in your records. They are different claims and they are now expected to be recorded as such.
4. Check your certificate has per-item fields, not just per-batch: the serial, the method, the date, the operator, and the verification result.
5. Write down who owns the program. Rev. 2 expects defined roles. If nobody is named, that is the gap an assessor will find first.
6. Date your policy and set a review interval. A program that cannot show when it was last reviewed is difficult to evidence.

The part that is genuinely harder

Points 3 and 4 both come back to the same thing: the record has to be per-item, it has to distinguish between two similar-sounding states, and it has to be trustworthy after the fact.

That is straightforward when a system captures it as the work happens. It is painful when a technician is reading serials off labels and typing them into a spreadsheet at the end of a shift — because a spreadsheet cannot show that it has not been edited, and a batch line cannot carry a per-device verification result.

Whatever you use, the question an auditor will eventually ask is not whether you follow NIST. It is whether you can show, for one specific device chosen at random, what happened to it and who confirmed it.

What we are not claiming

We are not a certification body and this is not compliance advice. Rev. 2 is a NIST guidance document; how it applies to you depends on your clients, your contracts and your certifications. Read the source, and take advice where it matters. The links below go to the primary documents rather than to anyone’s summary — including ours.