Most enterprises don’t know which TLS libraries their dependencies use, which JWT alg their microservices accept, or which signature algorithm their internal CA issues. The PQ migration is, more than anything, a forced cryptographic inventory exercise. Treat it as that, and the algorithm changes become the easy part.
Phase 1 — Discovery (Months 1-3)
Inventory every cryptographic primitive in production. The categories:
- TLS endpoints: every load balancer, every internal-mesh proxy, every API gateway. Audit cipher suites in use; flag ones using ECDHE_*, RSA_*, DH_*.
- SSH: every server’s
/etc/ssh/sshd_configKexAlgorithms, HostKeyAlgorithms, PubkeyAcceptedAlgorithms. - VPN / IPsec: site-to-site VPN configs, employee remote-access configs.
- JWT signing keys: every microservice that issues or verifies JWT — what alg (RS256? ES256?). Centralised auth services?
- S/MIME and PGP: anyone sending signed/encrypted email? Internal or external?
- Code signing: software releases, JAR signing, RPM/DEB signing, Authenticode.
- Internal CA: which algorithm does your internal root CA use? Intermediate? Issued certs? Lifetime?
- Database TDE: SQL Server, Oracle, PostgreSQL transparent data encryption — what’s the encryption key wrapped with?
- Backup encryption: tape backup, S3 KMS, etc.
- HSM-resident keys: AWS CloudHSM, Thales, Gemalto — what algorithms are supported and used?
- Certificate transparency: SCT signatures from CT logs (these will need to migrate).
Output: a spreadsheet with every cryptographic dependency, library version, current algorithm, ownership team. This is your migration backlog.
Custom team training + practitioner advisory
Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.