03.14.01 Flaw remediation: requirements and evidence

What 03.14.01 flaw remediation requires for CUI systems

NIST SP 800-171 03.14.01 asks an organization to identify system flaws, report them and correct them, and to install security-relevant software and firmware updates within time periods the organization defines after each update is released. For a compliance lead or engineer, the practical test is whether you can show that this cycle runs on every system that stores, processes or transmits CUI, and that the time limits are written down and followed. The requirement covers operating systems, applications, and the firmware in devices such as network equipment, storage arrays and endpoints. An unpatched flaw in any of these can give an attacker a route into the enclave, so the gap between a vendor release and your installed fix is a risk you own, even when a managed provider runs the update.

Two defined parameters make this requirement harder than it looks. Rev. 3 leaves the time period for security-relevant software updates and the time period for security-relevant firmware updates to the organization, and a federal agency that has not specified them leaves that choice to you. Confirm the values with the contracting agency before you write them into the system security plan. The assessor will check that both values exist and that your records show the updates were applied within them, so a vague policy such as "as soon as practical" will not pass.

Most organizations struggle in three places. The first is inventory gaps: a patch process cannot cover software or devices nobody has recorded, and CUI systems often include laptops, test servers and appliances that sit outside the main asset list. The second is firmware outside patch routines, since BIOS, controller and appliance firmware is often updated by a different team, or only during hardware refresh. The third is undocumented windows: teams apply patches on whatever schedule they have, and when an assessor asks for the defined period, nobody can point to it. Start by reconciling your asset inventory against the CUI system boundary, then set and document the two time periods for each update class before you run another patch cycle.

Which systems, teams and suppliers 03.14.01 covers

Flaw remediation applies to every component that stores, processes or transmits CUI or protects that boundary, and the work is split across endpoints, network devices, firmware, cloud workloads and the people or providers who patch them. The scope decisions below determine who owns each update and which evidence an assessor will ask for.

Endpoints and servers handling CUI

Workstations, servers and virtual machines that store, process or transmit CUI are the core of 03.14.01. Build an inventory that ties each host to the CUI boundary and records its operating system, installed applications and patch owner. Check whether engineering, test or backup hosts that touch CUI are inside the boundary, because an unpatched host outside your inventory is still a flaw an assessor can find. Confirm which owner signs off on the defined update windows for each host group.

Network and security appliances

Firewalls, VPN gateways, routers, switches and security tools that enforce the boundary need the same flaw handling as servers, and a vulnerable appliance can undermine every control behind it. Decide whether appliances are patched by your staff, a vendor or a managed service provider, and write that split into the system security plan. Track end-of-support dates so that unsupported appliances are replaced or documented as exceptions.

Firmware on in-boundary devices

Firmware on laptops, storage arrays, printers, IoT sensors and network devices is a separate update path that many inventories miss. 03.14.01 has its own organization-defined time period for security-relevant firmware updates, so it must be set apart from the software period. Confirm for each device class whether updates come from the vendor, a local staging process or a management platform, and record who approves them.

Out-of-band management interfaces

Baseboard management controllers, out-of-band consoles and remote KVM devices often run their own firmware and sit on separate networks. Decide whether they are inside the CUI boundary, since they can reach systems that hold CUI even when they hold no CUI themselves. Assign firmware ownership to a named team, usually infrastructure or data center operations, and confirm that the owner receives vendor advisories for these devices.

Shared platforms and the boundary decision

A shared identity provider, logging stack, ticketing system or CI pipeline changes the work if it processes CUI or can reach systems that do. Each shared platform must either sit inside the boundary with its own flaw remediation evidence, or be shown to be outside it through documented separation. Ask who patches the shared platform and whether that owner is covered by the same update periods as in-boundary systems.

Cloud workloads and managed providers

Cloud virtual machines, containers and managed services shift part of patching to the provider and part to your team, and the split varies by service model. Write the responsibility matrix for each service, confirm how the provider communicates patch status, and ask your managed service provider for its patch records as evidence. Contracts with external providers should state the update periods that apply to the systems they operate.

