FAR CUI Rulemaking and NIST 800-171 Rev. 3: What Contractors Should Watch

Executive summary

The June 23, 2026 FAR overhaul proposal is worth reading carefully if your business handles Federal Contract Information or Controlled Unclassified Information.

It is not just a formatting exercise.

The proposed rule would move a lot of safeguarding language into a consolidated FAR Part 40, create new FAR clauses for covered Federal information and CUI, and point non-federal CUI systems toward NIST SP 800-171 Revision 3. It also uses a proposed CUI requirements form, identified in the notice as SF XXX, to tell contractors what CUI applies to a contract, what systems matter, what incident reporting path applies, and whether enhanced NIST SP 800-172 requirements have been selected.

The Federal Register notice is still a proposed rule. It was published on June 23, 2026, and comments are due July 23, 2026. That means small contractors should not treat it like live contract language today.

But they should not ignore it either.

The practical signal is that the federal acquisition side is trying to make CUI obligations more explicit at the contract level. The security baseline is also moving toward the current NIST SP 800-171 Rev. 3 structure, while the DoD CMMC program is still in a transition space where current Level 2 assessments remain tied to Revision 2 until future rulemaking changes that.

That split is where businesses can get confused.

The right move is not to panic-rewrite the entire security program this week. The right move is to build a cleaner contract intake process, map where CUI could enter the business, understand which systems would be in scope under a Rev. 3 style clause, and keep current DoD CMMC obligations separate from proposed governmentwide FAR language.

What changed in the proposed FAR overhaul

The proposed rule is part of the broader Revolutionary FAR Overhaul. The notice covers FAR Parts 1, 2, 4, 33, 39, 40, 52, and 53, but the security conversation mostly lives in the proposed Part 40 and related clauses.

The useful shift is this:

FAR Part 40 would become the place to look for safeguarding policy across classified information, CUI, and covered Federal information.

For contractors, that matters because it would put a cleaner structure around questions that usually show up too late:

• Are we handling only covered Federal information?
• Are we handling CUI?
• Is the system federal or non-federal?
• Is the CUI basic or specified?
• Does the agency require NIST SP 800-172 enhanced requirements for a critical program or high-value asset?
• What incident reporting path applies?
• Which subcontractors need the same obligations flowed down?

The proposed rule would also replace the current FAR 52.204-21 basic safeguarding structure with proposed FAR 52.240-5, Covered Federal Information. That is still the FCI-level conversation: information provided by or created for the Government, not intended for public release, but not necessarily CUI.

The heavier change is proposed FAR 52.240-7, Controlled Unclassified Information. That clause is where the Rev. 3 conversation appears.

Plain English: the proposal would make the contract itself a more explicit operating document for CUI. If finalized in this form, contractors would need to read the contract, the clause, and the CUI requirements form together before they decide what systems, providers, subcontractors, evidence, and incident paths matter.

This is not the same as current CMMC timing

One mistake would be to read the proposed FAR rule and immediately tell every defense supplier that CMMC Level 2 has moved to NIST SP 800-171 Rev. 3.

That is not the current public position.

The Department's CMMC FAQ says CMMC Level 2 uses NIST SP 800-171 Revision 2 today, and that the Department will incorporate Revision 3 through future rulemaking. It also says the Department issued a class deviation to keep Revision 2 as the assessment standard until Revision 3 is incorporated into the CMMC Program rule.

That matters.

A DoD supplier preparing for a current CMMC Level 2 path still needs to understand the Revision 2-based assessment expectations. The same supplier should also watch Revision 3 because NIST published it as the current CUI security publication in May 2024, and the FAR proposal points non-federal CUI systems toward Revision 3.

Those two statements can both be true.

The business problem is keeping them separated:

• Current DoD CMMC assessment path: understand the Rev. 2-based CMMC requirements, scoring, affirmations, POA&M limits, and contract timing.
• Current NIST publication: understand NIST SP 800-171 Rev. 3 as the current NIST CUI security baseline.
• Proposed FAR CUI clause: understand how future governmentwide contract language may use Rev. 3, agency-defined CUI details, and selected enhanced requirements.

If those get blended together, leadership may approve the wrong budget, the IT provider may chase the wrong checklist, and the person signing an affirmation may not know what standard they are standing behind.

