Tessera PQC
PX-04
What it finds
Your cryptography, wherever it hides.
Most of a bank's cryptography is not in code it wrote. It is in vendor products delivered as compiled files, in HSMs and cloud key stores, and on network endpoints. Tessera PQC reads all of it into one CycloneDX 1.6 CBOM — each finding with its location, algorithm, key size, severity, the post-quantum replacement and a transition option.
01
03
Read into one inventory
Input | What is read |
|---|---|
Source code | Python, JavaScript and TypeScript, Java and Kotlin, Go, C and C++, C# and .NET — the key type, size and curve at the exact line |
Vendor applications | Compiled Java archives and Linux, Windows and macOS binaries. Covers core-banking and other vendor products shipped without source |
Container images | Docker and OCI images, read offline, every layer |
Keystores and certificates | JKS, PKCS#12, PEM and more. Metadata only — private key bytes never reach a report |
HSMs and key stores | Read-only PKCS#11 inventory; AWS KMS, Azure Key Vault, Google Cloud KMS and HashiCorp Vault; Windows certificate stores and AD CS templates |
Live endpoints | TLS and SSH checks for post-quantum key exchange, without completing a handshake or logging in. Only hosts you name |
Network evidence | A receive-only listener on a mirror port, packet captures, and imports from the tools your team already runs |
Servers, without an agent | A one-shot collector run once per server. Nothing stays installed |
Server configuration | Settings in SSH, web servers, load balancers and OpenSSL that rule out post-quantum key exchange |
Crypto libraries | Dependency lockfiles for 32 cryptography libraries, each marked PQC-ready, upgrade available, or no PQC release yet |
Indian schemes | UIDAI Aadhaar, NPCI UPI and CCA eSign cryptography, tagged with the scheme operator who must change it |
← Swipe for the rest of the table →
← Drag for the rest of the table →
Everything is read; nothing is changed. Fixes go through your own pull requests and change process.
02
03
What every finding carries
01
Where
File and line, artefact and layer, key store or host and port — enough for the owner to find it without asking.
02
What
Algorithm, key size and curve, and whether it is already weak today or breakable only by a quantum computer.
03
Who
The owning service and team, or the vendor or scheme operator when the cryptography is not yours to change.
04
By when
The migration date from the regulatory profile you work to.
05
With what
The NIST replacement — ML-KEM (FIPS 203), ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) — and a hybrid transition option.
06
Since when
Findings persist across runs, so the inventory says what is new, what is fixed and what came back.
03
03
From what you have to what replaces it
Found today | Replace with | Transition |
|---|---|---|
RSA key exchange and encryption | ML-KEM-768 (FIPS 203) | X25519MLKEM768 hybrid key exchange |
ECDH, X25519 | ML-KEM-768 (FIPS 203) | X25519MLKEM768 or SecP256r1MLKEM768 |
RSA and ECDSA signatures | ML-DSA-65 (FIPS 204) or SLH-DSA (FIPS 205) | Classical + ML-DSA-65 composite signature |
DSA, RSA-1024, DH-1024 | Replace now — already weak today | No transition: these are critical |
← Swipe for the rest of the table →
← Drag for the rest of the table →