NIST Post-Quantum Cryptography Standards: ML-KEM, ML-DSA, SLH-DSA, and What Comes Next

Andrei Olin

NIST has finalized three principal post-quantum cryptography standards and not four “quantum-safe encryption algorithms.”

The distinction matters.

FIPS 203 specifies a key-encapsulation mechanism for establishing shared secrets. FIPS 204 and FIPS 205 specify digital-signature algorithms for authentication and integrity. A fourth algorithm, FN-DSA, formerly known as Falcon, was selected by NIST but remains in development as FIPS 206.

For organizations operating Managed File Transfer and enterprise data exchange environments, these standards provide a practical foundation for planning the transition away from quantum-vulnerable public-key cryptography.

In Summary

In August 2024, the National Institute of Standards and Technology finalized its first three principal post-quantum cryptography standards:

  • FIPS 203: ML-KEM, a key-encapsulation mechanism used to establish shared secrets
  • FIPS 204: ML-DSA, a lattice-based digital-signature algorithm
  • FIPS 205: SLH-DSA, a hash-based digital-signature algorithm

These standards address two different cryptographic functions: key establishment and digital signatures. They should not collectively be described simply as encryption algorithms.

NIST also selected FN-DSA, derived from Falcon, for future standardization as FIPS 206. In addition, NIST selected HQC in 2025 as a second post-quantum key-encapsulation mechanism based on different mathematics from ML-KEM. Neither is currently one of the three finalized principal FIPS standards.

Organizations should begin preparing now by identifying quantum-vulnerable cryptography, prioritizing information with long confidentiality requirements, evaluating vendor and partner readiness, testing interoperability, and building cryptographic agility into their architecture.

Key Takeaways

  • NIST has finalized three principal post-quantum cryptography standards: FIPS 203, FIPS 204, and FIPS 205.
  • ML-KEM establishes a shared secret that can be used by symmetric encryption; it does not directly encrypt an enterprise file by itself.
  • ML-DSA and SLH-DSA provide digital signatures rather than data encryption.
  • FN-DSA was selected for standardization but remains under development as FIPS 206.
  • HQC was selected as an additional key-encapsulation mechanism and is intended to diversify NIST’s portfolio.
  • Post-quantum migration requires changes to protocols, certificates, applications, products, partner connections, and operational procedures—not merely an algorithm substitution.
  • Cryptographic inventory, data-lifecycle analysis, interoperability testing, and crypto-agility are the practical starting points.

What Did NIST Actually Standardize?

NIST’s current post-quantum portfolio includes three finalized principal standards covering key establishment and digital signatures.

This terminology is important because encryption, key establishment, and digital signatures perform different jobs.

A key-encapsulation mechanism allows two parties to establish a shared secret over a public channel. That secret can then be used with symmetric cryptography to encrypt and authenticate information.

A digital signature allows a recipient to verify the origin and integrity of information. It does not make the information confidential.

Why Is “Four Quantum-Safe Encryption Algorithms” Inaccurate?

In 2022, NIST announced four candidates selected for eventual standardization:

  • CRYSTALS-Kyber
  • CRYSTALS-Dilithium
  • SPHINCS+
  • Falcon

Those selections were subsequently developed under standardized names:

  • CRYSTALS-Kyber became ML-KEM.
  • CRYSTALS-Dilithium became ML-DSA.
  • SPHINCS+ became SLH-DSA.
  • Falcon is being developed as FN-DSA.

However, only the first three became finalized FIPS standards in August 2024. NIST’s PQC standardization page identifies FIPS 206 for FN-DSA as still in development.

Calling all four encryption algorithms is also technically imprecise. ML-KEM supports key establishment, while ML-DSA, SLH-DSA, and FN-DSA are digital-signature algorithms.

A more accurate description is:

NIST has finalized three principal post-quantum cryptography standards and is developing additional algorithms to provide alternatives and cryptographic diversity.

FIPS 203: What Is ML-KEM?

ML-KEM, or the Module-Lattice-Based Key-Encapsulation Mechanism, is NIST’s principal post-quantum standard for establishing shared secrets.

It is derived from CRYSTALS-Kyber and is based on the computational difficulty of the Module Learning with Errors problem.

ML-KEM allows two parties communicating over a public network to establish shared secret material. That shared secret can then be processed into keys used by symmetric algorithms for encryption and authentication.

