Post-quantum
Post-quantum cryptography is the default, not a roadmap item.
ApexAI signs and exchanges keys with the NIST post-quantum standards today, and helps you find what to migrate in your own code.
Why now
A large enough quantum computer would break the public-key algorithms most systems rely on today: RSA and elliptic-curve key exchange and signatures. Data recorded now can be decrypted later (“harvest now, decrypt later”), so anything that must stay secret or authentic for years is already exposed.
NIST has standardised replacements: ML-KEM for key establishment (FIPS 203) and ML-DSA for digital signatures (FIPS 204). ApexAI uses them by default.
Where ApexAI uses them
| Algorithm | Standard | Used for |
|---|---|---|
| ML-KEM-1024 | FIPS 203 | Key exchange; hybrid ML-KEM field protection in the Data Gate |
| ML-DSA-87 | FIPS 204 | Platform licences; audit-log entries and Merkle roots, alongside Ed25519 |
| ML-DSA-65 | FIPS 204 | SOC decision policies and risk-index versions, bound to their workspace |
PQC Shield, for your own code
The same standards, applied to what you build: PQC Shield finds quantum-vulnerable cryptography in your repositories and plans the move.
- A CycloneDX CBOM of your repositories
- Findings classified by exposure to harvest-now, decrypt-later
- Remediation tracking per finding
- Migration designs to ML-KEM / ML-DSA, and exportable reports
What we do not claim
- Audit-log signing keys are software keys on the backend’s key volume; there is no TPM.
- The CBOM scanner matches patterns in source code rather than parsing it fully; treat its inventory as a starting point.
- No validation of ApexAI’s cryptographic modules is claimed. [FIPS 140-3 status — confirm.]
Start your post-quantum inventory.
Scan a repository with us and walk through the migration design.