# NIAP and PQC: Common Criteria Protection Profiles **Source**: https://quantumsequrity.com/blog/niap-pqc-requirements **Category**: Compliance & Regulation --- [← Back to Blog](../../blog.html) Compliance & Regulation # NIAP and PQC: Common Criteria Protection Profiles 10 min read The National Information Assurance Partnership (NIAP) is the United States body that approves Common Criteria evaluations for products that go into National Security Systems and many federal civilian deployments. NIAP works through Protection Profiles (PPs) and Functional Packages (FPs), which describe what a product class has to do, and how an evaluator has to test it. As the post quantum transition has progressed, NIAP has been updating its Protection Profiles to either include or require ML-KEM, ML-DSA, and the rest of the algorithm catalog from [CNSA 2.0](cnsa-2-0-timeline-detailed.md). This article walks through how NIAP works, which Protection Profiles already touch post quantum cryptography, what the Functional Package for SSH and TLS look like with the new algorithms, and how a vendor should plan a NIAP submission with PQC support in mind. References point to niap-ccevs.org, which is the authoritative source. ## What NIAP Is and Why It Matters NIAP is a National Security Agency directed program that runs the United States piece of the Common Criteria Recognition Arrangement (CCRA). When a vendor wants its product certified to a NIAP approved Protection Profile, it submits the product, the evaluation laboratory tests it, NIAP issues the certificate, and the certificate is then recognized by the other CCRA member nations. For information technology procured into NSS, the federal acquisition language often requires either a current NIAP certificate or a clear path to one. In practice, the Department of Defense uses NIAP listings as gates on the Approved Products List. If your product needs to be sold to a DoD customer, and the relevant Protection Profile is currently on the NIAP list, then you need a NIAP certificate against that Profile. Without it, the contracting officer cannot accept delivery. ## The Protection Profile Library NIAP maintains a catalog of Protection Profiles at niap-ccevs.org. Profiles cover product classes, not individual products. Examples relevant to PQC include: - Protection Profile for Application Software (App PP) - Functional Package for Transport Layer Security (TLS Package) - Functional Package for Secure Shell (SSH Package) - Protection Profile for Network Devices (NDcPP) - Protection Profile for Mobile Device Fundamentals (MDF PP) - Protection Profile for Operating Systems (OS PP) - Functional Package for Cryptographic Module (where applicable) Each Protection Profile lists Security Functional Requirements (SFRs) the product has to satisfy. Cryptographic SFRs are stated in the FCS (Cryptographic Support) family and reference NIST FIPS standards or RFCs as the algorithm definitions. When NIST published FIPS 203, 204, and 205 in August 2024, NIAP began updating FCS clauses to allow or require those algorithms. ## How a Profile References an Algorithm A typical FCS_COP (cryptographic operations) clause specifies the operation, the algorithm, the key size, the mode, and a normative reference. For pre quantum cryptography, the reference points at FIPS 197 (AES), FIPS 186 (ECDSA), and FIPS 198 (HMAC). For post quantum, NIAP began adding references to FIPS 203 for ML-KEM and FIPS 204 for ML-DSA in 2024 and 2025 updates. A second clause, FCS_CKM (cryptographic key management), specifies key generation. For ML-KEM, the FCS_CKM clause references FIPS 203 Section 5 (key generation) and requires a NIST approved random number generator from SP 800-90A and 90B. For ML-DSA, FCS_CKM references FIPS 204 Section 5.1 and requires the same RNG hierarchy. The FCS_TLS clause in the TLS Functional Package was updated to permit hybrid key exchange combining a classical curve with ML-KEM, in line with the IETF draft on hybrid key exchange in TLS 1.3 (draft-ietf-tls-hybrid-design). Vendors implementing hybrid TLS must point at the relevant draft or RFC and demonstrate the wire format conforms. ## Functional Package for SSH and PQC OpenSSH 9.0 introduced sntrup761x25519, and OpenSSH 9.5 added support for hybrid key exchange. NIAP's SSH Functional Package was updated to allow these hybrid key exchange methods, alongside the classical curve25519-sha256 and ecdh-sha2-nistp384. A product claiming the SSH Package can list either the legacy classical algorithms only, or hybrid with ML-KEM, depending on the version of the package the product targets. For SSH host keys, ML-DSA based key types (such as ssh-mldsa-87 in some draft proposals) are not yet final in IETF. NIAP profiles tend to wait for IETF draft progress before requiring or permitting new SFR text, so SSH host key signing is still ECDSA P-384 or Ed25519 in current Functional Packages, with ML-DSA expected in a future revision. ## Functional Package for TLS and PQC The TLS Functional Package permits TLS 1.3 with the named groups for key exchange. The IETF draft draft-ietf-tls-hybrid-design defines named groups such as X25519MLKEM768 (which combines X25519 with ML-KEM-768) and SecP256r1MLKEM768. Browsers and TLS libraries shipped support for these in 2024 and 2025. The Functional Package update tracks the draft. A product evaluating against the latest TLS Package can claim hybrid named groups in its FCS_TLS_EXT.1 selection, and the evaluator will run wireshark or similar packet captures during testing to confirm the negotiated cipher suite and key share match the claim. ## Application Software Protection Profile The App PP version 1.4 and later specifies cryptographic SFRs for general purpose applications. The relevant FCS clauses cover: - AES-128 or AES-256 in GCM, CBC, or CTR mode - HMAC SHA-256, SHA-384, SHA-512 - RSA, ECDSA, or DSA digital signatures (legacy) - ECDH or DH key agreement (legacy) App PP updates in 2025 added ML-KEM and ML-DSA as optional algorithms. The selection language says "the application shall provide ECDH, ECDSA, RSA, ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, ML-DSA-87". Products claiming PQC support in the App PP must demonstrate the algorithms work, the keys are generated with an approved RNG, and the keys are stored in a protected manner per FCS_STG. ## Network Device Protection Profile The NDcPP version 2.2 and 3.0 governs routers, switches, firewalls, and similar network devices. Cryptographic SFRs cover IPsec (with IKE), TLS, SSH, and management protocols. The 3.0 series introduced PQC capable selections, including IKE with ML-KEM via the IETF draft draft-ietf-ipsecme-ikev2-mlkem. A network device claiming the latest NDcPP can include ML-KEM in IKE_INIT, and the FCS_IPSEC SFRs allow the evaluator to verify the algorithm with a known answer test (KAT) suite. NIST has published KAT vectors as part of the Cryptographic Algorithm Validation Program (CAVP), and the NDcPP references CAVP test vectors as the validation backstop. ## Mobile Device and Operating System Profiles MDF PP version 3.3 and OS PP version 4.3 are mobile and desktop OS profiles. Both have FCS clauses that reference cryptographic libraries provided by the OS. The current OS shipping in 2026 (Apple iOS / iPadOS, Android, Microsoft Windows, common Linux distributions) all include ML-KEM and ML-DSA implementations in their kernel cryptographic libraries. The Profile updates allow OS vendors to claim PQC support, and downstream applications can rely on the OS provided implementation. The validation evidence is the underlying CAVP certificate for the kernel module. ## How a Vendor Plans a NIAP Submission with PQC A vendor planning a 2026 or 2027 NIAP submission should: 1. Pick the latest version of the relevant Protection Profile that has PQC selections, not an older version. 2. Decide whether to claim PQC algorithms now or to add them in a follow up amendment. 3. Source FIPS 140-3 validated cryptographic modules that include ML-KEM and ML-DSA. Modules with CAVP certificates are not enough by themselves; FIPS 140-3 module validation is required when the Protection Profile says so. 4. Schedule lab time. NIAP labs are a finite pool, and labs that have done PQC test runs are even fewer. 5. Plan the security policy document and the Assurance Activity Report (AAR) so that PQC algorithm specifications match the Protection Profile language exactly. The submission timeline from kickoff to certificate is typically twelve to eighteen months. PQC adds time at the front end because lab procedures are still maturing and at the back end because NIAP technical reviewers are working through PQC specific questions for the first time. ## Common Criteria Recognition Arrangement Implications Once a NIAP certificate is issued, the Common Criteria Recognition Arrangement requires other CCRA member countries to recognize it for products evaluated to substantial assurance level (assurance components up to EAL 2 augmented). The CCRA includes most NATO members, Japan, Korea, Australia, India, and Singapore. PQC algorithms that NIAP recognizes through its Protection Profiles therefore become reciprocally recognized in those countries. Some countries maintain their own national schemes (BSI in Germany, ANSSI in France) and may require additional national specific evaluations on top of the recognized base. We cover the European angle in our [Common Criteria PQC article](common-criteria-pqc.md). ## Where the Bumps Are A few real world friction points are worth flagging. First, the App PP and NDcPP update cycles are not synchronous. A product that needs both an App PP claim and an NDcPP claim might find that one Profile permits ML-KEM and the other does not, in the same calendar quarter. Vendors should track NIAP update calendars closely. Second, hybrid key exchange in TLS and SSH depends on IETF drafts that are still evolving. NIAP cannot reference an unstable draft as normative. Until the relevant RFC publishes, NIAP language is necessarily conservative and may say "until the IETF finalizes draft-X, vendors may use draft-X version Y as evidence". This conservative wording can confuse procurement officers. Third, FIPS 140-3 modules with PQC support are still rare in 2026. The CMVP queue is long, and most major cryptographic modules are not yet validated with ML-KEM and ML-DSA. Vendors should pick a module supplier with a clear CMVP roadmap. Fourth, supporting documents (the technical guidance that accompanies a Protection Profile and tells the evaluator exactly how to test each SFR) lag the Protection Profile itself. A Profile may be updated in one quarter, but the supporting document with PQC test procedures may not appear until two or three quarters later. Vendors who try to evaluate against the new Profile before the supporting document is available may face evaluator improvisation that raises rework risk. Fifth, evaluator skill in PQC is uneven. Common Criteria evaluators are mostly trained on classical cryptography. Lattice based and hash based primitives have unfamiliar parameter selection, key sizes, and failure modes. Labs that have completed at least one PQC capable evaluation are better choices than labs running their first one. ## Documentation Templates Help The international iTCs publish template Security Target language and supporting document text. Vendors building their first PQC capable Common Criteria evaluation should use those templates as starting points rather than write from scratch. Reusing accepted text reduces the chance of evaluator pushback and shortens the technical review phase. The Network Devices iTC, the Application Software iTC, and the Mobile Devices iTC each maintain GitHub or vendor portal repositories with current draft and approved text. Engagement with the iTC mailing lists also helps vendors understand which questions evaluators are asking and how the answers are evolving. ## FAQ **Q: Is NIAP certification required for federal civilian sales?** A: NIAP is most strictly required for NSS. Federal civilian agencies often follow NIAP listings by policy or contract, but the exact requirement varies. Many civilian acquisitions allow FIPS 140-3 validation alone. **Q: Can I claim PQC support in a product that has not been evaluated yet?** A: You can advertise PQC support before evaluation, but the contractual force of a Protection Profile claim only attaches once NIAP issues the certificate. Customers writing PQC into procurement language usually require a current NIAP certificate or a binding submission date. **Q: What is a Functional Package versus a Protection Profile?** A: A Protection Profile is a top level definition for a product class. A Functional Package is a reusable bundle of SFRs (for example, TLS or SSH) that can be incorporated into multiple Protection Profiles. PQC updates often happen in Functional Packages first and propagate to Protection Profiles. **Q: Does my product need a separate NIAP submission for hybrid TLS versus pure PQC TLS?** A: No. The Protection Profile selections allow the product to claim either or both. The evaluator tests what the product claims. **Q: How long does NIAP evaluation take?** A: Twelve to eighteen months end to end is typical, with PQC capable products often at the longer end of that range. ## Sources 1. NIAP, Common Criteria Evaluation and Validation Scheme. https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/scheme-pub-1.cfm 2. NIAP, Protection Profile and Functional Package Library. https://www.niap-ccevs.org/Profile/PP.cfm 3. NIST, FIPS 203 and FIPS 204 (August 2024). https://csrc.nist.gov/pubs/fips/203/final and /204/final 4. IETF, draft-ietf-tls-hybrid-design (Hybrid Key Exchange in TLS 1.3). https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ 5. IETF, draft-ietf-ipsecme-ikev2-mlkem. https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/ 6. Common Criteria Recognition Arrangement. https://www.commoncriteriaportal.org ## Related Articles - [Common Criteria PQC](common-criteria-pqc.md) - [CNSA 2.0 Detailed Timeline](cnsa-2-0-timeline-detailed.md) - [NIST FIPS Guide](nist-fips-guide.md) - [Hybrid Encryption Explained](hybrid-encryption.md) - [PQC for Government and Defense](pqc-government-defense.md) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)