Who sets the patch windows and why the Rev. 3 change matters

Under 03.14.01, the patch windows are organization-defined parameters, and NIST does not set their values. The requirement has two of them: the time period within which to install security-relevant software updates after release, and the time period within which to install security-relevant firmware updates after release. NIST's Rev. 3 catalog counts 88 ODPs across 50 requirements, and NIST leaves each value to the party that owns the requirement. If the federal agency that holds the contract or agreement specifies the two windows, the nonfederal organization must meet them. If it does not, the organization must assign its own values to complete the requirement, and an assessor will check that both values are defined and that the organization follows them. Confirm with the contracting officer which windows apply before you write any policy, because a value that is too loose will fail the contract and one that is too tight may not be operable for your change process.

The values may also come from a different direction. A FAR overhaul proposed rule published on 23 June 2026 would require contractors handling CUI to comply with SP 800-171 Rev. 3 using ODP values published by the DoW CIO. Comments closed on 23 July 2026, and the rule was not final as of October 2026, so treat it as a signal to watch rather than a current obligation. Meanwhile, DoW Class Deviation 2026-O0025, Revision 3 (signed 3 September 2026) points contracting officers to SP 800-171 Revision 2 and cites a 13 July 2026 DoW CIO memorandum requiring baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. Before choosing patch windows, read the clause in your actual contract and any deviation it cites.

NIST classes the change from Rev. 2 requirement 3.14.1 to Rev. 3 03.14.01 as significant, because the Rev. 3 version adds more detail and foundational tasks. CMMC Level 2 still assesses the Rev. 2 wording, as SI.L2-3.14.1, and under the 32 CFR 170.24 scoring methodology it carries 5 points. Under 32 CFR 170.21, that practice cannot be placed on a plan of action and milestones to reach Conditional status, so an unpatched gap in flaw remediation must be closed before the assessment. Plan for the stricter reading now: document both window values, the owner who approves exceptions, and dated evidence that installs met them.

How an assessor tests 03.14.01 under SP 800-171A

This table maps the SP 800-171A Rev. 3 procedure for 03.14.01 to the methods an assessor uses, the objects they request and the evidence they expect. Read it as a checklist of what to prepare before an assessment, and note the common findings that cause gaps.

Assessment element	What the assessor does	Evidence to have ready
Determination statements (five)	Checks that the organization identifies, reports and corrects system flaws, and installs security-relevant software and firmware updates within the defined time periods.	A documented flaw remediation process showing each step from identification through correction, with records for a sample of flaws.
ODP definition checks (two)	Confirms that the time period for installing security-relevant software updates and the time period for firmware updates are both defined.	Written values for both periods, approved by the accountable owner, and a statement of where they are applied.
Examine method	Reads the system and information integrity policy, the flaw remediation procedures and the configuration management procedures.	Approved policy, flaw remediation procedure and configuration management procedure, with version history and review dates.
Interview method	Talks with the personnel who install, configure or maintain the system, and with the personnel who own flaw remediation.	Named owners, a short walkthrough of how a recent update was approved and deployed, and consistent answers across roles.
Test method	Observes the processes for identifying, reporting and correcting flaws, often by tracing a sample of recent flaws from detection to closure.	Scan or inventory outputs, tickets or change records, and timestamps showing release date, install date and verification.
Scope of systems	Checks that the flaw remediation process covers every in-scope component that handles CUI, including endpoints, servers, network devices and their firmware.	Asset inventory tied to the system security plan boundary, with firmware and appliance entries marked.
Common finding: undefined ODP values	Flags the requirement as incomplete when the update time periods are blank, implied or only described as prompt.	Specific numeric or defined time periods for software and firmware, not general statements of intent.
Common finding: firmware left out of scope	Identifies firmware on routers, firewalls, storage and peripherals that the process never reaches, even when software is current.	Firmware inventory and a record of firmware update decisions for each device class in the boundary.

