That might sound like a bureaucratic detail that doesn't touch you directly. But if you work with government clients, critical infrastructure, or even just sell software to organizations operating in the US or EU, this deadline is closer to you than it seems.

Why "post-quantum" cryptography actually matters

Short version: the encryption algorithms we use today — RSA, ECC, the ones behind every TLS handshake and every SSH key — rely on math problems that classical computers can't solve in a reasonable amount of time. A sufficiently powerful quantum computer could, in theory, break them much faster.

The problem isn't just "quantum computers will exist someday." The real problem has a name: harvest now, decrypt later. Someone can steal and store encrypted data today, even without being able to decrypt it yet, and simply wait until a capable enough quantum computer shows up. For any data that needs to stay confidential for more than a few years — government contracts, medical records, intellectual property — the risk is already active, not hypothetical.

Google estimated back in March 2026 that a quantum computer capable of breaking RSA-2048 could arrive as early as 2029. Only 13% of organizations have already moved post-quantum cryptography (PQC) into production, and 60% haven't even seriously started migrating.

The deadlines worth knowing about

It's not a single cutoff date, it's a cascade:

• September 21, 2026 — NIST moves FIPS 140-2 certificates to "Historical." Only FIPS 140-3 (with PQC support) is accepted for new US federal procurement.

• June 22, 2026 — the US president signed Executive Order 14412, the first binding legal mandate for PQC migration for federal civilian agencies and their contractors: December 31, 2030, for key establishment, December 31, 2031, for digital signatures.

• End of 2026 — in the EU, member states are expected to publish national PQC strategies and start inventorying their existing cryptographic systems, under the framework developed by the NIS Cooperation Group.

• 2030–2035 — the broader horizon for completing migration of critical infrastructure and most systems, both in the US and the EU.

Here's the part worth remembering: for large organizations with complex infrastructure, a full migration realistically takes 8 to 15 years. Which means anyone who hasn't started planning yet risks missing the window, no matter how motivated they get later.

Where this actually hits you as a developer

• SSH host keys — most of your server access infrastructure relies on algorithms that are vulnerable over the long term.

• TLS termination — any web-facing service you operate is transmitting data encrypted with algorithms that can theoretically be "harvested" right now.

• Code and firmware signing — if you distribute software or firmware, the digital signatures used for integrity verification fall directly under the new requirements.

• Public procurement — if your company sells to the public sector or to government contractors, you may already be seeing explicit cryptographic compliance requirements showing up in tender specifications.

Even if you don't work directly with government clients, this trend is spreading fast into the private sector too, as major cloud providers align their own roadmaps (Google, for instance, is targeting 2029 to complete its own migration).

What you can actually do right now

You don't need to fix everything in a week, but a few concrete steps genuinely matter:

1. Do a cryptographic inventory — figure out exactly where vulnerable algorithms are used across your infrastructure: certificates, SSH keys, crypto libraries, dependencies.

2. Prioritize long-lived data — anything that needs to stay confidential for 10+ years is already a real "harvest now, decrypt later" target, not a theoretical one.

3. Migrate external-facing protocols first — TLS termination, SSH host keys, and VPN tunnels represent the main surface exposed to attackers.

4. Watch for hybrid schemes — during the transition period, most recommendations (including the ETSI TS 103 744 technical specification) support combining classical and post-quantum algorithms, rather than a sudden, risky switch.

If you want a concrete example of how this topic is already landing on the public procurement agenda, this piece on a infrastructure tender in Israel makes it clear the conversation isn't theoretical for governments anymore — it's already a line item in a budget. For the technical source of truth on the standards themselves, NIST's official Post-Quantum Cryptography Standardization page is the place to go — it covers FIPS 203, 204, and 205 in detail, along with ongoing work on additional algorithms.

The takeaway

September 21, 2026 won't flip a switch overnight, but it marks a clear turning point: "old" cryptography is officially moving from "still acceptable" into "historical" territory. With only 13% of organizations prepared and federal deadlines closing in fast, this is a topic that deserves a lot more attention than it usually gets in day-to-day technical conversations.

If you want to keep an eye on how demand for security and encryption solutions is evolving at the public procurement level, you can follow the software and information systems sector on Tenderwell, where new tenders tied to security, encryption, and standards-compliant infrastructure keep showing up.

But governments and public institutions spend an enormous amount of money on software every year: new portals, internal tools, data platforms, integrations, cybersecurity work, cloud migrations. A meaningful chunk of that spending happens through open, public tenders, and anyone, in principle, can bid on them. Not just the usual suspects.

So why don't more small teams do it?

The real reasons small teams stay away

It's not that developers don't want the work. It's that the process has historically been miserable to navigate:

• Fragmentation. Every country, and often every region or municipality, publishes tenders on its own portal, in its own format, sometimes in its own language.

• Legal noise. Tender documents are written for procurement officers and lawyers, not for the person who'll actually write the code.

• Time cost. Monitoring dozens of portals manually, just to catch the handful of opportunities that fit your skill set, isn't something a two-person team can justify doing every week.

• Opacity. It's hard to tell, from the outside, what a realistic win rate even looks like, or which agencies are worth paying attention to.

For a large IT contractor with a business development team, this friction is a Tuesday. For a small dev team, it's usually enough to make the whole category feel not worth the effort even when the actual work described in the tender is exactly the kind of project they'd love to build.

What's actually changing

Two things have shifted this over the past couple of years.

First, public sector IT spending keeps growing: cloud modernization, digital identity, AI adoption inside government agencies, smart city infrastructure. Analysts tracking the GovTech sector consistently describe it as one of the faster-growing corners of enterprise software, precisely because so much of the underlying infrastructure is still outdated and in active need of replacement.

Second, and this is the part that actually changes things for small teams — the discovery problem is being chipped away at by AI. Instead of checking twenty separate portals by hand, a handful of platforms now pull tender data from hundreds of official sources, standardize it, and let you filter by industry, budget, or location. The more useful part is what happens after the aggregation: AI models classify each listing into a sector, extract the actual requirements from dense legal PDFs, and generate a short summary you can skim in under a minute instead of reading a twenty-page document to figure out if it's even relevant.

That's the real unlock. It's the difference between "government contracts are a full-time research job" and "government contracts are a filtered search you check once a week, with the boring part already done for you."

What this looks like in practice

Picture a three-person dev shop that mostly builds internal tools and dashboards for mid-sized companies. They've never bid on public work, mostly because they assumed it meant giant infrastructure projects they couldn't compete for.

In reality, a large share of government IT tenders are small and specific: a data visualization tool for a regional health department, a booking system for a municipal library network, an accessibility audit and rebuild of an old citizen portal. Exactly the size of project a small team can deliver well, and exactly the kind of listing that's easy to miss if you're not actively monitoring the right sources.

This is where aggregator platforms earn their keep. Most group tenders by sector, including a dedicated category for software, IT services, and digital transformation work — instead of leaving you to guess which of hundreds of daily listings might be relevant. For a small team, that kind of filtering is what turns "we should really look into this someday" into an actual Tuesday-morning routine: a five-minute check instead of a weekend of manual digging.

Practical first steps

If you want to actually try this rather than just read about it, here's roughly what it takes:

1. Register as a supplier. Most public buyers require this before you can even view full tender documents. It's usually a one-time process per country or platform.

2. Learn to read a CPV code. The EU's Common Procurement Vocabulary (and equivalent classification systems elsewhere) tags every tender by category. IT services and software development typically fall under specific numeric ranges. This breakdown of how CPV codes are structured is a good starting point if the system is new to you. Once you know which digits to look for, filtering becomes much faster.

3. Start with the official sources directly, even if you later add an aggregator on top. In the EU, that's Tenders Electronic Daily (TED), the official publication platform for public procurement. In the US, it's SAM.gov, the federal government's system for contract opportunities.

4. Read a few closed or awarded tenders before bidding. Most platforms let you see who won past contracts and roughly what they were worth. This can help you understand whether a category is realistically competitive for a team your size.

5. Prepare boilerplate documents in advance, such as company registration proof, references, and standard capability statements, so you're not scrambling every time a good opportunity appears with a tight deadline.

It's not effortless, and that's worth saying honestly

None of this makes public procurement easy. Some tenders require certifications or track records small teams simply don't have yet. Timelines can be slower than private-sector clients. Paperwork, even in a good process, is still paperwork.

But "harder than a cold DM to a startup founder" and "not worth attempting" are two different things. For teams willing to spend a little time understanding the process, public tenders are one of the few markets where the buyer's budget, requirements, and deadline are all public information before you even reach out, which is more than you can say for most private-sector sales.

Have you ever looked into bidding on a public tender, or did the process put you off before you even started? Curious what specifically got in the way.

Recent healthcare contracts in Spain provide a small view of how hospitals manage these needs, from maintaining existing medical equipment to ensuring a stable supply of essential medicines.

Maintaining the equipment behind hospital care

Medical equipment does not stop being important after it is purchased. Machines, hospital beds, and technical systems require regular maintenance, replacement parts, and specialist support.

In 2022, Hospital Clínic de Barcelona awarded a contract for the supply of materials, spare parts, and preventive maintenance services for Hill-Rom equipment. The agreement covered maintenance activities for medical equipment used inside the hospital.

The contract had an initial value of €209,620 without VAT and included a planned duration of 45 months, with the possibility of a further 12-month extension. The details of the Hill-Rom equipment maintenance contract at Hospital Clínic de Barcelona show how hospitals often rely on long-term agreements to reduce equipment downtime.

This type of spending is becoming increasingly important as healthcare systems modernize. In 2026, Spain’s healthcare authorities announced new centralized agreements for medical technology equipment, including radiology and cardiology systems, with an estimated investment of more than €185 million.

Ensuring continuous medicine supply

Another major category of hospital spending is pharmaceuticals. Unlike equipment purchases, medicine contracts are often connected directly to daily patient care because hospitals need regular deliveries.

Hospital Universitari Vall d’Hebron in Barcelona recently awarded a contract for the supply of medicines. The agreement was awarded through a negotiated procedure and included requirements related to delivery times, quantities, packaging, and technical conditions. The medicine supply contract awarded by Hospital Universitari Vall d’Hebron was signed with Chiesi España, S.A.U. The contract period ran until July 2026 and included detailed conditions for how products should be delivered and managed.

These details show that medicine procurement is not only about choosing a supplier. Hospitals also need predictable logistics, quality controls, and reliable access to treatments.

A look at healthcare priorities through contracts

These examples show two different but connected challenges for hospitals. Medical equipment needs regular maintenance to remain safe and available, while medicines require reliable supply chains to support patient treatment. Both areas require careful planning because interruptions can directly affect daily hospital operations.

Healthcare systems are going through a lot of changes. Spain is investing in new medical technologies while hospitals continue managing essential services such as equipment maintenance and medicine supply. Together, these examples show the many layers behind a functioning healthcare system, from large technology investments to the everyday services that keep hospitals running.