Sign-in methods compared
What the integrator sets up, and what the user does and how long it takes at the first and at a repeat sign-in. The times of the other methods come from published reports and our own measurements; the Veriqa times are all our own measurements. The setup answers and the effort levels are our assessment, and the rules behind them are below the table.
| Website sign-in method | Setup complexity | Website sign-in scenario | User effort and time | ||
|---|---|---|---|---|---|
| First sign-in | Repeat sign-in | Time | |||
| Password |
The agent writes the code; a person sets up the e-mail provider and DNS
Hours
An e-mail provider, no approval
Password storage and hashing, a sign-up form, e-mail confirmation, password reset, an e-mail provider, a second factor, brute-force protection, support for users who forget their password. |
Password only | ~30 s 3 | ||
| With a second factor | ~69 s 1 | ||||
| SMS code |
The agent writes the code; a person signs the contract and registers the sender
Hours of work and days of waiting
An SMS provider and the carriers, with approval
A contract with an SMS provider, sender registration with the carriers, code generation and verification, rate limits and protection against SMS fraud, a charge for every message. |
~17 s 4 | |||
| Social login |
The agent writes the code; a person opens the developer accounts and creates the applications
Hours for each provider, plus waiting for the review
Each provider, with a review of the application
For each provider: a developer account (paid, in Apple's case), an application, a consent screen, redirect URIs, keys, the provider's review of the application, and your own code that handles the response and links accounts. |
30 s 6 3.4 s 6 | |||
| Passkey |
The agent writes the code; a person sets up the e-mail provider for the fallback sign-in
Minutes for the passkeys, hours with the fallback sign-in
Not needed for the passkeys; an e-mail provider for the fallback
A WebAuthn server library, the relying party ID and origin settings, a table for the users' public keys, sign-up and sign-in code on the server and on the front end. The integrator creates no secrets. A fallback sign-in is needed for a lost or new device — usually a link by e-mail, and that takes an e-mail provider. |
The key is on the same device | 3–15 s 1 2 3 | ||
| The key is on the phone, the sign-in is on a computer | 24 s 7 18 s 7 | ||||
| Veriqa |
The agent does everything except creating the bot
15–30 minutes
The messenger: a Telegram bot is created right away, with no approval
Run the container, point it at a database, create a bot and set its token, issue two token certificates, declare an OIDC client, put the service behind a reverse proxy and connect your application as you would to any OIDC provider. |
On a computer, automatic sign-in | 3.5 s 5 | ||
| On a computer, with confirmation | 6 s 5 | ||||
| On a phone, automatic sign-in | 2.4 s 5 | ||||
| On a phone, with confirmation | 4 s 5 | ||||
Sources for the sign-in times
- Microsoft Learn — Passkeys (FIDO2) authentication method in Microsoft Entra ID Signing in with a synced passkey takes 3 seconds, versus 69 seconds for a password with a traditional second factor. Data on Microsoft consumer accounts.
- FIDO Alliance — Passkey Index, October 2025 A passkey sign-in takes 8.5 seconds on average. Data reported by nine member companies of the alliance.
- Google Security Blog — Making authentication faster than ever: passkeys vs. passwords A sign-in takes 14.9 seconds on average with a passkey and 30.4 seconds with a password. Data on about 100 million sign-ins to Google accounts, March–April 2023.
- Google for Developers — Mercari's passkey authentication speeds up sign-in 3.9 times A sign-in with an SMS code takes 17 seconds on average. Mercari's data on its own users.
- Our own measurement, taken in Telegram on a phone where the messenger was already installed and signed in. On a computer sign-in the user opens the camera, points it at the QR code and taps the link; with confirmation they also tap Confirm. In other messengers the time may differ.
- Our own measurement of sign-in with Google on the Logto sign-in page. The first sign-in took 30 seconds in a browser already signed in to Google: Google still asked for the second factor. A repeat sign-in took 3.4 seconds and one click. In a browser not signed in to Google, the first sign-in also requires typing the account password.
- Our own measurement of a passkey kept on the phone, on the same Logto sign-in page. Creating the key took 24 seconds after some practice and about a minute the very first time; creating the account is not counted. A repeat sign-in on a computer took 18 seconds.
In the table, times of up to 15 seconds are green; longer ones are red.
Two times separated by a slash are for the first sign-in and a repeat sign-in.
Where the sources give no time for the first sign-in, the table shows only the repeat one.
The figures were collected in different ways: a survey of companies, the statistics of one vendor and our own measurement. Read them as an order of magnitude, not as one experiment.
How user effort is counted
We count what the user does in a clean browser, with no password manager: every click, tap, scan and typed field. Scanning a QR code with the phone camera is one action.
- One or two actions, nothing to type
- Three actions, nothing to type
- Four or more actions, or one field to type
- Two fields to type
- Three or more fields to type
- Password
- Password only
- First sign-in Type the e-mail and the password twice, then open the mailbox and click the confirmation link.
- Repeat sign-in Type the username and password.
- With a second factor
- First sign-in Type the e-mail and the password twice, then open the mailbox and click the confirmation link.
- Repeat sign-in Type the username and password, then open another app and type the second-factor code.
- SMS code
- First sign-in Type the phone number, wait for the SMS, type the code.
- Repeat sign-in Type the phone number, wait for the SMS, type the code.
- Social login
- First sign-in Click the button, complete the social network's second-factor check and accept the consent screen. In a browser not signed in to the social network, the user also types its username and password.
- Repeat sign-in Click the button.
- Passkey
- The key is on the same device
- First sign-in Create an account another way, usually with a password or a code, then create the key and confirm with biometrics.
- Repeat sign-in Click the button and confirm with a fingerprint or a face scan.
- The key is on the phone, the sign-in is on a computer
- First sign-in Create an account another way, usually with a password or a code, then create the key and confirm with biometrics.
- Repeat sign-in Click the button, choose another device, scan the QR code with the phone and confirm with biometrics on it. Bluetooth has to be on.
- Veriqa
- On a computer, automatic sign-in
- First sign-in Scan the QR code with the phone camera and tap the link.
- Repeat sign-in Scan the QR code with the phone camera and tap the link.
- On a computer, with confirmation
- First sign-in Scan the QR code with the phone camera, tap the link and tap Confirm.
- Repeat sign-in Scan the QR code with the phone camera, tap the link and tap Confirm.
- On a phone, automatic sign-in
- First sign-in Tap the messenger button on the sign-in page.
- Repeat sign-in Tap the messenger button on the sign-in page.
- On a phone, with confirmation
- First sign-in Tap the messenger button on the sign-in page and tap Confirm.
- Repeat sign-in Tap the messenger button on the sign-in page and tap Confirm.
How the setup is assessed
Three questions for each method: can an AI agent do the whole setup, how much of a person’s time it takes, and whether a third party has to be involved. Green means the integrator is not held back, red means they wait on someone else or do much by hand. The answers are our assessment; only the Veriqa time was measured.
- Password
- The agent writes the code; a person sets up the e-mail provider and DNS Hours An e-mail provider, no approval
- Password storage and hashing, a sign-up form, e-mail confirmation, password reset, an e-mail provider, a second factor, brute-force protection, support for users who forget their password.
- SMS code
- The agent writes the code; a person signs the contract and registers the sender Hours of work and days of waiting An SMS provider and the carriers, with approval
- A contract with an SMS provider, sender registration with the carriers, code generation and verification, rate limits and protection against SMS fraud, a charge for every message.
- Social login
- The agent writes the code; a person opens the developer accounts and creates the applications Hours for each provider, plus waiting for the review Each provider, with a review of the application
- For each provider: a developer account (paid, in Apple's case), an application, a consent screen, redirect URIs, keys, the provider's review of the application, and your own code that handles the response and links accounts.
- Passkey
- The agent writes the code; a person sets up the e-mail provider for the fallback sign-in Minutes for the passkeys, hours with the fallback sign-in Not needed for the passkeys; an e-mail provider for the fallback
- A WebAuthn server library, the relying party ID and origin settings, a table for the users' public keys, sign-up and sign-in code on the server and on the front end. The integrator creates no secrets. A fallback sign-in is needed for a lost or new device — usually a link by e-mail, and that takes an e-mail provider.
- Veriqa
- The agent does everything except creating the bot 15–30 minutes The messenger: a Telegram bot is created right away, with no approval
- Run the container, point it at a database, create a bot and set its token, issue two token certificates, declare an OIDC client, put the service behind a reverse proxy and connect your application as you would to any OIDC provider.