800-171 Rev 3 ODPs: The Blanks DoD Already Filled In

Last week's post called organization-defined parameters the most practical change in Revision 3. Here is why.

Rev 2 said "limit unsuccessful logon attempts" and left the number to you. Rev 3 writes the blank into the requirement — "[Assignment: organization-defined number]" — and expects the agency that imposes the requirement to fill it in. For defense contractors, DoD has. A memo signed on April 10, 2025 by David W. McKeown, then performing the duties of Deputy DoD CIO for Cybersecurity, publishes a value for every ODP in the Rev 3 source document and establishes those values "as policy," explicitly "in preparation to implement" Rev 3 as the minimum requirement for contractors.

That memo is the closest thing available to a preview of the settings you will be assessed against. It is also the cheapest Rev 3 homework there is, because almost none of it requires new tooling.

What the memo actually is

Three things are worth being precise about, because this document gets over-read in both directions.

It is policy, not contract language. The memo binds DoD components. It does not amend DFARS 252.204-7012, and the class deviation of May 2, 2024 still keeps that clause pointed at Revision 2. Nothing in it changes what a C3PAO or a self-assessment measures today. Your assessment is a Rev 2 assessment.

It is not provisional. DoD describes the values as a consensus position drawn from existing federal frameworks, with input from DoD components, other agencies, UARC and FFRDC subject matter experts, and industry — and says they "will be updated as necessary." Read that as a stable starting point that can move at the margins, not a draft.

Four of the 80 entries are guidance, not a value. The memo says so itself: "In four (4) instances the ODP has been defined as guidance versus a specified value." Those four — terms and conditions for using external systems, limiting component functionality, cryptographic key management, and the user and administrator documentation expected under systems security engineering principles — are paragraphs of direction, not thresholds you can diff against a group policy object. Everything else is a number, a frequency, or an enumerated list.

The values most contractors should check first

These nine requirements cover the ODPs that map onto settings you almost certainly already have, in tools you already run. Each links to its side-by-side Rev 2 and Rev 3 text on the CMMC Navigator.

DoD footnotes "significant" as "having or likely to have influence or effect."

Two of these are worth a second look because they are the ones most likely to be wrong in a small environment today.

Sixteen characters. That is the single biggest gap most contractors will find, and it is a deliberate trade: Rev 3 drops Rev 2's password-expiry and complexity-composition rules in favor of length and a compromised-password check. If your policy still reads "twelve characters, one of each type, rotate every 90 days," you are further from Rev 3 than a shop with a 16-character passphrase and no expiry at all. Changing this is also the one item here that touches every user, so it is the one worth starting early.

Ten years for identifier reuse. This is not a setting in most directories; it is a records-retention commitment. In practice it means never recycling a username, and being able to show that you don't. If your convention generates jsmith2 when a second J. Smith arrives, you're already fine and the work is writing it down.

Why you'll see two different ODP counts

Published counts of Rev 3's ODPs disagree, and the disagreement is not a mistake — the two source documents number them differently.

The DoD memo uses the requirement-statement scheme from SP 800-171r3 itself, where a blank is identified by its position in the requirement: 03.01.01.f.02 is the second item under paragraph f. Counted that way, DoD assigns 80 values. The assessment guide, SP 800-171A Rev 3, numbers each blank as a determination item instead — A.03.01.01.ODP[01] — and lands on 88 across 50 requirements. Same blanks, two ways of counting them.

Nothing turns on the count. It matters only when you are reconciling two spreadsheets that appear to describe the same thing, which is exactly when a phantom discrepancy costs an afternoon. If a tool reports a different total, check which numbering scheme it used before you assume it's wrong.

What to do with this now

Worth doing today:

• Export what you actually enforce — lockout threshold and duration, screen lock, session timeout, password policy, inactive-account handling, training cadence — and put it next to the table above. It is one page.
• Record each line as stricter, equal, or looser. Stricter and equal are finished; they need no change under either revision, and the comparison itself is evidence that you checked.
• Fix the looser ones on their own merits, not as Rev 3 work. Every value in that table is a defensible setting under Rev 2 too, which is why this is safe to do before the rule moves.
• Start the password-length conversation now if 16 characters is a change. That one has a people cost and a helpdesk cost, and neither shrinks by waiting.

Premature — don't:

• Rewrite your SSP around these values. Your SSP describes the requirements you are assessed against, and those are Rev 2's.
• Cite the memo as a contractual requirement to a customer, a prime, or a subcontractor. It isn't one yet, and flowing it down as though it were creates an obligation you'll have to unwind.
• Drop a Rev 2 practice — password expiry is the tempting one — because Rev 3 relaxes it. Until the clause changes, the Rev 2 objectives still apply.
• Treat the four guidance entries as gaps. There is nothing to configure against them.

Next in this series

Next Tuesday, September 29: Identification and Authentication — what actually changes for passwords and MFA when 3.5.1 through 3.5.11 become eleven Rev 3 requirements plus a new one, and which of the values above land inside that family.

If the task force report, a new deviation, or the transitional rule lands mid-series, that week's post becomes the breakdown and the series slides a week.

An unofficial reading aid. It doesn't create or waive obligations; where this post and your contract disagree, your contract is right. Values are quoted from the April 10, 2025 DoD CIO memo; where this table and that memo disagree, the memo is right.