A new approach to cybersecurity
For Business → ProtectionGrid For Large Corporates → ProtectionGrid For Law Enforcement → Intelligence For Governments → Intelligence
Home/ Technology/ Post-Quantum Encryption
Post-Quantum Encryption · Live since 2025

Encryption built for
what's coming.

Most encryption in use today will be broken by quantum computers within this decade. Most security vendors are not prepared. We deployed post-quantum cryptography to production in 2025 — among the first European cybersecurity platforms to do so.

2025
PQC live in production
Hybrid
Classical + PQC stack
NIST FIPS
203, 204, 205 standards
5+ years
ahead of industry adoption
The threat that's already happening

Harvest now,
decrypt later.

State-level adversaries are already capturing encrypted traffic at scale — not because they can decrypt it today, but because they will be able to within years.

TODAY
Capture encrypted data

Adversaries record encrypted communications, financial records, medical files, government correspondence. They can't read it yet — but they store it.

~2030
Quantum computers reach scale

Cryptographically relevant quantum computers (CRQCs) are projected to break RSA, ECC, and Diffie-Hellman within this decade. The exact year is debated, the direction isn't.

~2030+
Stored data decrypted retroactively

Everything captured today gets decrypted. Long-lived sensitive data — IP, contracts, medical records, classified communications — is exposed years after it was supposedly secure.

Our approach

Hybrid by design.
Sovereign by default.

We use a hybrid cryptographic stack — classical algorithms (proven, time-tested) running alongside post-quantum algorithms (resistant to known quantum attacks). Both must fail before the connection is compromised.

This isn't theoretical. Hybrid PQC has been live in identiqa production since 2025 across all customer-facing endpoints in ProtectionGrid — TLS handshakes, VPN tunnels, internal service-to-service authentication, customer data at rest.

Why hybrid rather than pure PQC? PQC algorithms are new. Classical algorithms have decades of cryptanalytic scrutiny. Combining both means a flaw in either layer doesn't compromise the system — a defensive posture that NIST and ENISA both recommend during this transition period.

  • NIST-standardized primitives only. ML-KEM (Kyber) for key encapsulation, ML-DSA (Dilithium) for digital signatures, SLH-DSA (SPHINCS+) for high-assurance signatures.
  • Continuous evaluation against new cryptanalytic results. PQC is younger than classical crypto — we monitor academic developments and patch quickly when needed.
  • EU-jurisdiction key management. All PQC and classical keys are generated, stored, and rotated within our EU data centres. No third-party HSM providers in non-EU jurisdictions.
  • Crypto-agility built in. Algorithms are abstracted so we can rotate to NIST round-2 or future standards without breaking customer integrations.
Hybrid Cryptographic Stack
Classical Layer
X25519 + AES-256-GCM
+
Post-Quantum Layer
ML-KEM-768 + ML-DSA-65
identiqa Hybrid TLS
Both layers must fail → resistant to classical AND quantum attack
Standards we use

No proprietary crypto.
Only peer-reviewed standards.

Every algorithm in our PQC stack went through 8+ years of NIST evaluation and global cryptanalytic review. We don't roll our own crypto.

FIPS 203
ML-KEM
Key Encapsulation

Module-Lattice-Based Key Encapsulation Mechanism. Based on Kyber. Used for establishing shared secrets in TLS handshakes, VPN tunnels, and service-to-service authentication. We deploy ML-KEM-768 as our default security level.

FIPS 204
ML-DSA
Digital Signatures

Module-Lattice-Based Digital Signature Algorithm. Based on Dilithium. Used for code signing, certificate signatures, and document attestation. ML-DSA-65 is our default — balancing signature size against security level.

FIPS 205
SLH-DSA
High-Assurance Signatures

Stateless Hash-Based Digital Signature Algorithm. Based on SPHINCS+. Used where maximum conservatism is required — long-term archival signatures, root certificates, audit log attestation. Slower than ML-DSA, but built on different mathematical assumptions.

Where it's deployed

Where PQC actually runs.

Hybrid PQC isn't a marketing claim on a future roadmap — it's running across our infrastructure today.

Tier 1 · Customer-facing
TLS endpoints

All customer-facing TLS endpoints negotiate hybrid handshakes when the client supports them. ProtectionGrid modules, CyberHub portal, API gateways.

Live since 2025
Tier 2 · Internal
Service mesh

Internal service-to-service communication uses hybrid mTLS. Every microservice authenticates to every other microservice with both classical and post-quantum credentials.

Live since 2025
Tier 3 · Long-lived data
Data at rest

Customer data stored for extended periods (logs, backups, evidence packages) is encrypted with hybrid PQC envelope encryption. Even if classical layer breaks, data stays protected.

Live since 2025
PQC standards timeline

Why five years ahead matters.

1994
Shor's algorithm published — quantum threat to RSA/ECC proven theoretically
Theory
2016
NIST opens Post-Quantum Cryptography standardization process
Process
2022
NIST selects first PQC algorithms (Kyber, Dilithium, Falcon, SPHINCS+)
Selection
2024
NIST publishes final FIPS standards (FIPS 203, 204, 205)
Standards
2025
identiqa deploys hybrid PQC across all production endpoints
Deployed
2026
Mainstream cybersecurity vendors begin announcing PQC roadmaps
Catching up
~2030
Cryptographically Relevant Quantum Computers expected — too late to start migration then
Threat horizon
For technical evaluators

Questions cryptographers ask first.

Why hybrid rather than pure post-quantum?
PQC algorithms are new. Classical algorithms (RSA, ECC, AES) have 30+ years of cryptanalytic scrutiny — we know exactly where they break. PQC algorithms have ~10 years of public scrutiny. A hybrid stack means both layers must fail before security is lost. If a flaw is discovered in ML-KEM tomorrow, X25519 still protects us until we patch. NIST and ENISA both explicitly recommend hybrid approaches during this transition. Pure PQC will become standard practice once the algorithms mature — we'll get there, but conservatism wins for now.
What about the "Y2Q" or "Q-day" timeline — is the threat real?
The exact arrival date of cryptographically relevant quantum computers is debated. Estimates range from 2030 to 2040+. But the threat for current encrypted data isn't tomorrow's quantum computer — it's today's "harvest now, decrypt later" attacks. State-level adversaries are already capturing encrypted traffic at scale, expecting to decrypt it years from now. For long-lived sensitive data — financial records, medical files, IP, classified communications — the threat is operational today. Migration should be done before, not after.
Why FIPS 203/204/205 specifically? What about FN-DSA (Falcon)?
We deploy ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) because they have final published standards as of August 2024. FN-DSA (Falcon, FIPS 206) is on the roadmap but the standard wasn't finalized at our 2025 deployment date. We monitor it for adoption. SLH-DSA covers our high-assurance signature use cases until FN-DSA stabilizes. We're committed to crypto-agility — algorithms are abstracted so we can swap in new ones without breaking customer integrations.
Performance impact of hybrid PQC?
Real, but manageable. ML-KEM-768 handshakes add roughly 1-2 KB to TLS handshakes vs. classical X25519, and parsing/validation is slightly slower. End-to-end TLS handshake latency increases by approximately 5-10ms on modern hardware. Inside our anycast network, this is well below noticeable thresholds. ML-DSA signatures are larger than ECDSA (~3.3 KB vs. ~70 bytes), so signature-heavy workflows like OCSP can see meaningful overhead — we mitigate this with caching and signature aggregation.
How does this affect my integration with identiqa?
For most customers, transparently. If your client supports hybrid TLS extensions (modern OpenSSL, BoringSSL, Go crypto/tls 1.21+), we negotiate hybrid automatically. If your client only supports classical TLS, we fall back to classical — no broken connections. Crypto-agility means you don't have to do anything for PQC; it just gets stronger as your client stack updates. For customers with specific compliance requirements (e.g., DORA Article 19, NIS2 cyber hygiene), we provide attestation documentation showing PQC is active on relevant connections.
Are you using PQC in third-party libraries we should know about?
Our PQC implementations are based on liboqs (Open Quantum Safe project) and OpenSSL 3.x with PQC providers, both of which are open-source and audited. We don't roll our own implementations of ML-KEM, ML-DSA, or SLH-DSA — those algorithms are too new and too easy to implement incorrectly. We track upstream patches closely and apply security fixes within hours, not weeks.

Want the technical deep dive?

Our cryptography team runs technical sessions for prospective customers and journalists — architecture review, threat modeling for your specific data lifetime requirements, cryptographic agility roadmap. Typically 60 minutes, signed NDA, no marketing.

Request technical session Back to Technology overview →