FIPS 203 specifies three parameter sets:

  • ML-KEM-512
  • ML-KEM-768
  • ML-KEM-1024

The appropriate parameter set depends on security, interoperability, and performance requirements.

Where ML-KEM May Be Used

ML-KEM may eventually become part of cryptographic negotiations supporting:

  • TLS and HTTPS
  • Secure APIs
  • VPNs
  • Cloud-service connections
  • Application-to-application communication
  • Managed File Transfer sessions
  • Other protocols that currently depend on RSA or elliptic-curve key establishment

Implementation still depends on support within the relevant protocols, software libraries, products, certificates, hardware, and partner environments. Publishing a standard does not automatically upgrade every existing connection.

FIPS 204: What Is ML-DSA?

ML-DSA, or the Module-Lattice-Based Digital Signature Algorithm, is NIST’s principal post-quantum digital-signature standard.

It is derived from CRYSTALS-Dilithium and uses lattice-based mathematics.

ML-DSA can help verify:

  • Who or what signed information
  • Whether signed information changed after signing
  • Whether software, data, or a message came from an expected signer

Potential enterprise uses include:

  • Document signing
  • Software and code signing
  • Certificate-related processes
  • Application authentication
  • Signed transactions
  • Business-partner authentication
  • File and message integrity verification

ML-DSA does not encrypt file contents. It provides authenticity and integrity through digital signatures.

FIPS 205: What Is SLH-DSA?

SLH-DSA, or the Stateless Hash-Based Digital Signature Algorithm, is derived from SPHINCS+.

Unlike ML-DSA, SLH-DSA relies on hash-based cryptography rather than structured lattices.

This gives NIST’s signature portfolio mathematical diversity. If a future cryptanalytic discovery affects one family of algorithms, organizations may have an alternative based on substantially different security assumptions.

SLH-DSA generally involves different signature-size and performance tradeoffs from ML-DSA. Organizations should evaluate those characteristics against their specific applications, transaction volumes, network constraints, and verification requirements.

What Is the Status of FN-DSA?

FN-DSA is a digital-signature algorithm derived from Falcon.

NIST selected Falcon during its original post-quantum competition because its relatively compact signatures may be useful in bandwidth-sensitive or storage-constrained environments.

However, FN-DSA is not currently one of the three finalized principal standards. NIST identifies it as a future standard under development as FIPS 206.

Organizations may monitor FN-DSA and evaluate its potential use cases, but production migration decisions should distinguish clearly between finalized standards and algorithms that remain in the standardization process.

What Is HQC?

In March 2025, NIST selected HQC for standardization as an additional key-encapsulation mechanism.

HQC is based on code-based cryptography, while ML-KEM is lattice-based. This difference provides cryptographic diversity within the key-establishment portfolio.

NIST expects ML-KEM to remain the primary KEM for most applications. HQC is intended to provide an alternative based on different mathematical assumptions.

HQC has been selected, but it has not yet replaced ML-KEM or become another finalized principal FIPS standard.

Do These Standards Replace AES-256?

No.

AES is a symmetric encryption algorithm. ML-KEM, ML-DSA, and SLH-DSA perform different functions:

  • ML-KEM: Establishes shared secret material
  • ML-DSA: Creates and verifies lattice-based digital signatures
  • SLH-DSA: Creates and verifies hash-based digital signatures
  • AES: Encrypts and decrypts data using a shared symmetric key

A post-quantum architecture may use ML-KEM to establish key material and AES to encrypt the actual session or file data.

Quantum algorithms affect symmetric and public-key cryptography differently. Shor’s algorithm creates the principal concern for widely used RSA and elliptic-curve systems. Grover’s algorithm provides a theoretical quadratic speedup for certain search problems, but it does not make strong symmetric encryption instantly useless.

This is one reason AES-256 commonly remains part of post-quantum security planning.

What Quantum Computers Do, and Do Not Do

Quantum computers do not literally test every password simultaneously and then reveal the correct one.

Quantum algorithms use superposition, entanglement, interference, and measurement to increase the probability of obtaining useful results for particular mathematical problems. They are not automatically faster for every computing task.

The primary cryptographic concern is that a sufficiently capable quantum computer running Shor’s algorithm could solve the factoring and discrete-logarithm problems underlying widely deployed RSA and elliptic-curve cryptography much more efficiently than known classical methods.

