Post-Quantum Validation for Cloud-Native Firewalls
The first independent, AMTSO-registered methodology to validate NIST post-quantum cryptography standards in cloud-native firewalls. Up to 16 vendors. Three cloud platforms. GenAI and MCP server workload security. Results publish at the end of October 2026.
Two things are happening at the same time.
Federal procurement mandates are tightening. CISA’s January 2026 list named cloud-native firewalls among the product categories agencies must acquire only in post-quantum-enabled form. Federal agencies were due to file PQC transition plans in April 2026 under National Security Memorandum 10 (NSM-10) and OMB Memorandum M-23-02. NSA Commercial National Security Algorithm (CNSA) 2.0 compliance applies to new National Security System acquisitions from January 2027, with full NSS compliance due by 2033.
Every cloud-native firewall vendor will soon claim post-quantum readiness. Without independent empirical evidence, procurement teams cannot verify those claims. Vendor self-attestation is not a substitute for testing.
Until now, no published methodology purpose-built for cloud-native firewalls has tested PQC implementation, GenAI workload security, MCP server controls, and multi-cloud enforcement together — under reproducible conditions, on identical cloud infrastructure, with results scrutinizable by anyone.
How NIST post-quantum cryptography standards are validated at the firewall layer
The methodology tests vendor implementation of ML-DSA-65 and ML-DSA-87 for digital signature certificate signing, ML-KEM-768 and ML-KEM-1024 for key establishment, and SHA-384 and SHA-512 for integrity verification. Empirical evidence that vendor PQC claims operate correctly under enterprise cloud workloads — not vendor self-attestation.
Why cloud-native firewalls require a separate methodology
Existing firewall methodologies measure VM-based appliances at VPC perimeters: throughput, block rates, signature coverage. Cloud-native firewalls embed in the cloud control plane, enforce policy via API across Kubernetes clusters, and inspect east-west container traffic. Traditional firewall methodologies cannot evaluate these mechanisms.
What three validation pillars measure across vendors
Security Efficacy quantifies threat defense from application-layer attacks through advanced evasion and cloud post-exploitation — including PQC encryption support, GenAI workload protection, and MCP server security. Operational Efficiency evaluates IaC-driven deployment and DevSecOps integration across AWS, Azure, GCP, and Kubernetes. Compliance Validation maps enforcement to GDPR, HIPAA, PCI DSS, NIST 800-171, SOC 2, ISO/IEC 27001:2022, and Secure by Design/Default principles.
How GenAI inference and MCP server security are tested
Cloud environments increasingly host inference endpoints and AI agent frameworks. The methodology validates firewall capabilities against sensitive data submission to GenAI inference APIs, prompt injection via cloud LLM APIs, unauthorized GenAI service access, and Model Context Protocol (MCP) server security threats — including unauthorized MCP server access, data exfiltration via tool-call responses, lateral movement through tool chains, prompt-injection-driven tool hijacking, and credential leakage through MCP responses.
Why a solution needs both prevention and detection
A firewall that blocks an attack but produces no audit trail doesn’t earn a top score. The methodology measures both prevention (the threat is stopped) and detection (the event is logged with the metadata needed for audit and forensics). High scores require both — security enforcement and forensic visibility together.
Methodology Scope
The CNFW CyberRisk Validation evaluates solutions deployed across AWS, Azure, and GCP, including managed cloud-provider firewall services (AWS Network Firewall, Azure Firewall, GCP Cloud Firewall) and third-party containerized or agent-based firewalls for Kubernetes environments (EKS, AKS, GKE) and serverless workloads.
Validation covers:
- Threat Defense across 7 categories: application-based attacks, vulnerability exploitation, malware and botnet defense, browser-based threats, data loss and cloud storage leakage, container and serverless security, and GenAI workload security
- Policy Enforcement across 8 categories: stateful inspection, application control, geolocation, service and port control, web/URL filtering, IP/port control, TOR exit node control, and identity-aware policies
- 11 Advanced Evasive Techniques from protocol tunneling and encrypted payloads through polymorphic malware, living-off-the-land, and APT campaigns mapped to MITRE ATT&CK Cloud Matrix TTPs
- Cloud-Centric Post-Exploitation including credential harvesting via cloud metadata APIs (AWS IMDSv1/v2, Azure IMDS, GCP metadata), lateral movement through microservice APIs, and container-specific exploitation
- Encryption Capabilities covering 22 TLS 1.2 cipher suites, 3 TLS 1.3 cipher suites, TLS session reuse (Session ID and Session Ticket), and Quantum Safe Cryptography validation: ML-DSA-65 and ML-DSA-87 (digital signatures); ML-KEM-768 and ML-KEM-1024 (key establishment); SHA-384 and SHA-512 (integrity verification)
Vendors Under Validation
Current vendor list: Amazon Web Services, Aviatrix, Barracuda Networks, Cato Networks, Check Point Software Technologies, Cisco, Cloudflare, Fortinet, Google Cloud, Illumio, Juniper Networks, Microsoft, Netskope, NordLayer, Palo Alto Networks, Zscaler.
Vendors do not pay to participate, cannot influence the validation process, and cannot prevent publication of results.
Validation Timeline
|
Phase |
Date Range |
|---|---|
|
Expected Test Commencement |
June 1, 2026 |
|
Vendor Configuration Feedback |
July 10 – July 30, 2026 |
|
Validation Execution |
July 30 – September 19, 2026 |
|
Feedback and Dispute Resolution |
September 19 – October 10, 2026 |
|
Anticipated Results Publication |
October 29, 2026 |
AMTSO Test ID: AMTSO-LS1-TP195 (view test registration on AMTSO.org)
Non-Commissioned, Vendor-Neutral
SecureIQLab funds this validation independently. This is a non-commissioned validation — vendors do not pay to participate, cannot influence the validation process, and cannot prevent publication of results. Scoring changes from successful disputes apply to all vendors, not just the disputing vendor.
Aligned With Federal PQC Mandates and Enterprise Risk Frameworks
PQC scope aligns with NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) standards, the CNSA 2.0 / NIST IR 8547 compliance timeline, and CISA’s January 2026 PQC product-category guidance. Validation criteria map to MITRE ATT&CK (Cloud Matrix), STRIDE, OWASP Cloud-Native Guidelines, and CSA Cloud Controls Matrix. Compliance Validation covers GDPR, HIPAA, PCI DSS, NIST 800-171, SOC 2, ISO/IEC 27001:2022, and Secure by Design/Default principles.
AMTSO-Registered Methodology
This validation methodology complies with the Anti-Malware Testing Standards Organization (AMTSO) Testing Protocol Standard v1.3 and Test Plan Template v2.4. AMTSO Test ID: AMTSO-LS1-TP195. The AMTSO attestation is signed by David Ellis, VP of Research and Corporate Relations at SecureIQLab. Every vendor is validated under identical conditions on identical cloud infrastructure. The methodology is published in full. Anyone can examine the process.
Verify Vendor PQC Claims
Complete validation criteria, 4-tier scoring framework, 16-vendor scope, NIST post-quantum cryptography validation requirements, and the June – October 2026 timeline. Validation begins June 1 — review the methodology now so you know exactly what’s being measured.