Temporary Deficiencies, Enduring Exceptions, and Operational Plans of Action: What are they and why do I care?
- vincentscott6
- 14 minutes ago
- 7 min read
All three concepts are defined in the CMMC rule, and represent expansions and clarifications of short entries in NIST 800-171. They have not been discussed much in the professional public dialogue, and I suspect that this is because they clearly conflict with the, “Bring the Hammer! No Mercy!” mentality that underlies the philosophical direction of these discussions of late. Although there is certainly legitimate cause for angst around implementation, swinging the pendulum too far in the other direction is ultimately counterproductive for the security of DoD information in my view. For Organizations Seeking Certification (OSCs) these three concepts are powerful tools for CMMC preparation. But they must be used properly.
Let’s start with what a Temporary Deficiency is.
“Temporary deficiency means a condition where remediation of a discovered deficiency is feasible, and a known fix is available or is in process. The deficiency must be documented in an operational plan of action.” https://www.federalregister.gov/d/2024-22905/p-2033
The root of temporary deficiencies is in the security requirement 3.12.2 from NIST SP 800-171. “Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.” NIST foresaw the need to address problems in an ongoing fashion. Things break. In our comments to the DoD on the proposed rule we pointed out that perfect implementation of any standard was not possible, and counter to the security controls of 171. Formalizing temporary deficiencies is their answer to that input.
Keep in mind that temporary deficiencies and vulnerabilities are not exactly the same. The regulation and 171 both speak to them distinctly. We highly recommend separating the two concepts rather than combining them, although strictly speaking in NIST definitions, they are often amorphously combined. An argument from NIST can be made that the two are synonymous, as well as in some narrow cases that they are distinct. In general, vulnerabilities can be, and should be managed, under a vulnerability scanning and remediation program in our view. Hardware and software is scanned, vulnerabilities are identified, and then corrected in accordance with risk acceptance. Have a program for this and execute with precision. We recommend that deficiencies, on the other hand, be defined as something broader and less precise. Issues that are identified, problems with architecture, security control implementation, and so on. Larger, less precise challenges that cannot be reduced to a CVE number.
How does this interpretation work out in real life? Vulnerabilities are things like CVE-2025-59287 a Remote Code Execution flaw in Windows Server. This is CVE Level 10, the highest, and should be identified with your vulnerability scanner and remediated in accordance with your procedures. Deficiencies may be something like determining that your current firewall does not have sufficient capabilities to meet all of your security requirements; therefore, you plan to upgrade.
“A temporary deficiency is not based on an `in progress' initial implementation of a CMMC security requirement but arises after implementation. A temporary deficiency may apply during the initial implementation of a security requirement if, during roll-out, specific issues with a very limited subset of equipment is discovered that must be separately addressed.”
This is a key concept. Do NOT plan to simply mark everything you are not doing as a temporary deficiency. This is similar to previous rumors and misconceptions that you could in fact give yourself credit for controls on your POAM, and declare your NIST 800-171 Score as 110 while not really implementing much of anything. This is patently not true, and the subject of several law enforcement actions under the False Claims Act.
However, it is worth noting that once a security requirement has been formally assessed as MET, then a future problem with that implementation could be designated a temporary deficiency.
“There is no standard duration for which a temporary deficiency may be active. For example, FIPS-validated cryptography that requires a patch and the patched version is no longer the validated version may be a temporary deficiency. (CMMC-custom term)”
Two critical items here. Temporary Deficiencies can last more than 180 days, and FIPS Validated Cryptographic patching is the example. More on how to use that below.
Temporary Deficiencies go onto your Operational Plan of Action (OPA). Everyone should have an Operational Plan of Action (OPA) and utilize it effectively to allow for normal IT operations, including when things break in your control stack. Proper use of the OPA can allow you the window to legally fix things without breaking your assessment affirmation (i.e. that oath you gave the DoD that you were doing it all and would keep doing so).
Wait. We have been doing Plans of Action all along right? And they are effectively forbidden now right? We just call them POAMs instead of OPAs. Same same? Not so.
“These operational plans of action are different from POA&Ms permitted under Conditional assessment. The rule has been updated to make this distinction clear.”
In the final 32CFR rule this distinction entered the picture for the first time in regulation. POAMs are described as:
“This section of the CMMC rule has been updated to add clarity when discussing the POA&M regarding security requirements that were assessed as NOT MET during a CMMC assessment. These POA&Ms are distinct from an operational plan of action.”
POAMs are utilized for security requirements that are found NOT MET during a certification or self-assessment. OPAs are different. What is an OPA then?
“Operational plan of action as used in security requirement CA.L2-3.12.2, means the formal artifact which identifies temporary vulnerabilities and temporary deficiencies (e.g., necessary information system updates, patches, or reconfiguration as threats evolve) in implementation of requirements and documents how they will be mitigated, corrected, or eliminated. The OSA defines the format (e.g., document, spreadsheet, database) and specific content of its operational plan of action. An operational plan of action does not identify a timeline for remediation and is not the same as a POA&M, which is associated with an assessment for remediation of deficiencies that must be completed within 180 days. (CMMC-custom term)” https://www.federalregister.gov/d/2024-22905/p-2009
“An operational plan of action can be created without risk to the certification validity period. If a security event generates risk for the protection of FCI or CUI, the associated security requirements should be readdressed expeditiously. If one or more of the requirements can't be remediated, the OSA should create an operational plan of action and resolve it in a time frame that continues to provide protection to FCI or CUI.”
“Operational plans of action are the appropriate mechanism to handle CSPs, ESPs (not a CSP) and third-party vendors that are no longer compliant with a CMMC requirement.”
One reason why we recommend everyone have an OPA is because of FIPS. FIPS validation is a requirement. Entire volumes can be, and have been written about FIPS validation, but for the purposes here only one point matters. Technically, FIPS validation is null and void when the software running it is patched or updated. Since the FIPS validation itself process runs 1.5-2+ years, you can virtually guarantee that there are software updates between submission to NIST and validation. By the time a module is validated nearly 100% of the time, the validated module is already seriously out of date. Further, the regulation says:
“Vendor limitations with respect to FIPS validation could be considered enduring exceptions or temporary deficiencies and should be addressed in an OSA's operational plan of action.”
Great. FIPS is both an example and explicitly called out in the regulation as a legitimate addition to the OPA. So, create an OPA and put all of your FIPS-validated cryptographic modules on there as a start.
OK, so what is an Enduring Exception then?
Enduring Exception means a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible. Examples include systems required to replicate the configuration of `fielded' systems, medical devices, test equipment, OT, and IoT. No operational plan of action is required but the circumstance must be documented within a system security plan. Specialized Assets and GFE may be enduring exceptions. (CMMC-custom term)
So Enduring Exceptions do not have to be on the OPA, but:
“(i) Enduring exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.”
Therefore, enduring exceptions do need to be identified in the SSP. This does offer some opportunity for allowance when things simply cannot meet all the security requirements. Operational Technology or OT is a great example of this. We recommend aligning Enduring Exceptions with your Specialized Asset scoping. Specialized Assets are:
“Specialized Assets, which are assets that can process, store, or transmit CUI but are unable to be fully secured, including: Internet of Things (IoT) devices, Industrial Internet of Things (IIoT) devices, Operational Technology (OT), Government Furnished Equipment (GFE), Restricted Information Systems, and Test Equipment, are documented but are not assessed against other CMMC security requirements, as addressed in table 3 to § 170.19(c)(1).”
We note that Specialized Assets are described as including six different types of assets which are described in greater detail in the scoping guide. Based on the “including” word in the definition we consider this list to allow for things outside of those six distinct asset types. A great example of this is a Super Computer. Although not specifically fitting into one of the six categories, it most certainly is a Specialized Asset in our view.
Summary
OSCs should use the OPA as outlined in the regulation, as a place for listing Temporary Deficiencies. Enduring Exceptions should be identified in the SSP. FIPS Cryptographic modules should be listed on an OPA since this is both the example in the regulation and nearly all cryptographic modules fall into the category of receiving software updates. Identified Vulnerabilities can also be listed in the OPA, but an OPA is not intended as a list of vulnerabilities. From a practical perspective we recommend using the OPA for those vulnerabilities which will require longer than your standard, stated (as required) timelines for remediation. Practically speaking, when your vulscanning and remediation process is handling these inside the existing process we see no reason to list them on the OPA. When they are going to take longer though, for example, when remediation of a vulnerability would impact operational processes through cascading dependencies, the OPA is a good place to record and track those issues’ remediation. Critically, in a self or certification assessment, items legitimately categorized as Enduring Exceptions or Temporary Deficiencies are assessed as MET.
170.24(b) “(i) Enduring exceptions when described, along with any mitigations, in the system security plan shall be assessed as MET.
(ii) Temporary deficiencies that are appropriately addressed in operational plans of action (i.e., include deficiency reviews and show progress towards the implementation of corrections to reduce or eliminate identified vulnerabilities) shall be assessed as MET.”
