Risk Overview
The vulnerability is the same as in HTTPS: the key exchange step. The application protocol
(FTP, SMTP, SQL) is irrelevant — what matters is whether the handshake uses RSA or classical
Diffie-Hellman. If it does, the session can be harvested today and decrypted later.
For the full explanation see Harvest Now, Decrypt Later.
| Protocol |
PII Carried |
Key Exchange |
HNDL Risk |
PQC Status |
| SFTP / SSH |
File payloads: HR, health, financial data |
RSA / ECDH (custom SSH KEX) |
High |
OpenSSH 9.0+ supports ML-KEM hybrid |
| FTPS |
Batch file transfers, EDI, partner data |
TLS (RSA or ECDH) |
High |
Depends on TLS version of server |
| SMTP / STARTTLS |
Email bodies, attachments |
TLS (RSA or ECDH) |
High |
No widely deployed PQC yet |
| LDAPS |
Employee PII, credentials, org structure |
TLS (RSA) |
High |
Depends on AD / LDAP server TLS config |
| Kerberos (PKINIT) |
Authentication tokens, identity |
RSA (certificate-based) |
Medium |
Microsoft roadmap in progress |
| IPsec / IKEv2 |
All tunnelled traffic including PII |
RSA / DH / ECDH (IKE) |
High |
RFC 9370 (ML-KEM for IKEv2) published |
| Database TLS |
Raw PII queries and responses |
TLS (RSA or ECDH) |
High |
Depends on DB engine TLS version |
| SIP / SRTP |
Voice/video calls (HIPAA, financial) |
DTLS / TLS (RSA or ECDH) |
Medium |
No standard PQC path yet |
| gRPC |
Internal microservice PII payloads |
TLS (RSA or ECDH) |
Medium |
Inherits from underlying TLS stack |
| MQTT (TLS) |
IoT sensor data, healthcare device data |
TLS (RSA or ECDH) |
Medium |
Inherits from underlying TLS stack |
External Connections
External connections are sessions that cross the internet between your organisation and an
outside party: a partner sending files, a vendor receiving data exports, mail servers
exchanging email. These sessions are not protected by a CDN. The CDN edge handles HTTP traffic.
Everything here bypasses it entirely and connects directly to your systems or goes directly
to the destination. There is no intermediary to configure. The TLS or SSH session is end-to-end
between your network and the external party, across the public internet, fully capturable.
This is the category where the harvest-now-decrypt-later exposure is most direct. The traffic
is already on the internet. An adversary does not need to be inside your network to capture it.
SFTP runs over SSH. The encryption is handled by SSH's own key exchange mechanism, which
is separate from TLS. SSH uses its own handshake protocol defined in RFC 4253. The key
exchange negotiation happens before any data is transmitted, and the algorithm used
determines whether the session is quantum-vulnerable.
PII Carried
Payroll exports, HR records, health data files, financial statements, partner EDI. SFTP is the standard transport for scheduled bulk PII transfers between organisations.
Key Exchange
SSH negotiates a KEX algorithm at connection time. Common algorithms: diffie-hellman-group14-sha256, ecdh-sha2-nistp256. Both are broken by Shor's algorithm. The negotiated algorithm is visible in the SSH handshake and can be captured.
HNDL Exposure
An adversary capturing the SSH handshake has the encrypted key exchange material. Once RSA or ECDH is broken, the session keys can be derived and all transferred file data decrypted.
PQC Path
OpenSSH 9.0+ (released 2022) supports sntrup761x25519-sha512, a hybrid post-quantum KEX algorithm. This is enabled by default in recent OpenSSH versions. Check your SSH server version and verify the negotiated algorithm with ssh -vvv.
Verify the negotiated algorithm:
ssh -vvv user@host 2>&1 | grep "kex algos\|KEX"
Look for
sntrup761x25519-sha512 in the output. If you see only classical
algorithms, the server or client doesn't support PQC KEX or it's been disabled.
FTPS is FTP over TLS. It uses the same TLS handshake as HTTPS, which means it has exactly
the same quantum vulnerability. The key exchange step in the TLS handshake uses RSA or ECDH,
and that handshake data is capturable on any internet-facing FTPS server.
PII Carried
Batch file transfers between organisations: insurance claims, payroll data, patient records, EDI transactions. Often automated, often unmonitored.
Key Exchange
TLS handshake (same as HTTPS). If the FTPS server is running TLS 1.2 with RSA key exchange, the handshake is quantum-vulnerable. TLS 1.3 with ECDH is classically forward-secret but still not quantum-safe without ML-KEM.
HNDL Exposure
Same as HTTPS. The TLS handshake can be captured on the wire. The payload (the file being transferred) can be decrypted retroactively once the key exchange is broken.
PQC Path
Upgrade the FTPS server to TLS 1.3. Then enable ML-KEM if the server software supports it. Many FTPS servers run on older stacks (FileZilla Server, IIS FTP) and may not have TLS 1.3 support at all. Audit the minimum TLS version first.
SMTP between mail servers uses STARTTLS to upgrade a plaintext connection to TLS.
The TLS session established during STARTTLS uses the same RSA or ECDH key exchange
as any other TLS connection. The email body, attachments, and headers are all
encrypted within that session.
PII Carried
Email bodies and attachments: HR communications, patient correspondence, financial advice, legal documents, authentication codes, password resets. Email is one of the highest-volume PII carriers in any organisation.
Key Exchange
TLS via STARTTLS. Most mail servers still negotiate TLS 1.2. The key exchange is RSA or ECDH depending on the cipher suite. The handshake happens between mail servers (MTA-to-MTA), not between the user's client and the server.
HNDL Exposure
An adversary with visibility at an internet exchange point or ISP can capture MTA-to-MTA SMTP sessions. The TLS handshake is captured. Email content transmitted years ago can be decrypted once RSA is broken. Email is particularly attractive because the content has long-term value.
PQC Path
No widely deployed PQC for SMTP yet. NIST and IETF are working on standards. For now: enforce TLS 1.3 on MTA connections where possible, and use MTA-STS to prevent downgrade attacks. Monitor vendor roadmaps (Google, Microsoft) for ML-KEM support in mail infrastructure.
STARTTLS vs SMTPS: SMTPS (port 465) wraps SMTP directly in TLS from
the start. STARTTLS (port 587 or 25) begins in plaintext and upgrades. Both end up in
a TLS session with the same key exchange vulnerability. The distinction matters for
downgrade attacks but not for the quantum threat.
Internal Connections
Internal connections are sessions within your network perimeter: directory lookups,
database queries, service-to-service calls, VPN tunnels between sites. These sessions
do not cross the public internet in the same way external connections do, but they are
not invisible. An adversary with access to internal network traffic (a compromised host,
a misconfigured span port, a cloud VPC tap, or access to backbone infrastructure) can
capture them just as easily.
Internal traffic also tends to carry more concentrated PII. A database query returns
raw records. An LDAP response contains the full directory. A VPN tunnel between two
sites contains everything. The harvest exposure here is lower probability but higher
value per capture.
LDAP is the protocol used to query directory services: Active Directory, OpenLDAP, and
similar systems. LDAPS wraps LDAP in TLS on port 636. LDAP with STARTTLS on port 389
is also common. Both carry highly sensitive PII and authentication data.
PII Carried
Employee names, email addresses, phone numbers, job titles, department, manager hierarchy, group membership. Also authentication: password hashes (in some configurations), Kerberos tickets, NTLM hashes. LDAP queries reveal organisational structure in detail.
Key Exchange
TLS handshake over port 636. Most enterprise Active Directory deployments use TLS 1.2. The RSA certificate on the domain controller is used for key exchange. Capturing the LDAP session captures both the directory query and the response containing employee PII.
HNDL Exposure
An adversary capturing LDAPS sessions gains: the directory data (PII), the authentication exchanges, and potentially credential material. This is a high-value target because the data is structural and long-lived, not transactional.
PQC Path
Upgrade Active Directory domain controllers to support TLS 1.3. Windows Server 2022 supports TLS 1.3 for LDAPS. Microsoft's PQC roadmap for AD is in progress. Until ML-KEM is available in AD, enforce TLS 1.3 and strong ECDH cipher suites as an interim measure.
Kerberos is the default authentication protocol in Active Directory. In its basic form
it uses symmetric key cryptography (AES), which is not quantum-vulnerable. However,
PKINIT (Public Key Cryptography for Initial Authentication) is a Kerberos extension
that uses RSA certificates for the initial ticket exchange, and that part is vulnerable.
PII Carried
Authentication identity and authorisation data. Kerberos tickets encode the user's identity and group membership. Compromising ticket exchange exposes who authenticated, when, and to what resources.
Key Exchange
PKINIT uses RSA to encrypt the session key in the AS-REQ/AS-REP exchange. This is equivalent to TLS 1.2 RSA key exchange. The encrypted session key material is visible on the network and capturable. Standard Kerberos (without PKINIT) uses symmetric AES and is not quantum-vulnerable at this step.
HNDL Exposure
Limited compared to TLS protocols, because Kerberos tickets are short-lived and the data inside is primarily identity rather than business PII. However, authentication data captured today could be used to establish identity context for future attacks.
PQC Path
Microsoft has announced PQC support for Active Directory Kerberos as part of their post-quantum roadmap. No generally available release yet. This is a lower-urgency item than LDAPS or SMTP given that standard Kerberos without PKINIT is not RSA-dependent.
IPsec site-to-site VPNs carry all traffic between network segments, including every
protocol listed on this page. The quantum vulnerability is in IKEv2, the key exchange
protocol that establishes the IPsec Security Associations. If IKEv2 is broken, the
entire tunnel is decryptable.
PII Carried
Everything tunnelled through the VPN: SFTP, LDAP, database queries, internal HTTP, email relaying. IPsec is a transport-layer protection, so the PII depends on what runs inside the tunnel. In a typical site-to-site VPN, this includes all inter-site traffic.
Key Exchange
IKEv2 uses RSA certificates or pre-shared keys for authentication and Diffie-Hellman (DH groups 2, 14, or ECDH) for key exchange. The DH exchange in IKEv2 Phase 1 is exactly the step a quantum computer breaks. RFC 9370 defines ML-KEM key exchange for IKEv2.
HNDL Exposure
An adversary capturing encrypted IPsec traffic between two sites has the IKEv2 handshake and all the tunnelled data. If the IKE key exchange is broken, every session within the tunnel is decryptable. This is the highest-volume exposure: all inter-site PII in one capture target.
PQC Path
RFC 9370 (ML-KEM for IKEv2) was published in 2024. Support is appearing in major VPN vendors. Check your VPN platform (Cisco, Palo Alto, Fortinet, StrongSwan) for IKEv2 PQC support. StrongSwan added ML-KEM support in 2024. Cisco and Palo Alto have roadmap commitments.
Why IPsec is a priority target: A single captured IPsec session between
two datacenters can contain years of PII from every internal protocol. One harvest point,
maximum exposure. Upgrading IKEv2 to ML-KEM closes the quantum risk for everything inside
the tunnel simultaneously.
Direct database connections from applications to database servers use TLS for encryption.
These sessions carry raw SQL queries and responses, which contain the actual PII stored
in the database, not a sanitised API response.
PII Carried
Raw database records: full names, DOB, SSN, health conditions, financial account data, authentication credentials. The application layer typically filters or transforms PII before exposing it via an API. The database connection sees it all.
Key Exchange
TLS handshake between the application server and the database server. MySQL, PostgreSQL, and MSSQL all support TLS, but default configurations vary. Many deployments run TLS 1.2 with RSA certificates. The key exchange is identical in structure to HTTPS.
HNDL Exposure
Capturing a database TLS session gives raw query results. A SELECT on a patient table returns every patient record in that query. This is the most direct path to PII in any application stack. Lateral movement within a network targeting database ports is a known attack pattern.
PQC Path
Database TLS inherits PQC support from the underlying TLS library:
- PostgreSQL: Uses OpenSSL. Supports TLS 1.3. ML-KEM available when compiled against OpenSSL 3.5+.
- MySQL / MariaDB: Uses OpenSSL or yaSSL. TLS 1.3 supported in MySQL 8.0+. ML-KEM roadmap in progress.
- MSSQL: Uses Schannel on Windows. Microsoft PQC for Schannel is in development as part of the broader Windows PQC rollout.
SIP (Session Initiation Protocol) establishes voice and video calls. The actual media
is encrypted with SRTP (Secure Real-time Transport Protocol). The key exchange for SRTP
typically happens via DTLS-SRTP, which uses DTLS (Datagram TLS) and inherits the same
RSA or ECDH vulnerability as TLS.
PII Carried
Voice and video content of calls: patient consultations (HIPAA), financial advisory calls (SEC record-keeping requirements), M&A discussions, legal privileged communications. Metadata is also sensitive: who called whom, when, for how long.
Key Exchange
DTLS-SRTP uses a DTLS handshake to exchange keys for SRTP media encryption. DTLS is TLS over UDP. The key exchange uses RSA or ECDH. Capturing the DTLS handshake captures the key material needed to decrypt the call audio once RSA is broken.
HNDL Exposure
Lower urgency than persistent data (files, database records) because call content has a shorter useful life. However, for high-value targets (executive calls, M&A, regulatory matters) the content may retain value for years. Metadata (who called whom) retains value indefinitely.
PQC Path
No widely deployed PQC standard for DTLS-SRTP yet. IETF is working on PQC for DTLS. Vendor support (Cisco, Zoom, Microsoft Teams) is in early roadmap stages. This is a medium-term item rather than immediate priority for most organisations.
gRPC is a high-performance RPC framework used for communication between microservices.
It runs over HTTP/2 with TLS. The quantum vulnerability is in the TLS handshake, which
is identical to any other TLS connection. The concern here is internal service-to-service
traffic that carries PII between components of an application.
PII Carried
Depends on the application. In a microservices architecture, gRPC calls between an auth service, a user profile service, and a payment service can carry full PII payloads. Internal traffic is often trusted more than external traffic but is equally visible to an internal adversary or network tap.
Key Exchange
TLS 1.2 or 1.3 depending on the gRPC server configuration. Many internal deployments use self-signed certificates and TLS 1.2 without careful cipher selection. The TLS handshake is the same as HTTPS and equally vulnerable.
HNDL Exposure
An adversary with access to internal network traffic (via a compromised host, a misconfigured mirror port, or a cloud VPC tap) can capture gRPC sessions. Internal traffic is often assumed safe and therefore monitored less carefully, making it a viable harvest target.
PQC Path
gRPC inherits PQC from the underlying TLS stack. If the application server and client are running a TLS library with ML-KEM support (OpenSSL 3.5+, BoringSSL with ML-KEM), gRPC will negotiate it automatically once configured. This is one of the easier protocols to upgrade because it follows TLS.
MQTT is a lightweight publish-subscribe messaging protocol used extensively in IoT.
When secured, it runs over TLS on port 8883. Healthcare IoT (patient monitors, wearables),
industrial IoT, and smart building systems use MQTT and often carry PII or operationally
sensitive data.
PII Carried
Healthcare: patient vitals, device readings, medication pump data. Industrial: operational data that may identify individuals or processes. Building systems: occupancy, access control events. The PII exposure depends heavily on the deployment domain.
Key Exchange
TLS handshake on port 8883. MQTT brokers (Mosquitto, HiveMQ, AWS IoT Core) use TLS for transport security. The key exchange is RSA or ECDH depending on the broker configuration and the TLS version in use. IoT devices often have constrained TLS stacks running older cipher suites.
HNDL Exposure
IoT devices are long-lived. A medical device deployed today may still be in operation in 15 years, transmitting the same TLS sessions with the same cipher suites. This is one of the hardest environments to upgrade and one of the longest harvest windows.
PQC Path
Highly dependent on the IoT device. Constrained devices (microcontrollers) may not have the compute or memory for ML-KEM. Managed cloud IoT brokers (AWS IoT, Azure IoT Hub) will gain PQC support as their TLS stacks are updated. For existing deployments: prioritise by data sensitivity and device replaceability.
The IoT upgrade problem: Unlike a server, an IoT device cannot always
be patched remotely. Some devices require physical replacement to change their TLS stack.
In healthcare, device replacement requires regulatory re-certification. The harvest window
for IoT MQTT traffic can extend well beyond the timeline for quantum computers to arrive.