When should an SME begin its post-quantum transition?

The right trigger is where the required confidentiality lifetime of the data, the time needed to migrate and uncertainty about an exploitable quantum threat intersect. Inventory uses of RSA, elliptic curves, certificates and key exchange. Prioritise data that must remain confidential for a long time and can be collected today. Test hybrid mechanisms with suppliers before any broad production rollout.

Does the HSM decrypt all data in envelope encryption?

In the usual architecture, the KMS or HSM protects the master key and decrypts the data key, while the authorised application decrypts the bulk data with that key. The KEK remains in the key-management service or HSM. The DEK exists temporarily in plaintext within the authorised component processing the data. IAM controls, logs and the DEK's lifetime therefore remain decisive.

Does a hash or MAC make a backup immutable?

A hash detects a change and a MAC authenticates its source, but neither prevents deletion, replacement or rollback to an older version on its own. Integrity requires a protected reference or authentication key. Immutability requires retention lock, WORM storage or an equivalent control. Recovery also requires isolated copies, versioning and regular tests.

Does quantum computing already make AES-128 vulnerable?

No: NIST considers that AES-128 should remain secure for decades despite Grover's theoretical advantage, while AES-256 provides additional margin for new sensitive architectures. The more urgent quantum threat concerns asymmetric cryptography used for key exchange and signatures. Choosing AES-256 does not remove the need to manage keys, nonces and authenticated-encryption modes correctly.

Do passkeys block every form of phishing?

WebAuthn resists credential theft through a false domain by binding authentication to the origin, but account security still depends on the endpoint, recovery, fallback methods and session protection. A synced passkey may be backed up across devices; a hardware key can remain bound to one authenticator. An attacker who steals a session cookie or controls the endpoint bypasses the problem solved by authentication. Privileged accounts benefit from hardware authenticators and tightly controlled recovery.

Does eIDAS 2.0 require browsers to integrate every authority on European trusted lists?

The Commission says that browsers must recognise QWACs and display their identity data, but are not required to integrate or directly use national trusted lists. A website's use of a QWAC remains voluntary. The final scope differs from criticism made during negotiations about imposed browser trust. Businesses should follow the implementing rules and retain a response procedure for compromised certificates.

Junyr Method™

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

29 May 2026 · Updated on 6 September 2026 · 18 min read · Paul-Antoine Tual

ANSSI encryption cryptography FIDO2 AI Junyr Method NIST passkeys SME post-quantum digital sovereignty

Cryptography has become a leadership decision because the post-quantum transition, attacks on identity and European requirements jointly affect data lifetimes, service continuity and the ability to change suppliers.

Prioritise data by sensitivity and required confidentiality lifetime.
Map protocols, certificates, libraries, keys and supplier dependencies.
Modernise through compatible, reversible trials before moving critical systems.
Govern access to keys, recovery methods and evidence of integrity.

The one-sentence takeaway. Crypto-agility is the ability to replace an algorithm, key or supplier without rebuilding the information system or interrupting essential uses.

1. The post-quantum transition: deciding amid uncertainty

1.1. What changes today

A cryptographically relevant quantum computer does not exist today, but Shor’s algorithm could eventually threaten RSA and elliptic curves, which already makes preparation rational for data exposed to the “Store Now, Decrypt Later” scenario.

Future threat: a sufficiently capable quantum computer could recover secrets protected by today’s main asymmetric mechanisms.
Present exposure: an adversary can retain encrypted TLS or VPN traffic and wait for a decryption capability.
Priority rule: address first the data whose confidentiality lifetime, plus migration lead time, overlaps a plausible quantum-risk horizon.
Limit: that horizon remains uncertain; a universal threshold of five or ten years would suggest precision the technology does not support.

Exchange confidentiality generally deserves the first effort because an interception can be stored now, whereas forging a signature normally requires an operational capability at the time of attack.

Key exchange: test hybrid mechanisms first for TLS, VPN and administrative access.
Signatures: also inventory certificates, PKI, code signing and firmware, whose replacement cycles can be long.
Dependencies: ask suppliers about formats, support timelines and rotation procedures.

1.2. Standards are available

Since August 2024, NIST’s first three final post-quantum standards have provided an implementation base, while protocols, libraries and parameters using them still require their own assessment.

