1Password branding with a key and a lattice-like protective pattern
Security / The story

1Password’s quantum-safe passkeys need a website on the other end

ML-DSA support is an early migration step. Updating the password manager does not convert every existing passkey or make every website compatible.

GeekRadarStory date Published 3 min read

1Password has added support for passkeys using ML-DSA, a digital-signature algorithm designed to resist attacks from a sufficiently capable future quantum computer. The practical limit is straightforward: the password manager and the website must both support it. Installing version 8.12.44 does not turn every account into a post-quantum account.

This is preparation for a migration, not an announcement that ordinary passkeys have suddenly stopped being useful. The company describes the change as precautionary. Existing credentials are not automatically replaced by a new algorithm simply because the application can now create another kind.

The signature is the part being changed

Passkey authentication uses a private key to produce a response that the service can verify with the corresponding public key. The service does not need a reusable password shared with the user. Our earlier explanation of passkeys covers why that changes the familiar phishing and password-reuse problems.

NIST’s FIPS 204 standard specifies ML-DSA for generating and verifying digital signatures. Its purpose is to preserve that verification relationship against a different class of cryptographic threat. This is not the same task as encrypting all the files in an account or proving that the account’s recovery process is secure.

Keeping those layers separate avoids an unhelpful conclusion: waiting for post-quantum support is not a reason to return to reused passwords. A future cryptographic migration and today’s account-security choices can proceed at the same time.

Compatibility includes the format and the platform

RFC 9964 defines how ML-DSA keys and signatures are represented in formats including COSE. Agreeing on the algorithm is only part of interoperability; software also has to agree on how the relevant information is encoded and exchanged.

The standard notes that ML-DSA keys and signatures are substantially larger than those of traditional alternatives. That does not make adoption impractical, but it gives implementers real constraints to evaluate: memory, bandwidth and processing limits cannot be assumed away merely because a standard exists.

There is also a current platform distinction. 1Password says authentication works across its supported platforms, while creating an ML-DSA passkey is not yet supported on iOS or through the native macOS autofill extension. Creating a credential and using one already created are separate operations.

The company is working with standards groups on updating existing passkeys. That is ongoing work, not evidence that a universal automatic migration has already been deployed. Users should not delete working credentials on the assumption that a website will immediately accept replacements in the new format.

A transition succeeds when it becomes ordinary

Our coverage of post-quantum standards explains why selecting algorithms is only the beginning. Products, protocols and services then have to move together without breaking the routines people rely on.

For a user, the visible action is modest: keep the password manager current and use the sign-in options the actual service supports. For a website operator, the work is deeper, because accepting a new algorithm changes a real authentication path that must remain recoverable and compatible.

The milestone is therefore not a badge saying “quantum-safe” beside every login. It is the first supported connection between two systems that can speak the new cryptographic language—and a route for more of them to follow.