Skip to main content

Services · Post-quantum migration

We inventory your cryptography, then migrate your data to post-quantum cryptography.

Two scoped engagements. Written scope before work starts, a runbook at handover. Plaintext, keys, and passwords never leave your infrastructure.

Engagements 2 live
Typical start 2–4 weeks
Deliverables Written
Data leaves site Never

Two engagements, scoped to your data

01 · Live now

PQC Readiness Assessment

A fixed-scope consulting engagement. We inventory your crypto, rank the risk, and hand you a written remediation roadmap. Your production systems are not touched.

2–4 weeks · Fixed scope · Contact for quote
  • Crypto inventory across GPG/PGP, X.509 (PEM/DER), PKCS#12, PKCS#7, PKCS#8, Java Keystore, SSH & PuTTY keys, S/MIME, encrypted databases & archives.
  • Risk-ranked from Critical (RSA, ECDSA) through Safe (already PQC).
  • HNDL exposure map: what data, how long it lives, which systems will break first.
  • Systems covered by NIST IR 8547 deprecation timelines and the CNSA 2.0 Jan 2027 mandate.
  • Deliverables: inventory report, written roadmap, effort estimates, optional MaaS scope document. See a real sample of the scan evidence.
Request assessment
02 · Live now

Migration as a Service

A longer consulting engagement: we design, pilot, stage-roll, validate, and hand over the post-quantum migration of a scoped data surface. Your team runs it the day after handover.

Pilot → staged rollout · Written scope · Contact for quote
  • Design: target algorithms per data class, key hierarchy, rollback plan, staging order.
  • Pilot on one data store or tier. Pilot must pass KAT validation before we scale.
  • Staged rollout in named waves, per-wave rollback documented.
  • Validation: known-answer tests against NIST ACVP vectors where applicable. Third-party crypto review available as an add-on.
  • Handover: runbook, rollback plan, test vectors, on-call window. Scope: data at rest on storage you control. In-place database TDE rekeying is a separate engagement (see below).
Discuss scope
03 · On roadmap

Database Migration to PQC

In-place TDE and column-level key-envelope re-wrapping for transactional and analytical stores. Pilot customers being scoped now.

Targets: PostgreSQL, MySQL, SQL Server, Oracle · Pilot waitlist open
  • Move RSA-wrapped DEKs to hybrid ML-KEM + X25519. Data stays on AES-256-GCM.
  • Per-store rollback, staged cutover, KAT validation of re-wrapped keys.
  • Discovery of DB key material on disk is covered by the Readiness Assessment today.
Join pilot waitlist
04 · On roadmap

Cold Storage PQC

Re-envelope long-retention archives for 10+ year horizons without a full decrypt/re-encrypt round trip.

Targets: S3 Glacier, Azure Archive, tape · Pilot waitlist open
  • Key envelope re-wrapped with hybrid ML-KEM + X25519. Payload stays AEAD (AES-256-GCM).
  • BLAKE3 + Merkle chain of custody per object.
  • Focus: Harvest-Now-Decrypt-Later exposure on data retained longer than the crypto.
  • Manual re-envelope workflows using qnsqy encrypt are already available under MaaS.
Join pilot waitlist
Crypto core Same primitives as the product: FIPS 203/204/205, hybridized.
Data handling We don't move plaintext, keys, or passwords off your systems. Ever.
Lock-in Runbooks are QNSQY commands you can execute yourself after handover.
Scope Written before work starts. No open-ended retainers.

Why now

Three published standards documents set the clock. Any organization with long-lived data or long-lived deployments is already inside the migration window.

01 · CNSA 2.0

New NSS deployments must be PQC by January 2027

NSA Commercial National Security Algorithm Suite 2.0 targets January 2027 for all new National Security System deployments to use CNSA 2.0 algorithms (ML-KEM, ML-DSA, LMS/XMSS, SHA-384, AES-256). Classical-only deployments after that date are out of policy.

Source: NSA Cybersecurity Advisory, Announcing the Commercial National Security Algorithm Suite 2.0, Sep 2022.

02 · SP 800-131A Rev 3

Classical key-establishment is deprecating

NIST SP 800-131A Rev 3 (public draft) defines the schedule on which classical key-establishment and signature algorithms move from acceptable to deprecated to disallowed. Vendors selling into federal or regulated buyers follow this document.

Source: NIST SP 800-131A Revision 3 (initial public draft), Transitioning the Use of Cryptographic Algorithms and Key Lengths.

03 · NIST IR 8547

The official PQC transition plan

NIST IR 8547 (initial public draft) lays out the transition from classical to post-quantum standards, including deprecation milestones for RSA, DH, ECDH, and ECDSA.

Source: NIST IR 8547, Transition to Post-Quantum Cryptography Standards, Nov 2024.

04 · HNDL

Data stolen today, readable tomorrow

Ciphertext captured today under RSA or ECDH key agreement is on the clock. A cryptographically relevant quantum computer retroactively reads all of it. Retention windows over ten years are the first to re-encrypt.

Further reading: Harvest Now, Decrypt Later on this site, and NIST IR 8547 §3.

How an engagement runs

01

Intro call

30 minutes. Map your data, retention, and regulatory drivers against the engagements above. Pick a starting point.

02

Written scope

Scope, deliverables, acceptance criteria, and price in writing before any work starts.

03

Pilot

Every MaaS engagement starts with a pilot on one store or one archive tier. Pilot must pass KAT validation before we scale.

04

Staged rollout

Expand from pilot to full surface in named waves. Per-wave rollback documented.

05

Validation

Known-answer tests, cross-check against NIST ACVP vectors where applicable. Third-party crypto review available as an add-on for MaaS.

06

Handover

Runbook, rollback plan, test vectors, and a defined on-call support window. Your team runs the system without us the day after handover.

Common questions

No. The qnsqy CLI and the migration tooling run where your data already lives. Plaintext, keys, and passwords never leave your infrastructure. Deliverables are inventory reports, runbooks, and test vectors - not your data.
Key wrapping: hybrid ML-KEM + X25519 (FIPS 203 + classical ECDH). Signatures: hybrid ML-DSA + Ed25519 (FIPS 204 + classical EdDSA). Bulk: AES-256-GCM or XChaCha20-Poly1305. Password-derived keys: Argon2id. Algorithm choice is configurable per data class.
MaaS engagements are written against the CNSA 2.0 algorithm set targeting the January 2027 new-deployment milestone. Non-NSS organizations still benefit: CNSA 2.0 overlaps with NIST FIPS 203, 204, and SP 800-208.
Readiness is 2–4 weeks, fixed scope, zero changes to production. It outputs a written roadmap. MaaS is longer, changes production under a pilot-then-staged-rollout protocol. Most customers start with Readiness and use the roadmap as the MaaS scope input.
Not for discovery or assessment work. For implementation we work inside your change-management using your existing identities and audit trail. We don't hold long-lived production credentials.

Start with a 30-minute call

Describe your data, your retention window, and your regulatory drivers. We respond with a written scope and a price before any work begins.