ML-KEM establishes shared secrets to protect confidentiality.
ML-DSA and SLH-DSA produce digital signatures with different size and performance trade-offs.
LMS/XMSS, already standardised in SP 800-208, suit some stateful-signature uses, including firmware.

Standard	Original name	Standardised name	Function	Main use
FIPS 203	CRYSTALS-Kyber	ML-KEM	Key encapsulation	Secret establishment and protection against SNDL
FIPS 204	CRYSTALS-Dilithium	ML-DSA	Digital signature	Certificates, PKI and code signing
FIPS 205	SPHINCS+	SLH-DSA	Stateless digital signature	Diversification and long-lived uses
SP 800-208	LMS / XMSS	LMS / XMSS	Stateful signature	Firmware and environments that strictly manage state

1.3. Hybridisation as a transition

During the transition, ANSSI recommends combining a proven classical primitive with a post-quantum primitive so that the construction retains protection if either family remains secure, subject to a sound combiner and implementation.

Assurance: the classical component offsets the limited history of the new algorithms.
Long-term confidentiality: the post-quantum component addresses the risk that classical cryptography is broken later.
Cost: larger keys, ciphertexts and signatures increase message sizes and can expose network incompatibilities.
Reversibility: suites must remain negotiable, observable and replaceable according to the applicable doctrine and supplier support.

2. Data in transit: test the whole chain

Migrating TLS, IPsec and SSH depends as much on firewalls, proxies, concentrators and libraries as on algorithms, because larger messages can break a connection whose cryptography is otherwise correct.

Inventory protocol versions, TLS termination points, inspection devices and old clients.
Test fragmentation, round trips, latency, failure rate and fallback behaviour.
Deploy progressively, monitor negotiation and retain a controlled rollback procedure.

2.1. TLS 1.3 and QUIC

TLS 1.3 is the main field for hybrid trials — Cloudflare observed this version on more than 93% of connections on its own network in early 2024 — and groups such as X25519MLKEM768 add enough data to the ClientHello to expose fragile intermediaries.

Scope of the figure: 93% describes connections observed by Cloudflare in 2024, rather than every secure connection worldwide.
Compatibility: test paths containing TLS inspection, firewalls, load balancers, NAT and reduced-MTU links.
Ossification: GREASE helps implementations reveal intolerance to new values, without replacing end-to-end tests.
Authentication: track the standardisation and support of post-quantum certificates and signatures separately.

2.2. IPsec and IKEv2

For IPsec, the post-quantum issue is concentrated in IKEv2 key establishment rather than a data plane correctly configured with strong symmetric encryption, and several RFCs supply the components required for larger or multiple exchanges.

RFC 7383: fragmentation of IKE messages at the protocol layer.
RFC 9242: the IKE_INTERMEDIATE exchange for carrying additional payload before authentication.
RFC 9370: negotiation of multiple key exchanges to construct a hybrid solution.
RFC 8784: a post-quantum pre-shared key, useful as an additional defence in some closed systems.

An upgrade must target combinations actually supported by every client, gateway and security policy, because a firmware’s reference to an RFC guarantees neither interoperability nor appropriate parameters.

Check compatibility matrices and maximum message sizes.
Test rekeying, recovery after interruption and high availability.
Surface silent refusals and fallbacks to a weaker suite in monitoring.

2.3. SSH

OpenSSH has offered a hybrid key exchange by default since version 9.0 and has used mlkem768x25519-sha256 by default since OpenSSH 10.0, released in April 2025, enabling a practical migration wherever both endpoints support it.

Compatibility: update servers, administrator workstations, bastions and automation before requiring the new suite.
Verification: inspect the algorithm actually negotiated instead of inferring protection from the version number alone.
Scope: post-quantum key exchange protects session confidentiality; it does not automatically make host-key or user-key signatures post-quantum.

2.4. Group messaging and MLS

The Messaging Layer Security standard (MLS, RFC 9420) organises key establishment for asynchronous groups around a tree, reducing the cost of group updates and providing an extensible framework without automatically making every deployment post-quantum.

Scale: an update follows a logarithmic path through the tree rather than a separate renegotiation with every member.
Security: guarantees depend on the implementation, identity management and selected cipher suites.
Supplier choice: verify protocol version, audits, interoperability and the post-quantum roadmap rather than relying on the MLS label alone.

3. Data at rest: algorithms, keys and retention

For stored data, AES remains a sound base and NIST considers that AES-128 should remain secure for decades despite Grover’s algorithm, while AES-256 adds margin without solving poor management of keys, nonces or access.

Algorithm: use a correctly configured authenticated mode, such as AES-GCM where appropriate.
Margin: prefer AES-256 in a new sensitive architecture when its cost and compatibility are acceptable.
Operations: separate duties, limit access, log use and test rotations.

3.1. Envelope encryption

Envelope encryption separates data processing from protection of master keys: a DEK encrypts the content, then a centrally managed KEK wraps that DEK to limit exposure of the more sensitive key.

Encryption: the application generates or receives a DEK, encrypts the data locally and stores the content with the wrapped DEK.
Key decryption: the KMS, potentially backed by an HSM, uses the KEK to unwrap the DEK after authorisation.
Bulk decryption: the authorised service then uses the plaintext DEK in its own memory; the bulk data does not normally pass through the HSM.
Controls: HSM certification, FIPS level, rotation and separation of duties follow the risk and applicable requirements; Level 3 is not a universal requirement.

3.2. Sovereignty and control of keys

Control of keys reduces some legal and operational risks, but no acronym guarantees sovereignty on its own if the supplier can still reach plaintext, the execution component or an unwrapped key during processing.

Supplier-managed keys: maximum simplicity, with minimal customer control over authorisation and revocation.
BYOK / CMEK: stronger lifecycle governance, although the supplier can often use the key to provide the authorised service.
External KMS / HYOK: the KEK-use decision remains outside the supplier, adding availability, latency and integration dependencies.
Client-side encryption: the strongest protection from supplier access when keys and plaintext genuinely remain outside its perimeter, sometimes at the cost of cloud functionality.

The decision must therefore connect jurisdiction, location, processing architecture and technical access, treating SecNumCloud as a broader qualification with its own requirements rather than as another name for one key model.

Classify data and identify every actor able to reach plaintext.
Check contracts, subcontractors, access logs, revocation and KMS-outage scenarios.
Have the architecture and legal basis validated for the relevant sector and transfers.

3.3. Backup integrity and immutability

A recoverable backup combines cryptographic detection of changes, retention that blocks deletion and an operating model able to survive compromise of the primary domain, because none of these layers replaces the other two.

Integrity: a protected hash detects change; a MAC or signature authenticates the evidence according to the threat model.
Immutability: retention lock or WORM storage prevents overwrite and deletion for a defined period.
Rollback resistance: versioning, protected indexes or logs and controlled recovery points.
Recovery: an isolated copy, separate administrative identities and measured restore exercises.

4. Identities: passwords, phishing and recovery

Identity work often delivers a rapid effect because it joins three controllable decisions — proper secret storage, origin-bound authentication and removal of weak fallbacks — while still requiring a workable recovery path.

Protect existing passwords with a slow, appropriate derivation function.
Deploy WebAuthn for privileged accounts and then exposed populations.
Harden enrolment, recovery and revocation as carefully as normal authentication.

4.1. Storing passwords correctly

A password should pass through a slow derivation function with a unique salt, using parameters measured on the infrastructure and reviewed over time so that every guess remains expensive after a database leak.

Argon2id is OWASP’s general recommended choice.
scrypt provides a memory-resistant alternative.
bcrypt is retained for legacy systems and requires explicit handling of its 72-byte input limit.
PBKDF2-HMAC-SHA-256 remains relevant when FIPS compliance is required, with an iteration count matched to maintained guidance.

Algorithm	Use	OWASP benchmark consulted on 6 September 2026
Argon2id	General choice	m = 19 MiB, t = 2, p = 1 minimum, then tuned by measurement
scrypt	Alternative	N = 2¹⁷, r = 8, p = 1, or a documented equivalent trade-off
bcrypt	Legacy	Work factor ≥ 10; common 72-byte limit
PBKDF2-HMAC-SHA-256	FIPS need	≥ 600,000 iterations under the consulted OWASP guidance

A pepper adds a defence when its secret remains separate from the database, for example in a KMS or HSM, but it requires rotation and recovery procedures that account for the fact that losing it prevents verification.

The salt is unique to each password and may be stored with the hash.
The pepper is shared across a defined scope, secret and absent from the application database.
Algorithm version and parameters accompany each stored value to allow progressive migration.

4.2. Where conventional MFA fails

