NIAP CCEVS oversees evaluations of commercial IT products for use in National Security Systems. The Common Criteria Evaluation and Validation Scheme (CCEVS) is the U.S. evaluation scheme implemented under NIAP to meet the requirements of the Common Criteria Recognition Arrangement. The terms “NIAP” and “CCEVS” are commonly used interchangeably. 

NIAP works with both government and industry to oversee evaluation of COTS IT products for use in National Security Systems. Successful evaluations benefit product developers and government procurers by validating that the products meet security requirements for U.S. national security system procurement. Because NIAP is a member of the international Common Criteria Recognition Arrangement (CCRA), NIAP evaluations are mutually recognized in all CCRA member nations.

NIAP evaluations are conducted by NVLAP-accredited commercial testing labs, called Common Criteria Test Labs (CCTLs). A product vendor chooses an approved lab to complete the product evaluation against applicable Protection Profile(s). A Protection Profile is an implementation-independent set of security requirements and test activities for a particular technology that enables achievable, repeatable, and testable evaluations.

All products evaluated under NIAP must demonstrate exact compliance to the applicable Protection Profile(s). NIAP validates the results of the security evaluation conducted by the CCTL, if the evaluation is successful, issues a Common Criteria certificate.  U.S. customers (designated approving authorities, authorizing officials, integrators, etc.) may treat these CCRA mutually-recognized evaluation results as complying with the Committee on National Security Systems Policy (CNSSP) 11, National Policy Governing the Acquisition of Cybersecurity and Cybersecurity-Enabled Information Technology Products - dated June 2013 (https://www.cnss.gov/CNSS/issuances/Policies.cfm).

No.  NIAP oversees the evaluation of only Commercial Off-the-Shelf (COTS) IT products by accredited Common Criteria Testing Labs (CCTLs).

The vendor of the product is typically the “sponsor” of a CC evaluation. To initiate an evaluation, contact an accredited Common Criteria Testing Laboratory directly.

See the NIAP website for a description of the NIAP evaluation process:  https://www.niap-ccevs.org/Ref/Evals.cfm.

An evaluation in NIAP can be completed in less than 90 days, but must not exceed 180 days (6 months). The time it takes to evaluate/validate a product depends on many factors, including; size and complexity of the product, the amount of evidence available vs. the amount that needs to be generated, and the availability of lab resources to do the evaluation. Common Criteria evaluations conducted outside of NIAP (in other CCRA nations) may take longer.

NIAP’s Assurance Continuity process allows vendors to maintain their product evaluation through a process that recognizes that as minor changes are made to an evaluated product, evaluation work previously performed need not be repeated in all circumstances.  NIAP’s Assurance Continuity is typically a quick turn process to update a product evaluation.  More details are available in NIAP’s Publication 6,  Assurance Continuity:  Guidance for Maintenance and Re-evaluation.

If the product evaluation exceeds the estimated completion date but has not exceeded the 180-day evaluation timeline requirement, the schedule will be updated and the product may remain on the Products in Evaluation list. If an evaluation exceeds the 180-day limit it will be terminated and removed from the Products in Evaluation list.  Vendors and CCTLs should define schedules which they believe can be met, within the NIAP limitations. For more information on evaluation time limits, see: 
 — CCEVS Policy Letter #18, “Time Limits on NIAP Evaluations”
 — CCEVS Policy Letter #25, “Terminated Evaluations: Limitations and Restrictions”
 — CCEVS Policy Letter #4, “Inactive Evaluations”

NIAP does not set evaluation fees, nor charge for evaluation oversight activities.  The cost of an evaluation is negotiated between the vendor and the Common Criteria Testing Laboratory (CCTL), and NIAP is not involved or privy to evaluation costs. Vendors are encouraged to contact multiple NIAP CCTLs to compare expertise, experience, and costs.  All NIAP CCTLs offer consulting services to help the vendor determine what will be required prior to formally entering the evaluation process.

First, select a CCTL from the list of approved Labs. Vendors are encouraged to contact multiple NIAP CCTLs to compare expertise, experience, and costs.  All NIAP CCTLs offer consulting services to help the vendor determine what will be required prior to formally entering the evaluation process.
The NIAP evaluation process requires that a Security Target (ST) be produced to describe how the product meets the requirements defined in the selected Protection Profile(s).  The CCTL conducts testing, as defined in the Protection Profile(s) to confirm the security requirements are met in the product.  
At the conclusion of the evaluation, if the product has satisfied all requirements, NIAP issues a Common Criteria certificate validating the products' evaluation and publishes the product and associated documentation on the NIAP Product Compliant List (PCL).
A Common Criteria evaluation certificate signifies that all necessary evaluation work has been performed to convince the validation authority that the TOE meets all the defined assurance requirements as grounds for confidence that an IT product or system meets its security objectives. Assurance Continuity recognizes that as changes are made to a certified TOE or its environment, evaluation work previously performed need not be repeated in all circumstances.

The product sponsor/developer has two options for maintaining the validity of the evaluation as the product evolves from one version to the next: (1) Request a re-evaluation of the next version of the product, or (2) Participate in Assurance Continuity process. Assurance Continuity enables developers to bring a validated product up to date by incorporating all patches, updates, and other changes, resulting in an updated product’s new assurance baseline.
Vendors/developers planning to maintain their validation through the Assurance Continuity process must submit an Impact Analysis Report (IAR) up to 30 days prior to the product’s Assurance Maintenance Date that is posted on the NIAP Product Compliant List.  NIAP then reviews the IAR to determine if changes to the product have a major or minor security impact on the Target of Evaluation. Major changes require that the product undergo re-evaluation.  Minor changes require that the detailed changes be documented in an Assurance Continuity Maintenance Report and the updated Security Target document be published to the NIAP Product Compliant List.  For more information regarding the Assurance Maintenance process, please refer to NIAP Publication #6, “Assurance Continuity: Guidance for Maintenance and Re-evaluation.”

When selecting a CCTL the sponsor should use a careful screening process and should consult with multiple/all NIAP CCTLs. Review and consider the CCTL personnel’s experience with the technology, the fees, the estimated schedule, and any other pertinent factors. Details of the contract between the CCTL and the sponsor are left to the two parties to negotiate, with no NIAP involvement.  NIAP does not set evaluation fees nor charge for validation activities.

If the product is intended to be used on National Security Systems, an evaluation is mandated by CNSS Policy #11.  Use of an evaluated product facilitates expeditious procurement and accreditation processes.

The PCL is continuously updated as products complete their evaluations or as product evaluations expire.

Products evaluated in other CCRA member nations demonstrating exact compliance with a NIAP-approved Protection Profile (PP) or collaborative Protection Profile (cPP) can be listed on the PCL.  To request that NIAP post a product on the PCL evaluated in another CCRA Scheme against a NIAP-approved PP or cPP, the vendor/evaluating scheme must already have completed the evaluation and be listed in on the CC Portal. The Security Target must claim exact conformance to one or more of the applicable NIAP-approved PPs/Extended Packages (EPs) or a collaborative Protection Profile (cPP).  Additional required documents are the Administrative Guidance (to configure the product to its evaluated configuration) and the Assurance Activity Report (AAR), as stated in NIAP Policy #1 and #24. The request for posting a product to the PCL must be submitted to NIAP here.

NIAP mutually recognizes evaluations completed under the terms of the CCRA. If a product evaluated in another CCRA Scheme is listed on NIAP’s PCL after undergoing the above process, it is eligible for procurement for use in national securty systems as per the Committee on National Security Systems Policy (CNSSP) #11. Products on NIAP’s PCL must be considered in the context of the environment of use, including appropriate risk analysis and system accreditation requirements.  Customers must ensure that the products selected will provide the necessary security functionality for their architecture.

NIAP uses the official definition for Cybersecurity and Cybersecurity-enabled, as documented in DoD Policy 8500.1 and in CNSS Instruction No. 4009.

Cybersecurity Product:  A product whose primary purpose is to provide security services (e.g., confidentiality, authentication, integrity, access control, non-repudiation of data); correct known vulnerabilities; and/or provide layered defense against various categories of non-authorized or malicious penetrations of information systems or networks.

Cybersecurity-Enabled Product:  A product whose primary role is not security, but provides security services as an associated feature of its intended operating capabilities.

There is no guarantee that any product will be free of defects. A NIAP certification ensures that the product has successfully completed evaluation.  The purpose of evaluation is to assess the products IT security against a selected applicable Protection Profile.  A Protection Profile is an implementation-independent set of security requirements for a particular technology that enables achievable, repeatable, and testable evaluations.

NIAP oversees evaluations of commercial IT products for use in National Security Systems.  NSA-approved products are generally Government Off-the-shelf, or GOTS, products. A NIAP certificate indicates that the product has successfully completed an evaluation - it is not an endorsement of the product or an NSA approval for use. NIAP provides a list of evaluated/validated products that can be considered by DoD organizations for use. Products must be considered in the context of the environment of use, including appropriate risk analysis and system accreditation requirements. Customers must ensure that the products selected will provide the necessary security functionality for their architecture.

National Security System Certification and Accreditation processes mandate procurement of COTS IT products that have met the requirements of CNSSP #11.  The System's Authorizing Official (AO) should be consulted about what product(s) can be connected to a system to ensure the necessary level of protection.

NIAP does not provide guidance for media destruction. Review the NSA web site for information/guidance related to media destruction devices:  Media Destruction Guidance (nsa.gov).

NIAP maintains a Product Compliant List (PCL) that contains all current validated products.  NIAP also maintains a list of products that are "In-Evaluation.” See the current Products in Evaluation List at https://www.niap-ccevs.org/Product/PINE.cfm.

NIAP maintains a list of Products in Evaluation.

Information related to each Product in Evaluation listing (e.g., product or Protection Profile names, versions, etc.) may change during the evaluation. Be sure to contact the documented evaluation sponsor to obtain the most current information.

This list may not reflect all products in NIAP evaluation as each listing is subject to vendor approval.  The fact that a product is in evaluation does not guarantee that it will successfully complete the NIAP evaluation process.

The NIAP PCL includes all current products evaluated against NIAP approved PPs and cPPs.  Additional products, evaluated in other CCRA schemes are listed on the Common Criteria Portal.  NIAP evaluated products with expired certifications are on the NIAP Archived Product List.

We recommend that procurement representatives join Technical Communities for the technology areas of interest to influence the security requirements that are included in the applicable Protection Profiles.

If the product has not been evaluated by a Common Criteria Scheme, the customer may contact the vendor directly to request a product evaluation. POCs for vendors can be found on the Product Compliant List (PCL). Pick a product by a selected vendor, click on the product title, and scroll to the bottom of the product detail page for the vendor contact information.

The NIST Cryptographic Module Validation Program (CMVP) validates cryptographic modules to Federal Information Processing Standards (FIPS) 140-2, Security Requirements for Cryptographic Modules, and other FIPS cryptography-based standards. Vendors of cryptographic modules use independent, accredited Cryptographic and Security Testing (CST) laboratories to test their cryptographic modules against all applicable requirements as specified in FIPS 140-2 and in the cryptographic algorithm standards. A cryptographic module successfully tested by a lab and validated by NIST is added to the module validation list, which identifies the vendor, module type, validation date, and a description of the associated algorithms and the operational environment.

See the NIST website for additional information.

The Cryptographic Algorithm Validation Program (CAVP) provides validation testing of FIPS-approved and NIST-recommended cryptographic algorithms and their individual components. Cryptographic algorithm validation is a prerequisite of Cryptographic Module Validation Program (CMVP).  Vendors may use any of the National Voluntary Laboratory Accreditation Program (NVLAP) accredited Cryptographic and Security Testing (CST) Laboratories to test algorithm implementations.  An algorithm implementation successfully tested by a lab and validated by NIST is added to an algorithm validation list, which identifies the vendor, implementation, operational environment, validation date and algorithm details.

See the NIST website for additional information.

See the NIST website for information on this topic.

NIAP oversees evaluations of Commercial Off-The-Shelf products for use in National Security Systems. The Cryptographic Module Validation Program (CMVP) is designed to evaluate cryptographic modules within products. The CMVP program provides customers with confidence that commercial cryptographic modules meet one of the four security specification levels documented in FIPS 140-2, Security Requirements for Cryptographic Modules, and that the FIPS-approved algorithms are properly implemented. Common Criteria evaluation includes both cryptographic and non-cryptographic security functions of a Cybersecurity or Cybersecurity-enabled COTS IT product against security requirements documented in the associated Protection Profile.  NIAP Policy #5 and Policy #5 FAQ provide additional information about minimizing duplicate testing between the programs.

NIAP oversees evaluations of commercial IT products for use in National Security Systems. 

The Cryptographic Algorithm Validation Program (CAVP) is designed to provide validation testing of FIPS-approved and NIST-recommended cryptographic algorithms and their individual components. The Cryptographic Module Validation Program (CMVP) is designed to evaluate cryptographic modules within products. While both NIAP and the NIST programs are used to evaluate COTS Cybersecurity and Cybersecurity-enabled products, they focus on different aspects of the product and use different criteria. The CMVP program provides customers with confidence that commercial cryptographic modules meet one of the four security specification levels documented in FIPS 140-2, Security Requirements for Cryptographic Modules, and that the FIPS-approved algorithms are properly implemented. Common Criteria evaluation encompasses both cryptographic and non-cryptographic security functions of a Cybersecurity or Cybersecurity-enabled IT product. In many cases, the cryptographic portion of a product will be evaluated under FIPS 140-2 to meet cryptographic requirements that are part of a NIAP evaluation.  

In order for a U.S.-evaluated product to be posted on the NIAP Product Compliant List, the product’s cryptography must, at minimum, have a CAVP certificate and optimally, a CMVP certificate.  NIAP accepts CAVP and CMVP certificates to demonstrate compliance to certain Protection Profile requirements, thereby eliminating duplicate test activities.

NIAP Policy #5 and Policy #5 FAQ provide additional information about minimizing duplicate testing between the programs.

NIAP PPs are written so that they can be used internationally by nations that do not participate in FIPS.  However, test activities that result in a NIST CAVP/CMVP certificate may be used to demonstrate compliance to some PP/cPP assurance activities, thereby eliminating the need for redundant Common Criteria testing for these assurance activities.

The Committee on National Security Systems (CNSS) sets national-level Cybersecurity policies, directives, instructions, operational procedures, guidance, and advisories for United States Government (USG) departments and agencies for the security of National Security Systems (NSS). It provides a comprehensive forum for strategic planning and operational decision-making to protect NSS and approves the release of INFOSEC products and information to Foreign Governments. The CNSS (formerly named the National Security Telecommunications and Information Systems Security Committee (NSTISSC)) was established by National Security Directive (NSD)-42, “National Policy for the Security of National Security Telecommunications and Information Systems in 1953. This was reaffirmed by Executive Order (E.O.) 13284, dated January 23, 2003, “Executive Order Amendment of Executive Orders and Other Actions in Connection with the Transfer of Certain Functions to the Secretary of Homeland Security” and E.O. 13231, “Critical Infrastructure Protection in the Information Age” dated October 16, 2001.Under E.O. 13231, the President re-designated the NSTISSC as CNSS. The Department of Defense continues to chair the Committee under the authorities established by NSD-42. See the CNSS website.

The objective of CNSSP #11, National Policy Governing the Acquisition of Cybersecurity and Cybersecurity-enabled IT Products, is to ensure that COTS Cybersecurity and Cybersecurity-enabled IT products acquired for use to protect information on U.S. National Security Systems comply with the requirements of the NIAP program in accordance with NSA-approved processes and, where applicable, the requirements of the Federal Information Processing Standard (FIPS) Cryptographic validation program(s).

CNSSP #11 is a critical policy component of the U.S. Government's overall Cyber Security strategy. This binding national policy clarifies the required evaluation processes applicable to Commercial-Off-The-Shelf (COTS) and Government-Off-The-Shelf (GOTS) Cybersecurity and Cybersecurity-enabled IT products that are used on U.S. National Security Systems (NSS) to protect the information therein. Acquirers, users, and vendors of Cybersecurity and Cybersecurity-enabled IT products are encouraged to familiarize themselves with the policy and its associated processes to ensure full compliance with its documented requirements.

Today's technology advances and threats necessitate agile and cost effective approaches to protecting national security systems and information. The U.S. Government has migrated from the exclusive use of Government Off-the-Shelf (GOTS) products to a mix of Commercial Off-the-Shelf (COTS) and GOTS products for the protection of information within our national security systems. The proliferation of COTS Cybersecurity products such as firewalls and intrusion detection systems, as well as Cybersecurity-enabled products such as operating systems and mobile devices with security attributes, has provided the community of users with a multitude of products to choose from. All of the products come with their own specific claims relative to the security functions they provide. In this context, it is important that COTS Cybersecurity and Cybersecurity-enabled IT products acquired by U.S. Government NSS departments and agencies successfully pass a standardized evaluation process that provides assurance that claimed security functionality is present and operational.

CNSSP # 11 applies to products being acquired for National Security Systems that are used to enter, process, store, display, or transmit national security information. This policy applies to all Cybersecurity and Cybersecurity-enabled IT products acquired for use by or on behalf of U.S. Government (USG) Departments and Agencies (D/A) to protect NSS and the information that resides therein. Departments and agencies responsible for governing non-national security systems but considered part of the of critical infrastructure as defined in the Presidential Decision Directive on Critical Infrastructure Protection (PDD-63), may wish to consider CNSSP #11 in their cybersecurity procurement strategy.

No, NIAP does not have the authority to waive the Committee on National Security Systems Policy #11 (CNSSP #11) requirements. When a NIAP-approved Protection Profile (PP) does not exist for a technology, NIAP will work with the vendor, lab and/or customer to determine the best way to proceed.  See NIAP’s published Guidance for when no PP exists.

To help ensure commercial component vendors meet CNSS Policy (CNSSP) No. 11 requirements, the following contractual language is recommended for procurements involving commercial technologies: “Technologies for [Program X] shall be procured in accordance with CNSSP No. 11, "National Policy Governing the Acquisition of Cybersecurity and Cybersecurity-Enabled Information Technology Products." In addition, technologies shall be procured which have been validated by Common Criteria Testing Labs, in accordance with the National Information Assurance Partnership (NIAP) Protection Profiles (PPs). Where a PP exists but the desired product has not been validated against it, [Program X] shall direct the desired vendor to have their product validated against the appropriate, corresponding PP. For National Security Systems (NSS) where classified data is being protected at rest or in transit by commercial products, technologies from the Commercial Solutions for Classified (CSfC) Components List shall be used, in accordance with NSA's published CSfC Capability Packages.” Capability Packages and CSfC Components can be found on the CSfC Components List. NIAP-validated products can be found on the NIAP Product Compliant List.

The process for establishing a CCTL is documented in Publication #4: Guidance to NIAP-Approved Common Criteria Testing Laboratories.

Publication #4 provides a sample Letter of Intent.

No. NIAP no longer accepts EAL-based evaluations and has transitioned to evaluations with exact compliance to technology-specific Protection Profiles (PP) in order to provide achievable, repeatable, testable evaluation results.  Products being evaluated against a NIAP-approved PP must be in exact compliance with the PP. If a PP does not exist for a technology, NIAP will work with the vendor, lab, and/or customer to determine the best way to proceed per published guidance.

NIAP has worked closely with government agencies including NIST to ensure all references to Evaluation Assurance Levels (EALs) and Robustness were removed from applicable documentation. Occasionally, EAL or Robustness is mentioned, usually in regards to product acquisition. In the rare cases where this does happen, we ask you inform us and we will work with the agency to explain the NIAP evaluation process and have the language removed and/or modified.

The Common Criteria for Information Technology Security Evaluation (CC), ISO/IEC 15408 Standard, defines general concepts and principles of IT security evaluation and presents a general model of evaluation. It presents constructs for expressing IT security objectives, for selecting and defining IT security requirements, and for writing high-level specifications for products and systems.

The advantage of using the Common Criteria international standard is that products can be evaluated once and sold in multiple nations.  This allows for efficient use of both government and industry resources.  The CCRA ensures that accredited laboratories, regardless of their geographic location or national affiliation, will test products against the same criteria and use the same testing methodology.

The Common Criteria (CC) for Information Technology Security Evaluation is an international standard (ISO/IEC 15408) for computer security evaluations/certifications. FIPS 140 is a U.S. Government computer security standard used to accredit cryptographic modules.  The two standards are different but they complement each other. The CC does not certify the crypto module but will ensure that the interfaces and other crypto parameters where the module was integrated into the COTS product, is implemented as stated by the vendor.   Vendors of cryptographic modules use independent, accredited Cryptographic and Security Testing (CST) laboratories to test their cryptographic modules against all applicable requirements as specified in FIPS 140-2 and in the cryptographic algorithm standards.

NIAP oversees evaluations of commercial IT products for use in National Security Systems.  CNSSP #11, National Policy Governing the Acquisition of Cybersecurity and Cybersecurity-Enabled IT Products, requires that COTS Cybersecurity and Cybersecurity-enabled IT products acquired for use to protect information on U.S. National Security Systems comply with the requirements of the NIAP program in accordance with NSA-approved processes and, where applicable, the requirements of the Federal Information Processing Standard (FIPS) Cryptographic validation program(s).

The DoD Unified Capabilities (UC) Approved Products List was established in accordance with the UC Requirements (UCR 2013) document and mandated by the DoD Instruction (DoDI) 8100.04. Its purpose is to maintain a single consolidated list of products that have completed Interoperability (IO) and Cybersecurity certification. Use of the DoD UC APL allows DoD Components to purchase and operate UC systems over all DoD network infrastructures.

A NIAP certificate is a pre-requisite for listing a product on the UCAPL.

NIAP collaborates with DISA to eliminate redundancies in requirements documentation and test activities required for product certifications necessary for DoD procurement. Industry benefits from a more efficient and less expensive approval process, while the DoD gains a wide range of current COTS products available for procurement.

NIAP and DISA collaboratively develop DoD Annexes that define DoD configuration settings for NIAP-evaluated products.  NIAP Protection Profiles (PPs), in conjunction with the DoD Annexes, eliminate DISA Security Requirements Guides (SRGs) for NIAP-DISA aligned technologies.

Security Technical Implementation Guides (STIGs) may be developed by DISA as part of NIAP evaluations for aligned technologies.

The NSA/CSS Commercial Solutions for Classified (CSfC) Program enables evaluated commercial products on the NIAP Product Compliant List to be used in layered solutions to protect classified National Security System information. Layering evaluated products to form systems provides the ability to communicate securely based on commercial standards in a solution that can be fielded in months, not years.

Products that are evaluated in accordance with NIAP-approved Protection Profiles and CSfC-mandated selections and for which the vendor has signed a Memorandum of Agreement (MOA) are eligible for inclusion on the CSfC Components List.

Products on the CSfC Component List are categorized within one or more technology areas (canisters).

The list of CSfC canisters can be found at https://www.nsa.gov/Resources/Commercial-Solutions-for-Classified-Program/Components-List/.

The CSfC components list provides vendors the ability for their products to be used as part of layered solutions to protect National Security System information.

CSfC selections define the specific PP requirements that must be included as part of a Common Criteria evaluation for a product to be eligible for use in a CSfC solution.  The list of CSfC-mandated selections can be found at https://www.nsa.gov/Resources/Commercial-Solutions-for-Classified-Program/Components-List/.

Yes, NIAP recognizes evaluations conducted against NIAP approved Protection Profiles in other schemes per the Common Criteria Recognition Arrangement.

CSfC maintains a list of needed technology types at the following web page:  https://www.nsa.gov/Resources/Commercial-Solutions-for-Classified-Program/Components-List/.

A Protection Profile is an implementation-independent set of security requirements and test activities for a particular technology that enables achievable, repeatable, and testable evaluations.

NIAP requires exact conformance to PPs. However, individuals may submit a query to the applicable Technical Rapid Response Team (TRRT) for clarification on wording or intent of PP requirements or assurance activities.  Read more about TRRT:  http://niap-ccevs.org/Documents_and_Guidance/TRRT.cfm.  NIAP encourages representatives from industry, government, and academia to participate in Technical Communities to develop Protection Profiles, share knowledge, and influence requirements and test activities in PPs.

All current versions of all PPs are available on the NIAP web site at http://niap-ccevs.org/Profile/PP.cfm.

The sunset date is the date after which a new product evaluation can no longer be initiated against that version of the PP/EP.  When an updated PP or Extended Package (EP) is developed, the existing PP/EP will sunset and a transition period (generally 6 months) will be publicly posted. During the transition period, product evaluations will be allowed to comply with either the old or the updated version of the PP/EP.  For example, if a PP has a sunset date of May 1, no new evaluations can be initiated against that PP after May 1.

No.   A Product is only compliant with the version of the PP against which it was evaluated.  Depending upon the scope of the changes in the new version of the PP, a product may be updated to comply with the new PP through the Assurance Continuity process.

PPs are regularly updated to account for new security capabilities, address known vulnerabilities, and align with industry standards and best practice. Between versions, changes to PPs are documented as Technical Decisions (TDs) in response to issues submitted through NIAP Technical Rapid Response Teams (TRRTs).

A PP is a NIAP Protection Profile developed by a Technical Community overseen by NIAP.  While the Technical Communities that develop PPs can be international in scope, such PPs are considered U.S. PPs.  A collaborative Protection Profile is developed by an international Technical Community (iTC) under the oversight of the CCRA committees.  NIAP participates in iTCs to develop cPPs. The list of both NIAP PPs and cPPs eligible for use in NIAP evaluations is here.

NIAP creates and manages TCs composed of representatives from industry, government, and academia to create and maintain Protection Profiles (PPs). This collaborative effort leverages industry’s expertise, is international in scope, and fosters partnership between industry and government. To read more about TCs and for instructions on how to join one, go to https://www.niap-ccevs.org/NIAP_Evolution/tech_communities.cfm.

International Technical Communities are formed to produce and maintain collaborative Protection Profiles (cPPs) for use by all nations in the CCRA.  For further information, including how to join, go to http://www.commoncriteriaportal.org/communities/.