Quantum entanglement should also be described carefully. Entangled systems exhibit correlations that classical physics cannot reproduce in the same way. However, entanglement cannot be used to transmit usable information faster than light, as NIST’s quantum guidance explains.

These distinctions matter because accurate explanations help organizations prioritize genuine cryptographic risks without treating quantum computing as a universal or magical attack mechanism.

Why Do the NIST Standards Matter for Managed File Transfer?

Managed File Transfer platforms frequently depend on public-key cryptography for:

  • Establishing protected sessions
  • Authenticating servers and clients
  • Managing certificates
  • Verifying digital signatures
  • Protecting API connections
  • Exchanging keys
  • Establishing trust with external partners

They may also process information that must remain confidential for many years, including:

  • Healthcare records
  • Financial information
  • Government data
  • Legal documents
  • Intellectual property
  • Engineering designs
  • Research data
  • Personally identifiable information

An attacker could collect encrypted information today and retain it in the hope that future computing capabilities make decryption possible. This risk is commonly called harvest now, decrypt later.

Organizations should therefore consider both sides of the risk equation:

  1. How long must the information remain confidential?
  2. How long will it take to update the systems, protocols, vendors, and partners protecting it?

If those periods approach the estimated time before cryptographically relevant quantum computers become available, the organization may already have a migration risk.

Post-Quantum Migration Is More Than Algorithm Replacement

A cryptographic algorithm is only one component of a secure enterprise exchange.

Post-quantum migration may affect:

  • TLS and SSH implementations
  • SFTP and HTTPS connections
  • AS2 and AS4 deployments
  • APIs
  • Certificates and public-key infrastructure
  • Cryptographic libraries
  • Hardware security modules
  • Key-management systems
  • Cloud platforms
  • Identity systems
  • Digital-signature workflows
  • Software-signing processes
  • MFT products
  • Partner endpoints
  • Monitoring and audit systems

Changing one algorithm without updating the surrounding protocols and trust infrastructure does not complete the migration.

Organizations must also account for larger keys or signatures, processing requirements, certificate compatibility, network overhead, implementation maturity, partner readiness, and operational recovery.

How Should Organizations Begin Applying the NIST Standards?

The availability of finalized standards allows organizations to move from general preparation toward implementation planning.

The immediate objective is not to replace every cryptographic mechanism at once. It is to determine where the new standards apply, validate support across the complete ecosystem, and test them without disrupting critical business processes.

1. Map Each Standard to the Correct Cryptographic Function

Identify workflows that depend on public-key cryptography and determine which function they require:

  • ML-KEM for establishing shared secret material
  • ML-DSA for general-purpose post-quantum digital signatures
  • SLH-DSA when a hash-based signature alternative is appropriate
  • Symmetric encryption such as AES for encrypting the actual session or file data

This analysis should cover TLS, SSH, certificates, APIs, file-signing processes, software libraries, MFT connections, and partner integrations.

The purpose is not simply to find RSA or elliptic-curve cryptography. It is to understand what each existing mechanism does before selecting its eventual replacement.

2. Verify Product, Protocol, and Partner Support

A standardized algorithm can protect a production exchange only when every required component supports it.

Organizations should confirm:

  • Which finalized NIST standards the product supports
  • Which product version provides that support
  • Whether the implementation is production-ready or experimental
  • Which protocols and workflows can use it
  • Which parameter sets are supported
  • Whether clients, servers, libraries, certificates, and hardware are compatible
  • Whether external partners can negotiate the same configuration
  • How the selected cryptography is recorded for auditing

A statement that a product “supports post-quantum cryptography” is not specific enough. The relevant question is which algorithm, cryptographic function, protocol, configuration, and product version it supports.

3. Pilot Complete Business Workflows

Testing should validate the entire exchange rather than demonstrating that an individual algorithm works.

A meaningful MFT pilot should evaluate:

  • Session establishment
  • Authentication
  • File signing and verification
  • Certificate and key handling
  • Transaction throughput
  • Network and processing overhead
  • Partner interoperability
  • Failure recovery
  • Monitoring and audit visibility
  • Configuration rollback
  • Downstream application processing

The objective is to prove that post-quantum cryptography can be introduced without breaking the business process it is intended to protect.