SMS codes, TOTP and push approval remain useful against password theft alone, but an AiTM proxy can relay a login in real time and recover the session token after otherwise successful authentication.

The user connects to a domain controlled by the attacker.
The proxy relays the legitimate service’s pages and challenges.
The code or MFA approval is forwarded while valid.
The resulting session token may then be reused, depending on the service’s protections.

The response must combine phishing-resistant authentication with session protection, because training users to recognise every imitation stops neither real-time relay nor theft from an already authenticated endpoint.

Prefer WebAuthn/FIDO2 to prevent a signature intended for the wrong domain.
Reduce fallback methods and monitor unusual enrolment or recovery.
Limit session lifetime and scope, then detect anomalous reuse.

4.3. FIDO2 and passkeys: a precise guarantee

WebAuthn binds each public credential to its relying party and asks the authenticator to sign a challenge in the context of that origin, resisting credential phishing without promising that the account is invulnerable.

Origin: a page on a false domain cannot request an assertion valid for the real service.
Key: the authenticator manages the private key; multi-device passkeys may be backed up or synced, while hardware keys can remain device-bound.
Residual risk: weak recovery, fallbacks, endpoint compromise and session theft sit outside the origin guarantee.

Figures published by the FIDO Alliance on 7 May 2026 indicate broad adoption but need their scope: five billion passkeys is a worldwide estimate, while 68% deployed or actively deploying came from 1,400 decision-makers at organisations with at least 500 employees across ten countries.

The global estimate counts credentials rather than five billion distinct users.
The enterprise survey does not specifically represent French SMEs.
Deployment choices should follow the organisation’s population, endpoints and recovery constraints.

5. The European framework: separate the text, its interpretation and its status

Two European files affect digital trust, but they require a precise, dated reading of scope rather than a general conclusion about certification authorities or end-to-end encryption.

eIDAS 2.0 covers, among other matters, qualified website authentication certificates and their presentation.
Fighting online child sexual abuse: a temporary measure and a proposed permanent framework follow distinct paths.

5.1. eIDAS 2.0, QWACs and browsers

According to the European Commission FAQ consulted on 6 September 2026, browsers must recognise a QWAC and display the attested identity data in a user-friendly form, while a website’s use of a QWAC remains voluntary and browsers are not obliged to integrate national trusted lists.

Obligation: recognise the QWAC and present identity data within the browser environment.
Technical freedom: the vendor chooses the display mechanism and need not integrate the trusted lists directly.
Security debate: criticism concerning incidents, revocation and governance should be attributed to its authors rather than treated as a description of the final text.

For critical applications, the useful controls are to know the relevant authorities and certificates, monitor Certificate Transparency, keep browsers and libraries current and prepare rapid revocation; pinning suits only applications that truly control their update and recovery cycle.

Inventory certificates, authorities, expiry dates and operational owners.
Alert on unexpected issuance and test renewal.
Restrict pinning to managed clients, with backup keys and a proven rotation procedure.

5.2. The temporary measure and future EU framework

As at 6 September 2026, the EU had reinstated until 3 April 2028 a temporary derogation allowing certain voluntary detection of child sexual abuse material, while permanent rules remained under negotiation and cannot be inferred from this transitional agreement.

The Council gave its final approval to the temporary measure on 23 July 2026.
The adopted amendments exclude number-independent interpersonal communications to which end-to-end encryption applies, has applied or is intended to apply.
The Council says that this temporary exclusion does not prejudge its position on the future permanent framework.

A business assessment must distinguish the technical possibility of scanning on an endpoint from its effects on the security model, confidentiality and professional duties, because moving inspection before encryption does not preserve every expected E2EE guarantee.

Track the interim regulation and permanent proposal separately.
Identify the services, communication types and data categories actually in scope.
Subject any client-side inspection to risk, applicable-law and reporting-governance review.

6. Where to focus effort in 2026 with the Junyr Method™

The Junyr grid can order progress without acting as a security certification: Artisan addresses the foundations, Orchestre makes change manageable and Architecte aligns data lifetimes, suppliers and governance.

The horizons below are indicative and depend on inventory, contracts and renewal cycles.
Each level should produce verifiable evidence: configurations, logs, tests and accountable owners.
No level removes the need for a sector-appropriate risk assessment.

At Artisan level, the organisation secures the foundations in a first short cycle by addressing identities, storage and operational ownership.

