NIAP Policy Letter #12, titled “Acceptance Requirements of a Product for NIAP Evaluation,” was updated in February 2025 from its original 2014 version. The new version has streamlined some terminology (e.g., replacing Extended Packages with PP-Modules) and also introduced a new concept of core functionality.
Per Policy Letter #12, NIAP’s statement about core functionality is as follows:
“To ensure evaluations cover a meaningful set of security requirements, the PP must include Core Functionality of the TOE. Core functionality is defined as the primary purpose for which a product is marketed.”
The above statement reflects NIAP’s effort for developing Protection Profiles (PPs) that capture requirements for applicable technology types through the engagement of Technical Communities/international Technical Communities. It has long been understood that NIAP requires exact conformance with NIAP-approved Protection Profiles (PPs). However, NIAP’s enforcement of Policy Letter #12 suggests a subtle but critical shift, that is, applicable PPs corresponding to core functionality must be claimed. For example, a vendor may be questioned by NIAP why their product evaluation does not include conformance to the PP-Module for WLAN Clients if their product implements wireless connectivity.
This move is aligned with the intended effect of the Policy Letter, which is to ensure that NIAP-validated products must conform to all applicable PPs specific to the TOE type.
Although the Policy Letter explicitly addresses PPs, the same principle applies to PP-Modules and functional packages, as NIAP treats these as equally mandatory when they correspond to a product’s core functionality. Vendors are therefore obligated to include in the evaluation scope all applicable PPs, PP-Modules, and Functional Packages pertaining to the product’s core functionality. In short, no core functionality can be excluded: whether covered by a base-PP, a PP-Module, or a functional package, all core functionality must be reflected in the evaluation scope.
For vendors, this means that greater care must be taken when planning evaluations under the NIAP scheme. NIAP expects the evaluation of the TOE (Target of Evaluation) to reflect the product’s true capabilities, not just a trimmed-down scope limited to a subset of core features for convenience. Such exclusions create a gap between the evaluated “product” (i.e., TOE) and the product as marketed. Policy Letter #12 aims to minimize this gap by ensuring evaluations provide a holistic and accurate reflection of a product’s security posture.
To meet NIAP’s expectation, vendors should begin by identifying the core features of their product, especially those tied to security. From there, the appropriate base-PP should be selected, and then relevant PP-Modules and functional packages should be added to capture all core functionality.
