It is the clause that appears in almost every Department of Defense contract, and the one most contractors have accepted without reading. It creates four duties. Inside the first one is a requirement about encryption — unchanged since 2017 — that the certificates behind a lot of standard software stop being able to evidence the same way on 21 September 2026.
If your contract carries this clause, you have taken on real, enforceable obligations — not a policy preference, and not something an IT provider quietly absorbs on your behalf. This page says what they are in plain English, and then follows one of them to a date almost nobody has checked against their own systems.
The full title is “Safeguarding Covered Defense Information and Cyber Incident Reporting.” It is a standard clause in the Defense Federal Acquisition Regulation Supplement, and it attaches to contracts where a contractor will hold, process or produce Controlled Unclassified Information — CUI: government information that is not classified, but is still not for the open world. Technical drawings, specifications, personnel data, logistics detail.
You do not negotiate it. It arrives in the contract, and signing accepts it.
One
You implement NIST SP 800-171 — a checklist of 110 security requirements — on any system that touches CUI. Not “consider”: implement. Where something is not yet in place, it is carried as a documented plan with a date rather than left unsaid.
Two
If something happens that affects covered information or the systems holding it, you report it to the Department of Defense within 72 hours of discovery. That clock is short by design. It assumes you have already decided who reports, from which account, and with what evidence — in advance, not on the day.
Three
After an incident you keep the relevant images and data for at least 90 days, so the government can review them if it chooses. Ordinary backup retention is not automatically the same thing.
Four
The clause travels. If you pass covered information to a supplier, the same duties go with it — which is why many companies first meet this clause in a questionnaire from a prime contractor rather than in a contract with the government.
One line in that 110-item checklist behaves differently from all the others. NIST SP 800-171, requirement 3.13.11:
“Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.”
Read it slowly. It does not say strong encryption, or modern encryption, or encryption a vendor describes as enterprise-grade. It says validated — meaning one specific version of one specific product was tested by an accredited laboratory and holds a certificate from NIST's Cryptographic Module Validation Program.
That distinction is the whole of it. Software can be excellent and unvalidated at the same time; the requirement is not a judgment about how secure your encryption is. It asks whether a certificate exists covering the exact version you are running. In an assessment, that certificate is the evidence — and without one there is nothing to put in front of anybody. The same requirement is assessed under CMMC as practice SC.L2-3.13.11.
The contract does not mention encryption certificates, and NIST's certificate list does not mention your contract. They are connected, but by four steps — which is why so few people have followed it all the way down.
The contract
DFARS 252.204-7012. You agreed to implement NIST SP 800-171 on any system that touches CUI.
The checklist
NIST SP 800-171, requirement 3.13.11. One of the 110: employ FIPS-validated cryptography to protect CUI.
What “validated” means
NIST's Cryptographic Module Validation Program. The public list of which exact product versions hold a certificate. If it is not on that list, it is not validated — however good it is.
21 September 2026
Every remaining FIPS 140-2 certificate moves to Historical. The module does not change. Its standing does.
Where it costs you
Your assessment — which applies today. If your contract requires 800-171, 3.13.11 is scored in every assessment of it: your own, and DoD's, if it assesses you. Where a solicitation carries 252.204-7019, a current assessment in SPRS is a condition of being “considered for award”; where it names a CMMC level (252.204-7021), a current CMMC status is. Nobody audits “Active versus Historical” as such — no clause mentions certificate status at all. What decides the outcome is whether you can document the gap.
On that date, every remaining FIPS 140-2 certificate moves to NIST's Historical list. It is a scheduled transition to the newer FIPS 140-3 standard, it has been public for years, and it is no surprise — to NIST.
Historical status does not switch anything off. Systems keep running, and continued use is permitted on a documented assessment of where and how each module is used. What it governs is new procurement: in NIST's words, a historical module “should not be included by Federal Agencies in new procurements.”
So it does not bite on the date. It bites at your next contract action — a bid, a renewal or option year, an assessment, or a prime's questionnaire. Which leaves one question worth answering before somebody else asks it of you: on the day of your next award, will the encryption you actually run still be citable?
This is the part that catches people out. The clause travels down the supply chain. Under paragraph (m) of 252.204-7012, a prime contractor that passes covered information to a supplier must pass the same obligations with it — and that supplier must do the same again.
So a machine shop, a fabricator, an engineering practice or a facilities contractor can be carrying every duty on this page without ever having spoken to a contracting officer. You do not find out from the government. You find out when a prime sends a questionnaire, six weeks before an award, asking which certificate covers your encryption.
Your trade does not exempt you, because the clause does not look at your trade. It looks at the information. A construction firm, a mechanical contractor, an architect or a facilities manager is not covered because of what they build — they are covered when the drawings, specifications, site layouts, utility routing, security-system plans or personnel lists they receive are covered defense information.
If that material arrives in your email, sits in your file share, goes home on a laptop or is passed to your own subcontractors, then the systems that hold it are in scope. The concrete is not the point. The site plan of the building the concrete goes into is.
Before anything technical, settle the contractual question. It takes an afternoon and needs no specialist:
Search your contracts, purchase orders and flow-down clauses for 252.204-7012, 800-171 or CMMC. If none of them appears anywhere, none of this reaches you. If one does, the encryption requirement came with it, and somebody has to be able to answer for it.
We read the public NIST record against the software you actually run, and report where each system stands: holding a validation, losing one on the September date, already without one, or genuinely unverified. Where a question can only be settled by the company that sold you the software, we write the letter for you to send.
What we will not do is tell you that you are compliant. Whether a requirement is met is your assessor's determination and your own affirmation, not ours. We are not a testing laboratory, we do not certify cryptographic modules, and we are not a C3PAO. What we give you is the evidence to answer the question — and the list of who to ask, where the answer is not yet in hand.
This page explains a public contract clause and a public NIST standard. It is general information about what those documents require. It is not legal advice, and it is not a compliance determination for any particular contract.