AnonymousSign in
Start from a neutral baseline and add what matters to you. Criteria are labeled by source — the platform baseline is architecture-neutral; buyer-contributed criteria are shown separately.
This evaluation is stored in your browser only. We cannot see it, and it is not tied to any account. Save it to a link or create an account to keep it across devices — you can export it at any time either way.
Signing up adds sharing with your team, sending this as an RFP to vendors, and private document sharing. Nothing above is taken away, and nothing here is sent anywhere until you choose to.
Look for named, validated implementations of the finalized NIST standards — 'PQC-ready' without naming validated algorithms is marketing, not capability.
Migration can't start without knowing what to migrate; strong answers describe automated discovery across code, certificates, and protocols with a real coverage figure, not just a manual questionnaire.
Crypto-agility (algorithm swap as configuration, not re-engineering) is the core long-term value; a product hard-wired to today's algorithms just recreates the same migration problem later.
Hybrid modes are the current real-world deployment pattern — a product that only offers pure-PQC or pure-classical doesn't match how the transition is actually happening.
No buyer-contributed criteria yet
Verified buyers can suggest criteria (anonymized before pooling).
QKD requires dedicated physical infrastructure with hard distance limits and is rarely the right answer versus software PQC — be skeptical of QKD-led pitches that don't acknowledge this.
PQC keys/signatures are significantly larger than classical — strong answers give measured overhead figures on realistic workloads and disclose where it matters (e.g., high-volume TLS termination).
HNDL is the actual business driver for early migration; look for a data-lifetime-based prioritization methodology, not undifferentiated 'migrate everything now' urgency.
Look for honest treatment of the immature public-CA landscape — private-PKI-first support with a public-CA roadmap is the credible current answer.
PQC is a rapidly evolving space — a vendor with only a vague 'we're working on it' answer and no committed timeline creates real planning risk for a customer with regulatory PQC-migration deadlines.
Integration with existing PKI/HSM tooling is materially less disruptive than requiring an entirely new parallel infrastructure — ask for a concrete integration example, not just algorithm-level compatibility claims.
Given how early PQC adoption is industry-wide, a real production reference (versus only pilot/lab deployments) is a meaningful differentiator — press for specifics if the vendor only offers vague customer-count claims.
For government/defense-adjacent customers, alignment to a named regulatory PQC timeline (not generic 'quantum-ready' marketing language) is the real evaluation criterion.
Firmware/embedded crypto inventory is a distinct and much harder discovery problem than network-traffic-level discovery — a vendor should clarify this scope boundary explicitly rather than implying comprehensive discovery.
Algorithm standardization by NIST doesn't guarantee a specific vendor's implementation is bug-free — ask for independent validation of the actual implementation, a materially different and more specific claim than 'we use a NIST-standardized algorithm.'
Given PQC algorithm selection has already seen candidates broken during the standardization process itself, a vendor with no contingency plan for a similar future event is a real risk — ask for a concrete crypto-agility response plan, not just a general reassurance.
Real-world PQC migration will be gradual and uneven — ask specifically how the platform surfaces where a connection silently fell back to classical-only crypto rather than that happening invisibly.