How we deployed post-quantum TLS without any code changes

In March, we announced our first major post-quantum milestone. Customers using a compatible browser could negotiate X25519MLKEM768 when connecting to the 1Password web app. This protected browser traffic from harvest-now, decrypt-later attacks (HNDL) without any customer action required. While this release raised the bar, it did not cover other ways customers connect to 1Password.

Today, every first-party 1Password client can negotiate hybrid PQ-TLS. In other words, all vault data transmitted over the internet through the 1Password applications and services we control is protected against HNDL, not just data sent through a compatible browser.

In our previous launch, a single policy change on our TLS endpoints enabled PQ-TLS on our API endpoints. This release focused on the other half of the negotiation: the client. A single dependency change in our client build enabled PQ-TLS there. Across the two milestones, we migrated both sides of the connection without changing any code or deploying new services. This was possible because of the cryptographic agility built into 1Password and the undifferentiated heavy lifting AWS completed.

Post-quantum TLS is a two-sided negotiation

TLS 1.3 starts with the client offering the key exchange groups it supports. The server selects one of those offers. Our previous launch protected compatible browser traffic because those browsers already offered X25519MLKEM768. Our native 1Password clients use a TLS stack that we package and control, so enabling PQ-TLS required us to add X25519MLKEM768 support to the client side as well.

When both sides support X25519MLKEM768, TLS combines the classical X25519 key exchange with post-quantum ML-KEM-768. The hybrid design preserves the classical protection we rely on today while adding protection against a future quantum adversary. Our first-party clients and endpoints now negotiate that hybrid group.

Customers do not need to enable a setting or change how they use 1Password. The client offers the hybrid group, the server selects it, and TLS manages the rest.

One policy, one TOML change, no application code changes

On the server, the migration was a single AWS Application Load Balancer policy change. Applying that policy across all of our API endpoints enabled PQ-TLS without changing server application code.

On the client, our TLS stack uses Rustls for connection management and rustls-platform-verifier for certificates, which historically selected ring as the cryptographic provider. In our build, selecting aws-lc-rs as the provider enabled PQ-TLS and made X25519MLKEM768 the preferred key exchange group. Our client migration was a one-line change in Cargo.toml.

Taken together, those two configuration changes delivered a PQ migration on both the server and client, with no application code changes.

Cryptographic agility by design

The simplicity of this migration is only part of the story. Our TLS stack, networking logic, and business logic stayed the same. We did not deploy a new service, migrate to a new load balancer, or introduce a new TLS stack. Separating the cryptographic provider from our application allowed us to deploy PQ-TLS at the pace our customers expect.

Moving to aws-lc-rs gave us high-performance cryptographic implementations, formally verified algorithms , and PQ support through Rustls all at once. AWS reported an average 113% improvement for X25519 and between 2.0x and 2.4x for ML-KEM-768 over previous implementations. That work includes functional-correctness proofs for X25519’s core routines and machine-checked safety and correctness properties in mlkem-native. Together, this gave us highly optimized implementations of both parts of X25519MLKEM768 with stronger assurance in the code we depend on.

This cryptographic agility let us deploy across different microarchitectures with the same high performance and assurance requirements, without code changes or customer impact.

Building on AWS and open-source cryptography

Both the client and server migrations benefited from work AWS had already completed. Application Load Balancer exposed hybrid post-quantum TLS as a managed policy. AWS-LC provided the cryptographic implementation, aws-lc-rs exposed it to Rust, and Rustls made it available through its provider model.

Implementing ML-KEM securely, optimizing it across processors, and integrating it into TLS are specialized tasks. AWS and open-source maintainers did that work once in reusable infrastructure and libraries, where this undifferentiated heavy lifting belongs.

We still inventoried connection paths, updated builds, tested supported platforms, rolled out gradually, and monitored compatibility. We did not have to write or maintain a post-quantum cryptographic implementation ourselves or deploy new services.

Another milestone in a longer post-quantum roadmap 

We are taking a pragmatic, risk-based approach to post-quantum cryptography. We consider internet traffic the most immediate HNDL risk today, so that is where we started. As we address each priority, our cryptographic inventory will guide us to the next. We’ll do this with transparency in mind and will publish more blog posts as we reach new milestones.