Ready for the quantum era? Where Big Tech's apps actually stand

Quantum computing is edging closer to breaking the cryptographic primitives used to protect today’s internet traffic, making it urgent for the apps and services we rely on to adopt post-quantum security. Two standards lead that shift: ML-KEM, which is used for a post-quantum approach to key exchange, and ML-DSA. Certificates based on ML-DSA algorithms are used to authenticate and verify the identities of servers or resources. Surfshark reviewed 15 widely used apps and platforms to see which publicly confirm using each. This assessment reflects what companies have disclosed and the threats known today; an undisclosed rollout can't be ruled out, and defenses considered strong now may need to evolve as new threats appear.

Key insights

• There are two quantum migrations, and only the easy one is happening. Securely encapsulating the key exchange part with ML-KEM is a near drop-in upgrade, so it has spread quickly; proving identity with ML-DSA means overhauling the shared system of trust behind every secure connection, which is why 8 of the 15 services reviewed have deployed ML-KEM but only 2 have deployed ML-DSA.¹,⁹,¹⁰
• The two "deployed" ML-DSA cases aren't apps at all. Both are cloud key-management services — Google Cloud KMS and AWS KMS — where ML-DSA is offered as a signing option that a customer has to actively choose and integrate, not something that's on by default.⁹,¹⁵
• Not a single consumer app in the review has moved its identity checks to ML-DSA, which means the headline capability exists mostly as infrastructure waiting to be used.⁷,¹⁶,⁸
• "Available" is quietly doing a lot of work in company announcements. Apple ships ML-DSA to app developers and Microsoft built it into Windows, but neither has turned it on in the products people actually open — Safari, iMessage, Edge, or Microsoft 365.²,⁴,¹² A tool a developer could use is being counted, in headlines, as protection a user already has.
• Your messages are better defended than proof of who sent them. Signal is steadily rolling ML-KEM out to every conversation yet shows no sign of using ML-DSA to authenticate messages,³ and Apple's iMessage encrypts chats with an early post-quantum method while still leaning on pre-quantum technology to verify the sender.⁴
• TikTok confirms ML-KEM for some sensitive data but not direct messages,⁵ while WhatsApp, Messenger, Instagram, Google Messages, X, Reddit, and LinkedIn disclose nothing about either standard for private messages. We label these "no public evidence" rather than "unprotected," but the practical effect is the same: users have no way to verify what, if anything, is guarding their conversations.
• The companies closest to the problem are the most candid about the timeline. Cloudflare and Akamai already run ML-KEM at scale, but openly say post-quantum identity on the web is years out. Cloudflare has ML-DSA live only on limited behind-the-scenes links and is testing a leaner certificate design with Google to make broad use viable.¹,¹¹,¹³ Akamai lists full support as a roadmap item with no firm date.⁶,¹⁴ When the infrastructure providers are still experimenting, the apps riding on top can't be finished either.
• The quantum threat has two deadlines, and we're only meeting the first. ML-KEM counters "harvest now, decrypt later" — data stolen today and cracked tomorrow — which is why it was prioritized.¹,⁷ But once quantum computers can forge signatures, unprotected authentication lets an attacker impersonate a site or contact in real time, and on that front, the everyday internet is barely defended.

Methodology and sources

We assessed 15 widely used apps, platforms, and infrastructure providers to determine whether each publicly confirms using two post-quantum cryptographic standards: ML-KEM (FIPS 203) to establish and exchange the parts of key that build the whole shared secret for encryption, and ML-DSA (FIPS 204), to protect authenticity by verifying that a message, website, or app is genuine. For each provider, we recorded a separate status for ML-KEM and ML-DSA, drawn only from first-party, publicly available sources — company security blogs, official documentation, developer references, and product changelogs — collected as of September 2026.

Each status reflects the strongest verifiable claim a provider makes about its own products, and we distinguish between a capability being available (offered to developers or customers) and a standard being deployed (actively running in a product or service). Where a provider offers a standard as a tool or infrastructure that customers must switch on themselves, it is marked as available rather than deployed. Cases with no first-party confirmation are labeled "no public evidence" rather than "not protected," because a provider may have deployed a standard without disclosing it.

This assessment captures a fast-moving field at a single point in time and reflects public disclosures rather than independent testing of the underlying code. Providers ship updates continuously, so a status recorded here may change; an "available" capability may become a default deployment, and a provider showing no public evidence today may confirm support tomorrow. The findings should therefore be read as a snapshot of what companies have publicly committed to, not a permanent verdict on any app's security.

References