NIAP updated how vulnerabilities in evaluated products are handled in its recent Policy Letter 17 (and Addendum #1), published in May 2025. The changes cover everything from which vulnerabilities prevent a product from being listed on the Product Compliant List (PCL) to mandatory search terms. Given these tweaks will impact every evaluation, we wanted to share our thoughts and provide insight into what vendors seeking evaluations can expect.
The “Crucial” Question
One thing that sticks out immediately in the Policy Letter is the mention of “crucial security-relevant vulnerabilities”, as these are the vulnerabilities that will primarily preclude a product from being listed on the PCL.
This raises the question: “What counts as a crucial vulnerability?”
Crucial vulnerabilities, as defined in Addendum #1, must meet all three of the following criteria:
- The affected component is used by the TOE in the evaluated configuration.
- The vulnerability is exploitable remotely.
- The vulnerability causes a fault belonging to one or more of the following categories:
- Cryptographic functionality.
- Key/credential disclosure/leakage.
- Authentication bypass/privilege escalation or
- Arbitrary code execution.
Source: NIAP Policy 17 Addendum – Vulnerability Mitigation Guidance
Let’s cover the impact first: This effectively means that fewer vulnerabilities will prevent a product from being listed on the PCL, as previously any security-relevant vulnerability could prevent a PCL listing.
That said, NIAP clearly states that they reserve the right to request any vulnerability found be addressed before listing, so it’s still safest to have no unaddressed vulnerabilities (to no one’s shock, we’re sure).
As for the list, the first point boils down to understanding the difference between the TOE and a product: the TOE can be present in a product that contains more than just the TOE. As such, if a component in the product has an unaddressed vulnerability but that component is not used by the TOE being evaluated, it is not considered a crucial vulnerability that will block being listed on the PCL.
atsec understands the second point to revolve around assumptions made in the Security Problem Definition: Most protection profiles (PPs) assume that agents using the TOE, either administrators or users, are trusted. Furthermore, physical security requirements can ameliorate the threat of a non-trusted agent maliciously accessing the TOE locally, leaving remote exploitation the more troubling vector. We should note that NIAP has not explicitly said this, but this is how atsec interprets the addendum’s focus on remote exploits.
The third point simply narrows what can be considered a crucial vulnerability – anything that falls outside those categories could be security-relevant but would not be crucial.
Before we move on to tackling vulnerabilities, there is one more exception worth noting: “Denial of Service vulnerabilities shall ALWAYS be addressed if they are listed in the CISA KEV catalog.” That’s a direct quote, emphasis NIAP’s.
Planning Ahead
Let’s say you run into a crucial security-relevant vulnerability when atsec performs a vulnerability search before your PCL posting (no more than 30 days before the posting), and you can’t mitigate the vulnerabilities within those 30 days (or fewer, depending).
In this case, the CC Testing Lab (CCTL) needs to submit a mitigation plan to NIAP and will be required to apply and test the mitigations within the time frame specified in the plan. Once completed and reviewed, the product enters Assurance Maintenance so long as the checkout package is completed.
atsec will obviously work with vendors to draft such a mitigation plan, but we also do everything we can to discover vulnerabilities that need mitigation well before it’d be infeasible to mitigate said vulnerabilities before the PCL posting date.
In the event a mitigation plan is necessary, NIAP does have some requirements for it:
- Mitigation plan shall be submitted prior to the evaluation termination date
- Mitigation shall include a timeline for patching the vulnerability that must be addressed
- Mitigation plan shall include a description of each fix/patch to be implemented
- Mitigation plan shall not be approved if all non-CVE issues have not been completed by the evaluation termination date
- If the initial mitigation plan and timeline cannot be met, the CCTL must inform NIAP no later than 5 business days prior to the agreed upon deadline.
Source: NIAP Policy 17 Addendum – Vulnerability Mitigation Guidance
Additionally, there are four accepted mitigation methods:
- Apply Vendor Patch (required, if available);
- Remove affected functionality;
- Disable affected functionality; or
- Additional Configuration documentation for the TOE or operational environment.
Source: NIAP Policy 17 Addendum – Vulnerability Mitigation Guidance
Documenting the Details
While we’ve talked about how there are fewer show-stopping vulnerabilities and how mitigation plans allow you to deal with late-discovered vulnerabilities, we want to be exceptionally clear: NIAP is still expecting all vulnerabilities to be reported, and those fall into one of two categories: vulnerabilities that do not affect the TOE, and vulnerabilities that affect the TOE.
For vulnerabilities that do not affect the TOE, a rationale of why the vulnerability isn’t applicable is mandatory; for vulnerabilities that do affect the TOE, NIAP expects detailed explanations of the vulnerability description and the mitigation method (if mitigated).
NIAP provides a lengthy list of information that must be included for all evaluations, which we will leave to Addendum #1 to provide in full. A lot of the information is on the CCTL to provide, so atsec will take care of most of this for vendors.
Also relevant to atsec’s work is the new list of mandatory search concepts, including the TOE name, any enabled external application layer interfaces, and terms identified by the technical community in PPs relevant to the evaluation. Again, check Addendum #1 for the full list.
As most of these reporting changes are on the CCTL to implement, rest assured that atsec has already briefed its security consultants on the changes and has updated its processes and documentation to ensure ongoing and future evaluations adhere to the new requirements.
Ongoing Support
Before we wrap up, there’s one more critical change that warrants highlighting: NIAP will not validate products that are submitted for evaluation that are End-of-Life. Importantly, this includes components within the TOE boundary. Furthermore, End-of-Life products that are already validated will be actively pruned from the PCL.
To remain on the NIAP PCL, products need to be actively supported with regular updates, which could include software patches, firmware updates, replacement parts, and maintenance contracts. Per NIAP, “support that is limited to only investigation and troubleshooting issues does not satisfy the actively supported requirement.”
Ultimately, atsec does not foresee many drastic changes in how evaluations play out for vendors, as a lot of the additional rigor introduced falls on the CCTLs rather than the vendors. However, the changes that require regular support will be of immediate concern to all vendors, as it affects whether your products will be able to achieve a successful validation with NIAP based on what are likely entrenched support policies at your business.
At the end of the day, though, atsec is still committed to getting all vendor’s products successfully evaluated and listed on the PCL. This Policy Letter provides additional clarity and requires more rigorous reporting, but these are extensions of the work we already do so we’re confident there will be next to no slowdown in current or future evaluations.
