Humanitarian organisations routinely handle information that can put people at risk if it is exposed or altered. A shelter registration may reveal the location of displaced families. A medical referral may contain sensitive health information. A protection case file may identify a survivor, witness, or community leader. A logistics message may disclose the location of a warehouse, convoy, clinic, or field team.
These systems depend on cryptography to protect confidentiality, authenticate users, and detect tampering. The concern behind post-quantum cryptography is that some public-key systems used today could eventually be broken by sufficiently capable quantum computers. NIST explains that quantum computing could threaten current encryption and digital-signature systems, while noting that the relevant machines may still be years or decades away. [1] [2]
That future threat matters because humanitarian data often has a long life. An attacker may capture encrypted traffic today and attempt to decrypt it later. Sensitive information can remain consequential years after collection, particularly in protection, health, identity, land, and conflict-related programmes.
Post-quantum cryptography does not mean sending messages through a quantum network. It means using conventional software and hardware with algorithms designed to resist attacks from both conventional and quantum computers. NIST finalised its first three post-quantum standards in 2024 and encourages organisations to begin migration rather than wait for a cryptographically capable quantum computer. [1]
WHAT HUMANITARIAN SYSTEMS NEED TO PROTECT
A humanitarian organisation rarely has one communication system. It may use cloud applications, email, mobile data collection, satellite links, radio gateways, identity providers, case-management platforms, health systems, warehouse tools, and partner APIs. Each may use cryptography differently.
The first task is not simply to install a new algorithm. It is to identify where vulnerable public-key cryptography is used and which data and services depend on it. CISA, NSA, and NIST recommend a quantum-readiness roadmap, a cryptographic inventory, supply-chain assessment, and engagement with technology vendors. [3]
The inventory should cover mobile data-collection platforms, case-management systems, email and collaboration tools, satellite or radio gateways, identity services, cloud platforms, partner APIs, backups, and archived data. For every system, the organisation should record the public-key algorithms in use, certificates and trust relationships, data sensitivity, vendor, owner, replacement cycle, and migration status.
NIST’S FIRST STANDARDS
NIST’s initial standards address two core functions. ML-KEM, specified in FIPS 203, is a key-encapsulation mechanism for establishing shared secrets across a public network. ML-DSA, specified in FIPS 204, and SLH-DSA, specified in FIPS 205, are digital-signature standards used for authentication and integrity. [1] [2]
A key-encapsulation mechanism is not a complete messaging system. It helps two parties establish a shared secret, after which symmetric encryption protects the data. Digital signatures help a recipient verify that a message, software package, form, or configuration came from an authorised source and was not altered.
Replacing one public-key algorithm does not automatically secure a field application. The application still needs secure session handling, endpoint authentication, access control, logging, device protection, key recovery, and safe data deletion. Post-quantum migration is one change within a wider security architecture.
NIST states that ML-KEM, ML-DSA, and SLH-DSA are intended to provide the f
REAL-TIME APPLICATIONS IN THE FIELD
Consider a flood assessment team using an offline-capable mobile form. A worker records a household location, shelter capacity, urgent protection concern, or damaged health facility while disconnected. When connectivity returns, the device synchronises with the coordination platform. Post-quantum migration matters at several points: the device-to-server session, the identity used to authenticate the worker, the signed application update, and the partner API that moves the record into a dashboard. The system still needs consent, data minimisation, duplicate detection, and human review; cryptography protects the channel but does not make an inaccurate assessment reliable.
A second example is an emergency medical referral. A clinic may send a patient record, referral code, or bed-availability update to a referral centre over a public network. ML-KEM could support establishment of a shared secret in a future-ready transport layer, while ML-DSA or another approved signature scheme could help verify the sending service and detect changes to a referral message. The clinical workflow must still restrict who can read the record, avoid unnecessary personal details, and provide a safe fallback when the network is unavailable.
The same principle applies to real-time logistics. A coordination cell may receive a vehicle position, warehouse stock level, cold-chain alarm, or delivery confirmation from several partners. A secure API needs more than encryption: it needs authenticated services, replay protection, time and sequence checks, role-based access, and a way to revoke a compromised partner credential. During migration, the organisation should test message size and handshake delays on the satellite, cellular, or radio-backed links that field teams actually use.
Emergency alerts provide another practical case. A warning service may distribute a flood evacuation message, wildfire perimeter update, shelter change, or security notification to staff and partner organisations. Digital signatures can help recipients distinguish an authorised alert from a forged message, but the trust list, key rotation process, language, accessibility, and human confirmation procedure are equally important. A signed false input is still a dangerous input, so the alerting workflow needs independent verification.
Software and configuration updates are also real-time operational events. A field data-collection application, satellite gateway, or local coordination server may need a security patch while a response is active. Post-quantum-ready signatures can form part of a verified update chain, allowing a device to check that a package came from an approved publisher and was not altered in transit. The update process should support staged rollout, rollback, offline verification, and recovery when only some devices reconnect.
These examples show why post-quantum cryptography should be treated as an operational upgrade rather than a distant research topic. It can strengthen the trust foundations of data collection, medical coordination, logistics, alerts, and software maintenance, while humanitarian teams continue to manage the equally important problems of power, connectivity, identity, governance, and human judgement.
ADDITIONAL REFERENCES
Additional References
NIST IR 8547 — Transition to Post-Quantum Cryptography Standards: https://csrc.nist.gov/pubs/ir/8547/ipd
NIST — Considerations for Achieving Crypto Agility: https://csrc.nist.gov/news/2025/nist-releases-cswp-39-for-public-comment
IETF RFC 9954 — Hybrid Key Exchange in TLS 1.3: https://www.rfc-editor.org/info/rfc9954
NIST NCCoE — Migration to Post-Quantum Cryptography FAQ: https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/
