Post quantum security for small businesses and open source projects

[DarkLantern]

TL;DR

• Small organisations and open source projects will get most post quantum protection through updates to browsers, operating systems, cloud services and libraries
• The most useful steps today are keeping software current, enabling hybrid key exchange on servers, and checking SSH and TLS configurations
• OpenSSL 3.5 and OpenSSH 10.0 support ML-KEM, OpenSSH uses hybrid post quantum key exchange by default, and OpenSSH 10.1 warns when a connection lacks it
• Ask suppliers and SaaS providers a few simple questions about their post quantum plans, especially if your customers include government or regulated sectors
• Open source projects should plan for post quantum release signing as tooling such as Sigstore, Go and OpenSSL adds ML-DSA support

Why this guide exists

Most post quantum guidance is written for governments and large enterprises with dedicated security teams. Small businesses, charities, startups and volunteer run open source projects read those documents and wonder what applies to them. The answer is reassuring. Much of the heavy lifting is already being done by the vendors and projects you rely on, and the steps you need to take are modest and affordable

This thread sets out what small organisations and open source maintainers should know and do. It avoids enterprise jargon and focuses on practical actions that fit limited time and budgets. It also explains when post quantum questions might come from customers, which is increasingly common in supply chains. By the end, you should have a short, realistic plan

A quick reminder of the threat helps frame the advice. A future quantum computer could break the public key cryptography that protects most online connections and signatures today. Attackers can record encrypted traffic now and decrypt it later, a strategy called harvest now, decrypt later. That makes long lived sensitive data the priority, while signatures need replacing before a capable machine arrives

What you get for free through updates

If you use a modern browser, you are probably already protected for much of your web traffic. Chrome, Edge, Firefox and other major browsers use a hybrid key exchange combining X25519 with ML-KEM when the server supports it. Large websites and content delivery networks support it widely, and Cloudflare reports that more than two thirds of browser traffic to its network is protected this way. Simply keeping browsers updated is one of the most effective post quantum steps anyone can take

Major cloud and SaaS providers are moving too. Google has set a 2029 target for its own systems, Cloudflare has set a 2029 goal for full post quantum security across its services, and Microsoft plans early adoption by 2029 and full transition by 2033. When these providers upgrade their infrastructure, their small business customers inherit the benefits. That is a big part of why small organisations do not need large migration budgets

Messaging apps provide another example. Signal and Apple's iMessage have added post quantum protection to their protocols, so conversations on those platforms gain protection automatically after updates. Operating systems are adding support in their TLS stacks and certificate tools. The pattern is consistent: update regularly and you benefit

Password managers and encrypted storage services are worth a quick look too. Many protect stored data with strong symmetric encryption, which already holds up well against known quantum attacks. Their sync and sharing features use public key cryptography, so ask whether those parts have a post quantum plan. Reputable providers will answer clearly

Your own servers and websites

If you run your own web servers, check which TLS library they use. OpenSSL 3.5, released in April 2025, added ML-KEM, ML-DSA and SLH-DSA, and recent versions of web servers built against it can offer hybrid key exchange such as X25519MLKEM768. Let's Encrypt explicitly advises server operators to enable hybrid post quantum key exchange now, because encryption is the more urgent risk. Many hosting providers and managed platforms handle this for you, so check their documentation first

If your site sits behind a content delivery network or reverse proxy, the connection between visitors and the proxy may already be post quantum. The connection from the proxy to your origin server may not be. Some providers support post quantum key exchange on that origin connection as well, so it is worth checking the settings. Protecting both legs matters for sensitive data

Certificates are a separate matter. Public post quantum certificates are not yet available for the web, and Chrome and Let's Encrypt are working on Merkle Tree Certificates targeted for 2027. Small site owners do not need to do anything about certificates yet beyond keeping automated renewal working. When the new certificates arrive, ACME clients and hosting platforms should handle most of the change

SSH and remote access

SSH is one of the easiest places to check your post quantum status. OpenSSH 10.0, released in April 2025, made the hybrid mlkem768x25519-sha256 key exchange its default, and earlier versions from 9.0 used another hybrid called sntrup761x25519-sha512 by default. OpenSSH 10.1 warns users when a connection does not use post quantum key exchange, which is a helpful nudge for spotting old servers. If you see that warning, update the server or its SSH configuration

GitHub added a hybrid post quantum SSH key exchange for Git access in September 2025, so developers using modern SSH clients benefit when pushing and pulling code. VPN products are adding post quantum options too, though support varies widely. Ask your VPN provider whether it supports ML-KEM or another hybrid key exchange and when. These are quick checks that cover a lot of everyday traffic

Questions to ask suppliers

Small organisations depend heavily on suppliers, so a few well chosen questions go a long way. Ask whether the service supports post quantum key exchange today, which standards it follows, when signatures and certificates will move, and whether you need to do anything. You do not need to understand the cryptography in depth to judge the answers. Clear, specific replies naming FIPS 203 and 204 are a good sign, while vague promises suggest a supplier has not planned yet

