For more than sixty years the password has been the default authentication mechanism in computing, and for almost all of that time it has also been its weakest point. Most of the security breaches that make the headlines do not start with a sophisticated attack on a fortified system, but with something far more mundane: a credential that was stolen, reused or guessed.
The good news is that the industry has spent years building stronger alternatives. Multi-factor authentication (MFA) dramatically reduces the chance that a compromised password turns into unauthorized access, and passkeys — credentials based on the FIDO2/WebAuthn standard — promise something even more ambitious: to eliminate the password entirely, along with the whole class of attacks that surround it.
In this article we explain why the password fails, what the different authentication factors are and how they compare, what makes passkeys special, and how an organization can chart a realistic path towards a passwordless model without breaking its operations.
The Password Problem
The fundamental flaw of the password is that it is a shared secret: the user knows it and the server stores it (ideally as a hash). Any point where that secret travels, is typed or is kept is an opportunity to steal it. On top of that structural weakness sit several well-known problems:
- check_circle Reuse: the average user manages dozens of accounts and repeats the same password across many of them. A leak in a minor service opens the door to all the others.
- check_circle Phishing: one convincing fake page is enough for the victim to type their password where they should not. No complexity policy protects against a user who hands it over voluntarily.
- check_circle Brute force and dictionary: against leaked hashes or forms with no attempt limit, the attacker tries millions of combinations until the weak passwords fall.
- check_circle Credential stuffing: with billions of username/password pairs from previous leaks, attackers replay them automatically against other services, exploiting reuse.
- check_circle Massive breaches: every year databases with hundreds of millions of credentials are exposed. A password that is valid today may already be circulating in a dump that has not yet gone public.
The common denominator is that all these attacks exploit a secret that can be copied. That is why the defense is not just about having longer passwords, but about changing the paradigm: adding extra factors and, ultimately, replacing the shared secret with cryptography that cannot be stolen at a distance. It is the same defense-in-depth logic we apply across our whole security strategy.
The Three Authentication Factors
Authenticating someone means proving they are who they claim to be. Classic theory distinguishes three categories of proof, and the strength of a system depends on how many independent categories it combines:
- check_circle Something you know: passwords, PINs, answers to security questions. It is the weakest factor because knowledge can be transmitted, guessed or stolen.
- check_circle Something you have: a phone, an authenticator app, a hardware security key. The attacker would need the physical object or to compromise the device.
- check_circle Something you are: biometrics such as a fingerprint or face recognition. In practice it is used to locally unlock a possession factor, not as a secret that travels over the network.
Multi-factor authentication (MFA), often called 2FA when there are two factors, requires combining at least two different categories. The key is the word different: asking for two passwords is not MFA, because both belong to "something you know" and share the same weaknesses. What adds value is crossing categories, so that a single type of compromise is not enough for access.
MFA/2FA: Types and Their Phishing Resistance
Not all second factors offer the same protection. The critical difference is whether they resist phishing — that is, whether an attacker who tricks the user into interacting with a fake page can still walk away with the access. Ordered from weakest to strongest:
SMS OTP (code by text message). It is the most widespread and also the weakest. The one-time code travels over a telephony network that was never designed for security, it is interceptable and, above all, vulnerable to SIM swapping: the attacker convinces the carrier to port the number to a SIM they control and receives every code. On top of that, an SMS code can be entered into a fake page just as easily as the password itself. It works as a minimum, but should not be the only second factor for an important access.
TOTP (authenticator apps). Apps such as Google Authenticator, Microsoft Authenticator or Aegis generate a temporary six-digit code from a shared secret and the current time. It is clearly better than SMS because the code never travels over the mobile network and there is no number to hijack. However, it is still a secret the user can type into a fraudulent site, so it is not phishing-resistant in real time.
Push notifications. Instead of typing a code, the user gets a notification on their phone and approves with a tap. It is convenient, but it introduces a risk of its own: MFA fatigue (or MFA bombing), where the attacker, already holding the password, fires repeated requests until the user approves one out of tiredness or carelessness. Variants with number matching mitigate the problem, but do not eliminate it.
FIDO2/WebAuthn keys and credentials. Here the nature of the system changes. Instead of a shared secret, a pair of cryptographic keys is used, and authentication is bound to the service's real domain. Even if the user falls for a fake page, the browser will not sign the challenge for a domain that does not match, so the attack simply does not work. It is the gold standard and the technical foundation of passkeys. You can dig deeper into how these deceptions are countered in our article on phishing and social engineering.
What Passkeys Are and How They Work
A passkey is a FIDO2 credential based on public-key cryptography. When you register with a service, your device generates a key pair: a private key that never leaves the device (protected by secure hardware and unlocked with your biometrics or PIN) and a public key handed to the server. The server stores something that, on its own, cannot impersonate you: the public half of the pair.
Signing in is a challenge-response process. The server sends a random challenge; the device signs it with the private key after the biometric unlock and returns the signature. The server verifies it with the public key it already had. At no point is a reusable secret transmitted: there is nothing to intercept or to steal from the service's database, because the private key is never shared.
Furthermore, each passkey is bound to the domain it was created for. The browser only allows it to be used on the legitimate origin, which makes passkeys impossible to phish: a fraudulent site cannot trigger a valid signature for the real domain. This property alone eliminates the most profitable attack vector against credentials.
Passkeys come in two variants depending on where the private key lives. Synced passkeys are replicated in encrypted form across the user's devices through a keychain such as iCloud Keychain or Google Password Manager, prioritizing convenience and recovery. Device-bound passkeys, or those tied to a hardware key such as a YubiKey, never leave that physical medium, offering the highest guarantee for critical access. The standard and its ecosystem are coordinated by the FIDO Alliance.
The idea in one sentence:
If there is no shared secret to type, there is nothing an attacker can steal by phishing, leak from a database or crack by brute force. Passkeys do not make passwords stronger: they make them unnecessary.
The advantages stack up: credential phishing is eliminated, the user experience improves (a biometric tap instead of remembering and typing complex strings) and the burden of managing, rotating and storing passwords disappears. For the security team, it also removes an entire family of incidents that today consume most of the response time.
Comparison of MFA Methods
The following table sums up how the main methods behave against the three criteria that matter most when choosing: phishing resistance, user experience and deployment cost.
| Method | Phishing resistance | User experience | Cost |
|---|---|---|---|
| Password only | None | Low (recall/type) | Very low |
| SMS OTP | Weak (SIM swapping) | Medium | Low-medium |
| TOTP (app) | Medium (still phishable) | Medium | Low |
| Push notification | Medium (MFA fatigue risk) | High | Medium |
| Passkey / FIDO2 (sync) | High (anti-phishing) | Very high (biometrics) | Medium |
| Hardware key (YubiKey) | Maximum | High | Medium-high (hardware) |
The Passwordless Path in the Enterprise
Moving an organization towards a passwordless model is a phased process, not a switch you flip overnight. The starting point is non-negotiable: mandatory MFA now, on every access and with no "temporary" exceptions that end up permanent. From there, the migration to passkeys is gradual, enabling them first where support is mature and expanding coverage as applications allow.
The main lever is SSO and the identity provider (IdP). Centralizing authentication in Microsoft Entra ID, Okta or Keycloak lets you apply MFA and passkey policies uniformly across dozens of applications from a single point, instead of configuring each system separately. The IdP also becomes the natural place to apply conditional access based on the risk of each session.
There are accesses where phishing-resistant MFA is not optional but mandatory: SSH to servers, admin panels, VPN and backup systems. These are precisely the accesses whose compromise gives the attacker the keys to the kingdom, and where a hardware key or a device-bound passkey provides the highest guarantee. In the same vein, it is worth moving machine secrets out of scripts and environment variables into a dedicated manager, as we explain in our guide to secrets management with Vault.
All of this fits naturally into a Zero Trust architecture, where no network or device is trusted by default and identity is verified continuously on every access. A strong, phishing-resistant identity is the foundation the rest of the model rests on: without it, any segmentation or least-privilege policy collapses the moment a credential is stolen. We develop this in depth in the practical Zero Trust guide.
Common Mistakes to Avoid
Adopting MFA is necessary, but doing it halfway leaves gaps that attackers know well. These are the failures we see most often:
- arrow_right MFA only in some places: protecting email but leaving the VPN, the hosting panel or SSH access without a second factor. The attacker always comes in through the door left open.
- arrow_right SMS as the only second factor on critical accounts: it exposes you to SIM swapping and interception. It works as a fallback, not as the main defense.
- arrow_right No secure recovery codes: if the only device is lost and there is no protected recovery method, the legitimate user is locked out or an insecure shortcut is opened to "recover" the account.
- arrow_right Ignoring MFA fatigue: allowing unlimited push approvals without number matching invites MFA bombing. Limit attempts and train users to reject unexpected requests.
Frequently Asked Questions
What is the difference between traditional 2FA and a passkey?
Traditional 2FA (SMS, TOTP or push) adds a second secret on top of the password, and that secret can still be intercepted or entered into a fake page. A passkey is a FIDO2 credential based on public-key cryptography, bound to the domain and with no shared secret to steal, so it resists phishing even when the user is tricked.
Are passkeys synced to iCloud or Google secure?
Yes. Synced passkeys are end-to-end encrypted inside the provider's keychain and are never exposed to the sites where they are used. For the most critical access you can choose device-bound passkeys or a hardware security key (YubiKey), which never leave that physical device.
Can I remove passwords entirely across my company?
Full removal is a gradual goal. What is realistic today is to enforce MFA on every access, enable passkeys wherever the IdP and applications support them (Entra ID, Okta, Keycloak) and keep passwords only as a protected recovery method. Over time, most sign-ins become passwordless.
Conclusion
The password will not disappear overnight, but its role as the only barrier is exhausted. The path is clear and is walked in stages:
- arrow_right The password is a shared secret vulnerable to reuse, phishing, brute force, credential stuffing and massive breaches. Hardening it does not remove the class of attack.
- arrow_right MFA dramatically reduces the risk, but not all factors are equal: SMS is weak, TOTP and push are better, and only FIDO2/WebAuthn truly resists phishing.
- arrow_right Passkeys replace the shared secret with domain-bound public-key cryptography: nothing to steal, a better user experience and no passwords to manage.
- arrow_right The enterprise path is gradual: mandatory MFA now, migration to passkeys via SSO/IdP, reinforced protection of critical access (SSH, panels, VPN, backup) and integration into a Zero Trust architecture.
At EasyDataHost we recommend and support MFA on administrative access to our infrastructure, with protected panels and access so that identity is the first and strongest control. If you want to review how to harden access to your platform, talk to our security team for a no-obligation assessment.