Implementing flaw remediation in the order an assessor will check it

This sequence turns the 03.14.01 requirement into a set of decisions, records and tickets that an assessor can trace from a written time period to a verified fix. Each step names the evidence the organization should be able to show before the assessment begins.

Define the ODP time periods in writing
Start by deciding the two organization-defined parameters for 03.14.01: the time period for installing security-relevant software updates after release, and the time period for installing security-relevant firmware updates after release. If a federal agency or contract specifies these values, record them as given. If not, the organization must assign them, which NIST notes is required to complete the requirement. Have the system owner and the security lead approve the values and record the decision with a date and approver. Done means a signed ODP decision that the system security plan references, and that assessors can compare against the update records you produce later.
Build an asset inventory of software and firmware
Assessors cannot test remediation on components you have not listed. Build an inventory of every operating system, application, library, network device, appliance and firmware image inside the system boundary, including components that handle CUI and the tools that maintain them. Record the owner, version and patch source for each item. Keep the inventory in a controlled location with a change history. Done means an inventory export that matches the system security plan's component list, with no unowned items and a clear method for keeping it current as systems are added or retired.
Set up flaw discovery and vulnerability scanning
Configure the tools that identify flaws against the inventory. Options include an authenticated vulnerability scanner, host-based vulnerability detection that correlates agent software inventories with vulnerability feeds, and endpoint software inventory tools that match installed packages against advisory sources. The open-source options DeployOpen commonly deploys include Greenbone Community Edition, Wazuh and Fleet, and each has its own feed and coverage limits, which should be confirmed in your environment. Schedule scans and document the scope, credentials and feed update method. Done means scan configuration exports, a scan schedule and at least one completed scan report that covers the inventory.
Define how flaws are reported and assigned
Write the procedure that takes a finding from detection to an accountable owner. It should state who triages findings, how severity is assigned, how each flaw is linked to the affected asset, and how the flaw is assigned to a remediation owner with a due date based on the ODP periods. Where a finding tool deduplicates or imports results from several scanners, document how duplicates are handled so the same flaw is not tracked twice. Done means the written flaw remediation procedure and a sample record showing a finding moved from detection to an assigned, dated ticket.
Correct flaws through change control
Apply the correction through the organization's change management process, which links to the configuration management family. Each patch or firmware update should have a change request that names the affected asset, the test plan, the rollback method and the approver. Install the update within the ODP period, or record why it could not be installed. Done means closed change records that show the correction date, the approver and the link to the original finding, so an assessor can trace each flaw to its fix.
Verify the correction with a follow-up scan
Do not close a flaw on the basis of the change record alone. Run a targeted re-scan or a new inventory check on the affected asset after the update to confirm the flaw is no longer detected or that the installed version now matches the fixed version. Record the result in the ticket. Done means a closed ticket that contains the change reference and a verification scan or inventory export taken after the fix, showing the flaw is resolved.
Record exceptions and POA&M items
Some flaws will not be corrected within the ODP period, for example where a vendor has not released a fix or where a change would disrupt a CUI workflow. Record each such item as an exception with a documented risk decision, compensating controls, an owner and a review date. If the item is needed to support an assessment score, decide whether it belongs on a plan of action and milestones and confirm the rules that apply under your contract, since CMMC Level 2 does not allow every 03.14.01 item to appear on a POA&M. Done means an exception register and POA&M entries that match the tickets, with dated approvals.

Open-source tools that produce flaw remediation evidence

Flaw remediation evidence usually comes from several places: scanners that find vulnerable software, platforms that track findings to closure, and inventories that show which versions are installed. The four open-source tools below each cover one part of that chain. None of them replaces the organization's own patch records, and each needs to be checked against the firmware coverage the assessor will expect.

DefectDojo finding tracker