These questions matter more if your customers include government bodies or regulated industries. In the US, Executive Order 14412 requires federal contractors to meet post quantum FIPS requirements by the end of 2030, and that expectation will flow down supply chains. In the UK and EU, larger customers following NCSC and EU guidance may ask about your plans in security questionnaires. A short written answer prepared in advance saves time and builds trust

Protecting long lived data

Think about which of your data must stay confidential for many years. Customer records, health information, legal documents, intellectual property and financial records are typical examples. For data stored at rest, strong symmetric encryption such as AES-256 remains robust against known quantum attacks. The bigger concern is data sent over networks under classical key exchange, which could be recorded today

Sensible steps include using services that support post quantum key exchange for transferring sensitive files, minimising how long you keep sensitive data, and deleting what you no longer need. Data that no longer exists cannot be decrypted by anyone. Good data hygiene is one of the cheapest and most effective quantum defences available. It also helps with privacy law compliance

Email deserves a brief mention. Most email between providers is protected in transit by TLS, which will gain post quantum key exchange as providers upgrade. End to end encrypted email standards such as OpenPGP have post quantum extensions in development at the IETF. For highly sensitive material, a messaging app with post quantum protection may be a better choice for now

Open source projects: signing and dependencies

Open source projects have particular responsibilities because others depend on their code. The most important long term task is planning for post quantum signatures on releases, packages and commits. Today, most projects sign with classical algorithms through GPG, SSH signatures or Sigstore. Those signatures will eventually need post quantum replacements so that users can trust downloads after Q-Day

Tooling is moving in that direction. Sigstore has added ML-DSA to its protocol specification and is working on crypto agility so services can support new algorithms. Go added a standard library ML-KEM package in Go 1.24, and other language ecosystems are adding post quantum libraries. Maintainers do not need to switch today, but they should follow these developments and avoid designs that hard code a single signature algorithm

Projects that implement cryptography themselves face bigger questions. If your library offers TLS, SSH, signing or key management features, users will increasingly ask for ML-KEM and ML-DSA support. Relying on well reviewed implementations such as those in OpenSSL, BoringSSL, AWS-LC or the Open Quantum Safe project is usually wiser than writing your own. Side channel resistance is hard to get right, and reusing mature code protects users

Dependency management matters too. A project may be post quantum ready in its own code but depend on an older library that is not. Keeping dependencies current and noting cryptographic dependencies in a software bill of materials helps users assess risk. The CycloneDX format can describe cryptographic assets, and US guidance on cryptographic bills of materials is due from CISA and NIST in 2027

Continuous integration systems can help maintainers here. Automated checks can flag outdated cryptographic libraries, weak SSH settings on build servers or signing keys due for rotation. Small investments in automation repay themselves many times over. They also make it easier for new contributors to follow good practice

A small organisation action plan

• Keep browsers, operating systems, phones and apps updated automatically
• Check that your web servers, hosting or CDN offer hybrid X25519MLKEM768 key exchange
• Update SSH servers and clients to versions with post quantum key exchange and watch for OpenSSH warnings
• Ask key suppliers three questions: what is supported now, what is planned, and what do we need to do
• Identify long lived sensitive data and minimise how long you keep it
• Prepare a short paragraph describing your post quantum approach for customer questionnaires
• For open source maintainers: follow Sigstore and language ecosystem PQC work and plan for agile release signing

Keeping it in proportion

Small organisations face many security risks, and most are far more immediate than quantum computers. Phishing, weak passwords, missing backups and unpatched software cause the majority of real incidents. Post quantum readiness should fit alongside those basics, not replace them. Happily, the most important post quantum step, keeping software updated, is also one of the best defences against everyday threats

There is no need for expensive consultancy or special hardware. Be wary of anyone selling small businesses quantum encryption boxes or quantum proof products with dramatic claims. National agencies recommend standard post quantum cryptography delivered through ordinary software. That is good news for budgets

Closing thoughts

Post quantum security is achievable for organisations of every size. For small businesses and open source projects, it mostly means staying current, asking good questions and planning a little ahead. The global ecosystem is doing the hard work, and you benefit each time you install an update. A few hours of checking and planning puts you in a strong position for the years ahead

If you run a small business or maintain an open source project, please share how you are approaching this below. Practical stories from small teams are rare and very valuable. Questions are welcome too, however basic they may seem


Key references for citation

• OpenSSL 3.5 release notes, April 2025
• OpenSSH post-quantum cryptography page (openssh.org/pq.html)
• GitHub, post-quantum security for SSH access on GitHub, September 2025
• Let's Encrypt, post-quantum certificates announcement, 3 June 2026
• Sigstore, Sigstore and post-quantum cryptography, 2025
• CISA, NSA and NIST, Quantum-Readiness: Migration to Post-Quantum Cryptography fact sheet, August 2023