Harvest now, decrypt later: post-quantum encryption reaches the data layer

Post-quantum cryptography (PQC) is encryption designed to withstand attack by quantum computers — and U.S. policy now requires it. The most important fact about the quantum threat is that it does not wait for a quantum computer. An adversary who exfiltrates encrypted files or records encrypted traffic today can hold that ciphertext until a cryptanalytically relevant quantum computer exists, then decrypt everything at once. The intelligence community calls this "harvest now, decrypt later," and it is the reason quantum-safe protection is a present-tense requirement rather than a future one.

The deadline, in other words, is set by your data’s lifespan, not by quantum hardware roadmaps. Weapons-system data, medical records, legal files, and intellectual property that must stay confidential for ten or twenty years need quantum-resistant protection now, because the harvest phase of the attack is already underway.

U.S. policy has been converging on this conclusion for four years, along two parallel tracks: a civilian track (NIST standards, OMB memoranda, CISA product guidance) and a National Security Systems track (NSA’s CNSA 2.0). The last eighteen months turned both from direction into requirement. On the civilian side, National Security Memorandum 10 (May 2022) set the goal of migrating vulnerable federal cryptography; OMB Memorandum M-23-02 (November 2022) and the Quantum Computing Cybersecurity Preparedness Act (December 2022) required agencies to inventory their quantum-vulnerable systems annually and prioritize migration. The technical foundation arrived in August 2024, when NIST finalized the first three post-quantum standards: FIPS 203 (ML-KEM, for key establishment), FIPS 204 (ML-DSA, for digital signatures), and FIPS 205 (SLH-DSA, a hash-based signature backup).

Executive Order 14144 (January 16, 2025) then moved PQC into procurement: it directed CISA to publish a list of product categories where PQC support is widely available, told agencies to move toward quantum-resistant key establishment, and required agency support for TLS 1.3 (or its successor) by January 2, 2030. Executive Order 14306 (June 6, 2025) amended its predecessor but deliberately sustained the post-quantum provisions — requiring CISA, in consultation with NSA, to release the product-categories list by December 1, 2025, and keep it updated. CISA published that list in January 2026, tiering categories by how widely PQC-capable products are available. The signal to vendors and buyers alike: quantum-safe support is becoming a line item in federal solicitations, category by category.

For National Security Systems and the contractors who support them, the authoritative definition of quantum-resistant is NSA’s Commercial National Security Algorithm Suite 2.0. CNSA 2.0 specifies ML-KEM-1024 for key establishment, ML-DSA-87 for general-purpose signatures, LMS and XMSS for software and firmware signing, AES-256 for symmetric encryption, and SHA-384/512 for hashing — the highest parameter sets of the NIST standards, not the baseline ones. The transition is phased by technology category, with new NSS acquisitions expected to be CNSA 2.0 compliant starting January 1, 2027, and the full transition culminating in 2033.

Two details matter for storage buyers. First, AES-256 is already on the quantum-resistant side of the ledger: a quantum computer running Grover’s algorithm halves the effective strength of a symmetric key, which is exactly why CNSA 2.0 requires 256-bit AES rather than 128-bit. Second, the quantum-vulnerable pieces are the asymmetric ones — the key exchanges and signatures that protect data in transit and software integrity — which is where the new NIST algorithms come in.

BrickStor SP’s cryptography maps cleanly onto that symmetric/asymmetric split. For data at rest, BrickStor SP encrypts with AES-256 validated under FIPS 140-3, with per-dataset keys and integrated KMIP key management — already the algorithm and key length CNSA 2.0 requires, on the current federal validation standard. For data in transit and administrative access, BrickStor SP uses OpenSSH and OpenSSL — and names matter here: OpenSSH added ML-KEM hybrid post-quantum key exchange in version 9.9 and made it the default in OpenSSH 10, and OpenSSL 3.5 added ML-KEM, ML-DSA, and SLH-DSA. Sessions negotiated with quantum-resistant hybrid key establishment are not harvestable ciphertext waiting for a quantum computer.

The platform is CNSA 2.0 compliant, and BrickStor CSfC DAR — the dual-layer classified data-at-rest variant — is expected to achieve its NSA CSfC Component listing in fall 2026, extending the same quantum-safe posture to classified missions. And because the cryptographic stack rides on OpenSSH and OpenSSL rather than proprietary implementations, the path forward is clean: as NIST and NSA guidance evolves, the algorithms evolve with the libraries, without waiting on a vendor’s bespoke cryptography roadmap.

Post-quantum cryptography answers one question: if an adversary obtains your ciphertext, can they ever read it? That is essential, and it is not sufficient. Harvest-now-decrypt-later is, at bottom, an exfiltration problem — the harvest only works if the adversary gets the data out. A storage platform that detects bulk reads and staged exfiltration on live production data, enforces attribute-based least privilege on every SMB, NFS, S3, and Web Drive operation, and keeps an immutable per-operation audit record attacks the harvest itself, not just the later decryption. That is what Active Defense does inline in the data path.

The audit record carries a second dividend: if a harvest is suspected, an immutable per-operation record tells you exactly which files were read, by whom, and when — the difference between a scoped disclosure and a worst-case assumption. The complete posture for long-lived sensitive data is both layers together: quantum-resistant cryptography so captured data stays sealed, and Cyberstorage so far less of it is captured in the first place.