The proposed CUI clause is really a scoping tool

The most important part of the proposed rule is not the clause number.

It is the way the clause would force the scoping conversation into the contract package.

Proposed FAR 52.240-7 points to the CUI identified in SF XXX. That proposed form would be used to identify the CUI requirements for the contract. The clause then distinguishes federal information systems from non-federal systems and identifies out-of-scope assets for certain virtual desktop endpoints and commercial communications networks.

For a small contractor, this should change the first meeting.

Do not start with "Which tool do we need?"

Start with the contract package:

• Pull the solicitation, award, clauses, flowdowns, statement of work, data deliverables, drawings, attachments, and any proposed CUI form.
• Identify whether the contract references covered Federal information, CUI, both, or neither.
• Identify whether the agency has named CUI Specified requirements.
• Identify whether any NIST SP 800-172 enhanced requirements are selected.
• Identify the incident reporting destination and timing.
• Identify which subcontractors will need access to or the ability to access the CUI.

Then map the work.

Where will the information enter? Email, portal, shared drive, CAD/CAM workflow, ERP, ticketing system, cloud storage, collaboration tool, quality system, print shop, shop floor, backup, MSP console, or subcontractor handoff?

That map does not need to be beautiful. It needs to be honest enough that a business owner can decide what is in scope and what is not.

The proposed clause is a reminder that CUI readiness is not just a cybersecurity checklist. It is contract reading, data flow, system ownership, provider review, subcontractor flowdown, and evidence.

NIST SP 800-171 Rev. 3 changes the program conversation

NIST SP 800-171 Rev. 3 is not just Rev. 2 with a new cover page.

NIST says Rev. 3 provides recommended security requirements for protecting the confidentiality of CUI in non-federal systems and organizations, and that the requirements apply to components that process, store, or transmit CUI or provide protection for those components.

That sentence is doing real work.

It keeps the conversation tied to systems and components that actually touch or protect CUI. It also keeps the door open for practical scoping. A business does not need to drag every printer, laptop, production asset, family Dropbox folder, and billing system into the same bucket just because the company has one CUI contract. But the business also cannot pretend that identity, backups, endpoint management, cloud administration, logging, or MSP access are irrelevant if those services protect the CUI environment.

Rev. 3 also makes organization-defined parameters more visible. In simple terms, some requirements need values: how often something happens, how fast a notice is sent, how long inactivity can last, who counts as an authorized role, what events are reviewed, and similar details.

DoD has already published organization-defined parameter values for NIST SP 800-171 Rev. 3. The proposed FAR CUI clause points contractors toward those ODPs for applicable Rev. 3 security requirements.

That makes Rev. 3 harder to treat like a generic control list. A contractor needs decisions, not just a spreadsheet:

• Which accounts are allowed?
• Who approves privileged access?
• How quickly are terminated or transferred users removed?
• How often are privileges reviewed?
• Which security-relevant information is protected?
• What logs, scans, plans, and provider evidence can be produced on request?

A small team can handle this, but only if someone turns the requirement into operating rules that the business can actually run.

Cloud and external providers need an earlier review

The proposed FAR CUI clause keeps cloud services in the foreground.

If a contractor uses a cloud service provider to store, process, or transmit CUI identified in the proposed CUI form, the provider would need to meet security requirements equivalent to the FedRAMP Moderate baseline. That is not a tiny detail. It affects Microsoft 365 tenant choices, Google Workspace choices, file-sharing habits, backup platforms, ticketing tools, secure file transfer tools, CAD or engineering platforms, and any cloud dashboard that receives contract data.

The current DoD CMMC FAQ already says cloud service providers that process, store, or transmit CUI for a covered contract must meet requirements equivalent to the FedRAMP Moderate baseline. It also says encrypted CUI remains CUI until properly decontrolled.

So the practical review should start now:

• List each cloud service that may store, process, transmit, back up, scan, index, log, or administer CUI.
• Separate production use from convenience use. A user emailing a drawing to a personal account is not the same as an approved CUI repository.
• Ask whether each provider has an appropriate FedRAMP authorization or a documented equivalency basis when required.
• Check whether the MSP, MSSP, backup provider, file-transfer provider, or support vendor can access CUI or administer systems that protect CUI.
• Put the answer into the SSP or provider responsibility matrix instead of leaving it in someone's inbox.

Do not let "we use a cloud app" be the whole answer.

The useful answer is which cloud service, which boundary, which data, which tenant, which configuration, which admin roles, which evidence, and which contract requirement.

NIST SP 800-172 is not automatic, but it is not imaginary

The proposed FAR CUI clause also mentions NIST SP 800-172.

This is another place where contractors need nuance. NIST SP 800-172 Rev. 3 is the enhanced security requirements publication for CUI associated with a critical program or high-value asset. NIST says there is no expectation that all enhanced requirements will be selected by agencies; selection depends on mission and business needs and agency risk assessments.

That means a small contractor should not assume every CUI contract automatically becomes an 800-172 program.

But the business also should not ignore the possibility. If the agency identifies enhanced requirements in the contract package, they become part of the work. They may affect architecture, monitoring, segmentation, threat hunting, privileged access, configuration management, incident preparation, or evidence.

The right first step is boring and useful: add an 800-172 question to contract intake.

Does the solicitation, contract, flowdown, or CUI attachment identify NIST SP 800-172 requirements? If yes, which ones? Who owns them? What evidence would show they are implemented? Are they being applied to the entire environment or a narrower critical program or high-value asset lane?

That one question prevents two bad outcomes.

It prevents overreaction, where the company designs for requirements that were never selected.

It also prevents underreaction, where a selected enhanced requirement is buried in the contract package and nobody notices until a customer asks for evidence.

What contractors should do now

Do not treat the June 2026 FAR proposal as final contract language.

Do treat it as a warning about where contract cybersecurity is going.

The useful work now is specific:

Create a contract clause intake sheet. Track FAR 52.240-5, FAR 52.240-6, FAR 52.240-7, DFARS 252.204-7012, DFARS 252.204-7019, DFARS 252.204-7020, DFARS 252.204-7021, CMMC level, CUI form or attachment, incident reporting path, cloud requirements, subcontractor flowdown, and the standard named in the contract.

Separate FCI from CUI. FCI is not intended for public release, but CUI has additional safeguarding and dissemination controls. Do not scope everything as CUI just because it feels safer. Do not treat actual CUI like ordinary contract paperwork.

Build a CUI data map. Start with where information enters, where it is stored, who uses it, which systems protect it, which providers can access it, and where it leaves. Include paper, scans, email, portals, engineering files, backups, logs, and subcontractor handoffs.

Maintain a two-version view of NIST SP 800-171. If you are in a current DoD CMMC Level 2 path, keep the Rev. 2 assessment expectations clear. If you are building a durable CUI program, track Rev. 3, DoD ODPs, and the proposed FAR CUI clause so the program does not become stale the moment rulemaking catches up.

Ask cloud questions early. For any service touching CUI, ask whether FedRAMP Moderate authorization or equivalency is required, how the provider is configured, who administers it, what logs and exports exist, and how that evidence would be produced.

Update the SSP as a working system story. The proposed FAR clause contemplates making the SSP and related plans of action available to the Government on request. A small contractor should not wait for that request to discover the SSP does not describe the actual environment.

Watch the comment period and final rule. The Federal Register notice is open for comments until July 23, 2026. The final rule may change. Keep the effective contract obligation tied to the actual clause in your solicitation or contract, not to a headline.

The practical takeaway

The FAR overhaul proposal is not a reason to panic.

It is a reason to get more disciplined.

If the proposed CUI language survives in a similar form, the contractor that benefits will not be the one with the prettiest policy binder. It will be the one that can read the contract, identify the information, explain the system boundary, name the cloud and external providers, flow requirements to subcontractors, produce an SSP that matches reality, and show evidence that the controls are operating.

That is security program development.

It is also basic business hygiene for federal work.

For small contractors, the next step is not to wait for a prime contractor to translate this later. Pull the current contract language. Watch the proposed rule. Map the CUI path. Keep current CMMC obligations straight. Then start closing the gaps that would still matter under either Rev. 2 or Rev. 3: access control, asset inventory, logging, provider ownership, evidence, incident reporting, and honest scope.