Skip to content
Glossary

Quantum-Safe AI: Post-Quantum Cryptography for AI

How post-quantum cryptography (ML-KEM, ML-DSA) protects training data, model weights and AI interfaces against harvest now, decrypt later.

Definition: Quantum-safe AI means securing AI systems with cryptographic methods that will hold up against future quantum computers. This covers training data, model weights, interfaces and the traffic between AI agents. At its core, it means moving to post-quantum cryptography (PQC) wherever AI systems now rely on RSA or elliptic curves.

The threat: quantum computers and public-key cryptography

A strong enough quantum computer running Shor's algorithm could break the public-key schemes in wide use today:

  • RSA
  • Diffie-Hellman
  • elliptic curves (ECDH, ECDSA)

These schemes secure key exchange in TLS and VPNs. They also secure digital signatures. Symmetric encryption such as AES is less affected. With long enough keys, such as AES-256, it still counts as secure.

Nobody knows when such quantum computers will exist. The problem matters today anyway because of "harvest now, decrypt later". Attackers record encrypted traffic now and decrypt it later. Anything that must stay confidential for many years is already at risk.

What this means for AI systems

  • Training data: health records, HR files, engineering data or customer histories are sent for training or fine-tuning. They often need protection for a long time. If they go to a cloud service over classic TLS today, attackers may decrypt them in the future.
  • Model weights: a model you have trained or fine-tuned is intellectual property. It may also hold facts from its training data. Weights must stay confidential when they move between data centre, cloud and edge devices.
  • Integrity of models and software: model files, container images and updates are signed so that tampering can be detected. If the signature schemes are broken, attackers could pass off a tampered model as genuine. This is a special concern for devices with AI features that stay in use for many years, for example in factories or medical tech.
  • AI interfaces and agents: prompts and responses often hold confidential business data. AI agents reach databases and third-party systems via APIs. They sign in with certificates or tokens, and these rely on public-key cryptography.

Not each AI project faces the same risk. An internal chatbot that handles short-lived data needs less protection than a model trained on twenty years of patient data.

The new standards

In August 2024 the US National Institute of Standards and Technology (NIST) published the first three PQC standards:

  • FIPS 203 (ML-KEM): key encapsulation for key exchange, derived from CRYSTALS-Kyber.
  • FIPS 204 (ML-DSA): lattice-based digital signatures, derived from CRYSTALS-Dilithium.
  • FIPS 205 (SLH-DSA): hash-based signatures, derived from SPHINCS+. Its security assumptions are more conservative, but its signatures are larger.

Germany's Federal Office for Information Security (BSI) advises using PQC in hybrid mode at first, together with a classic algorithm. The connection then stays secure even if one of the two later turns out to be weak. For TLS, the pair X25519 and ML-KEM is already available in common browsers and libraries.

Practical steps

  1. Build a cryptography inventory: Find out where your AI pipelines use crypto. Look at data transfer to cloud services, model storage, signatures, API sign-in and service account certificates.
  2. Assess protection lifetime: Prioritise data and models that must stay confidential for more than about ten years.
  3. Establish crypto-agility: Make algorithms easy to swap instead of hard-coding them. This makes any future move easier.
  4. Enable hybrid schemes: Where load balancers, reverse proxies and libraries support it, turn on hybrid key exchange for AI interfaces and data transfers.
  5. Encrypt data at rest with strong symmetric keys: Encrypt training data and model weights with AES-256. Manage keys in an HSM or a key management service.
  6. Involve your providers: Ask AI and cloud providers about their PQC roadmap. Include it when you assess your suppliers.

Regulatory context

NIS2 requires policies on the use of cryptography and encryption as part of risk management. In Germany, this applies to entities in scope through the BSIG. Art. 32 GDPR calls for measures that reflect the state of the art. Neither rule currently forces a move to PQC. But both set the expectation that you assess known risks such as "harvest now, decrypt later".

Conclusion

Quantum-safe AI is not a product in itself. It means applying post-quantum cryptography to all data and model flows of AI systems. Organisations that build an inventory and invest in crypto-agility now can migrate step by step, without time pressure. SecTepe supports cryptography inventories and prioritisation as part of your ISMS.

Frequently asked questions

Do I need to act now?

For data that needs long-term protection, yes. At least build an inventory and a plan. For short-lived data, it is enough to plan the move as part of your regular tech update cycle.

Are AI models themselves threatened by quantum computers?

Not the models as such. The threat is to the cryptography that protects their confidentiality and integrity in transit, at rest and through signatures.

More terms in “AI & Machine Learning”

All terms in “AI & Machine Learning” →