{"id":905,"date":"2026-09-23T12:14:31","date_gmt":"2026-09-23T12:14:31","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/?p=905"},"modified":"2026-09-25T18:00:41","modified_gmt":"2026-09-25T18:00:41","slug":"what-are-passkeys-how-passwordless-login-works","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/en\/what-are-passkeys-how-passwordless-login-works\/","title":{"rendered":"What Are Passkeys? How Passwordless Login Works"},"content":{"rendered":"<div class=\"aiw-summary\" id=\"aiw-ozet\">\n<p class=\"aiw-summary-title\">Quick Summary &#8211; Passkeys<\/p>\n<p>Passkeys replace reusable passwords with public-key credentials protected by your device. The server stores a public key, while the private key stays in the authenticator.<\/p>\n<ul>\n<li><strong>No reusable password<\/strong> \u2014 The sign-in flow uses a cryptographic signature instead of sending a password to the server.<\/li>\n<li><strong>Phishing resistance<\/strong> \u2014 The browser binds the credential to the registered website and origin.<\/li>\n<li><strong>Local approval<\/strong> \u2014 A PIN, fingerprint, face recognition, or another device-lock method authorizes use of the key.<\/li>\n<li><strong>Public key storage<\/strong> \u2014 The service stores a public key and cannot use it to reconstruct the private key.<\/li>\n<li><strong>Recovery matters<\/strong> \u2014 A lost device can become an account lockout unless you register another device or maintain a tested recovery method.<\/li>\n<li><strong>Plan the rollout<\/strong> \u2014 Website and VPS administrators must test origins, proxy headers, multiple credentials, and account recovery.<\/li>\n<\/ul>\n<\/div>\n<p class=\"aiw-lead\">Passkeys are device-protected login credentials based on public-key cryptography. You approve a signature with a device lock instead of typing a reusable password, while the service stores only the public key and verifies challenges tied to the legitimate website.<\/p>\n<div class=\"aiw-toc\" style=\"border:1px solid #dbe3ea;border-radius:8px;padding:16px 20px;margin:0 0 28px\">\n<p class=\"aiw-toc-head\"><strong>Table of Contents<\/strong><span class=\"aiw-toc-meta\"> \u00b7 12 min read<\/span><\/p>\n<ol style=\"margin:10px 0 0;padding-left:22px\">\n<li><a href=\"#passkeys-solve-a-password-problem-not-every-security-problem\">Passkeys solve a password problem, not every security problem<\/a><\/li>\n<li><a href=\"#the-cryptographic-part-is-straightforward\">The cryptographic part is straightforward<\/a><\/li>\n<li><a href=\"#what-you-actually-do-during-sign-in\">What you actually do during sign-in<\/a><\/li>\n<li><a href=\"#passwords-totp-security-keys-and-passkeys\">Passwords, TOTP, security keys, and passkeys<\/a><\/li>\n<li><a href=\"#they-are-strong-but-recovery-can-still-be-weak\">They are strong, but recovery can still be weak<\/a><\/li>\n<li><a href=\"#lost-phone-broken-laptop-missing-security-key\">Lost phone, broken laptop, missing security key<\/a><\/li>\n<li><a href=\"#what-web-and-vps-administrators-need-to-test\">What web and VPS administrators need to test<\/a><\/li>\n<li><a href=\"#small-migration-mistakes-become-large-lockouts\">Small migration mistakes become large lockouts<\/a><\/li>\n<li><a href=\"#before-you-move-an-account-to-passkeys\">Before You Move an Account to Passkeys<\/a><\/li>\n<li><a href=\"#frequently-asked-questions\">Frequently Asked Questions<\/a><\/li>\n<li><a href=\"#sources\">Sources<\/a><\/li>\n<\/ol>\n<\/div>\n<h2 id=\"passkeys-solve-a-password-problem-not-every-security-problem\">Passkeys solve a password problem, not every security problem<\/h2>\n<p>A passkey lets you sign in without typing a reusable password. Your device creates a private and public key pair: the private key stays with the authenticator, while the service stores the public key. You approve the operation with a PIN, fingerprint, face recognition, or another local screen-lock method.<\/p>\n<p>The password never travels to the server during the normal passkey flow. That removes two familiar problems at once: password reuse and the stolen-password part of phishing.<\/p>\n<p>The FIDO Alliance uses <em>passkey<\/em> for a passwordless sign-in experience built on WebAuthn and the FIDO2 protocol family. The name is friendly; the underlying process is public-key cryptography and a browser checking the identity of the website.<\/p>\n<p><strong>Start here<\/strong>: check the recovery options before registering your first passkey. I would rather spend five minutes planning a second login method than discover a lockout after closing the only working session.<\/p>\n<h2 id=\"the-cryptographic-part-is-straightforward\">The cryptographic part is straightforward<\/h2>\n<p>During registration, the authenticator generates an asymmetric key pair. The private key remains on the device, in an operating-system credential store, or on a security key. The public key is sent to the service and associated with your account.<\/p>\n<p>When you sign in, the server creates a random <code>challenge<\/code>. The browser passes that challenge, along with the relying-party information and request details, to the authenticator. After you approve the operation locally, the authenticator returns a response signed with the private key.<\/p>\n<p>The server verifies the signature with the public key it saved earlier. It also checks the challenge, the relying party, and the expected origin. An old response should not work again because challenges are intended to be short-lived and single-use.<\/p>\n<p>That is the useful bit. The server gets proof that the registered authenticator signed this particular request, not a password that can be copied into another login form.<\/p>\n<h3>Where the private key lives<\/h3>\n<p>Depending on the device, the private key may be protected by a TPM, Secure Enclave, another hardware-backed component, an operating-system credential store, or a dedicated security key. A website cannot normally export it. Your fingerprint or face is not sent to the website either; it only unlocks the local authenticator.<\/p>\n<p>In my lab, I treat the device screen lock as part of the security boundary. A passkey protected by an easily guessed PIN is not a sensible account policy, even when the cryptography is sound. The lock matters.<\/p>\n<h2 id=\"what-you-actually-do-during-sign-in\">What you actually do during sign-in<\/h2>\n<ol>\n<li>Open <em>Add a passkey<\/em>, or the service&#8217;s equivalent option.<\/li>\n<li>Approve the registration request created by the browser or device.<\/li>\n<li>Complete local verification with a PIN, fingerprint, face recognition, or the screen lock.<\/li>\n<li>Wait for the service to save the new credential.<\/li>\n<li>At the next login, choose the passkey instead of entering an email address and password.<\/li>\n<\/ol>\n<p>You can sometimes use a passkey stored on your phone to sign in on a computer. The computer may display a QR code, which you scan with the phone. Bluetooth proximity checks can support the exchange between the two devices. The private key is not copied to the computer; the phone completes the authentication.<\/p>\n<p>Browser and operating-system support still matters. WebAuthn requires a secure context, which normally means HTTPS. Development environments can have exceptions for <code>localhost<\/code>, but plain HTTP is not a production plan.<\/p>\n<p>Before enabling this on a real domain, I test HTTPS, the expected origin, a second device, and the recovery flow together. A passkey that works only in the browser session where I created it is not a finished setup.<\/p>\n<div class=\"aiw-callout aiw-callout-example\">\n<p class=\"aiw-callout-label\">Example<\/p>\n<p>A phone can approve a login on a computer after scanning a QR code. The phone completes the authentication; its private key is not copied to the computer.<\/p>\n<\/div>\n<h2 id=\"passwords-totp-security-keys-and-passkeys\">Passwords, TOTP, security keys, and passkeys<\/h2>\n<table>\n<thead>\n<tr>\n<th>Method<\/th>\n<th>Information stored by the server<\/th>\n<th>Phishing resistance<\/th>\n<th>User action<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Password<\/td>\n<td>Password hash or derived verification data<\/td>\n<td>Low<\/td>\n<td>Type a password<\/td>\n<\/tr>\n<tr>\n<td>SMS code<\/td>\n<td>Phone number and one-time-code flow<\/td>\n<td>Low to medium<\/td>\n<td>Type a code from the message<\/td>\n<\/tr>\n<tr>\n<td>TOTP app<\/td>\n<td>A derivative of a shared secret<\/td>\n<td>Medium<\/td>\n<td>Type a six-digit code<\/td>\n<\/tr>\n<tr>\n<td>Hardware security key<\/td>\n<td>Public key<\/td>\n<td>High<\/td>\n<td>Insert or touch the key<\/td>\n<\/tr>\n<tr>\n<td>Passkey<\/td>\n<td>Public key<\/td>\n<td>High<\/td>\n<td>Approve with the device lock<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>You can type a password or TOTP code into a fake login page. A passkey operation is associated with the relying party identity, so the browser should not use a credential registered for the real website on an unrelated domain.<\/p>\n<p>Passkeys are not phishing-resistant because they use biometrics. The important protections are domain-bound public-key credentials, origin validation, and keeping the private key with the authenticator.<\/p>\n<p>Does a passkey always replace a second factor? No. That depends on the service&#8217;s registration and authentication policy. A passkey protected by a local unlock method can often represent both possession of the authenticator and local user verification, while an enterprise may still require a managed device or a separate hardware key.<\/p>\n<h2 id=\"they-are-strong-but-recovery-can-still-be-weak\">They are strong, but recovery can still be weak<\/h2>\n<p>A database breach does not give an attacker a directly usable password when the service stores a public key. Reconstructing the private key from it would require defeating the cryptographic assumptions of the system in use.<\/p>\n<p>WebAuthn validation also checks the origin, challenge, and relying-party information. If you are redirected to a fake domain, the browser should not offer the passkey registered for the legitimate site.<\/p>\n<p>That does not make passkeys a magic shield. A weak screen lock, malware controlling a local session, or an account-recovery email controlled by someone else can still lead to compromise. The recovery path deserves the same attention as the login page.<\/p>\n<p>Some ecosystems synchronize passkeys between devices using end-to-end encrypted account synchronization. That can make device replacement easier, but it also makes the provider account, its recovery process, and its own multi-factor controls part of your security boundary.<\/p>\n<p>I once treated recovery as paperwork and focused only on whether the primary login worked. That was a poor test plan. Now I try the failure path before removing an older credential.<\/p>\n<div class=\"aiw-callout aiw-callout-warn\">\n<p class=\"aiw-callout-label\">Caution<\/p>\n<p>A passkey does not protect a weak screen lock or an account-recovery process that support staff can bypass too easily. Review the entire recovery chain, not only the cryptography.<\/p>\n<\/div>\n<h2 id=\"lost-phone-broken-laptop-missing-security-key\">Lost phone, broken laptop, missing security key<\/h2>\n<p>The result depends on where the passkey is stored. A synchronized passkey may be available on a new trusted device through the same provider account. A device-bound passkey may disappear with the original phone or computer.<\/p>\n<p>Review the service&#8217;s registered credentials separately from your general account settings. Remove devices you no longer control, but do not delete the old device until the new one has completed a real login. Keep the door open until you know the new key works.<\/p>\n<p>For security keys, registering two is a sensible minimum for important administrator accounts. Use one day to day and keep the spare somewhere secure. I apply the same rule to hosting panels, domain registrars, payment services, and identity-provider administrators.<\/p>\n<p>Document emergency access and recovery codes in a password manager with restricted access. Do not leave them in a plain-text file on the VPS itself; a server that is locked down should not become the storage place for the key to its own recovery.<\/p>\n<div class=\"aiw-callout aiw-callout-tip\">\n<p class=\"aiw-callout-label\">Tip<\/p>\n<p>Register a second device or security key before removing your password. Test the new credential from a fresh browser session so you know the recovery path works.<\/p>\n<\/div>\n<h2 id=\"what-web-and-vps-administrators-need-to-test\">What web and VPS administrators need to test<\/h2>\n<p>Adding a passkey is more than putting a button next to the password form. The application needs to handle WebAuthn registration and authentication, multiple credentials per user, credential IDs, public keys, user verification policy, and account recovery.<\/p>\n<p>A service will commonly store information such as:<\/p>\n<ul>\n<li>Credential ID<\/li>\n<li>The public key associated with the user<\/li>\n<li>Relying-party ID<\/li>\n<li>User identifier, username, or display name<\/li>\n<li>Last authentication time and, where applicable, the signature counter<\/li>\n<\/ul>\n<p>The relying-party ID and origin are different values. An origin includes the scheme, domain, and port. <code>https:\/\/panel.example.com<\/code> and <code>https:\/\/example.com<\/code> are different origins. The relying-party ID defines the domain scope, and choosing it incorrectly can produce surprising behavior across subdomains.<\/p>\n<p>A reverse proxy must pass the external HTTPS scheme correctly to the application. Do not accept <code>Host<\/code>, <code>Origin<\/code>, or proxy headers from arbitrary clients. Trust them only when the request comes from a proxy address you control. The role separation described in <a href=\"https:\/\/www.vps.tc\/blog\/en\/what-does-admin-mean-admin-definition-explained\/\">What Does Admin Mean? Admin Definition Explained<\/a> is a useful starting point for protecting web-application administrator accounts.<\/p>\n<p>For operating-system administration, passkey support is usually provided through an identity provider, VPN, SSO layer, or web management panel rather than added directly to a traditional SSH login. The same principle appears in <a href=\"https:\/\/www.vps.tc\/blog\/en\/what-is-windows-server-core-guide\/\">What Is Windows Server Core? A Guide to GUI-Free Administration<\/a>: reduce the management surface and restrict privileged accounts. A passkey will not repair an open port or an incorrect firewall rule.<\/p>\n<p>When choosing a WordPress passkey plugin, I check its update history, WebAuthn compatibility, role-based policy, and recovery behavior. The server hardening steps in <a href=\"https:\/\/www.vps.tc\/blog\/en\/install-wordpress-on-vps-step-by-step\/\">How to Install WordPress on a VPS: Step-by-Step Guide<\/a> still apply. Changing only the login method leaves plenty of other doors untouched.<\/p>\n<p>Test the origin, relying-party ID, proxy behavior, multiple credentials, and recovery flow as separate cases. When something fails, record the browser version, domain, HTTPS status, device platform, and exact error rather than restarting the server and hoping.<\/p>\n<div class=\"aiw-callout aiw-callout-field\">\n<p class=\"aiw-callout-label\">From the field<\/p>\n<p>I keep a separate lab account for passkey tests. It has saved me from confusing a browser registration problem with an administrator lockout, and it makes recovery testing much less stressful.<\/p>\n<\/div>\n<h2 id=\"small-migration-mistakes-become-large-lockouts\">Small migration mistakes become large lockouts<\/h2>\n<p>Do not replace a random password in your password manager before checking how recovery works. If support staff can restore the old authentication method with a weak identity check, attackers may target that process instead of the passkey.<\/p>\n<p>Do not tie every administrator to one device. People lose phones, leave companies, and change device policies. Register separate credentials for the administrators who need access, keep a spare security key where policy allows it, and review the list periodically.<\/p>\n<p>Synchronization is not the same as a tested backup. It improves availability, but the provider account and its recovery chain become part of the setup. For higher-risk accounts, unsynchronized hardware keys may fit the policy better.<\/p>\n<p>Do not change WebAuthn code without reading the browser error. <code>NotAllowedError<\/code> can mean user cancellation, a timeout, or an origin mismatch. The error name alone is not a diagnosis.<\/p>\n<p>I keep a small lab account for passkey changes instead of experimenting first with an administrator account. That habit came after too many browser-based changes that looked harmless until the recovery screen behaved differently. The test account gives the failure somewhere safe to land.<\/p>\n<p>Keep the old login method during a defined transition period. Test two devices, logout, passkey deletion, re-registration, and recovery before removing it. A failed test is cheap when nobody depends on the result yet.<\/p>\n<h2 id=\"before-you-move-an-account-to-passkeys\">Before You Move an Account to Passkeys<\/h2>\n<ul class=\"aiw-checklist\">\n<li>Check the service&#039;s recovery options and emergency access policy.<\/li>\n<li>Create the first passkey on a device with a strong screen lock.<\/li>\n<li>Register and test a second device or hardware security key.<\/li>\n<li>Verify the production domain uses HTTPS and the expected origin.<\/li>\n<li>Test login, logout, passkey deletion, and account recovery.<\/li>\n<li>Review registered credentials and remove devices you no longer control.<\/li>\n<li>Document recovery codes and emergency access in a restricted password manager.<\/li>\n<\/ul>\n<div class=\"aiw-cta\">\n<p>If you are adding passkeys to a website, hosting panel, or VPS workflow, start with a test account and a second recovery device. The safest migration is the one you have intentionally allowed to fail before users depend on it.<\/p>\n<p class=\"aiw-cta-action\"><a href=\"https:\/\/www.vps.tc\/en\/vps\">Explore VPS plans<\/a><\/p>\n<\/div>\n<p>When I secure a passwordless login flow, I also think about automated abuse around sign-in and recovery endpoints; my guide, &#8220;<a href=\"https:\/\/www.vps.tc\/blog\/en\/what-is-captcha-how-bot-protection-works\/\">What Is CAPTCHA? How Bot Protection Works<\/a>,&#8221; explains how CAPTCHA fits alongside server-side verification, rate limits, and monitoring.<\/p>\n<h2 id=\"frequently-asked-questions\">Frequently Asked Questions<\/h2>\n<div class=\"aiw-faq\">\n<details class=\"aiw-faq-item\" open>\n<summary>What are passkeys in simple terms?<\/summary>\n<p>A passkey is a login credential stored and protected by your device. Instead of typing a password, you approve a cryptographic operation with a PIN, fingerprint, face recognition, or another screen-lock method. The website stores a public key and checks the signature produced by your private key. The private key is not sent to the website during normal authentication.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Are passkeys safer than passwords?<\/summary>\n<p>They are generally more resistant to phishing and password reuse because there is no reusable secret for you to type into a fake website. The credential is tied to the legitimate relying party and origin. Security still depends on your device lock, operating-system security, and account-recovery process. A weak recovery path can undermine an otherwise strong passkey setup.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Can a passkey be used on more than one device?<\/summary>\n<p>Yes, depending on the passkey type and the provider&#039;s ecosystem. Synchronized passkeys can become available on other devices through an encrypted account-sync service. Device-bound passkeys remain tied to the original authenticator. You can also register multiple passkeys separately, which is useful for administrators who need a spare phone or hardware security key.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>What happens if I lose my phone with a passkey?<\/summary>\n<p>The result depends on whether the passkey was synchronized or device-bound. A synchronized credential may be restored on another trusted device through the provider account. A device-bound credential may be unavailable after the loss. Keep another registered device or security key, and verify that the service&#039;s recovery method works before deleting the lost device from account settings.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Do passkeys replace two-factor authentication?<\/summary>\n<p>Sometimes, but not automatically. A passkey protected by a local device unlock can provide possession of the authenticator and local user verification in one flow. The service decides how it classifies that credential and whether additional controls are required. Enterprise systems may still require managed devices, separate hardware keys, or an additional policy for privileged accounts.<\/p>\n<\/details>\n<details class=\"aiw-faq-item\">\n<summary>Can I use passkeys on a VPS or SSH server?<\/summary>\n<p>Passkeys are most commonly used through a web application, identity provider, VPN, SSO layer, or management panel rather than directly in a traditional SSH login. You can still protect the web control plane used to administer a VPS with passkeys. Keep SSH hardening, firewall rules, least privilege, and tested recovery in place; a passkey does not fix an exposed port or an incorrect access policy.<\/p>\n<\/details>\n<\/div>\n<h2 id=\"sources\">Sources<\/h2>\n<ul class=\"aiw-sources\">\n<li><a href=\"https:\/\/www.w3.org\/TR\/webauthn-3\/\" target=\"_blank\" rel=\"noopener\">W3C &#8211; Web Authentication: An API for accessing Public Key Credentials<\/a> \u2014 w3.org<\/li>\n<li><a href=\"https:\/\/pages.nist.gov\/800-63-3\/sp800-63b.html\" target=\"_blank\" rel=\"noopener\">NIST &#8211; Digital Identity Guidelines: Authentication and Lifecycle Management<\/a> \u2014 pages.nist.gov<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Passkeys replace reusable passwords with device-protected cryptographic credentials. Here is how they work, what they protect, and how to deploy them safely.<\/p>\n","protected":false},"author":2,"featured_media":903,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-905","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"lang":"en","translations":{"en":905,"tr":904},"pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/905","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/comments?post=905"}],"version-history":[{"count":2,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/905\/revisions"}],"predecessor-version":[{"id":946,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/905\/revisions\/946"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media\/903"}],"wp:attachment":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media?parent=905"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/categories?post=905"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/tags?post=905"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}