For the broader preparation roadmap, read Quantum Computing, Post-Quantum Cryptography, and Managed File Transfer. For detailed guidance on inventories, hybrid migration, and architectural flexibility, read Crypto-Agility for Post-Quantum Readiness.

Are Post-Quantum Requirements Already Mandatory?

There is no single universal mandate requiring every private organization to adopt post-quantum cryptography on the same date.

FIPS requirements apply to U.S. federal information systems in applicable contexts, while obligations for private-sector organizations depend on jurisdiction, industry, contracts, procurement requirements, risk exposure, and future regulatory guidance.

NIST currently advises organizations to begin migrating. Its published transition planning anticipates deprecating and ultimately removing quantum-vulnerable algorithms from NIST standards by 2035, with higher-risk systems moving earlier.

Organizations should monitor authoritative guidance from NIST, CISA, sector regulators, standards bodies, customers, and contractual partners rather than relying on predictions that governments will impose one immediate universal deadline.

How TDXchange Supports Post-Quantum Readiness

TDXchange is bTrade’s Managed File Transfer and enterprise data exchange platform.

bTrade’s approach to post-quantum readiness includes:

  • Support for NIST-standardized post-quantum cryptographic capabilities
  • Crypto-agile architecture
  • Hybrid migration options
  • Centralized key and certificate management
  • Policy-driven cryptographic controls
  • Detailed configuration and transaction auditing
  • Enterprise observability
  • Partner-specific migration planning
  • Zero Trust controls across users, applications, APIs, workflows, and services
  • Readiness assessments and implementation assistance

The objective is not to force every connection to change simultaneously. It is to help organizations introduce new cryptographic mechanisms in controlled phases while maintaining interoperability with applications and trading partners.

The Bottom Line

NIST has finalized three principal post-quantum cryptography standards: ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures. FN-DSA and HQC remain part of NIST’s continuing standardization work and should not be represented as finalized FIPS standards.

For enterprise data exchange, the priority is not simply installing new algorithms. Organizations need an accurate cryptographic inventory, risk-based migration plan, interoperable protocols, vendor and partner coordination, testing, governance, and the ability to change cryptography without disrupting critical business workflows.

To discuss post-quantum readiness for your Managed File Transfer environment, contact the bTrade team.

About the Author

Andrei Olin is Chief Technology Officer at bTrade, where he leads product strategy, delivery, and security across the company’s B2B, Managed File Transfer (MFT), and security platforms. He brings over 30 years of experience in enterprise technology, including designing and operating mission-critical MFT and messaging platforms for global financial institutions such as Merrill Lynch and Deutsche Bank. Andrei holds Master’s and Bachelor’s degrees in Information Technology with a focus on Information Security.

Frequently Asked Questions

How many post-quantum cryptography standards has NIST finalized?

NIST has finalized three principal standards: FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, and FIPS 205 for SLH-DSA.

Are all three standards encryption algorithms?

No. ML-KEM supports key establishment. ML-DSA and SLH-DSA provide digital signatures.

What happened to CRYSTALS-Kyber and CRYSTALS-Dilithium?

The standardized algorithm derived from CRYSTALS-Kyber is named ML-KEM. The standardized algorithm derived from CRYSTALS-Dilithium is named ML-DSA.

Has NIST finalized Falcon?

No. Falcon was selected for standardization and is being developed under the name FN-DSA as FIPS 206.

Is HQC a finalized NIST standard?

No. NIST selected HQC for future standardization as an additional key-encapsulation mechanism, but it is not yet a finalized FIPS standard.

Which NIST algorithm encrypts transferred files?

None of the three directly serves as general file encryption. ML-KEM establishes shared secret material, while ML-DSA and SLH-DSA provide signatures. Symmetric algorithms can use derived keys to encrypt the actual data.

What should MFT organizations do first?

They should identify where RSA, elliptic-curve cryptography, certificates, SSH keys, TLS, SSH, digital signatures, and other public-key mechanisms are used across applications, workflows, and partner connections.

Why is interoperability testing necessary?

A standardized algorithm is useful only when the protocol, client, server, library, certificate infrastructure, product, and trading partner can implement it compatibly.

Continue Your Post-Quantum Security Journey

To learn more about preparing for the quantum era, explore the next articles in our post-quantum security series: