A walkthrough of what actually happens when Quantera scans customer-vault, a Java service protecting customer financial records.
customer-vault encrypts customer records with AES-256-GCM, protects that AES key with RSA-2048, and signs transactions with ECDSA. Nothing about this is unusual — it's a normal Java service written years before ML-KEM or ML-DSA existed.
A .zip upload or a GitHub App connection, pinned to a commit. The Repository Scanner parses 284 files, resolves 1,041 symbols, and produces an inventory:
| Algorithm | Location | Purpose | Status |
|---|---|---|---|
| AES-256-GCM | VaultEncryptionService.java:42 | Data encryption | Retain |
| RSA-2048/OAEP | RsaKeyProtectionService.java:47 | Key protection | Migration Ready |
| ECDSA P-256 | TransactionSigner.java:29 | Digital signature | Review Required |
The Cryptographic Context Engine resolves the call chain — not guessed, walked.
| Finding | Determination |
|---|---|
| RSA-2048 (key protection) | Key establishment → ML-KEM-768 |
| AES-256-GCM | Already quantum-resistant → Retain |
| ECDSA P-256 (signature) | Flagged separately → signature migration, reviewed on its own |
RSA key protection → ML-KEM-768 (FIPS 203), approved by the policy engine's recipe for this exact pattern.
A draft pull request, not a merged change: