Cryptography 2026: transport, storage, identities and the post-quantum transition, the decision framework for business leaders and CISOs

Cryptography is no longer a matter for engineers. It has become a leadership decision. Three underlying shifts are converging in 2026: the post-quantum transition, the industrialisation of attacks on identity, and a European regulatory framework that is becoming clearer. Each one calls for trade-offs that only a business leader can settle: which data to protect first, what level of sovereignty to aim for, at what pace to modernise.

The good news is that the standards exist, the timeline is known, and the path is marked out by ANSSI, NIST and industry best practice. There is no cause for panic; there is a method to apply. This article sets out the decision framework in three stages (data in transit, data at rest, identities), then places it within the maturity grid of the MATIA Method™ so that you can decide where to focus your effort this year.

The one-sentence takeaway. The winning reflex in 2026 is not to buy yet another tool, but to establish crypto-agility: the ability to change algorithm without overhauling the information system with every new development.

---

1. The post-quantum transition: a timeline, not an alarm

1.1. What is changing, and why it is manageable

The asymmetric cryptography that secures the Internet (RSA, elliptic curves) relies on mathematical problems that a sufficiently powerful quantum computer, described as “cryptographically relevant” (CRQC), would be able to solve quickly thanks to Shor’s algorithm. This CRQC does not yet exist. The issue for a business leader is therefore not tomorrow’s machine, but a practice of today to be anticipated calmly.

This practice has a name: “Store-Now, Decrypt-Later” (SNDL), or “harvest now, decrypt later”. Actors with substantial resources can intercept and store encrypted communications today (TLS traffic, VPN tunnels), with the intention of decrypting them once quantum computing power becomes available. The consequence is simple and actionable: any data whose confidentiality must hold for more than five to ten years deserves to be protected right now by quantum-resistant mechanisms.

This is why priority goes to confidentiality (key exchange) rather than to signature: impersonating an identity through signature would require a quantum computer operational in real time, whereas data intercepted today simply waits.

1.2. Stable standards to build on

In August 2024, NIST published its first finalised post-quantum cryptography standards. They no longer rely on factorisation but on different mathematical families, designed to resist both classical and quantum attacks.

Standard	Origin	New name	Function	Primary use
FIPS 203	CRYSTALS-Kyber	ML-KEM	Key exchange (KEM)	Confidentiality in transit, protection against SNDL
FIPS 204	CRYSTALS-Dilithium	ML-DSA	Digital signature	Server authentication, certificates, PKI
FIPS 205	SPHINCS+	SLH-DSA	Digital signature	Fallback to ML-DSA, software/firmware integrity
SP 800-208	LMS / XMSS	LMS / XMSS	Stateful signature	Firmware updates

These standards allow software vendors, operating systems and agencies to begin large-scale integration. The ground is mapped out.

1.3. The transition doctrine: hybridisation, a prudent choice

Post-quantum algorithms are robust, but recent: they do not yet have the decades of analysis that RSA or elliptic curves have undergone. Rather than replacing everything at once, industry and the European agencies recommend hybridisation: combining, for the duration of the transition, a proven classical algorithm (ECDH) with a post-quantum algorithm (ML-KEM). To compromise the session, an adversary would have to break both at once, one requiring a quantum computer, the other being immune to it. This is a belt-and-braces approach, and therefore reassuring.

National doctrines diverge on the tempo, which has a concrete implication for international companies:

Agency	Country	Stance on hybridisation
ANSSI	France	Required; primary and immediate transition strategy
BSI	Germany	Strongly recommended; aligned with ANSSI / ENISA
NCSC	United Kingdom	Transitional measure; prefers a direct transition in the long run
NSA (CNSA 2.0)	United States	Direct transition to pure PQC for national security systems
CCCS	Canada	Neutral

The practical consequence: designing crypto-agile architectures, able to negotiate hybrid modes in Europe (ANSSI/BSI compliance) while being able to switch to pure PQC modes elsewhere. This is precisely the flexibility that crypto-agility aims for.

---

2. Data in transit: modernising without breaking the network

Three protocols structure secure transport: TLS (web, API), IPsec (site interconnections, remote working) and SSH (administration). Their move to post-quantum is above all a matter of network engineering: post-quantum keys are larger, and some older equipment copes poorly with bigger packets. The good news: the solutions are known and documented.

2.1. TLS 1.3 and QUIC

TLS 1.3 accounts for more than 93% of secure connections (Cloudflare, 2024) and serves as the foundation for QUIC (HTTP/3). The priority is to hybridise the key establishment phase, with configurations such as X25519MLKEM768. A point to watch: a hybrid key exceeds one kilobyte (compared with ~32 bytes for a classical exchange), which can push the first message (“ClientHello”) beyond the standard size and cause fragmentation that is poorly handled by older firewalls or load balancers, a phenomenon of network “ossification”.

The recommended action is simple: audit the network inspection chain to check its tolerance for these larger packets. The GREASE mechanism (built into TLS 1.3) already helps to prevent filtering rules from becoming frozen. For hybrid X.509 certificates, ANSSI recommends waiting for the IETF standards to be finalised: the priority remains confidentiality, not authentication.

2.2. IPsec and IKEv2

The IPsec data plane (ESP/AH, using AES-256-GCM) resists quantum attacks well. It is the establishment phase, driven by IKEv2 over UDP, that requires hybridisation. As UDP handles very large packets poorly, ANSSI and the IETF rely on a stack of standards that are now available:

• RFC 7383: fragmentation at the IKE level (avoids blind IP fragmentation);

• RFC 9242: intermediate exchange (IKE_INTERMEDIATE) to carry large payloads reliably;

• RFC 9370: negotiation of multiple key exchanges (hybridisation proper), integrated into StrongSwan 6.0+;

• RFC 8784: post-quantum pre-shared keys (PPK), an immediate stopgap for closed systems.

The concrete action: update the firmware of VPN concentrators and firewalls to versions supporting these RFCs. Without this upgrade, hybridisation would block the establishment of tunnels, hence the importance of planning these updates before switching over.

2.3. SSH

SSH is the gateway to administration. OpenSSH was a pioneer: from version 9.0, hybrid key exchange by default (X25519 + NTRU Prime); with 10.0, ML-KEM hybridisation by default, aligned with FIPS 203. The recommended action: upgrade the administration fleet to OpenSSH 10.0+. Key authentication (users and hosts) remains classical for want of a finalised IETF standard; in the meantime, frequent key rotation is automated (Vault, Ansible) and administration networks are segmented.

2.4. Group messaging: the MLS standard

For end-to-end encrypted (E2EE) group communications, the historical approach (Signal’s “Double Ratchet”) scales poorly: adding or removing a member in a group of n people costs an effort proportional to n. In July 2023 the IETF published the Messaging Layer Security (MLS, RFC 9420) standard, which reduces this cost to a logarithmic order thanks to a tree structure (TreeKEM). MLS is already in production (Cisco Webex, RCS (Universal Profile 3.0)) and was designed to natively incorporate future post-quantum mechanisms, a useful marker for choosing a collaboration platform that will last.

---

3. Data at rest: the real question is that of keys

For storage, the encryption algorithm is not the issue: AES-256 remains the norm and resists quantum attacks. Grover’s algorithm halves the effective strength of a symmetric key: an AES-128 key would fall to a vulnerable level, whereas AES-256 retains a comfortable security margin. The real challenge shifts to key management and sovereignty.

3.1. Envelope encryption

Modern cloud relies on a hierarchy of keys: a DEK (data encryption key, ephemeral) encrypts the files; a KEK (master key) encrypts the DEK. The DEK is never stored in the clear. KEKs must be generated, managed and stored in HSMs (hardware security modules) validated to FIPS 140-3 Level 3, via a KMS service. Every decryption operation takes place in the protected memory of the HSM.

3.2. Sovereignty: the question to settle at leadership level

The risk is not only criminal (ransomware targeting backups), it is also legal. The CNIL, drawing on ANSSI, warns: if the cloud provider holds both the data and the master keys, it can technically be compelled, by legislation with extraterritorial reach (the US CLOUD Act, Section 702 of FISA, intelligence laws of third-party jurisdictions), to provide data in the clear. Sovereignty is therefore reasoned in terms of jurisdiction and infrastructure, not the presumed national origin of threats.

Three levels of key control, to be weighed according to the sensitivity of the data:

• By default: the provider manages everything. Simple, but no protection against an extraterritorial order.

• BYOK (Bring Your Own Key): you generate your keys and import them. Better control of rotations, but the provider retains technical access in memory during processing.

• HYOK / External KMS (the CNIL’s “Approach 4”): you retain physical control of the KEKs in your own HSMs (on-premises or a sovereign provider). This is the only option that guarantees strict cryptographic sovereignty; it is more demanding to integrate. It is also the spirit of ANSSI’s SecNumCloud qualification.

3.3. Protecting the integrity of backups

Encryption is no longer enough: attackers target backups in order to erase or alter them. Robust hash functions (SHA-384, SHA-512, the SHA-3 family) and integrity mechanisms (MAC) are used to guarantee the immutability of offline backups, the condition for recovering calmly from an attack.

---

4. Identities: the password alone has had its day

This is probably the project with the best effort-to-impact ratio for an SME in 2026.

4.1. Storing passwords correctly

In a database, a password is never stored in the clear, and fast hashes (MD5, SHA-1), crackable by GPU farms, are banned. The OWASP/ANSSI rule: use “memory-hard” functions, hungry for RAM, which make the attack economically unattractive.

Algorithm	Status	Configuration benchmark
Argon2id	Recommended (de facto standard)	m = 19 MiB minimum, t = 2, p tuned to the server
scrypt	Good alternative	N = 2¹⁷ (≈128 MiB), r = 8
bcrypt	Legacy	Work factor > 10; beware of truncation beyond 72 bytes
PBKDF2	Tolerated (compliance)	Not “memory-hard”: to be avoided for any new project

A salt (unique, against rainbow tables) is systematically added and, in high-security settings, a pepper (a global secret key stored in an HSM). These mechanisms are quantum-resistant as long as the underlying hash function is robust.

4.2. Why “classic” MFA no longer protects

MFA via SMS, one-time code (TOTP) or push notification was considered sufficient. It is no longer sufficient against “Adversary-in-the-Middle” (AiTM) proxy attacks, which have become industrialised.

The principle, put simply: the attacker places a transparent proxy between you and the real site. You see the genuine login page (relayed in real time), you enter your credentials and then your MFA code. The attacker captures, in passing, the session token issued after validation. From that point on, your password no longer matters: the attacker holds a legitimate session. These kits are sold “turnkey” (Phishing-as-a-Service), sometimes combined with vishing (a phone call from a fake support desk, possibly assisted by a synthetic voice). Recent incidents have led, by this method, to the theft of SSO credentials and the exfiltration of CRM databases, something no amount of vigilance training could have prevented.

The observation is stated without dramatising: no method relying on the human repetition of a secret withstands interception by proxy. The countermeasure exists, and it is mathematical.

4.3. FIDO2 / passkeys: the countermeasure by design

Passkeys (the FIDO2 / WebAuthn standard) solve the problem through a principle called origin binding. At registration, your device generates a key pair specific to the service; the private key never leaves the secure enclave (TPM, Secure Enclave, a hardware key such as a YubiKey). At sign-in, the browser itself verifies the exact domain and only signs the challenge if it matches the registered domain. On a fake site, the signature is refused automatically: the attack fails without the user having to judge the validity of the URL.

Adoption reached critical mass in 2026: more than 5 billion passkeys in use, 68% of organisations deploying them. Pioneering companies (Cloudflare, Snap) report zero compromise through phishing after a full switch-over and the deactivation of vulnerable fallback methods.

---

5. The European regulatory framework: a horizon becoming clearer

Two European matters deserve the attention of business leaders, not to cause worry but to anticipate.

eIDAS 2.0 (Article 45 / QWAC). The regulation creates a European digital identity wallet, a useful step forward. One technical provision is contested: the obligation on browsers to embed certain certificate authorities endorsed by member states (QWAC) without being able to remove them freely. Browser vendors, cryptographers and digital-rights organisations (EFF, Internet Society) warn that this could slow incident response (revocation of a compromised authority) and set a precedent liable to be invoked by other jurisdictions with weaker democratic safeguards, fuelling the fragmentation of the Internet. Leadership action: for critical applications, put certificate pinning in place and monitor Certificate Transparency.

“Chat Control” and end-to-end encryption. The proposal to pre-emptively scan messaging services in order to combat child sexual abuse material ran up against a technical impossibility: scanning end-to-end encrypted messages would require “client-side scanning” (analysis on the device before encryption), which amounts to weakening encryption for everyone and undermines professional confidentiality (lawyers, doctors, journalists). In late 2025 and early 2026, at Denmark’s instigation, the Council of the EU amended the text to exclude any obligation of forced detection on E2EE spaces, a welcome clarification. The matter is entering the trilogue phase; vigilance remains warranted, but the direction is reassuring.

---

6. Where to focus effort in 2026: reading it through the MATIA Method™

Not everything is done at once. The MATIA Method™ grades AI maturity across five levels (Spectateur, Artisan, Orchestre, Architecte, Pionnier). For cryptography, effort concentrates on three of them (Artisan, Orchestre, Architecte), which provide a clear and workable order of march. Here is how cryptography fits into them:

Artisan level: securing the foundations (0-6 months). The high-impact, low-complexity moves: roll out passkeys / FIDO2 for privileged accounts (leadership, IT, finance) and disable vulnerable fallback MFA methods; check that password storage uses Argon2id; confirm that all encryption at rest uses AES-256. This is where most of the resilience is won, and quickly.

Orchestre level: structuring crypto-agility (6-18 months). Map encrypted flows and certificates (a cryptographic inventory), enable TLS 1.3 hybridisation on exposed services, plan network updates (IPsec/IKEv2, OpenSSH 10.0+), and weigh the level of key sovereignty (BYOK vs HYOK) according to the sensitivity of the data. The objective: to be able to change algorithm without rebuilding everything.

Architecte level: steering by data and duration (18 months and beyond). Classify data by the required confidentiality period and prioritise post-quantum protection for the longest (the SNDL logic); integrate a sovereign External KMS / HYOK architecture; choose collaboration platforms built on durable standards (MLS); integrate regulatory monitoring (eIDAS, E2EE) into governance.

This progression avoids two pitfalls: wait-and-see (“we will see when quantum arrives”) and costly haste (“let us replace everything”). For organisations that wish to delegate part of this orchestration (inventory, certificate monitoring, key rotation), Junyr Agents™ can automate repetitive tasks under supervision, in a logic of method rather than an accumulation of tools.

---

Conclusion

Cryptography has changed status: it now determines an organisation’s digital trust as much as its compliance. But the picture in 2026 is not that of an insurmountable threat. It is that of a mapped-out path: stable standards (NIST, ANSSI), a prudent doctrine (hybridisation), proven countermeasures (FIDO2), and a European framework that is becoming clearer. The business leader’s task is not to do everything at once, but to structure crypto-agility and to place the effort in the right place, in the right order. It is achievable, and it is even a competitive advantage for those who go about it methodically.

To position your organisation on the maturity scale and build your roadmap: AI & Security Express Audit & Roadmap.

---

Sources: direct verified links (audit 29 May 2026)

Links verified on 29 May 2026.

Post-quantum, standards and transition 1. NIST, NIST Releases First 3 Finalized Post-Quantum Encryption Standards 2. NIST CSRC, Post-Quantum Cryptography 3. Akamai, A Guide to International Post-Quantum Cryptography Standards 4. Akamai, Post-Quantum Cryptography Implementation Considerations in TLS 5. Palo Alto Networks, A Complete Guide to Post-Quantum Cryptography Standards 6. ANSSI, Follow-up position paper on Post-Quantum Cryptography (addendum 2023)

Transport (TLS, QUIC, IPsec, SSH) 7. ANSSI, Transition post-quantique du protocole TLS 1.3 8. ANSSI, Transition post-quantique de SSHv2 (PDF) 9. ANSSI, Transition post-quantique du protocole IPsec 10. DataGuidance, France: ANSSI releases guide on Post-Quantum Transition of IPsec 11. blog.ogwilliam.com, Concrete Technical Steps for Post-Quantum TLS, SSH, and IPsec 12. AWS Security Blog, Enable post-quantum key exchange in QUIC with the s2n-quic library 13. Cloudflare Blog, The state of the post-quantum Internet

Group messaging / MLS 14. IETF Datatracker, RFC 9420, The Messaging Layer Security (MLS) Protocol 15. Feisty Duck, RFC 9420: Messaging Layer Security 16. Gopher Security, Understanding Messaging Layer Security 17. YouTube (37C3), RFC 9420 or how to scale end-to-end encryption with Messaging Layer Security

Storage, KMS, cloud sovereignty 18. Google Cloud, Envelope encryption / Chiffrement encapsulé (Cloud KMS) 19. AWS, Protection des données dans AWS Key Management Service 20. Entrust, Quelles sont les meilleures stratégies de gestion des clés d’entreprise ? 21. CERT-FR (ANSSI), Secteur du cloud, État de la menace informatique (CERTFR-2025-CTI-001) 22. CNIL, Les pratiques de chiffrement dans l’informatique en nuage (cloud) public 23. ANSSI, Recommandations de déploiement d’un service IaaS OpenStack SecNumCloud (ANSSI-BP-104)

Password hashing 24. OWASP, Password Storage Cheat Sheet 25. ANSSI / MonServiceSécurisé, Protéger les mots de passe stockés sur le service 26. ANSSI, Guide des mécanismes cryptographiques : règles et recommandations (ANSSI-PG-083)

AiTM, MFA, FIDO2 / passkeys 27. The Hacker News, How AitM Phishing Attacks Bypass MFA and EDR, and How to Fight Back 28. Luxgap, Okta/SSO hit by vishing: how FIDO2 blocks MFA bypass 29. WorkOS, Passkeys stop phishing. Your MFA fallbacks undo it. 30. FIDO Alliance, The State of Passkeys 2026: Global Consumer and Workforce Report

eIDAS 2.0 31. EFF, eIDAS 2.0 Sets a Dangerous Precedent for Web Security 32. R Street Institute, Cybersecurity Score, European Union Electronic Identification, Authentication, and Trust Services (eIDAS 2.0)

Chat Control / E2EE 33. European Newsroom, Privacy vs. child protection: EU’s “chat control” plans split member states 34. EFF, EU Parliament Blocks Mass-Scanning of Our Chats, What’s Next? 35. EFF, After Years of Controversy, the EU’s Chat Control Nears Its Final Hurdle: What to Know 36. EDRi, Chat Control is in the final stretch, but it could be a marathon, not a sprint 37. Tech Policy Press, How Europe’s “Chat Control” Regulation Could Compromise American Communications