Every encrypted session your organization runs today is a quiet bet about the future. The wager is that the mathematics protecting it — the TLS handshake behind your customer portal, the VPN tunnel linking your data centers, the signatures on your firmware updates — will stay unbreakable for as long as the data underneath needs to remain secret. Against a classical attacker that bet is sound. Against an adversary who records your ciphertext today and simply waits for a cryptographically relevant quantum computer, it is reckless. That patient strategy has a name — harvest now, decrypt later — and in 2026 it has graduated from an academic footnote to a line item on serious risk registers across Europe and North Africa.
The reason to act now, rather than on the morning a quantum breakthrough makes headlines, is simple arithmetic. Take the number of years your data must remain confidential, add the number of years it will realistically take to migrate every system to quantum-resistant cryptography, and compare that sum against the estimated arrival of practical quantum decryption. If the first two numbers together exceed the third, you are already exposed: the traffic leaving your network this week can be broken well within its useful lifetime. Cryptographers call this Mosca's inequality, and it is the single most useful lens for the whole transition. It reframes the question from "when will quantum computers arrive" to "how long can we afford to wait before starting" — and for most organizations handling long-lived data, the honest answer is that they cannot afford to wait at all.
The Standards Are Final and the Excuses Are Gone
For years the defensible answer to "which algorithm should we adopt" was "wait for NIST." That excuse expired in 2024. The National Institute of Standards and Technology has published its first post-quantum standards, and they are stable, named, and ready for production:
- ▸FIPS 203 (ML-KEM): the Module-Lattice Key-Encapsulation Mechanism, derived from CRYSTALS-Kyber. It replaces RSA and elliptic-curve key exchange — the mechanism that protects data in transit and is therefore the top priority against harvesting.
- ▸FIPS 204 (ML-DSA): the Module-Lattice Digital Signature Algorithm, derived from CRYSTALS-Dilithium, the general-purpose successor to RSA and ECDSA signatures.
- ▸FIPS 205 (SLH-DSA): a stateless hash-based signature scheme built on SPHINCS+. It is larger and slower, but rests on conservative hash-function assumptions, making it a strong hedge for long-lived roots of trust and firmware signing.
A fourth signature standard based on FALCON, expected as FIPS 206 (FN-DSA), will add compact signatures for constrained environments. The lattice-based schemes are not experimental; they are the consensus output of a multi-year open competition, and reference implementations are already shipping inside mainstream libraries.
What the Threat Actually Touches
Harvest now, decrypt later is not a uniform risk — it is sharply weighted toward data with a long secrecy lifetime. A session cookie that expires in an hour is worthless to an attacker who can only decrypt it years from now. A twenty-year state secret, a patient genome, or a decade of intellectual property is a different matter entirely.
- ▸Confidentiality of long-lived data: health records, biometric templates, financial histories, trade secrets, and diplomatic or defense communications — anything whose value outlives the migration window.
- ▸Key exchange first: because ciphertext can be captured passively and stored cheaply, quantum-vulnerable key establishment (RSA, ECDH) is the most urgent surface. This is where ML-KEM earns its priority.
- ▸Signatures as a slower burn: forging a signature requires an attacker with a working quantum computer in the present, not a recording from the past. The risk is real but less acute, with one exception: trust anchors and firmware signed today that must stay valid for a decade or more.
Step One Is Always Visibility
You cannot migrate cryptography you cannot see, and most organizations dramatically underestimate how much of it they run. Cryptography hides in TLS terminators, database drivers, message queues, hardware security modules, IoT firmware, hardcoded library calls, and third-party dependencies nobody has audited in years. The modern discipline for surfacing all of it is the Cryptographic Bill of Materials (CBOM), an extension of the CycloneDX software-bill-of-materials format that catalogs algorithms, key lengths, certificates, and their locations.
Treat discovery as an engineering project in its own right: scan source repositories for cryptographic API calls, inventory every certificate and its issuer, interrogate your TLS endpoints for negotiated suites, and map which business processes depend on which primitives. The output is a prioritized target list ranked by data sensitivity and exposure — the foundation of every credible migration plan.
A Practical Migration Roadmap
1. Establish executive ownership: name an accountable owner and fold post-quantum readiness into the enterprise risk register, not just the security team backlog. 2. Build and maintain a CBOM: inventory every algorithm, certificate, key store, and dependency, and keep it current as a living artifact. 3. Apply Mosca's inequality per data class: rank systems by secrecy lifetime plus migration effort. Long-lived confidential data at the internet edge goes first. 4. Adopt hybrid key exchange for data in transit: deploy combinations that run a classical algorithm and ML-KEM together, so a break in either one alone does not compromise the session. 5. Re-architect for crypto-agility: remove hardcoded algorithm assumptions so future swaps become configuration changes rather than rewrites. 6. Modernize PKI and signing: pilot ML-DSA and SLH-DSA for code and firmware signing where signature size and verification cost are manageable. 7. Test, measure, and rehearse rollback: validate interoperability, watch handshake latency and payload sizes, and confirm you can revert cleanly before touching production at scale.
Regulation Has Become the Forcing Function
The transition is no longer purely voluntary. A cluster of European rules now makes cryptographic resilience an auditable obligation, and their reach extends to any supplier serving the EU market.
- ▸NIS2: broadens the scope of essential and important entities and hardens supply-chain security expectations, pulling encryption governance into the compliance perimeter.
- ▸DORA: obliges financial entities and their ICT providers to manage technology risk end to end, including the cryptography protecting operational resilience.
- ▸EU Cyber Resilience Act (CRA): sets security-by-design duties for products with digital elements and demands vulnerability management across a product lifetime — a lifetime that will outlast classical cryptography for many devices.
- ▸GDPR: continues to require appropriate technical measures for personal data. "Appropriate" is a moving target, and knowingly relying on harvestable encryption for long-lived personal data sits uneasily beside it.
National authorities such as France's ANSSI and Germany's BSI have already published guidance favoring hybrid deployments during the transition, signaling the direction of travel for the whole bloc.
What This Means for Tunisia and North Africa
For Tunisian and wider North African technology firms, the post-quantum shift is not an abstract European concern — it is a commercial one. The region's nearshoring model depends on serving EU clients in banking, healthcare, telecommunications, and public administration, precisely the sectors where NIS2, DORA, and the CRA now push cryptographic requirements down the supply chain. An EU bank subject to DORA will increasingly expect its Tunisian development and operations partners to demonstrate a credible crypto-agility posture as a condition of the contract.
- ▸Data residency and local law: Tunisia's personal-data regime under Law 2004-63 and the oversight of the Instance Nationale de Protection des Données à Caractère Personnel (INPDP) already shape how cross-border data is handled. Post-quantum readiness becomes part of the same due-diligence conversation.
- ▸Talent as an advantage: the region's strong pipeline of mathematics and engineering graduates is well suited to lattice-based cryptography and secure-systems work. Firms that invest early can turn post-quantum expertise into a differentiator rather than a compliance cost.
- ▸Cost and timing: migration is cheaper when planned than when forced. Nearshore providers that build CBOMs and pilot hybrid TLS now will avoid the premium of a rushed, contract-threatening scramble later.
The strategic point is straightforward: European buyers are beginning to treat quantum-safe capability as a procurement criterion, and North African suppliers who can answer the question early will win work from those who cannot.
What to Do Monday
- ▸Assign one accountable owner for post-quantum readiness and put it on the risk register this week.
- ▸Start the CBOM with a single scan of your internet-facing TLS endpoints and your most sensitive data store.
- ▸Identify your three longest-lived confidential data classes and calculate Mosca's inequality for each.
- ▸Enable hybrid key exchange in one non-critical service to learn the operational realities before deadline pressure arrives.
- ▸Ask every critical vendor for their post-quantum roadmap. The answers will sort your supply chain quickly.
The organizations that navigate this transition well will not be the ones that predicted the arrival of quantum computers most precisely. They will be the ones that treated cryptography as something to be inventoried, abstracted, and rotated on demand — a managed asset rather than a buried assumption. The standards are finished, the regulatory pressure is compounding, and the harvesting, if it is happening, is happening now. In 2026 the work is unglamorous and entirely doable: see your cryptography, rank it by how long it must survive, and begin swapping the most exposed pieces first. The window to do this calmly, rather than under duress, is open — but like every good bet, it will not stay open forever.