Compare the Same Protection
Post-quantum HTTPS protects the key exchange for a network connection when both ends negotiate it. That matters if someone records the connection for future decryption. It does not by itself stop the cloud service reading data after TLS terminates.
Post-quantum file-key protection addresses a different exposure: a captured public-key envelope containing the secret that decrypts a file. With end-to-end encryption, authorized clients open that envelope. A service can implement this without making every signature, login or recovery mechanism post-quantum.
AES-256 is not obsolete. It is symmetric encryption, with a different quantum risk from RSA or elliptic-curve key exchange. A service using AES-256 at rest is not automatically vulnerable because its storage documentation lacks the phrase “post-quantum.” Evaluate how the keys are protected and who can obtain them. NIST’s FAQ explains the distinction.
File Services and Personal Cloud Storage
This table compares the named file products. A capability in the same company’s email app, browser or developer library is not automatically a capability of its file service. “Not confirmed” means the cited documentation does not establish the feature; it is not proof that the provider has no internal work underway.
| Service | Documented file protection | Post-quantum scope and availability | What to distinguish |
|---|---|---|---|
| NDEVR OWL | Client-side content encryption, with ML-KEM-768 + P-256 hybrid wrapping for recipient content keys. AES-256 protects file contents. | All accounts at launch. Automatic profile upgrades and wrapping of existing content keys are part of the release commitment. The public endpoint also supports hybrid HTTPS for compatible clients. | Application key protection and HTTPS are separate layers. This does not claim that every authentication or recovery path is post-quantum. Launch scope; construction and limits. |
| Tuta Drive | Tuta explicitly advertises quantum-resistant end-to-end encryption for stored files. | Vendor-announced closed beta. The April 16, 2026 launch announcement describes invitation-only access; the product page repeats the quantum-resistant storage claim. | This is a direct file-storage claim, not just HTTPS. The cited announcement does not establish unrestricted availability. Beta announcement; product details; roadmap. |
| Proton Drive | End-to-end encrypted files and sharing. Its security page describes Curve25519 and OpenPGP. | Drive-specific PQ key protection not confirmed by the cited security page and roadmap. Proton does document a gradual, opt-in post-quantum rollout for new encrypted Mail messages. | Drive appears in Mail’s minimum-version prerequisites; that does not establish PQ protection for Drive files. Mail’s feature does not retroactively re-encrypt existing emails. Drive security; Drive roadmap; Mail’s scope. |
| Google Drive / Workspace | Encryption in transit and at rest. Eligible organizations can add Workspace client-side encryption, using an external key service. | Drive-specific PQ file-key protection not confirmed by the cited CSE documentation. Google separately documents substantial PQ deployment in its infrastructure. | CSE changes who controls file keys; its presence alone does not specify a PQ key-wrapping algorithm. Google Cloud’s network milestones are covered below. Encrypted Drive files; external key-service architecture. |
| OneDrive / SharePoint | Microsoft documents TLS in transit, disk encryption and per-file AES-256 encryption at rest for these Microsoft 365 services. | Product-specific PQ file-key protection not confirmed by the cited encryption documentation. Microsoft’s broader PQ migration program has a 2029 goal for critical products and services. | Server-side AES-256 encryption is meaningful protection. A company-wide migration goal does not establish a completed PQ rollout for every OneDrive operation. File encryption; Microsoft’s program. |
Cloud Infrastructure Is Already Moving
Infrastructure services are building blocks for applications. Their network and storage protections deserve credit, but do not by themselves establish end-to-end encryption between the users of an application built on them.
| Platform | Documented capability | Boundary and availability |
|---|---|---|
| Amazon Web Services | Deployed: Amazon S3 supports hybrid post-quantum TLS 1.3. AWS combines this with default AES-256 server-side encryption and describes quantum-resistant protection in transit and at rest. | A compatible client must negotiate PQ-TLS. Current documentation excludes S3 PrivateLink, Multi-Region Access Points and S3 Vectors. This is service-side protection, not a claim that AWS cannot decrypt a server-side-encrypted object. S3 documentation; November 2025 launch. |
| Google Cloud | Deployed: its August 2026 roadmap reports hybrid ML-KEM on Google Cloud API endpoints. Supported load balancers offer X25519MLKEM768. The broader PQ-readiness target is 2029. | Load-balancer documentation schedules default enablement beginning October 2026, with a deferral option until October 2027. The described support covers frontend connections; clients must advertise the group. It does not establish that every backend hop or application key is covered. Roadmap; TLS support and rollout. |
| Microsoft cloud program | Published migration commitment: Microsoft’s July 2026 security report targets PQ migration in critical products and services by 2029. | The program covers network traffic, stored-data protection and trust chains. A program target is evidence of planning, not a service-by-service completion statement for Azure or Microsoft 365. July 2026 progress report. |
These sources do not support saying that few cloud services plan for post-quantum threats. They support a more precise conclusion: capabilities differ by product, encryption layer, configuration and rollout stage.
OWL’s Coverage at Launch
NDEVR’s release commitment is coverage for every OWL account. Profiles upgrade automatically with the product update, and existing content keys will be wrapped with the hybrid post-quantum construction by launch day. Temporary pre-release enrollment restrictions are not the product-release baseline used in this comparison.
OWL combines ML-KEM-768 with P-256 for recipient key wrapping, using HPKE, HKDF-SHA256 and AES-256-GCM. Its HTTPS endpoint supports X25519MLKEM768, a separate hybrid key agreement. The main article documents the formats, pinned protocol drafts and the distinction between key establishment, signatures and account recovery.
The distinction OWL offers is post-quantum protection for recipient content-key envelopes alongside hybrid HTTPS. It is not a claim to be the only provider planning for quantum attacks, nor a claim that ML-KEM makes every part of an account quantum-resistant. An updated key wrap also cannot revoke or repair a vulnerable copy that an adversary obtained before migration.
Sources and Comparison Method
This comparison is published by NDEVR and is not an independent product audit. Competitor entries summarize first-party product documentation and announcements reviewed on October 28, 2026; each row links the evidence for its claims. OWL’s algorithm details come from its implementation and technical article. Its all-account launch coverage is NDEVR’s release commitment, confirmed on the same date, rather than a claim that a public launch audit has already occurred.
The selection covers familiar file services and major infrastructure providers; it is not a market-wide census. No competitor endpoints were tested for this comparison. “Not confirmed” is limited to the reviewed documentation, and a roadmap is not a guarantee of delivery. A fair procurement review should ask each provider which clients, key types, recovery paths and older data are covered.
.jpg){kind=link}