1Password completes post-quantum TLS across all its clients without touching application code

1Password has announced that all of its first-party clients —the applications and services the company controls directly— can now negotiate hybrid post-quantum TLS. This means that all vault data transmitted over the internet through its apps and services is protected against "harvest now, decrypt later" (HNDL) attacks, in which an adversary captures encrypted traffic today in the hope of decrypting it in the future with a sufficiently powerful quantum computer.

The announcement completes a process the company began in March, when it enabled compatible browsers to negotiate the hybrid X25519MLKEM768 group when connecting to the 1Password web app. That first milestone covered only browser traffic, because in TLS 1.3 key negotiation is a two-party process: the client offers the key exchange groups it supports and the server picks one of them. In March, the server side already offered post-quantum support, but only browsers that already included X25519MLKEM768 could take advantage of it. That left the remaining connection paths outstanding: 1Password's native applications, which use a TLS stack bundled and controlled by the company itself.

The new milestone addresses precisely that client side. The hybrid design combines the classical X25519 key exchange with the post-quantum ML-KEM-768 mechanism, so current classical protection is maintained while resistance against a future quantum adversary is added. With both sides —client and server— offering and selecting that hybrid group, negotiation happens transparently: users do not need to turn on any option or change how they use the app.

What stands out about the case, as the company itself describes it, is the technical simplicity of the migration. On the server, a single policy change on its AWS Application Load Balancers, applied to all of its API endpoints, was enough, with no changes to application code. On the client, its TLS stack is based on Rustls for connection management and rustls-platform-verifier for certificates, which until now used "ring" as the cryptographic provider. The change consisted of selecting "aws-lc-rs" as the provider, which enabled post-quantum support and made X25519MLKEM768 the preferred key exchange group. In concrete terms, it was a one-line change in the project's Cargo.toml file.

According to 1Password, this was possible thanks to the "cryptographic agility" built into its design: by keeping the cryptographic provider decoupled from application logic, it was able to roll out the new scheme without deploying a new service, without migrating load balancers and without introducing a different TLS stack. The TLS stack, the networking logic and the business logic all remained untouched.

Switching the provider to aws-lc-rs brought not only post-quantum support but also high-performance cryptographic implementations and formally verified algorithms. The company cites figures reported by AWS: an average 113% improvement in X25519 performance and between 2.0x and 2.4x in ML-KEM-768 compared with earlier implementations, plus functional correctness proofs for the core X25519 routines and security and correctness properties verified through automated tools in mlkem-native.

1Password stresses that both the client and server migrations rested on work already done by AWS and by open source project maintainers: the Application Load Balancer exposes the hybrid post-quantum TLS policy as a managed offering, AWS-LC provides the cryptographic implementation, aws-lc-rs exposes it to Rust, and Rustls integrates it through its provider model. The company did not have to write or maintain its own post-quantum cryptographic implementation or deploy new services; its work was limited to inventorying existing connection paths, updating builds, testing supported platforms, rolling out gradually and monitoring compatibility.

The company frames the announcement as one more milestone within a broader post-quantum roadmap, which it describes as "pragmatic and risk-based": it considers internet traffic the most immediate HNDL risk today, which is why it started there, and says its cryptographic inventory will guide the next priorities, with a promise to publish further milestones as it progresses.

Beyond this specific case, the announcement illustrates a pattern relevant to any organization running critical infrastructure in the cloud: migrating to post-quantum cryptography need not mean rewriting proprietary code or taking on the risk of implementing new cryptographic primitives from scratch. When the architecture clearly separates the cryptographic provider from application logic, adopting security improvements such as hybrid key exchange can come down to configuration and dependency changes, leaning on infrastructure already built and verified by third parties such as AWS and the open source community. It is a concrete example of how designing systems up front for "agility" —cryptographic or otherwise— can turn a transition that would require months of re-engineering at other organizations into a one-line change.