What is post-quantum AI security?
Post-quantum AI security is the practice of preparing AI systems and the infrastructure around them — model APIs, data pipelines, vector databases, and enterprise integrations — for the cryptographic risks that future quantum computers may eventually pose. It involves identifying which cryptographic algorithms in an AI stack are quantum-vulnerable, migrating toward NIST-standardized post-quantum cryptography, protecting sensitive data before and after it enters AI systems, and building infrastructure that can swap cryptographic algorithms without a ground-up rebuild.
None of this depends on quantum computers being able to break encryption today. They can't, not at any scale that matters for enterprise systems. The reason to act now is more mundane: cryptographic migrations at enterprise scale take years, encrypted data collected today can still matter a decade from now, and AI has quietly expanded the number of systems that carry sensitive information through cryptographic channels most security teams haven't inventoried yet.
What Is Post-Quantum Cryptography?
Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to remain secure even against an attacker with a sufficiently capable quantum computer. The concern is narrower than it sounds. Quantum computing doesn't threaten all of cryptography equally — it threatens a specific mathematical category: public-key cryptography built on problems like integer factorization and discrete logarithms.
RSA and elliptic-curve cryptography (ECC) fall into that category. Both are used constantly in enterprise systems — TLS handshakes, VPNs, code signing, certificate authorities, API authentication. Their security rests on math problems that are extremely hard for classical computers to solve but that Shor's algorithm, running on a large enough fault-tolerant quantum computer, could solve efficiently. No such machine exists today. Building one that can attack real-world RSA-2048 or comparable ECC keys is still, by most expert estimates, years to decades away, and nobody can state that timeline with precision.
Symmetric cryptography is a different story. AES-256 doesn't rely on the same mathematical structure, and the best-known quantum attack against it (Grover's algorithm) only halves the effective key strength — which for AES-256 still leaves a workload well beyond anything practical. AES-256 is generally treated as quantum-resistant as it stands today. The urgency in PQC conversations is almost entirely about public-key cryptography, not symmetric encryption.
NIST finalized its first three PQC standards in August 2024, closing out roughly eight years of public evaluation:
- FIPS 203 (ML-KEM) — a module-lattice-based key-encapsulation mechanism, derived from CRYSTALS-Kyber. It's used for key establishment: the part of a protocol like TLS where two parties agree on a shared secret. ML-KEM is a replacement candidate for RSA and Diffie-Hellman/ECDH key exchange, not for encryption itself.
- FIPS 204 (ML-DSA) — a module-lattice-based digital signature algorithm, derived from CRYSTALS-Dilithium. It's a general-purpose signature standard intended to replace RSA and ECDSA signatures for things like certificates and code signing.
- FIPS 205 (SLH-DSA) — a stateless hash-based signature standard, derived from SPHINCS+. It's slower and produces larger signatures than ML-DSA, but its security rests only on hash function properties rather than lattice assumptions, which makes it a useful conservative fallback.
It's worth being precise here: only ML-KEM handles key establishment. ML-DSA and SLH-DSA are signature standards, not encryption algorithms. NIST has continued the process since — a fourth algorithm, HQC, was selected in 2025 as a backup key-encapsulation mechanism with a different mathematical foundation than ML-KEM, and a Falcon-based signature standard (FIPS 206) has moved through the pipeline as well. The standardization work is ongoing rather than finished in one release.
Why Post-Quantum Cryptography Matters for Enterprise AI
It's tempting to treat "AI security" and "PQC migration" as separate workstreams. They aren't, and treating them that way tends to leave gaps.
Every AI system an enterprise runs sits on top of ordinary infrastructure: TLS connections between services, API authentication, certificates for model-serving endpoints, encrypted storage for logs and cached results, identity systems that gate who can call an internal API. None of that infrastructure becomes exempt from cryptographic risk just because the workload happens to be a large language model instead of a CRM.
- What's changed is the surface area. A typical enterprise AI deployment now touches:
- Model APIs and inference endpoints, often across multiple vendors
- Data pipelines that move information from source systems into embedding and retrieval layers
- Vector databases storing embeddings generated from proprietary content
- Retrieval-augmented generation (RAG) systems that pull live enterprise data into model context
- Third-party integrations and plugins connected to internal tools
- Cloud storage and compute tied to model training or fine-tuning
- Identity and access infrastructure controlling who and what can query these systems
Each of these carries cryptographic dependencies — most of them classical, some of them long-lived. A cryptographic inventory that stops at the network perimeter and doesn't extend into the AI stack is an incomplete inventory. That's the practical reason PQC belongs in AI security conversations: not because AI introduces a new category of quantum risk, but because AI infrastructure has grown quickly enough that a lot of it hasn't been mapped yet.
What Is Harvest Now, Decrypt Later?
Harvest now, decrypt later describes a scenario where an adversary collects encrypted data today with the expectation of decrypting it once cryptographically relevant quantum computing capability exists, or once some other weakness is found. It works like this:
- An attacker intercepts or exfiltrates encrypted traffic or stored ciphertext now, while current public-key cryptography is still computationally infeasible to break.
- The attacker retains that ciphertext, betting on future advances — whether quantum computing or something else — that make decryption feasible later.
- If that capability eventually arrives, some of the historical ciphertext collected years earlier becomes readable.
- The risk is concentrated in data whose confidentiality needs to hold for a long time, since that's the only data still worth anything by the time decryption becomes possible.
Not every encrypted dataset carries this risk equally. A payment token that's meaningless after a transaction clears isn't a harvest-now target. Data with long confidentiality lifetimes is a different matter — think intellectual property and R&D data, unannounced M&A information, long-term financial records, healthcare records, government and defense information, trade secrets, and customer records an organization is contractually or legally obligated to protect for years. Organizations with this kind of data have a more immediate reason to start PQC migration planning, independent of when a cryptographically relevant quantum computer might actually exist.
Why Enterprise AI Embeddings Deserve Security Attention
An embedding is a numerical vector representation generated from source data — text, images, code, or other content — designed to capture semantic meaning in a form a model can compare and search efficiently. Enterprises generate embeddings for semantic search, RAG pipelines, recommendation systems, document retrieval, classification, and internal knowledge systems built on top of proprietary content.
Here's a distinction worth making precisely: an embedding is not simply an encrypted copy of the source document. It's a lossy, learned transformation optimized for a specific task — usually similarity comparison — not for reversibility. That means embeddings shouldn't be described as "encrypted corporate knowledge," because encryption implies a defined, reversible operation with a key. Embedding generation isn't that.
That said, "not encryption" doesn't mean "not sensitive." Research on embedding inversion has repeatedly demonstrated that under certain conditions — particularly when an attacker has query access to the embedding model or knowledge of its architecture — it's possible to reconstruct partial or approximate versions of the original input from its embedding. The degree of risk varies significantly depending on the model, the embedding dimensionality, and how much access an attacker has to the embedding function itself. It is not accurate to say every embedding can simply be converted back into its original document, and it's equally inaccurate to treat embeddings as inherently safe just because they're not human-readable. Vector representations of proprietary or personal data deserve the same access-control discipline as the source data they were built from.
Embedding Inversion and Quantum Risk Are Different Problems
This distinction gets blurred often enough that it's worth stating directly: embedding inversion and post-quantum cryptographic risk are not the same threat, and they don't sit on the same attack chain.
Embedding inversion is about information and data leakage from a vector representation — an attacker with the right access trying to reconstruct or infer something about the original input from its embedding. It's a machine learning security problem, tied to model architecture and access controls around the embedding function.
Post-quantum cryptographic risk is about the mathematical assumptions underlying public-key algorithms like RSA and ECC becoming solvable by a sufficiently powerful quantum computer. It's a cryptography problem, tied to key exchange, digital signatures, and the algorithms protecting data in transit and, in some cases, at rest.
A quantum computer breaking ML-KEM's cryptographic assumptions (hypothetically, since ML-KEM is designed specifically to resist that) wouldn't inherently reveal anything about the contents of a vector database — inversion requires its own separate access to the embedding function. Conversely, an embedding inversion attack doesn't require or benefit from a quantum computer at all; it's a present-day risk that exists regardless of the cryptography protecting the surrounding infrastructure.
Securing enterprise AI means addressing both where they're relevant to your architecture — but they call for different controls, owned in some organizations by different teams, and neither substitutes for the other.
How to Secure Vector Databases for AI Applications
Encryption is one layer of vector database security, not the whole answer. A reasonably complete approach covers:
- Encryption at rest for stored vectors and any associated metadata
- Encryption in transit between application layers, embedding services, and the vector store
- Access controls scoped to specific collections, indexes, or namespaces rather than blanket database access
- Identity and authentication integrated with the organization's broader IAM rather than a separate credential system
- Network isolation so vector database traffic isn't exposed to broader internal networks unnecessarily
- Tenant separation in multi-tenant deployments, so one customer's or business unit's vectors can't be queried across boundaries
- Key management with defined rotation and revocation processes
- Audit logging covering both administrative actions and query patterns, since unusual retrieval volume can itself be a signal of compromise
- Data minimization before embedding — the fewer sensitive fields that get vectorized in the first place, the smaller the exposure if the store is ever compromised
- Backup security, since backups often get less scrutiny than production stores despite holding the same data
- Retention policies that remove embeddings once the underlying business justification expires
- Cryptographic agility and PQC migration planning for the TLS and key-management layers surrounding the database, consistent with the organization's broader migration roadmap
No single control on that list does the whole job. A vector database encrypted at rest but with no access-control granularity, or one with tight access controls but embeddings generated from unredacted customer PII, both fail in different ways.
How to Implement Safe Data Vectorization for LLM Embeddings
A practical vectorization workflow looks something like this:
Source data → Classification → Sensitive-data identification → Redaction/anonymization where appropriate → Embedding generation → Secure vector storage → Access control → Retrieval monitoring → Secure output
A few of these steps deserve more explanation than they usually get:
Classification and sensitive-data identification should happen before anything gets near an embedding model. This is where an organization decides whether a document contains PII, PHI, financial identifiers, or other regulated categories, and routes it accordingly.
Redaction or data anonymization isn't a single technique — it ranges from removing specific fields to replacing identifiers with consistent tokens to more sophisticated transformations that preserve semantic utility while reducing identifiability. Reducing the sensitivity of what gets embedded reduces the consequences if that vector store, the embedding model's access controls, or a downstream system is ever compromised. It's a meaningful risk-reduction step. It is not, on its own, a guarantee that the resulting data is impossible to re-identify — that depends heavily on technique, context, and what other data an attacker might be able to correlate it against.
Retrieval monitoring is the step organizations skip most often. Logging what gets embedded is easy; logging and reviewing what gets retrieved, by whom, and in what volume is where actual misuse tends to surface.
What Does Quantum-Resistant Enterprise Infrastructure Look Like?
"Quantum-resistant infrastructure" gets thrown around as a marketing phrase more than it gets defined precisely. In practical terms, it describes an organization's progress through a migration program with these components:
- Cryptographic inventory — a documented record of which algorithms protect which systems, including AI infrastructure
- Algorithm discovery — tooling or process to find cryptographic dependencies that aren't already documented, which in most enterprises is a meaningful percentage of them
- PQC migration — the actual work of replacing quantum-vulnerable algorithms with NIST-standardized alternatives, prioritized by data sensitivity and system criticality
- Hybrid cryptography where appropriate, combining classical and post-quantum algorithms during the transition period
- Crypto-agility — architecture that allows algorithms to be swapped without rearchitecting the system around them
- Key management and certificate infrastructure capable of supporting new algorithm types and, in some cases, larger key sizes
- Coverage across APIs, cloud services, databases, AI infrastructure, and third-party vendor dependencies, since a migration that only covers internally-owned systems leaves the vendor supply chain exposed
The realistic framing is that PQC readiness is a migration program that unfolds over years, not a product an organization installs. Vendors claiming instant, complete "quantum-resistant" status for a complex platform should generally prompt a follow-up question rather than immediate confidence.
What Should Enterprises Look for in Quantum-Ready AI Infrastructure?
Buyers evaluating AI platforms and infrastructure vendors are increasingly asking about quantum readiness, and it's a fair question — but a vendor's marketing page answering "yes, we support PQC" isn't sufficient due diligence on its own. Worth evaluating:
- Whether the vendor has a documented cryptographic inventory covering their own infrastructure
- Whether there's a concrete PQC migration roadmap with dates, not just an intent statement
- Whether current cryptographic implementations follow modern, actively maintained standards
- Whether hybrid key exchange is supported where interoperability requires it
- How crypto-agility is actually implemented — can algorithms be swapped without a platform rebuild
- Whether APIs enforce strong authentication and encryption by default
- How identity and access controls are structured for both human users and service-to-service calls
- Whether data is isolated appropriately in multi-tenant environments
- How vector databases specifically are secured, given how much proprietary content often lives there
- What logging and audit capability is available to the customer, not just to the vendor internally
- What compliance frameworks the vendor maps to and how that's evidenced, not just claimed
- How transparent the vendor is about current limitations versus roadmap items
- How the vendor plans to handle long-lived sensitive customer data specifically
"Quantum-resistant" as a phrase on a website shouldn't be accepted at face value. It's reasonable to ask a vendor to show the inventory, the roadmap, and the specific algorithms in use rather than the adjective alone.
Post-Quantum Security for Enterprise Blockchain and Distributed Systems
Blockchain systems rely heavily on public-key cryptography — most commonly ECC-based signatures — to authenticate transactions and prove ownership of keys. That makes blockchain a relevant, if narrow, example within the broader PQC conversation.
Digital signatures on a blockchain prove a transaction came from the holder of a private key; if the underlying signature scheme were ever broken, transaction authenticity would be at risk. Key management on distributed systems is also harder to change retroactively than on centralized infrastructure, since public keys and addresses are often derived from the cryptographic scheme itself and embedded permanently in transaction history. And because blockchain assets are frequently long-lived by design, they intersect with the same harvest-now-decrypt-later logic as other long-confidentiality data.
This isn't a blockchain security article, and it shouldn't become one. The point is narrower: AI platforms, blockchain systems, and general enterprise applications frequently share the same underlying cryptographic libraries, key management practices, and public-key dependencies. A PQC migration program that treats these as unrelated efforts ends up duplicating work it didn't need to duplicate.
Cryptography in the AI Era: What Changes?
AI doesn't create a separate cryptographic universe with its own rules. What it does is increase the number of systems, data flows, and third-party dependencies an organization has to account for.
A typical enterprise AI deployment adds data pipelines connecting source systems to embedding services, distributed infrastructure spanning multiple cloud providers and often multiple model vendors, APIs and model endpoints that need their own authentication and encryption, vector databases as a new category of data store, and automated workflows — agents, in current terminology — that call multiple internal and external services without a human approving each step.
None of that requires new cryptographic primitives. It requires the same rigor applied to a larger, faster-changing footprint. Organizations that already run a mature cryptographic inventory program tend to fold AI infrastructure into it without much friction. Organizations that don't have that discipline tend to discover, usually during an audit or an incident, that nobody had mapped what the AI team stood up over the last eighteen months.
What Is Crypto-Agility and Why Does AI Infrastructure Need It?
Crypto-agility is the ability to replace a cryptographic algorithm, key size, or protocol version across a system without a fundamental rearchitecture. It sounds like a straightforward engineering property. In practice, most systems don't have it, because it's easy to hard-code assumptions about algorithm choice deep into application logic, API contracts, and data formats.
Here's a concrete version of the problem: if an organization builds its AI platform with a single cryptographic algorithm baked into every service-to-service call, every certificate, and every stored credential, replacing that algorithm later — whether because of a PQC migration or an unrelated vulnerability — can mean touching a large percentage of the codebase rather than updating a configuration value. A crypto-agile architecture separates the cryptographic mechanism from the systems that depend on it, so it can be upgraded with contained, predictable engineering effort instead.
For AI infrastructure specifically, that matters at the API gateway layer, in service-to-service communication between model-serving components, in certificate issuance and rotation, in key management for encrypted storage, in vector database connections, and across the cloud infrastructure the whole stack runs on. None of this makes an algorithm swap trivial or instant — that depends on the systems and interoperability constraints involved. What crypto-agility buys an organization is a bounded, plannable migration instead of an open-ended one.
Should Enterprises Use Hybrid Cryptography During PQC Migration?
Hybrid cryptography combines a classical algorithm (like ECDH) with a post-quantum algorithm (like ML-KEM) in the same key-exchange operation, so the resulting security depends on both remaining unbroken. It's a common approach during migration periods, for a few practical reasons: it preserves interoperability with systems that haven't yet adopted PQC, it hedges against the possibility — however unlikely current cryptanalysis suggests — that a newly standardized post-quantum algorithm has an undiscovered weakness, it provides defense in depth during a transition where confidence in the new algorithms is still building, and it allows organizations to migrate gradually rather than in one disruptive cutover.
There isn't a single hybrid architecture that fits every enterprise. The right approach depends on the specific protocols in use, vendor and library support, regulatory context, and interoperability requirements with partners and customers. Implementation should follow current IETF and NIST guidance and the specific recommendations of the cryptographic libraries an organization already relies on, rather than a generic template.
A Practical Enterprise PQC Migration Plan for AI
A realistic migration program tends to move through seven phases:
Phase 1: Discover. Build a cryptographic inventory covering the full stack, including AI infrastructure most organizations haven't mapped yet — model APIs, embedding pipelines, vector databases, and third-party AI integrations.
Phase 2: Classify. Identify which systems and datasets carry long confidentiality requirements. This is where the harvest-now-decrypt-later analysis actually gets applied to specific assets rather than treated as an abstract concern.
Phase 3: Prioritize. Focus first on systems that are both high-risk and hard to replace — legacy infrastructure with long lifecycles, systems protecting the longest-lived sensitive data, and dependencies with limited vendor support for modern cryptography.
Phase 4: Test. Evaluate PQC algorithms, libraries, and interoperability in non-production environments before committing to a rollout sequence. Performance characteristics — key size, signature size, computational overhead — vary meaningfully between ML-KEM, ML-DSA, and SLH-DSA, and matter differently depending on the system.
Phase 5: Migrate. Begin upgrading vulnerable cryptographic dependencies according to the prioritized sequence, using hybrid approaches where interoperability requires it.
Phase 6: Validate. Test performance, compatibility, and security of migrated systems under production-like conditions before full cutover.
Phase 7: Maintain. Build the crypto-agility that makes future transitions less painful, and keep monitoring NIST guidance and the broader standards landscape, since the standardization process is still active.
None of these phases is unique to AI infrastructure. What's different is that AI systems are new enough in most enterprises that Phase 1 alone often turns up gaps nobody expected.
Why Data Minimization Still Matters in a Post-Quantum World
PQC migration protects the cryptographic mechanisms guarding data. It doesn't reduce how much sensitive data exists in the first place, or how exposed that data is if a control somewhere else in the stack fails. That's a separate, complementary problem, and it's often the more immediately actionable one.
Data minimization means collecting and retaining only the data actually needed for a given purpose — the most direct form of exposure reduction, since data that was never collected can't be leaked.
Anonymization transforms data so individuals can no longer reasonably be identified from it. Done well, it can meaningfully reduce regulatory and breach exposure. It's also technically demanding to do well, and claims that a dataset is "fully anonymized" deserve scrutiny — re-identification research has repeatedly shown that supposedly anonymized datasets can sometimes be re-linked to individuals, particularly when combined with other available data.
Pseudonymization replaces identifying fields with consistent tokens or aliases, preserving the ability to link records for legitimate purposes (like analytics) without exposing the underlying identity directly. It's reversible with the right key, which makes it useful but not equivalent to anonymization for regulatory purposes.
Tokenization substitutes sensitive values with non-sensitive tokens, commonly used for payment data and similar structured, high-value identifiers.
Redaction removes or masks specific sensitive elements from a document or dataset entirely, typically the right choice when a field has no analytical value and only exists as a liability.
None of these techniques is a substitute for encryption, and encryption isn't a substitute for them either. The strongest posture applies both: encrypt what needs to travel and be stored, and reduce the sensitivity of what enters an AI system in the first place, so a future compromise — of a cryptographic assumption, a vector store, or anything else — has less to expose.
This is where Questa AI's approach fits into the broader picture. Questa AI is a privacy-first layer that sits between an organization's sensitive data and the AI systems processing it, anonymizing and redacting information before it reaches models, embeddings, or third-party AI tools. It's worth being precise about what that does and doesn't cover: Questa AI is not a post-quantum cryptography provider, and it doesn't implement quantum-resistant encryption or PQC key exchange. What it addresses is a different, complementary layer of the problem — reducing how much sensitive information is exposed to AI workflows in the first place, so that the data protected by an organization's broader cryptographic controls, PQC migration included, is data with less to lose if something downstream ever goes wrong. Cryptographic controls and data minimization aren't competing strategies. They protect different things, and a mature security posture needs both.
What Has Changed in Post-Quantum Security in 2026?
The most significant recent development remains NIST's August 2024 finalization of FIPS 203, 204, and 205 — that's still the anchor point for most enterprise migration planning. Since then, NIST has continued expanding the standard set, selecting HQC as a structurally different backup key-encapsulation algorithm in 2025 and advancing a Falcon-based signature standard through the pipeline, giving organizations more options as implementations mature.
On the regulatory side, momentum has been building without a single dedicated "post-quantum law" emerging. The EU's DORA framework, in force for financial entities since January 2025, requires cryptographic control policies that explicitly account for "quantum advancements" as part of the threat landscape organizations must monitor — without mandating specific PQC algorithms. The EU AI Act's cybersecurity requirements for high-risk systems use similarly technology-neutral "state of the art" language rather than naming PQC directly. U.S. national security systems, under NSA guidance, are working toward full PQC migration by 2030. None of this amounts to quantum computers threatening production systems today — it reflects regulators and standards bodies pushing organizations to have migration plans in place well ahead of any actual capability gap.
Cryptographic research continues to distinguish sharply between theoretical progress and demonstrated capability. Periodic announcements of quantum computing milestones are common, and it's worth reading them carefully: progress on qubit count or coherence time is not the same as a demonstrated attack against real-world RSA or ECC key sizes, and treating the two as equivalent tends to produce misleading headlines more often than useful signal.
