Why password-only login without 2FA is the main point of failure
The password is the only secret a user carries between services, and it is almost always the same one.
A leaked password database on any third-party site turns this habit into an open door: the login/password pair is checked against you automatically, without exploits or noticeable anomalies in logs.
Credential stuffing from stolen databases runs distributed from thousands of addresses and is almost indistinguishable from normal traffic by metrics. A fraction of a percent of successful attempts is enough to speak of mass account compromise rather than isolated cases.
The cost of such compromise is higher than it seems: under a hijacked account, attackers change the email and recovery method, revoke other sessions, exfiltrate data, and gain access to integrations and payment flows.
A complex password does not help — it was compromised on another service, and account protection cannot rely on user hygiene.
The second factor breaks this link: a one-time code is computed on the device from a shared secret, lives for less than a minute, and is not stored in the database.
Even if the password surfaces in someone else's dump, login without a valid code does not go through, and password reuse ceases to be critical.
Let's break down how this is closed in practice — from issuing secrets and backup codes to access recovery scenarios, so that the second factor does not become a blocker for customers and employees.
What changes after implementing the second factor: measurable effect
The second factor does not close "hacking in general" but a specific class of failures — login with a stolen username-password pair.
As long as the password remains the only proof, any third-party leak turns into mass credential-stuffing attempts, and the share of successful account takeovers grows in proportion to the volume of leaked databases.
A TOTP code is one-time and lives for only tens of seconds, so an interception at login no longer works.
The boundary of the method here is honest: it does not protect against real-time login page substitution — that requires a hardware key, and we allow for this possibility in advance. At the start, familiar apps such as Google Authenticator are used.
Login time increases only on the first device pairing — after that, "remember this device" returns it to the previous level.
Support load is redistributed: password reset requests fall because reset no longer opens access to the account, but a stream of "lost phone" requests appears — it is absorbed by backup codes and a second linked device issued during setup.
After launch, we look at the share of successful takeovers in the password-leak class, median login time, share of accounts with a confirmed second factor, and the number of requests for password reset and access recovery.
Comparison of 2FA methods: app, hardware key, email
The second factor is chosen based on the login scenario and the cost of error, not on the principle of "what is more secure in general." Mass customer login, privileged roles, and one-time contractor access set different requirements for friction and recovery. A single project usually accommodates two or three methods at once.
| Option | When it fits | Limitations |
|---|---|---|
| Authenticator app, one-time codes (TOTP) | Mass login of employees and customers, smartphone at hand | Codes are time-based: clock skew and phone loss require a procedure; the code is also entered on a fake page |
| Hardware key, e.g. YubiKey | Privileged roles: admins, production, finance | Every user needs a carrier plus a backup key; binding to a login point is coordinated in advance |
| Code by email or messenger | Rare login and access recovery | Delivery delays; access to email becomes the weak link of the entire scheme |
| Built-in device authenticator, trusted device | Mass login where the share of completed logins matters | Binding to the device and its ecosystem, transfer between platforms is limited |
A separate topic is trusted devices: "remember for 30 days" reduces the number of code requests but creates a list of exceptions that is reviewed when the device changes.
Backup codes are issued once and stored outside email — during an audit this is a full-fledged factor. We also check compatibility on the login provider side: not every system supports multiple factors for one account.
How 2FA implementation proceeds: from login audit to procedures
The order of stages here is not a formality: if codes are enabled before all entry points and access-return scenarios are described, some employees get locked out, and support drowns in manual unblocks. We go from inventory to full enablement — with the ability to roll back any step.
- Login point audit. We collect all places where the system lets a user in: the main form, administrative perimeter, service-to-service calls, password recovery, login via external providers. We mark where the second factor is absent and where it is bypassed by password reset.
- Scheme and access recovery scenarios. We decide what suits whom: one-time codes in an app for most, hardware keys for privileged accounts. We describe backup codes in advance, re-linking when a device is lost, and identity confirmation by an administrator.
- Configuration and testing on staging. We replicate the production configuration: code issuance and validation, clock skew, attempt limits, behavior on incorrect input.
- Phased enablement. First a small group, then departments one by one — an error in the scheme is visible on ten people, not the entire company.
- Pilot on a user group. A week of observation: share of successful logins, number of support requests, access recovery time. Based on the results, we adjust hints and lockout thresholds.
- Handover of procedures. Instructions for employees, procedure for issuing backup codes, access revocation upon dismissal, a memo for first-line support.
After that, the customer handles onboarding new employees independently — we stay in touch for scheme changes.
Handover package: configurations, flow diagrams, and support procedures
The package is assembled so that any team familiar with the stack, not only the code author, can maintain the solution. Below is exactly what we hand over and why each item is sufficient for independent development.
- Second-factor configuration: parameters for issuing secret keys, time step duration, set of supported confirmation algorithms, and allowable clock skew between the server and the user's device.
- Login flow diagrams: diagrams for login with password and code, re-confirmation, connecting a new device, and forced factor revocation — with points where the solution accesses the database and an external provider.
- Access policy: which roles and actions require the second factor (administration, payments, data exports) and where a password is sufficient, tied to roles in the system.
- Access recovery rules: scenarios for phone loss and device change, the reset procedure via support, the list of confirming data, and who is authorized to approve such a reset.
- Support instructions: handling requests by error codes, what to do with an incorrect code, clock skew, repeated failures, and suspected account compromise.
- Backup code handling: issuance of a one-time set, storage location, invalidation after use — login should not depend on a single device.
- Logging and notifications: which events are recorded (successful login, failure, factor reset, device change), where notifications go, and how long records are stored.
- Configuration change procedure: how to safely change factor parameters without locking out active users and how to roll back an unsuccessful change.
Project breakdown: second factor in a service with thousands of accounts
A service with thousands of active accounts lived on a single password. After a series of logins from atypical regions and matches with leaked databases, it became clear: a password does not protect against reuse. Every suspected takeover was investigated manually — locking an account took hours.
Timeline: eight weeks to mandatory mode
We started with an inventory of entry points — portal, admin perimeter, programmatic calls. The primary factor chosen was time-based one-time codes: they are supported by common authenticator apps, including Google Authenticator.
Rollout order: employees, then voluntary opt-in for customers, then mandatory mode for roles with access to personal data.
Mandatory second factor was enabled by 94% of active accounts. The share of successful first-attempt logins dropped from 97% to 91% and returned to 96% when trusted browsers stopped requesting the code again. Access recovery requests: 3.4 per thousand logins in the first two weeks, 1.1 by the fifth.
What turned out harder than expected
Not the code itself, but recovery: users lose phones and change devices, and the "contact support" scenario would have created a queue of requests.
We assembled a self-service path — backup codes, linking a second device, recovery via a confirmed email address with a delay. The event log shows support which factor worked: incident investigation takes minutes instead of hours.
Result: mass password guessing ceased to be a working scenario, while support load remained at the previous level.
How does multi-factor authentication differ from passwordless login?
The difference is not in the number of steps on the login screen, but in what exactly the system verifies. Multi-factor authentication (2FA) combines knowledge — a password — with possession: a one-time code or hardware key.
Passwordless login removes knowledge entirely: the browser responds to the server's request with a domain-bound signature, and the password is neither stored nor entered anywhere.
We keep the three levels compatible in one application — users can be migrated gradually, without recreating accounts.
| Login protection level | What is verified | Scenario | Limitations |
|---|---|---|---|
| Password plus second factor | Knowledge and possession of a device | Public services with an external audience | The code can be solicited by a phishing page |
| Multiple independent factors | Two factors from different categories | Payments, admin panel, personal data | Access recovery requires a procedure |
| Passwordless login by device key | Domain-bound signature | Employees logging in daily | A backup key and recovery path are needed |
For an online store storefront, the first level is enough: it cuts off mass password guessing and does not hinder the buyer. We protect the admin panel and payouts section with the second — a stolen password alone does not grant access.
The third is chosen where login is daily from one workstation: the employee does not enter a password, and a phishing page gets nothing that can be reused.
The levels do not exclude each other: a device key is connected as a second factor to the password, and passwordless mode is enabled for a specific user — everyone else logs in as before.
Technical concerns about 2FA: addressing them before project start
The code is generated using the standard TOTP algorithm and verified on the service side, so the doubts are caused not by mathematics but by operations: phone loss, partial enablement, service integrations, the flow of support requests.
We resolve these four questions before work starts — the answers change the access scheme and how secrets are stored.
An employee lost their phone — will they be left without access?
No. During linking, the service issues a set of one-time backup codes; only their hashes are stored in the database — recovery does not create a new leak point. Then either a code from the set or re-issuance of the link after identity confirmation via a second channel. Active sessions are revoked, and the event is recorded in the log.
Can protection be enabled not for everyone at once?
Yes, policies are tied to roles and groups: access to payments, personal data, and admin panels is closed immediately, while others are given a deadline for linking.
A workaround is more dangerous than the protection itself — an open service login or a mobile client with an old token creates a false sense of security, so the entry point inventory comes first.
What about service integrations and bots?
They do not go through interactive login and do not have a phone — and that is not a problem. Machine accounts have a separate access class: long-lived keys with a limited set of permissions, environment binding, and scheduled rotation.
They are stored in a secret vault, not in configuration files, and do not inherit a person's permissions.
Will support load increase?
The peak of requests is in the first weeks after enablement: linking and re-issuance. We reduce it with self-service recovery, a short instruction, and clear errors in the interface.
After that, the flow returns to the previous level; we track the share of recovery requests and time to access restoration.
Let's discuss the task and come back with a second-factor implementation plan
To come back with an implementation plan and scope estimate, rather than general promises, we need input on your system. Below is what to prepare for the second-factor discussion: this set is enough to break the work into stages and provide timelines.
- List of entry points: web portal, admin panel, mobile client, service interfaces, contractor login. Each point is either included in scope or explicitly excluded — this immediately clarifies the scope estimate.
- User groups and their number — employees, customers, external partners. This determines whether we enable the second factor for everyone at once or roll it out in stages by group.
- Access recovery scenarios: what to do if a phone is lost or the app is deleted. Backup codes, a second confirmed method, and a clear manual reset procedure via support are needed.
- Current login logic and secret storage: where accounts live, whether there is a corporate directory, how lockouts after failed attempts are arranged, and the login event log.
- Audit or regulator requirements for identity confirmation and log retention period — they determine who gets access to secrets and how long login records live.
- Stage order and constraints: release dates, maintenance windows, availability of a staging environment with a data copy, and what improvements your team is ready to make.
With this set, we come back not with promises: we show the stage order, implementation plan, and scope estimate with open risks. Describe the task — we will ask clarifying questions specifically about your system.
