Passwords are familiar, but they create problems every time you choose, remember, reuse, or protect one. Passkeys take a different approach: they connect your account to a device or software instead of a secret string of text. That change removes many of the weak points built into ordinary logins.
As of August 18, 2026, passkeys are supported by most major operating systems and password managers, though they are not available on every website. The result is a transition period where both systems exist side by side. Passwords still work in many places, but passkeys offer a stronger way to confirm that the right person is signing in.
How passwords and passkeys work
A classic password is a “secret code” of text that authenticates your account. Websites do not store passwords in plain text because a breach could expose every login. Instead, a one-way function turns each password into a scrambled version called a hash.
Salting adds a random string of data to that hash, creating unique hashes even when people use identical passwords. These protections help, but the password itself remains a secret that must be created, remembered, and entered. A weak password can still become a weak credential, and the same text can be handed over to a fake site or exposed during account access.
Passkeys remove the need to create a secret text credential. They rely on two keys: a public key stored by the website and a private key held on your device. The public key is not a secret, while the private key stays in a secure part of your phone or computer’s storage.
When you log in, the website asks you to confirm with the passkey stored on your device. The device then uses its existing authentication method, such as Face ID, a Windows Hello PIN, or a fingerprint scanner. You do not need to remember any text, except your device PIN if biometric authentication fails.
Why passkeys offer stronger protection
Passkeys are inherently strong because they cannot be created as weak credentials. They are also tied to a specific domain. If you open an imposter page, you cannot hand over the passkey in the same way you could type or share a password.
That design combines two types of security checks at once: “something you have,” meaning a trusted device, and either “something you know” or “something you are,” meaning a PIN or biometric authentication. A passkey therefore requires both the device and a local confirmation method before the account can be accessed.
Passkeys also reduce the risk of credential theft during a data breach. A website stores the public key, and public keys are already public. There is no password text or private passkey waiting in the website’s account database for someone to steal.
Still, passkeys are not used everywhere yet. Passwords remain familiar and available across many sites, while passkeys depend on support from the website, operating system, or password manager. That leaves users managing both methods until more services accept passkeys.
What device-bound sessions add
Passkeys protect the sign-in step, but account security also depends on what happens after login. Chrome is adopting device-bound session credentials to prevent account takeovers, and work on the idea has continued as a W3C standard for months.
The draft standard is called DBSC. Its goal involves binding a session to a key held by the device, with plans or aspirations to connect session credentials to hardware identity and boot-chain attestation. The current version does not involve attestation and remains website-specific, so those goals do not describe the system’s present capabilities.
DBSC specifies a session key for each session, not one permanent key for each device, and the design does not disclose long-lived device identifiers. A hardware-backed session key can make it unlikely that an attacker will gain access to the hardware, extract the private key needed to sign a challenge, and use that key to compromise accounts before the session is noticed and invalidated.
There are hardware limits to consider. Current TPM hardware may have limited storage space for cryptographic keys. An Infineon SPI TPM has 51kB of NVM available, while discrete TPMs have tens to approximately 100kB of NVM. Using an assumption of 1kiB per RSA4096 key pair, the available space can become an important design constraint.
Firmware TPMs typically do not store data on-die. Instead, they carve out an area in BIOS flash for storage. That detail matters because session systems must balance stronger account protection with the storage limits of the hardware that holds their cryptographic keys.
What passkeys and DBSC cannot solve
DBSC does not stop every attack. The draft standard will not prevent an attack where someone replaces or injects into the user agent during session registration. In that situation, the attacker can bind the session to keys that are not TPM-bound or to a TPM the attacker controls permanently.
Session credentials also do not verify cookies against the original client IP. Proxies, NAT, differences between IPv4 and IPv6, multipath requests, and ordinary IP changes make that check unreliable. Rolling IDs for sessions can help reduce the problems caused by changing IP addresses.
The larger picture is clear: passkeys solve many problems linked to passwords, while device-bound sessions aim to protect the account after authentication. Neither removes every security risk, but together they shift account protection away from secrets people must remember and toward trusted devices, local authentication, and cryptographic keys.
Based on