Correct password storage and remove fast hashing algorithms.
Deploy WebAuthn for privileged accounts with hardened recovery.
Verify authenticated encryption at rest and isolate critical backups.
Appoint an owner for keys, certificates and deadlines.

At Orchestre level, the organisation establishes crypto-agility across subsequent cycles by linking its inventory to trials, key choices and controlled automation.

Map flows, certificates, libraries, hardware and confidentiality lifetimes.
Test hybrid TLS, IKEv2 and SSH exchanges with interoperability measurements.
Choose BYOK, External KMS or client-side encryption from the threat model.
Automate rotation, expiry alerts and configuration checks.

At Architecte level, the organisation governs time and dependencies by bringing long-term risk, continuity and supplier roadmaps into its decisions.

Prioritise post-quantum migration by SNDL exposure and replacement lead time.
Test KMS continuity, revocation, restoration and supplier exit.
Bring MLS, PKI and post-quantum roadmaps into purchasing decisions.
Maintain dated regulatory monitoring with owners and review criteria.

Junyr Agents™ can assist repetitive inventory, monitoring and rotation-preparation work provided that the system fixes their rights, approvals and logs and assigns security decisions to named people.

Agents collect and reconcile technical evidence.
Deterministic policies limit their access and actions.
Accountable owners approve key, certificate and configuration changes.

Conclusion

A credible cryptographic strategy in 2026 rests neither on a claimed “Q-Day” date nor on any technology presented as absolute, but on a demonstrable ability to inventory, migrate, limit access, detect changes and restore services.

Start with long-lived data, privileged identities and old dependencies.
Test the post-quantum transition over real paths before enforcing it.
Treat confidentiality, integrity, immutability, availability and sovereignty separately.
Revisit choices when standards, law or supplier support changes.

Position your organisation with the Junyr AI maturity audit.

Sources: direct links and references, editorial update of 6 September 2026

Frequently asked questions

When should an SME begin its post-quantum transition?: The right trigger is where the required confidentiality lifetime of the data, the time needed to migrate and uncertainty about an exploitable quantum threat intersect.

Inventory uses of RSA, elliptic curves, certificates and key exchange.
Prioritise data that must remain confidential for a long time and can be collected today.
Test hybrid mechanisms with suppliers before any broad production rollout.
Does the HSM decrypt all data in envelope encryption?: In the usual architecture, the KMS or HSM protects the master key and decrypts the data key, while the authorised application decrypts the bulk data with that key.

The KEK remains in the key-management service or HSM.
The DEK exists temporarily in plaintext within the authorised component processing the data.
IAM controls, logs and the DEK's lifetime therefore remain decisive.
Does a hash or MAC make a backup immutable?: A hash detects a change and a MAC authenticates its source, but neither prevents deletion, replacement or rollback to an older version on its own.

Integrity requires a protected reference or authentication key.
Immutability requires retention lock, WORM storage or an equivalent control.
Recovery also requires isolated copies, versioning and regular tests.
Does quantum computing already make AES-128 vulnerable?: No: NIST considers that AES-128 should remain secure for decades despite Grover's theoretical advantage, while AES-256 provides additional margin for new sensitive architectures.

The more urgent quantum threat concerns asymmetric cryptography used for key exchange and signatures.
Choosing AES-256 does not remove the need to manage keys, nonces and authenticated-encryption modes correctly.
Do passkeys block every form of phishing?: WebAuthn resists credential theft through a false domain by binding authentication to the origin, but account security still depends on the endpoint, recovery, fallback methods and session protection.

A synced passkey may be backed up across devices; a hardware key can remain bound to one authenticator.
An attacker who steals a session cookie or controls the endpoint bypasses the problem solved by authentication.
Privileged accounts benefit from hardware authenticators and tightly controlled recovery.
Does eIDAS 2.0 require browsers to integrate every authority on European trusted lists?: The Commission says that browsers must recognise QWACs and display their identity data, but are not required to integrate or directly use national trusted lists.

A website's use of a QWAC remains voluntary.
The final scope differs from criticism made during negotiations about imposed browser trust.
Businesses should follow the implementing rules and retain a response procedure for compromised certificates.

Paul-Antoine Tual

AI Transformation Leader · Junyr Method™ · Transition manager specialising in AI for French SMEs and mid-caps. Engineer from the École des Mines de Nantes, lawyer, developer since 1993.

Free AI Maturity Audit →

← All articles