Native PQC HSMs Are Here: How QNSI Solves the Real Migration Problem

Evidence boundary: any present-tense QNSI product wording below describes source-declared contracts, architecture targets, or vendor-run artifacts-not independently observed production behavior. Conformance artifacts prove only their stated algorithm scope. End-to-end production execution is NOT VERIFIED.

Post-quantum security marketing needs a correction. The statement “HSMs cannot do post-quantum cryptography” is no longer defensible as a market-wide claim.

AWS KMS has supported generally available ML-DSA-44, ML-DSA-65, and ML-DSA-87 signing keys since June 2025. AWS states that its ML-DSA keys and signature operations run in FIPS 140-3 Security Level 3 validated HSMs. Thales Luna firmware 7.9.0 added native ML-KEM and ML-DSA mechanisms, and other HSM vendors are advancing their native post-quantum capabilities.

That matters because credible security infrastructure must change its claims when the evidence changes. It also reveals the harder problem: native PQC does not make an estate migrated.

Native PQC does not make an estate migrated

A large organization rarely has one key store, one HSM generation, one cloud, or one approval boundary. It has years of accumulated cryptography across applications, certificates, TLS endpoints, source repositories, databases, hardware appliances, cloud KMS services, disconnected systems, and vendor-specific interfaces.

Buying a native ML-DSA operation is useful. It does not automatically answer the operational questions that determine whether a migration succeeds:

Where is vulnerable cryptography still deployed?
Which assets can move to a native provider now?
Which systems are tied to an existing PKCS#11 estate?
Who approved each change, and what exactly changed?
Can an interrupted migration resume safely?
Can the organization prove the observed result to an auditor?
What happens when a provider, module, firmware version, or validation scope changes?

This is where QNSI fits: not as another HSM, and not as the owner of somebody else’s FIPS certificate, but as the vendor-neutral discovery, migration, policy, custody, and evidence layer across a mixed cryptographic estate.

Two valid paths, with different boundaries

The correct architecture is not “hardware versus software” as a slogan. It is a deployment decision based on the exact mechanism, module, configuration, operation, and assurance requirement.

Path one: use native PQC when the approved provider supports it. If an organization can use a native ML-DSA operation in an exact provider configuration that meets its requirements, it should. QNSI should govern and evidence that migration-not force the workload through a compatibility layer for marketing reasons.

Path two: use a compatibility custody pattern where the existing estate cannot move yet. Many qualified PKCS#11 deployments do not expose the required native ML-DSA mechanism on the model, firmware, client, or configuration the customer is authorized to operate. Replacing that estate may require procurement, recertification, application changes, downtime planning, or all four.

What QNSI HSPK actually does

QNSI’s current HSM-Sealed Post-Quantum Keys (HSPK) API addresses that second path for ML-DSA-44, ML-DSA-65, and ML-DSA-87.

The ML-DSA private key is encrypted with AES-256-GCM under a randomly generated content-encryption key. That content key is wrapped using RSA-OAEP under a non-extractable key held by the customer’s qualified PKCS#11 HSM. Authorized signing temporarily recovers the ML-DSA private key in QNSI software, performs the signature, and zeroizes the transient key material.

The boundary is explicit:

The HSM protects the RSA-OAEP custody root and performs the content-key wrap and unwrap.
QNSI performs ML-DSA in software outside the HSM module.
A vendor’s FIPS validation belongs to the exact validated module and configuration.
That validation does not transfer to HEOSSI, QNSI, or the software ML-DSA operation.

Three evidence domains, not one borrowed claim

QNSI has exercised its shipped PKCS#11 provider and HSPK custody flow against AWS CloudHSM hsm2m.medium in FIPS mode.

Marvell Semiconductor’s CMVP certificate #4703 is evidence about the LS2 module. AWS provides the CloudHSM service. QNSI’s qualification evidence is evidence about the integration path. They are related facts, not interchangeable claims.

Algorithm conformance, module validation, and deployment-specific integration qualification prove different things. QNSI states each boundary separately and does not claim that HSPK’s software ML-DSA operation inherits the HSM module’s validation.

The real differentiator is governed migration

QNSI connects the parts that a single cryptographic mechanism does not solve:

Discover. Inventory cryptography across infrastructure, hosts, TLS, and source code. Local source scanning can produce normalized findings without uploading repository contents.
Decide. Map each asset to a target path: native provider operation, HSPK compatibility, hybrid transition, remediation, or documented exception.
Govern. Use hash-bound dry runs, approval and four-eyes controls where configured, durable execution waves, per-asset cutover confirmation, crash recovery, and reconciliation.
Enforce. Apply tenant cryptographic policy and finalized-standard boundaries while retaining a broader catalog for interoperability, evaluation, and migration work.
Prove. Preserve tamper-evident operational records, signed product facts, reproducible conformance evidence, and deployment-specific HSM qualification evidence.

QNSI exposes a catalog of 87 post-quantum algorithms across 13 families for migration, interoperability, and research. HEOSSI-operated trust paths use the finalized NIST standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). The catalog is not a claim that all 87 algorithms execute in hardware.

Algorithm breadth, native hardware execution, module validation, integration qualification, and end-to-end migration governance are five different things. Serious buyers should expect a vendor to state which one it is proving.

A more useful question than “who was first?”

QNSI is not claiming to be the first FIPS Level 3 native-PQC HSM or cloud KMS. The public evidence does not support that claim, and QNSI is not an HSM manufacturer.

The more useful question is: can an organization move a heterogeneous cryptographic estate toward post-quantum security without losing custody, operational control, recoverability, or evidence?

That is the system we are building. Use native PQC where the exact approved provider supports it. Use a qualified compatibility path where an existing estate still needs one. Govern both through the same migration and evidence model.

That is a more honest position than claiming the market has no native hardware-and a more useful product than asking every customer to replace its infrastructure before it can begin.

Inspect the primary evidence

If your organization is deciding what should move to native PQC now-and what needs a governed bridge first-QNSI is free to start at https://cloud.qnsi.heossi.com/auth?mode=signup.