DefectDojo imports and reimports findings from more than 500 security tool report formats, through its UI or API, including in the open source edition, plus a generic findings import. It deduplicates findings using per-tool hashcode fields, so a recurring flaw reported by several scanners appears once with its history. For 03.14.01, this gives a single record of each flaw from identification through correction. Confirm that your scanners' report formats are supported and that the license terms (BSD-3-Clause) fit your internal use. Firmware findings only appear if a supported source reports them.

Greenbone Community Edition scans

Greenbone Community Edition, built on OpenVAS, runs vulnerability scans through gvmd, which schedules scan tasks, manages users and permissions, and stores results in PostgreSQL. Staff review results in the Greenbone Security Assistant web interface. The stored scan history and task schedules show that flaws were identified on a recurring basis and that reports were produced for correction. Confirm the AGPL-3.0-or-later obligations if you modify and distribute the software, and confirm whether its network and device checks cover the firmware of your appliances.

Wazuh vulnerability detection

Wazuh vulnerability detection correlates the software inventory collected by each agent with the Wazuh CTI vulnerability repository, or with a locally hosted offline copy, to identify vulnerabilities in the operating system and installed applications of monitored endpoints. For 03.14.01, the agent inventory and detection records show what is installed on each system and which known flaws apply. An offline copy suits enclaves without outbound internet access. Confirm whether the GPL-2.0-only license terms fit your deployment, and confirm firmware coverage, since operating system and application inventories may not include device firmware.

Fleet software vulnerability matching

Fleet detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. The matching output identifies which hosts run affected software versions, which supports a dated record of when each flaw was identified. Because the sources differ by operating system, confirm that the advisory feeds cover the platforms in your boundary. Fleet is licensed under MIT. Confirm that firmware on network devices and peripherals falls within its host coverage before treating it as complete evidence.

What meeting 03.14.01 costs in money and effort

This table breaks down the cost components of meeting 03.14.01 Flaw remediation, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build an internal estimate before asking for a written quote. No dollar figures or durations are given because none are supplied for this requirement.

Cost component	One-time or recurring	What drives it up or down
Tooling and licenses	Recurring where commercial tools are used	Open-source scanners such as Greenbone Community Edition, Wazuh and Fleet remove most license spend, but hosting, storage and database operations remain
Software and firmware inventory build	One-time, then recurring upkeep	Number of hosts, device models and firmware types; each new asset class adds collection and mapping work
Scanning and patch pipeline engineering	One-time build, recurring tuning	Number of patch sources, change windows and how many update types must be tested before deployment
ODP window design and documentation	One-time, reviewed periodically	Length of the software and firmware install windows you define; shorter windows usually need more automation and staffing
Evidence upkeep between assessments	Recurring	Frequency of scans, volume of tickets, and how consistently remediation records and exceptions are retained
External review or testing	Recurring or periodic	Scope of applications and infrastructure covered, and whether a third party validates the pipeline before an assessment
Assessor time	Periodic, per assessment	Completeness of evidence for the examine, interview and test methods; gaps in ODP values extend review
Internal staff time for remediation	Recurring	Fleet size, rate of security releases, and the number of systems that cannot be patched without downtime

Evidence that passes 03.14.01 and how to keep it current

An assessor testing 03.14.01 looks for a written decision on both organization-defined time periods, procedures that show how flaws move from identification to correction, and dated records that prove the windows were met. Each card below is an artifact that supports one part of that chain, along with the routine that keeps it accurate between assessments.

Written ODP decisions

Record the time period you set for installing security-relevant software updates and the separate period for security-relevant firmware updates. Both values are organization-defined parameters, so an assessor checks that each is defined, approved and applied to real systems. Name the owner and the date of approval. Review the values whenever a platform, vendor or contract changes, and confirm with your contracting officer whether the federal customer has specified values that override yours.

Flaw remediation procedure

Document how flaws are identified, reported, prioritized and corrected, including who receives vendor advisories and who approves emergency changes. The examine method for 03.14.01 reviews this procedure against what staff actually do, so keep steps tied to named tools and roles. Pair it with the configuration management procedure, which governs how patches enter baselines. Review both annually and after any major change to tooling or staffing.

Dated scan and inventory exports

Export vulnerability scan results and software inventories on a fixed schedule, with the scan date and target scope visible on each file. Assessors use these to confirm that flaws are identified across the system boundary, not only on the systems you selected for review. Store exports in a controlled repository with retention matching your assessment cycle. A scheduled export job with a named owner is more defensible than exports produced on request.

Change tickets showing installation within the window

For each security-relevant update, keep a change record that shows the release date, the approval, the installation date and the affected hosts. Compare the gap between release and installation against the ODP value you set. Where a window was missed, the ticket should show a documented reason and an approved exception. Run a monthly report that lists open updates approaching their deadline so overdue items surface before an assessor finds them.

Verification scans after remediation

After a patch or firmware update, rerun the relevant scan to confirm the flaw no longer appears on the target host. Retain the before and after results together so the correction is traceable. Verification also catches updates that reported success but did not take effect, which is a common gap in configuration drift. Record the scanner version and signature date alongside each result so the scan itself can be trusted.

Exceptions and POA&M entries

Where a security-relevant update cannot be installed within the defined period, document the exception with the affected system, the compensating measure, the risk owner and a target date. Enter open items in the plan of action and milestones that your assessment scope requires. Review the exception register quarterly, closing items that are resolved and escalating any that have passed their target dates. Confirm with your assessor how they expect POA&M entries to be formatted for your contract.

Interview notes and installer training records

Assessors interview the people who install, configure and maintain systems, and the people responsible for flaw remediation. Keep brief notes from practice interviews that show each person can describe the process, the ODP values and the escalation path. Pair these with training records showing when installers completed instruction on the flaw remediation procedure. Refresh the notes and records when staff change roles, and check that new administrators receive the same instruction before they take on patching duties.

Which parts of 03.14.01 to keep in-house and which to outsource

Your organization owns requirement 03.14.01 and every decision that makes it true in daily operations. Patching is performed by your administrators, and the policy that sets how fast updates must land is yours to define. The two organization-defined parameters, the period for installing security-relevant software updates and the period for firmware updates, must be set by your organization because NIST does not assign their values. Exceptions, such as a patch that cannot be applied to a production system, also need your approval and a documented compensating measure.

Setting the ODP values: Choose and record the software and firmware update windows, then tie them to your change control process.
Daily patching and firmware updates: Your operations staff apply updates, and they keep records of what was installed and when.
Exception approval: A named owner accepts, time-limits and reviews each deferred flaw.
Flaw triage and ownership: Your security team decides which findings are security-relevant and who corrects each one.
Procedures and training: Your staff write and maintain the flaw remediation procedures that the assessor will examine.

Before any engagement starts, confirm in writing which of these duties you will hold and which an outside party may touch.

Common questions about 03.14.01 cost, effort and outside help

How long does flaw remediation work usually take to put in place?

No duration is fixed by the standard, and the time depends on how many systems you run, how current your patching practice already is, and how many owners are involved. The requirement itself asks you to define time periods for installing security-relevant updates, so much of the early work is agreeing those periods and then proving you meet them. Teams with a clear asset inventory and an existing change window usually move faster than teams that must first find every system. Ask any partner to break the schedule into inventory, tooling, pilot patching and evidence collection, and to state which steps depend on your staff's availability.

Can a small team implement 03.14.01 without an outside partner?

A small team can implement the requirement alone if it has someone who owns patching, a current list of systems, and time to write the procedures an assessor will examine. The harder part is usually the evidence: showing that flaws are identified, reported, corrected and tracked against the periods you defined, across every operating system and firmware type. A partner can help with tooling and documentation, but the organization still owns the control and its results. Before deciding, compare your staff's hours against the assessment objects listed in SP 800-171A Rev. 3, and confirm the scope with whoever runs your assessment.

What must our team provide to an implementation partner?

A partner needs enough access and context to see what actually runs in your environment and how changes get approved. Typical inputs include an asset inventory, network diagrams for the CUI boundary, current patching and change procedures, vendor support lists, and the system security plan if one exists. You should also name the people who approve maintenance windows and own each platform. Share only what the engagement scope requires, and agree in writing how credentials and CUI-related data will be handled during the work.

Can a partner pass the assessment for us?

No. A partner can prepare systems, procedures and evidence, but only the assessing body issues the result, and the organization owns its controls and its score. For a DoD contractor, the assessment path depends on the contract and current DoD guidance, so confirm with the contracting officer which version and assessment method apply. Ask a partner to show how its work maps to the assessment objects in SP 800-171A Rev. 3 and to state plainly that the findings belong to your organization.

Which ODP values should we use if no federal agency has set them?

The requirement uses two organization-defined parameters for how quickly you install security-relevant software and firmware updates after release. NIST does not assign these values, and when a federal agency does not specify them, the nonfederal organization must set them to complete the requirement. Choose periods that match your risk, your vendors' release cadence and your contractual commitments, then write them into your procedures and apply them consistently. Confirm the values with the agency or prime contractor first, because a contract may already set them, and assessors will check that the values are defined and followed.

How does firmware patching differ from software patching for this requirement?

Software patching usually runs through your operating system and application management tools, while firmware patching often depends on each hardware vendor's release process, and some devices cannot be updated remotely. The requirement lists firmware as a separate ODP, so your procedures should cover it with its own time period. Expect more manual steps, vendor advisories to track, and maintenance windows that involve physical access or outages. Inventory firmware on routers, storage, endpoints and industrial devices early, because many gaps appear there first.

What should we ask for in a written quote for this work?

Ask for a fixed scope that lists the systems in and out of scope, the deliverables, and the dates each deliverable will be ready. The quote should separate one-time work, such as inventory, tooling setup and procedure writing, from recurring work, such as patch monitoring, reporting and support retainers. Ask who installs and operates each tool, which open-source components are included, what your staff must do, and how changes to scope are priced. Confirm that the partner does not issue assessment results and that the written terms state who owns the evidence.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, then prepares the flaw remediation process and evidence for 03.14.01 so your assessor can test it. We do not issue assessment results or certifications. Your organization owns the requirement, and an independent assessor makes the determination.

How we scope

Confirm which systems, enclaves and CUI-handling endpoints the 03.14.01 process will cover in writing before work starts.
Agree the organization-defined time periods for security-relevant software and firmware updates, since the requirement leaves those values to you.
Document which team owns each step of flaw identification, reporting, correction and update installation in the written scope.
Engagements are fixed-scope, with deliverables and timelines agreed in writing. Ongoing support is available as a retainer.

How we build

Deploy a vulnerability scanning and tracking workflow, such as Greenbone Community Edition, in your environment.
Configure endpoint vulnerability detection, such as Wazuh or Fleet, against the software inventory of in-scope systems.
Set up DefectDojo or a similar tracker to deduplicate findings and record remediation status with owners and due dates.
Map alert thresholds and patch windows to the time periods your organization has defined for software and firmware.

How we hand over

Deliver a written flaw remediation procedure and the update-timing rules that your organization approved.
Export the scan schedules, inventory reports, remediation tickets and update records that an assessor would examine.
Run a documented walkthrough so personnel responsible for patching and flaw remediation can explain the process in interviews.
Confirm with your assessor which evidence formats and sampling periods they expect before handover is final.

How we support

Review scan results and remediation backlog on a schedule agreed in your retainer, if you choose one.
Update detection feeds, tooling and documentation when platform versions or your defined update periods change.
Retest in-scope systems after material changes so the evidence reflects the current environment.
Ask your assessor, not DeployOpen, to judge whether the 03.14.01 evidence meets the requirement.