Key Takeaways
- Your patients’ health data is already being harvested for future quantum decryption: The “harvest now, decrypt later” attack is not theoretical. Adversaries are intercepting and storing encrypted health data today, waiting for quantum computers capable of breaking RSA and ECC encryption to unlock it. Patient health records have a confidentiality lifetime measured in decades, making them the single highest-value target for this attack vector. With healthcare data breaches already costing an average of $7.42 million per incident in 2025 and medical records selling for ten times the value of stolen credit card numbers on dark markets, the quantum dimension of this threat transforms a bad situation into an existential one for any organization handling PHI.
- NIST has finalized the standards, and the migration clock is running: In August 2024, NIST released FIPS 204, standardizing ML-DSA (Module-Lattice-Based Digital Signature Algorithm) as the primary post-quantum digital signature scheme. NIST has directed organizations to transition from RSA and ECC to ML-DSA by 2030, with post-quantum cryptography becoming mandatory for federal systems by 2035. The NSA’s CNSA 2.0 timeline is even more aggressive, requiring new National Security Systems acquisitions to be PQC-compliant by January 2027. For mHealth developers, the window between “early mover advantage” and “mandatory compliance scramble” is closing fast.
- The proposed HIPAA Security Rule update makes encryption mandatory, and quantum-safe encryption is the only forward-compatible implementation: HHS published a Notice of Proposed Rulemaking in January 2025 that would make encryption of all ePHI at rest and in transit a mandatory requirement, eliminating the current “addressable” loophole. A final rule is expected in 2026. Organizations that implement encryption today using only classical algorithms will face a second, far more disruptive migration when quantum-safe encryption becomes the regulatory baseline. Implementing ML-DSA and ML-KEM now means you encrypt once, correctly, and avoid the costly rearchitecture that awaits everyone who waits.
The Threat That Is Already Happening
If you are building, operating, or investing in mobile health applications, there is a security conversation you need to be having right now that almost nobody in the mHealth space is having. It is not about the breach that happened last quarter. It is about the breach that is happening right now, in slow motion, invisible to every monitoring system you have in place, and that will not become visible for another five to ten years.
The conversation is about quantum computing and a class of attack called “harvest now, decrypt later.”
Here is how it works. An adversary, whether a nation-state intelligence service, a sophisticated criminal organization, or a state-sponsored hacking group, intercepts encrypted data transmissions today. They cannot decrypt the data because current encryption, RSA-2048, ECDSA, ECDH, is computationally infeasible to break with classical computers. So they store the encrypted data. They wait.
They wait for a sufficiently powerful quantum computer to come online, one capable of running Shor’s algorithm at scale, which will factor the large integers and solve the discrete logarithm problems that underpin every public-key cryptosystem currently protecting your patients’ PHI. When that quantum computer arrives, they decrypt everything they have been collecting. Every patient record. Every diagnosis. Every prescription. Every therapy session note. Every genomic dataset. Everything.
This is not science fiction. The Federal Reserve Board published a paper in September 2025 specifically analyzing the harvest-now-decrypt-later risk and its implications for data protected by current cryptographic systems. The EU Member States, supported by the European Commission, published a Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography on June 23, 2025, setting migration targets of 2030 for high-risk use cases and 2035 for full transition.
An industry coalition led by The Quantum Insider, the Quantum Industry Coalition, and Holland & Knight officially launched 2026 as the “Year of Quantum Security” at a January 2026 convening in Washington, D.C., with participation from senior officials at the FBI, CISA, and NIST. The G7 Cyber Expert Group separately released a formal PQC transition roadmap for the financial sector in January 2026. A 2025 study by Sectigo and Omdia found that 60% of organizations are “very or extremely concerned” about harvest-now-decrypt-later attacks.
For healthcare data, the math is particularly brutal. Patient health records have a confidentiality requirement that extends across the patient’s entire lifetime and, in many cases, beyond. A 35-year-old patient’s records need to remain confidential for another 50 or more years. Data encrypted with RSA-2048 today and intercepted by an adversary today will be trivially decryptable once a cryptographically relevant quantum computer (CRQC) is achieved. Current expert timelines for CRQC range from the early 2030s to the mid-2040s, depending on the source and assumptions. Even the most conservative estimates place CRQC well within the confidentiality lifetime of health data being generated right now.
The mHealth market is enormous and growing rapidly. The global mHealth apps market was valued at approximately $40.65 billion in 2025 and is projected to grow to $45.14 billion in 2026, with North America accounting for nearly 31% of global revenue. These applications are transmitting and storing staggering volumes of PHI every day, from remote patient monitoring data and telehealth session records to prescription management, chronic disease tracking, and mental health therapy notes. Every byte of that data that is protected only by classical encryption is a byte that is vulnerable to harvest-now-decrypt-later.
Meanwhile, the healthcare sector continues to lead all industries in data breach costs. The IBM Cost of a Data Breach Report for 2025 puts the average cost of a healthcare data breach at $7.42 million, and that is the cost of a breach that is detected and disclosed. The cost of a breach that remains invisible for a decade because the decryption has not happened yet is incalculable, and the regulatory, legal, and reputational consequences when it is eventually revealed will dwarf anything the industry has experienced so far.
This is the threat landscape. Now let us talk about the solution.
What ML-DSA Is and Why It Matters for mHealth
On August 13, 2024, NIST released the first three finalized post-quantum cryptography standards, the culmination of an eight-year standardization process that began in 2016 with 82 candidate algorithms and concluded with three production-ready standards designed to remain secure even against adversaries in possession of a large-scale quantum computer.
The three standards are FIPS 203 (ML-KEM, Module-Lattice-Based Key-Encapsulation Mechanism, derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, Module-Lattice-Based Digital Signature Algorithm, derived from CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, Stateless Hash-Based Digital Signature Standard, derived from SPHINCS+). Two additional standards are in development: FIPS 206 will standardize FN-DSA (derived from Falcon), and in March 2025, NIST announced that HQC had been selected as a code-based backup KEM.
For healthcare app developers, the two standards that matter most are ML-DSA (FIPS 204) for digital signatures and ML-KEM (FIPS 203) for key encapsulation.
ML-DSA is a lattice-based digital signature algorithm designed to replace RSA-PSS, ECDSA, and EdDSA across all signature use cases, including certificate signing, code signing, document signing, and authentication token signing. It operates on the mathematical hardness of the Module Learning With Errors (MLWE) problem, which is believed to be resistant to both classical and quantum attacks. NIST has designated ML-DSA as the primary standard for digital signatures and has given explicit guidance that organizations should switch from RSA and ECC to ML-DSA by 2030, with quantum-ready cryptography becoming mandatory for government agencies after 2035.
ML-DSA comes in three parameter sets, each offering increasing security strength at the cost of larger key and signature sizes. ML-DSA-44 provides NIST security level 2 (roughly equivalent to AES-128), with public keys of approximately 1,312 bytes, secret keys of 2,560 bytes, and signatures of 2,420 bytes. ML-DSA-65 provides security level 3 (roughly equivalent to AES-192), and ML-DSA-87 provides security level 5 (roughly equivalent to AES-256). For comparison, an RSA-2048 signature is 256 bytes and an ECDSA-P256 signature is 64 bytes, so the size increase is substantial but manageable for modern mobile hardware and network bandwidth.
Performance is already competitive with classical schemes and will only improve. Benchmarks vary by hardware platform, but on modern x86-64 processors, ML-DSA-44 signing completes in tens to hundreds of microseconds (Go benchmarks on an Intel Core Ultra 7 show approximately 0.06 milliseconds per sign operation), and verification is consistently faster than signing. On ARM-based platforms more representative of mobile devices, an IEEE-published benchmark of ML-DSA-44 on ARM64 architecture recorded signing at approximately 1.9 milliseconds and verification at approximately 0.5 milliseconds. Even the more conservative ARM numbers are fast enough for real-time mHealth applications, including API authentication, session token validation, and clinical data integrity verification.
ML-KEM handles the other half of the equation: establishing shared secret keys between two parties over a public channel. In an mHealth context, ML-KEM replaces the ECDH key exchange that currently underpins TLS handshakes between the mobile app and the backend server. When a patient opens your app and connects to your API, the key exchange that establishes the encrypted session should be protected by ML-KEM, not ECDH, because any session key established via ECDH today can be retrospectively derived by a quantum computer that has captured the handshake.
Together, ML-DSA and ML-KEM provide a complete post-quantum security stack for mHealth applications: ML-KEM protects data in transit by securing the key exchange, and ML-DSA protects the authenticity and integrity of everything from API responses and clinical data payloads to software updates and certificate chains.
The Regulatory Convergence Driving Urgency
Three regulatory and policy threads are converging to make post-quantum cryptography implementation a near-term necessity for mHealth developers, not a distant planning exercise.
Thread 1: The HIPAA Security Rule Overhaul
On January 6, 2025, HHS published a Notice of Proposed Rulemaking containing the most significant proposed updates to the HIPAA Security Rule since the Omnibus Rule of 2013. The proposed rule would make encryption of all ePHI at rest and in transit a mandatory requirement for all covered entities and business associates, eliminating the current “addressable” designation that has allowed many organizations to avoid encryption entirely. A final rule is expected as early as May 2026, with a 240-day compliance window.
For mHealth developers, this means that encryption is no longer optional for any app that touches PHI. The question is not whether to encrypt, but how to encrypt in a way that does not require a complete rearchitecture when quantum-safe encryption becomes the regulatory standard.
Implementing ML-DSA and ML-KEM now, or implementing a hybrid classical-plus-PQC approach, means you meet the impending HIPAA encryption mandate and the future quantum-safe mandate with a single implementation effort. This is precisely the kind of forward-looking UX and security architecture decision that separates serious healthcare technology companies from those that will be perpetually retrofitting.
Thread 2: The Federal PQC Migration Mandate
The federal government has laid down an aggressive and increasingly specific timeline for post-quantum migration. NSM-10 (May 2022) requires all federal agencies to begin PQC migration and mitigate most quantum risk by 2035. OMB M-23-02 mandates annual inventories of quantum-vulnerable systems. Executive Order 14144 (January 2025) maintained PQC urgency and requires TLS 1.3 (or successor) across all federal systems by January 2, 2030. CISA and NSA were directed to publish a list of quantum-safe product categories by December 1, 2025.
The NSA’s CNSA 2.0 timeline is more operationally specific. Software and firmware signing must prefer CNSA 2.0 algorithms by end of 2025, with exclusive use by 2030. Web browsers, servers, and cloud services must support and prefer CNSA 2.0 by 2025, with exclusive use by 2033. All new National Security Systems acquisitions must be CNSA 2.0-compliant by January 1, 2027. CNSA 2.0 mandates ML-KEM-1024 for key establishment and ML-DSA-87 for digital signatures.
If your mHealth application serves federal employees through FEHB plans, processes Medicaid or Medicare data, integrates with VA or DoD health systems, or contracts with any federal agency, these timelines apply to you directly. If your application does not serve federal populations today but might in the future, PQC readiness is a competitive differentiator that determines whether you can respond to federal RFPs or not.
Thread 3: The PHI Confidentiality Lifetime Problem
Healthcare data is unique among regulated data categories because its confidentiality requirement is effectively permanent. Financial data has a regulatory retention window measured in years. Healthcare data, particularly genomic data, chronic condition records, mental health treatment histories, and substance abuse records, has a confidentiality requirement that extends across the patient’s entire life. Under HIPAA, PHI remains protected as long as it is individually identifiable, which for most clinical data means indefinitely.
This permanent confidentiality requirement collides directly with the harvest-now-decrypt-later threat. If an adversary captures encrypted PHI transmissions from your mHealth app today and decrypts them in 2035, the data is still protected under HIPAA and you are still liable for the breach, even though the encryption you used was considered adequate by 2025 standards. The regulatory liability does not expire because the encryption did.
This is why the convergence of the HIPAA encryption mandate, the federal PQC migration timeline, and the inherent confidentiality lifetime of PHI creates a regulatory environment in which post-quantum cryptography is not a future consideration. It is a present-tense compliance and risk management imperative for any serious healthcare mobile app development program.
Architecture for ML-DSA and ML-KEM Integration in mHealth Apps
Implementing post-quantum cryptography in a production mHealth application is not a matter of swapping one cryptographic library for another. It requires deliberate architectural decisions across the entire application stack, from the mobile client to the API gateway to the backend data layer. Here is how to approach it.
The Hybrid Approach: Belt and Suspenders
The recommended approach for production systems during the transition period (now through at least 2030) is a hybrid cryptographic architecture that combines classical and post-quantum algorithms. In a hybrid scheme, both a classical algorithm (e.g., ECDSA for signatures, ECDH for key exchange) and a post-quantum algorithm (ML-DSA for signatures, ML-KEM for key exchange) are applied simultaneously. The security of the system is maintained as long as either algorithm remains unbroken.
The hybrid approach provides three critical benefits. First, it protects against the possibility, however remote, that a vulnerability is discovered in one of the lattice-based PQC algorithms before the classical algorithms are broken by quantum computers. Second, it maintains backward compatibility with systems that have not yet migrated to PQC. Third, it satisfies compliance requirements that mandate specific classical algorithms while simultaneously providing quantum resilience.
For TLS connections between the mHealth client and the backend, this means implementing hybrid key exchange using both ECDH and ML-KEM, a configuration that Google, Cloudflare, and major TLS library maintainers have been shipping since 2024. For API authentication tokens, this means dual-signing with both ECDSA and ML-DSA. For stored data integrity, this means maintaining both classical and post-quantum signature chains.
Transport Layer: Quantum-Safe TLS
The most critical integration point is the TLS connection between the mobile app and the backend API. This is where harvest-now-decrypt-later attacks are most feasible because the encrypted traffic traverses public networks where interception is trivial.
Implementing hybrid PQC TLS requires support at both ends of the connection. On the server side, OpenSSL 3.5+ and BoringSSL (used by Google’s infrastructure) support ML-KEM hybrid key exchange. On the mobile client side, the situation depends on the platform. Apple began integrating post-quantum protections into iMessage in February 2024 with the PQ3 protocol and has been expanding PQC support across its security stack. Android’s TLS stack, based on BoringSSL via Conscrypt, has been adding ML-KEM support through Google’s efforts.
For mHealth apps that cannot wait for full platform-native PQC TLS support, the alternative is to implement application-layer encryption using a PQC-capable library (such as liboqs, the Open Quantum Safe project’s C library, or pqcrypto for Rust) and encrypt PHI payloads before they are transmitted over the classical TLS channel. This provides a double layer of protection: the classical TLS protects the data today, and the application-layer PQC encryption protects it against future quantum decryption.
API Authentication: ML-DSA Token Signing
Every API call in a well-architected mHealth application is authenticated with a signed token, typically a JWT (JSON Web Token) signed with RS256 (RSA) or ES256 (ECDSA). These signature algorithms are quantum-vulnerable. Replacing them with ML-DSA-signed tokens ensures that API authentication cannot be forged by a quantum-capable adversary.
The practical challenge is token size. An ML-DSA-65 signature is approximately 3,309 bytes, compared to 64 bytes for an ECDSA-P256 signature. For API authentication in mHealth apps where tokens are transmitted with every request, this size increase is meaningful but manageable. Modern mobile networks and HTTP/2+ compression handle the additional payload without significant latency impact. For applications with extreme latency sensitivity, such as real-time patient monitoring alerts, ML-DSA-44 (2,420-byte signatures) provides sufficient post-quantum security at a smaller footprint.
The token verification performance is excellent. ML-DSA verification completes in sub-millisecond timeframes on modern processors and is consistently faster than signing, meaning it will not introduce perceptible latency in any mHealth workflow, including real-time clinical data synchronization and telemedicine session establishment.
Data at Rest: Quantum-Safe Integrity Protection
PHI stored in the application’s local database, in cloud storage, and in backend data systems needs both confidentiality protection (encryption) and integrity protection (signatures or MACs). For confidentiality, AES-256 remains quantum-resistant because Grover’s algorithm only provides a quadratic speedup against symmetric encryption, reducing AES-256’s effective security to 128 bits, which is still computationally infeasible. The vulnerability is in how the AES key was established and protected.
If the AES-256 key was encrypted with RSA or exchanged via ECDH, a quantum computer can recover the AES key by breaking the key encapsulation, even though it cannot break AES directly. This means that every data-at-rest encryption system that uses RSA or ECC for key management must transition to ML-KEM for key encapsulation, even though the underlying symmetric encryption can remain AES-256.
For integrity protection of stored clinical data, ML-DSA signatures provide non-repudiation and tamper detection that remains valid even in a post-quantum world. This is particularly important for mHealth applications that generate clinical data used in treatment decisions, legal proceedings, or insurance claims, where the integrity of the data must be verifiable years or decades after it was created.
Code Signing and Software Supply Chain
The mHealth application binary itself, its updates, and its dependencies must be signed with quantum-resistant signatures to prevent a quantum-capable adversary from distributing tampered versions. The NSA’s CNSA 2.0 timeline prioritizes software and firmware signing as the first category for PQC migration, with support and preference for CNSA 2.0 algorithms required by end of 2025 and exclusive use by 2030.
For mobile app development teams, this means establishing a PQC code-signing workflow now, even if the app stores (Apple App Store, Google Play) do not yet require post-quantum signatures for distribution. The internal CI/CD pipeline should sign builds with both classical and ML-DSA signatures, creating a verifiable chain of custody that will remain trustworthy in a post-quantum environment.
Implementation Roadmap for mHealth Organizations
Transitioning an mHealth application to post-quantum cryptography is a multi-phase effort that touches cryptographic libraries, network infrastructure, backend systems, mobile clients, compliance documentation, and clinical validation. Here is a practical roadmap.
Phase 1: Cryptographic Inventory and Risk Assessment (Months 1-3)
Before you can migrate, you need to know what you are migrating from. Conduct a comprehensive cryptographic bill of materials (CBOM) that catalogs every use of public-key cryptography across your application stack. This includes TLS certificates and their signing algorithms, API authentication token signing, data-at-rest key management, FHIR API integration points, third-party SDK cryptographic dependencies, and code-signing certificates.
For each cryptographic asset, assess the quantum risk using Mosca’s Theorem: if the time to migrate (Y) plus the time the data needs to remain confidential (X) exceeds the time until a quantum computer can break the encryption (Z), then X + Y > Z and you are already at risk. For PHI, X is effectively unlimited (lifetime confidentiality), Y is typically 2 to 5 years for a full migration, and Z is estimated at 5 to 15 years. The math is clear: X + Y > Z for virtually every mHealth application handling PHI.
Organizations building applications that integrate with EHR systems should pay particular attention to their FHIR API integration points, where PHI is exchanged with hospital systems that may have their own PQC migration timelines and interoperability requirements.
Phase 2: Library Selection and Proof of Concept (Months 3-6)
Select a PQC cryptographic library that is appropriate for your mobile platform, has been validated against the NIST FIPS 204 and FIPS 203 specifications, and is actively maintained. The primary options include liboqs (C, from the Open Quantum Safe project), which provides reference implementations of all NIST PQC standards and integrates with OpenSSL via oqs-provider. For iOS development in Swift, the PQClean project provides portable C implementations that can be wrapped. For Android development in Kotlin/Java, the Bouncy Castle library has been adding PQC algorithm support.
Build a proof of concept that demonstrates hybrid ML-DSA/ECDSA token signing and verification, hybrid ML-KEM/ECDH key exchange, and PQC-protected data-at-rest key management in a representative mHealth workflow. Measure the impact on token size, handshake latency, battery consumption, and storage requirements. Validate that the performance characteristics are acceptable for your specific clinical workflows.
Phase 3: Backend Migration (Months 6-12)
Migrate the backend infrastructure first, because the backend controls the server-side TLS configuration, the token signing keys, and the key management system. Deploy ML-KEM-capable TLS on API gateways, transition token signing to dual ML-DSA/ECDSA, and update the key management system to use ML-KEM for key encapsulation. Implement cryptographic agility at the API layer so that the backend can negotiate either classical or hybrid PQC connections, supporting both migrated and unmigrated clients during the transition.
Phase 4: Mobile Client Migration (Months 12-18)
Update the mobile client to support hybrid PQC TLS negotiation and ML-DSA token verification. This requires updating the app’s cryptographic dependencies, modifying the network stack to prefer hybrid key exchange, and updating the local data storage layer to use ML-KEM-protected key wrapping. Deploy the updated client through the normal app store release process and monitor for compatibility issues.
Phase 5: Validation, Compliance Documentation, and Clinical Verification (Months 18-24)
Conduct a comprehensive security assessment of the PQC implementation, including penetration testing against the hybrid cryptographic configuration, performance testing under clinical load conditions, and interoperability testing with partner systems. Update all compliance documentation, including the HIPAA Security Risk Analysis, System Security Plan, and any FDA regulatory submissions if the application is classified as a Software as a Medical Device.
For organizations with digital therapeutics applications that have undergone FDA clearance, the cryptographic migration may require a regulatory notification or supplement, depending on the nature of the changes and the application’s classification.
Common Objections and Why They Do Not Hold Up
“Quantum computers are decades away.”
The most optimistic expert estimates place cryptographically relevant quantum computers in the early 2030s. The most conservative estimates place them in the 2040s. But the harvest-now-decrypt-later threat does not require waiting for quantum computers. The data interception is happening now. The question is not when quantum computers will arrive. The question is whether the data being generated and transmitted by your mHealth app today will still be confidential when they do.
“We will migrate when HIPAA requires it.”
HIPAA already requires adequate protection of PHI. If a covered entity knows that a threat exists (harvest-now-decrypt-later), knows that a mitigation is available (PQC), and chooses not to implement it, the risk analysis supporting that decision will be scrutinized if a breach occurs. The HIPAA Security Rule requires covered entities to “implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.” Arguing that quantum-vulnerable encryption was “reasonable and appropriate” in 2026, when NIST had already published the standards and every major government had mandated migration, will be a difficult position to defend.
“The key sizes are too large for mobile.”
ML-DSA-65 public keys are approximately 1,952 bytes and signatures are approximately 3,309 bytes. On a modern smartphone with gigabytes of RAM, hundreds of gigabytes of storage, and LTE/5G network connectivity, these sizes are trivially manageable. Performance benchmarks show signing in low single-digit milliseconds and verification in sub-millisecond timeframes on ARM-based mobile processors, demonstrating that PQC does not impose meaningful latency on mobile applications. The “too large” objection is a decade out of date.
“Our TLS provider handles encryption. It is not our problem.”
If your mHealth application transmits PHI over a TLS connection that uses ECDH key exchange, the session keys can be retrospectively derived by a quantum computer. Your TLS provider’s certificate may be valid and their server may be properly configured, but if the key exchange is quantum-vulnerable, the confidentiality of every PHI transmission across that connection is quantum-vulnerable. You cannot outsource this risk.
The Competitive Advantage of Moving First
The mHealth market is projected to reach $113.2 billion by 2034, and healthcare organizations are increasingly evaluating security posture as a differentiator when selecting technology partners. In a market where more than 275 million patient records were exposed in U.S. healthcare breaches in 2024 alone, and where the average breach cost exceeded $7 million in 2025, the ability to demonstrate quantum-resistant data protection is a powerful competitive signal.
Organizations that implement PQC now will be positioned to respond to federal RFPs that require CNSA 2.0 compliance. They will be ahead of the curve when the updated HIPAA Security Rule takes effect and when regulators begin asking about quantum-risk mitigation in security risk analyses. They will be able to market their applications with a credible, differentiated security narrative that competitors cannot match. And they will have protected their patients’ data not just against the threats of today but against the threats that are already being assembled to exploit the cryptographic assumptions of yesterday.
The standards are final. The libraries are available. The regulatory direction is unambiguous. The threat is active. The only question is whether you build your mHealth application’s cryptographic foundation on algorithms that have a known expiration date, or on algorithms designed to protect patient data for as long as it needs to remain confidential.
For organizations building healthcare technology in 2026, that is not really a question at all.
Frequently Asked Questions
What is ML-DSA and how does it differ from current digital signature algorithms used in mHealth apps?
ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is a post-quantum digital signature scheme standardized by NIST as FIPS 204 in August 2024. It was formerly known as CRYSTALS-Dilithium during development. Unlike RSA and ECDSA, which rely on mathematical problems (integer factorization and discrete logarithms) that quantum computers can solve efficiently using Shor’s algorithm, ML-DSA is based on the Module Learning With Errors (MLWE) problem, which is believed to be resistant to both classical and quantum attacks. In mHealth apps, ML-DSA replaces ECDSA and RSA for signing API authentication tokens, verifying data integrity, signing clinical payloads, and authenticating software updates. Performance is already competitive, with benchmarks on modern x86-64 processors showing signing in tens to hundreds of microseconds and verification consistently faster. Even on ARM-based mobile processors, signing completes in under 2 milliseconds and verification in under 1 millisecond, making ML-DSA suitable for real-time mobile health workflows.
What is the “harvest now, decrypt later” threat and why is healthcare data particularly vulnerable?
Harvest now, decrypt later (HNDL) is an attack strategy in which adversaries intercept and store encrypted data today, intending to decrypt it in the future when quantum computers capable of breaking current encryption become available. Healthcare data is uniquely vulnerable because PHI has a confidentiality requirement that extends across the patient’s entire lifetime, unlike financial data which has defined regulatory retention windows. A patient’s genomic data, chronic condition records, mental health treatment history, and substance abuse records remain sensitive indefinitely. If an adversary captures encrypted PHI transmissions from an mHealth app in 2026 and decrypts them in 2035, the data is still protected under HIPAA and the covered entity is still liable for the breach. The Federal Reserve Board published a formal analysis of the HNDL risk in September 2025, and a Sectigo/Omdia study found 60% of organizations are “very or extremely concerned” about HNDL attacks.
What is the recommended approach for implementing PQC in a production mHealth app?
The recommended approach is a hybrid cryptographic architecture that combines classical algorithms (ECDSA for signatures, ECDH for key exchange) with post-quantum algorithms (ML-DSA for signatures, ML-KEM for key exchange) running simultaneously. This ensures security as long as either algorithm family remains unbroken, maintains backward compatibility with non-PQC systems, and satisfies compliance requirements that still mandate specific classical algorithms. The migration should proceed in phases: cryptographic inventory and risk assessment first, then proof of concept with selected PQC libraries, followed by backend migration (TLS, token signing, key management), mobile client migration (network stack, local storage), and finally validation and compliance documentation updates. Organizations should plan for an 18 to 24 month migration timeline and should start immediately, particularly for applications handling PHI with long confidentiality requirements.
How do the NIST PQC standards interact with HIPAA compliance requirements?
HIPAA requires covered entities to implement security measures sufficient to reduce risks to a “reasonable and appropriate level.” The proposed HIPAA Security Rule update (January 2025 NPRM) would make encryption of all ePHI at rest and in transit a mandatory requirement. While the proposed rule does not currently specify post-quantum algorithms, the HIPAA risk analysis framework requires covered entities to assess known threats, and the harvest-now-decrypt-later threat is now well documented by NIST, NSA, and HHS itself. Organizations that implement only classical encryption today will need to migrate to PQC when quantum-safe encryption becomes the regulatory standard. Implementing hybrid PQC now satisfies both the impending mandatory encryption requirement and future quantum-safe requirements with a single implementation effort, avoiding a costly rearchitecture.
What are the timeline milestones that mHealth developers should be tracking?
The critical milestones are as follows: August 2024 was when NIST released FIPS 203, 204, and 205 as final standards. End of 2025 is the CNSA 2.0 target for software, firmware signing, and web services to support and prefer PQC algorithms. January 2027 is when all new National Security Systems acquisitions must be CNSA 2.0-compliant. 2030 is when NIST has directed organizations to complete the transition from RSA and ECC to ML-DSA. 2030 is also the TLS 1.3 adoption deadline for federal systems under Executive Order 14144. 2033 is the final mandatory compliance date for most NSS system types under CNSA 2.0. 2035 is when quantum-ready cryptography becomes mandatory for all federal agencies. And the expected HIPAA Security Rule final rule in 2026 will make encryption mandatory with a 240-day compliance window. For mHealth developers, the practical message is that the standards are final, the timelines are set, and migration should begin now.
