FailSafe R&D · QDay product

Post-quantum resilience extends our AI security and AI safety work.

QDay is a live FailSafe product and active R&D effort exploring how organizations can understand cryptographic dependencies, assess quantum-related risk, and prioritize resilience work. It extends our AI security and AI safety agenda to the cryptographic trust foundations of data, models, identities, and software.

Current research examines cryptographic inventory, long-term confidentiality, signature trust, and migration priorities. The scoring model shown here is an R&D framework, not a certification or security guarantee.

Harvest now, decrypt later

Encrypted traffic captured today may become readable if a cryptographically relevant quantum computer becomes available. The exposure depends on data sensitivity, how long it must remain confidential, and the cryptography in use.

Signature forgery

Quantum-vulnerable signing keys could undermine systems that trust their signatures, including certificates, software updates, and identity assertions. Inventory therefore includes trust and signing uses as well as confidential data.

QDay's current R&D model

Turn cryptographic observations into resilience priorities.

QDay's R&D organizes cryptographic inventory into three analytical layers. Each finding keeps evidence and provenance so teams can inspect the observations behind a resilience priority.

01 / QDAY R&D

Discover

Collect observations from network services, system configuration, source code and dependencies, key infrastructure, and asset inventories. Record where each observation came from and when it was made.

02 / QDAY R&D

Classify

Describe each cryptographic use by algorithm, purpose, data context, and migration status. A signing key, a TLS key exchange, and a symmetric data cipher carry different risks.

03 / QDAY R&D

Prioritize

Combine cryptographic strength with asset value, exposure, and remediation readiness. Roll findings up to services and business units while retaining the lowest-scoring items for review.

Five evidence sources under study

Network observations such as TLS and SSH handshakes; configuration files; source code and software dependencies; certificate authorities, HSMs, and KMS; and system-of-record feeds such as a CMDB or service catalog. QDay's R&D records what was observed, where it was found, how it was collected, and when it was made.

QDay R&D scoring framework

Prioritize resilience work, not certify safety.

QDay is exploring an evidence-weighted 0–100 model for prioritizing post-quantum resilience work. The research model combines four factors and keeps lower-level findings visible beneath organization-level rollups.

FactorWeightWhat it considers
Algorithm strength40%PQC-native, hybrid, or quantum-vulnerable
Asset value at stake30%Data sensitivity, lifetime, or signing trust
Attack surface20%Internet-facing, internal, or isolated
Remediation readiness10%Configuration change, upgrade, or redesign

90–100

PQC-ready

Monitor

70–89

Acceptable

Track and plan migration

40–69

At risk

Schedule migration

0–39

Critical exposure

Prioritize immediate review

These bands and weights describe one QDay R&D model. They are not a NIST standard, certification, or guarantee of quantum safety.

Illustrative QDay R&D scenario

One TLS endpoint, several different risks.

The scenario considers an internet-facing Apache server with anECDHE-RSA-AES256-GCM-SHA384TLS suite. QDay's research model classifies its ECDHE key exchange and RSA authentication as quantum-vulnerable public-key uses, while assessing the AES-256 and SHA-384 symmetric primitives separately. It weighs the endpoint's exposure, data context, and remediation readiness to produce an illustrative score of 34/100.

A candidate action is to evaluate a supported hybrid key exchange after the required library update. This scenario illustrates the R&D method, not a deployment instruction; compatibility, standards, and implementation guidance must be checked for each environment.

Standards context

Standards identify algorithms. Organizations still need an inventory.

NIST finalized three post-quantum cryptography standards in August 2024: ML-KEM for key establishment, and ML-DSA and SLH-DSA for digital signatures. QDay's R&D examines the operational work around those standards: finding where cryptography is used, what it protects, and how to sequence resilience work.

R&D boundaries

What this model does not establish

  • Discovery from network probes alone cannot reveal every cryptographic use inside an organization.
  • Asset value, data lifetime, and signing trust require context from system and business owners.
  • A score prioritizes investigation; it does not prove a system is quantum-safe or replace cryptographic review.
  • QDay's research model supports planning; implementation choices depend on the systems, standards, and cryptographic libraries in scope.

Active product research

QDay: Post-Quantum Resilience R&D

Dr. Ari Medvinsky, Chief Researcher · FailSafe R&D

QDay is an active FailSafe product and research effort. Its post-quantum work is one of FailSafe's R&D angles alongside our AI security and AI safety work, exploring cryptographic inventory, quantum-risk analysis, and resilience planning.

Questions & answers

Frequently asked questions

What QDay is and how its post-quantum resilience R&D extends FailSafe's AI security and AI safety work.

Yes. QDay is a live FailSafe product and active R&D effort. It extends our AI security and AI safety work into post-quantum resilience. The scoring framework shown here is an R&D model, not a certification or security guarantee.

QDay explores how organizations can inventory cryptographic dependencies, understand confidentiality and signature risks, and prioritize post-quantum resilience work. Its research model considers observations from network services, configurations, code and dependencies, key infrastructure, and asset records.

No. The score shown here is a prioritization model for R&D and planning. It depends on inventory coverage and asset context, and it is not a certification, cryptographic proof, or substitute for review by qualified cryptography and system owners.