Post-quantum cryptography
Does your organisation need to move to quantum-safe cryptography — and if so, when?
Quantum computers may eventually break widely used asymmetric algorithms such as RSA, Diffie–Hellman and ECC. The PQC discussion mainly concerns those mechanisms — key exchange, digital signatures and PKI — not symmetric algorithms such as AES on their own.
Pankkih identifies where public-key cryptography is used, assesses risk and timing, and prepares a migration plan for the affected systems. Where useful, we also run pilots and deploy supported configurations.
- Harvest now, decrypt later. Encrypted traffic can be stored today and decrypted later if the asymmetric protection in use is broken.
- Data lifetime. Information that must stay confidential for decades extends the risk window far beyond the present.
- Hardware and procurement. Many platforms are refreshed infrequently; PQC upgradability belongs in tender criteria.
- Vendor support. Deployment requires both ends to support the same mechanism in the relevant product versions.
What we assess
Cryptographic baseline
TLS, VPN/IPsec, SSH, PKI, certificates, signatures, and update and authentication mechanisms.
Required protection period
How long data must stay confidential, whether encrypted traffic is retained, and which systems matter most.
Platforms and vendors
PQC support in the products you run, planned upgrades, and hardware or interoperability constraints.
Priorities
What to change first, what can wait for the next lifecycle refresh, and where work is not yet justified.
You receive a map of cryptographic dependencies, prioritised recommendations, a view of vendor PQC support and a staged migration plan — including what to pilot and what to ask for in procurement.
Pilot projects and implementation
After the assessment we can test and deploy standardised PQC algorithms such as ML-KEM and ML-DSA, and vendor-supported implementations. Typical targets are TLS 1.3, SSH, IPsec VPN and the related key-exchange mechanisms — see also Network for the edge and routing layer.
Environments where support is available or emerging include OpenSSL 3.5+, OpenSSH 10+, strongSwan 6+ and FortiOS releases with corresponding PQC features. Hybrid designs (for example X25519MLKEM768) combine classical and quantum-safe key exchange. A hybrid key exchange alone does not make authentication or digital signatures quantum-safe.
Before production we verify interoperability, functionality, performance and rollback. Rollout always depends on product version and on both ends supporting the same mechanism.
Work stages
1. Assessment
Inventory of cryptographic dependencies, affected systems, vendor compatibility and migration priorities.
2. Proof of Concept
Testing of selected PQC mechanisms in a controlled environment, including interoperability and performance checks.
3. Migration & Implementation
Deployment of supported configurations, validation, documentation and rollback planning.
When should migration start?
Estimate urgency with Mosca’s model: X + Y > Z.
X is the required protection period in years, Y the estimated migration time and Z the assumed quantum threat horizon. The sliders update the result when JavaScript is available.
Exceedance: 1 year (X + Y − Z).
The timing of a cryptographically relevant quantum computer is unknown. This calculation illustrates a planning scenario, not a forecast.
Model: IETF RFC 9958 — Post-Quantum Cryptography for Engineers
Standards and references
- Traficom — Risk assessment in the PQC transition
- European Commission — PQC Implementation Roadmap
- NIST — Post-Quantum Cryptography
- NIST IR 8547 — Transition to Post-Quantum Cryptography Standards
- IETF RFC 9958 — Post-Quantum Cryptography for Engineers
Contact us if you want to review your current estate. Related: Services, Network, Solutions, Expertise, privacy-enhancing technologies.