Roughly 65 percent of the most popular mobile apps have disclosed nothing about how they plan to protect user data once quantum computers can crack today’s encryption. A Surfshark review of 40 widely used apps found that only 8 percent already employ post-quantum cryptography, even though the National Institute of Standards and Technology finalized its first three post-quantum encryption standards back in August 2024 and declared them ready for immediate use. Banking apps, shopping apps, and nearly every social platform in the sample scored zero on quantum readiness, leaving billions of encrypted messages, financial records, and personal files on a collision course with hardware that does not yet exist at scale but is advancing fast.
Why the 8 percent figure demands attention right now
The threat is not theoretical in the way most people assume. Adversaries can intercept and store encrypted traffic today, then decrypt it years later once a sufficiently powerful quantum machine is available. Cryptographers call this a “harvest now, decrypt later” attack, and it turns every app that handles sensitive data into a time-delayed vulnerability. The fact that only 8 percent of the 40 apps analyzed have adopted post-quantum protections means the vast majority of daily digital activity, from bank transfers to private chats, sits behind encryption that has an expiration date.
A reasonable expectation would be that companies with deep ties to government contracts or critical infrastructure would move first, since federal agencies are under executive and congressional pressure to migrate their own systems. The Surfshark data offers a partial test of that idea. TikTok, whose parent company operates a sprawling global infrastructure and has faced intense regulatory scrutiny, is the only social app in the sample using post-quantum cryptography. Messaging apps showed slightly higher preparation rates overall. Yet no banking or shopping app in the review has made the switch, despite the fact that financial institutions routinely hold federal contracts and face strict data-protection mandates. The pattern suggests that regulatory pressure alone has not been enough to push consumer-facing products toward quantum-safe encryption within the first 18 months after the NIST standards landed.
The timing matters because encryption transitions are slow even under ideal conditions. Replacing core cryptographic primitives requires redesigning protocols, updating software development kits, testing for performance regressions, and coordinating with third-party services and hardware vendors. For apps with hundreds of millions of users, a misstep can break logins, payments, or messaging. That complexity is one reason security teams argue that migration to post-quantum cryptography must start well before large-scale quantum computers actually arrive.
What the Surfshark review and independent research found
Surfshark’s analysis sorted the 40 apps into three tiers. The top tier, apps already running post-quantum cryptography, contained just 8 percent of the sample. A middle tier of about 30 percent showed evidence of researching or planning a transition. The remaining roughly 65 percent offered no public information on quantum resistance at all, according to the same review. Category breakdowns sharpen the picture: zero banking apps and zero shopping apps qualified for the top tier, and NIST’s finalized standards, FIPS 203, FIPS 204, and FIPS 205, have been publicly available since August 2024, giving developers more than a year to begin integration work.
An independent academic study hosted on arXiv reached a similar conclusion through code-level and documentation analysis. That preprint on quantum readiness found that the broader app ecosystem remains largely unprepared for post-quantum cryptography. The overlap between the two analyses is notable because they used different methods: Surfshark relied on public disclosures and product documentation, while the arXiv researchers examined code artifacts and bibliographic records. Both arrived at the same bottom line: adoption is minimal.
The NIST standards themselves were designed for practical deployment. FIPS 203 covers a general-purpose key-encapsulation mechanism, FIPS 204 addresses digital signatures, and FIPS 205 provides a hash-based signature scheme. All three were declared ready for immediate use upon release, meaning the bottleneck is not a lack of approved algorithms but a lack of engineering effort inside app development teams. In other words, the cryptographic building blocks exist; what is missing is the decision by product owners to prioritize them.
Some sectors face particularly high stakes. Banking and payment apps aggregate long-lived financial identifiers, transaction histories, and identity documents that could be valuable for years after collection. Health apps increasingly store medical records and biometric data that, once exposed, cannot be revoked or reissued. If attackers are already harvesting and archiving this traffic, the security value of today’s encryption could evaporate in a single technological leap.
Gaps in the evidence and what to watch next
Several open questions limit how far anyone can push these findings. Surfshark’s review relied on publicly available disclosures, so an app developer that has quietly begun integrating FIPS 203 or FIPS 204 into its codebase would not appear in the top tier unless it announced the work. No independent audit logs or code-commit records from the 40 app developers were included in the study, and NIST’s own National Vulnerability Database does not currently track which commercial apps have integrated the new algorithms in production builds. The arXiv preprint, while useful as a second data point, has not yet undergone formal peer review.
The absence of raw scan data or a fully reproducible methodology from the Surfshark review also means outside researchers cannot verify the exact criteria used to classify each app. Were apps scored on transport-layer encryption alone, or did the review also assess data-at-rest protections? The published percentages do not answer that question. It is also unclear how hybrid deployments-where classical and post-quantum algorithms are combined-were treated in the scoring.
There is a broader measurement problem as well. Unlike patching a known software vulnerability, post-quantum readiness is not a single yes-or-no state. An app might use quantum-resistant key exchange for some connections but not others, or protect backups with new algorithms while leaving live traffic on legacy protocols. Without consistent reporting standards, two assessments could reach different conclusions about the same product.
Despite these caveats, the alignment between Surfshark’s high-level findings and the arXiv team’s more technical review suggests that the signal is real: most consumer apps are still in the early stages of planning, if they have started at all. Future research that combines public documentation, network traffic analysis, and selective code inspection could narrow the uncertainty and give regulators and users a clearer picture.
What users and developers can do now
For ordinary users, the practical takeaway is straightforward. If an app handles financial transactions, health records, or private messages, check whether its developer has published a post-quantum roadmap or security white paper. Many companies maintain trust centers, transparency reports, or technical blogs where they describe encryption choices. The absence of any mention of post-quantum plans does not prove inaction, but it is a signal that the issue may not be a near-term priority.
Users can also pressure providers directly. Security and privacy settings pages increasingly include contact links or feedback forms; asking when an app will adopt NIST-approved post-quantum algorithms helps demonstrate demand. Enterprises that rely on popular consumer apps for internal communication or payments can push even harder, baking quantum-safe requirements into procurement contracts and vendor questionnaires.
For developers, the message from both Surfshark and the academic community is that waiting for quantum hardware to arrive is no longer defensible. Teams can begin by inventorying where cryptography is used in their stacks, mapping which libraries and protocols will need to change, and testing hybrid approaches that combine classical and post-quantum algorithms. Because the NIST standards are already finalized, early pilots can focus on performance, interoperability, and user experience rather than algorithm selection.
Regulators and industry groups, meanwhile, can help by standardizing how post-quantum readiness is reported. Clear labels, similar to existing disclosures for two-factor authentication or end-to-end encryption, would make it easier for users to compare apps and for watchdogs to track progress. Over time, such transparency could shift the current picture-where only a small minority of apps have moved-toward a baseline expectation that sensitive data will be protected against both today’s attackers and tomorrow’s quantum machines.
More from Morning Overview
*This article was researched with the help of AI, with human editors creating the final content.
