Passkeys Explained: A Practical Guide to Modern Authentication

Authentication is one of those problems that feels solved until it isn't. Organisations have layered defences on top of passwords for decades — two-factor codes, SSO federation, hardware tokens — and yet credential-based attacks remain the leading cause of data breaches. Passkeys represent the most significant rethink of authentication since passwords themselves, and understanding how they compare to existing methods is essential for any organisation evaluating its security posture.

The Authentication Landscape

Before diving into passkeys, it helps to understand what we are comparing against. Enterprise systems typically offer a spectrum of authentication methods, each with different security properties and operational trade-offs.

Local Username and Password

The oldest and most familiar method. A user creates a credential, the system stores a hashed version, and login involves submitting the password for comparison.

How it works: User types a password → server compares hash → access granted or denied.

Strengths:

• No external dependencies — works without third-party services
• Universally understood by users

Weaknesses:

• Passwords are routinely weak, reused, and phished
• Credential stuffing attacks exploit reused passwords across services
• Breached password databases make brute-force attacks practical
• Password resets are a major support burden and social engineering vector
• No cryptographic proof the server is legitimate — phishing pages work perfectly

Passwords do not fail because users are careless. They fail because the model is fundamentally broken: a shared secret that must be typed into a form on a website is inherently phishable.

Two-Factor Authentication (2FA / TOTP)

Two-factor authentication adds a time-based one-time password (TOTP) — typically a six-digit code from an authenticator app — on top of the password.

How it works: User submits password + TOTP code → both are verified → access granted.

Strengths:

• Significantly raises the bar for attackers — compromising a password alone is insufficient
• TOTP apps (Google Authenticator, Authy) are widely available and free
• No server-side changes to the password model required

Weaknesses:

• Still requires a password as the first factor — phishing can capture both simultaneously
• Real-time phishing attacks (adversary-in-the-middle proxies) can intercept TOTP codes before they expire
• TOTP codes are valid for 30 seconds — a narrow but exploitable window
• Users find it cumbersome and often resist adoption
• SMS-based 2FA (not TOTP) is actively exploited through SIM-swapping

2FA meaningfully improves security but does not eliminate phishing risk. A sophisticated attacker with a phishing proxy can harvest both the password and the TOTP code in real time.

OAuth2 / Social Login

OAuth2 delegates authentication to a trusted identity provider — Google, Microsoft, or a corporate IdP. The user authenticates with the provider, which issues a token that the application accepts.

How it works: User clicks "Sign in with Google" → redirected to Google → authenticates → Google issues token → application validates token → access granted.

Strengths:

• Eliminates passwords at the application level — no local credential database to breach
• Leverages the identity provider's own security (which may include phishing-resistant MFA)
• Reduces password fatigue — one account, many applications
• Centralised account management: revoke access from the IdP, access is immediately gone everywhere

Weaknesses:

• Creates a hard dependency on the identity provider — if Google or Microsoft has an outage, logins fail
• Token theft is a meaningful attack vector — stolen OAuth tokens grant access without credentials
• Misconfigured OAuth implementations are a common source of vulnerabilities
• Requires internet access to the IdP, which may not suit air-gapped or restricted environments
• Users with compromised Google or Microsoft accounts lose access to everything federated to it

LDAP / Active Directory

LDAP (and its Microsoft implementation, Active Directory) provides centralised directory authentication. The application passes credentials to the directory server for validation.

How it works: User submits username/password → application queries LDAP server → directory validates credentials → access granted.

Strengths:

• Centralised user management — a single directory serves all internal applications
• Integrates naturally with Windows environments
• IT can manage access, groups, and policies from one place
• Supports password policies, lockout rules, and expiry at the directory level

Weaknesses:

• Credentials still travel from the user's browser to the application to the LDAP server — phishing risk remains
• LDAP over unencrypted connections (port 389) is a significant risk; LDAPS or STARTTLS is essential
• LDAP injection is a real vulnerability in poorly implemented integrations
• Does not eliminate the fundamental weakness of password-based authentication
• Complexity: LDAP configuration, service accounts, and certificate management add operational overhead

SAML 2.0

SAML is an XML-based federation standard that allows an identity provider (IdP) to assert a user's identity to a service provider (SP) without the SP ever handling credentials.

How it works: User accesses application → redirected to IdP → authenticates with IdP → IdP sends signed SAML assertion → application validates signature → access granted.

Strengths:

• True credential separation — the application never sees the password
• Signed assertions are cryptographically verified — very difficult to forge
• Supports enterprise IdPs (Azure AD, Okta, Google Workspace, ADFS)
• Enables centralised MFA enforcement at the IdP
• Single logout across all federated applications

Weaknesses:

• Complex to configure correctly — SAML has many implementation pitfalls
• XML signature wrapping attacks have affected poorly implemented SAML libraries
• Still dependent on whatever authentication the IdP uses — if that is a password, the phishing risk moves to the IdP login page
• Not suitable for consumer-facing or small-team contexts

Passkeys: A Different Model Entirely

Passkeys (the consumer-friendly name for FIDO2/WebAuthn credentials) take a fundamentally different approach. Rather than a shared secret verified by the server, passkeys use public-key cryptography: the server stores only a public key, and the private key never leaves the user's device.

How it works:

1. Registration: The user's device generates a public/private key pair for the site. The public key is sent to and stored by the server. The private key never leaves the device.
2. Authentication: The server sends a cryptographic challenge. The device signs it with the private key (after the user authenticates locally via biometric or PIN). The server verifies the signature against the stored public key.

No password is transmitted. No shared secret exists that can be stolen from the server.

Why Passkeys Are Phishing-Resistant

This is the critical property that distinguishes passkeys from every other method above. When a passkey is created, it is cryptographically bound to the origin — the exact domain of the website (archive.company.com, for example). When a user is directed to a phishing site (archive-company.evil.com), the passkey simply will not work: the origin does not match, so the authentication ceremony fails. There is nothing for the attacker to harvest.

This is not a UI warning or a user decision — it is enforced by the cryptographic protocol. Phishing a passkey is not harder; it is not possible.

Passkeys vs. Everything Else

The User Experience Advantage

Beyond security, passkeys are genuinely more convenient than passwords. Authentication is a biometric prompt or device PIN — the same gesture used to unlock a phone or laptop. There is no password to remember, no TOTP code to copy, no risk of a typo. For most users, this is the fastest login experience they have ever had.

Device and Platform Support

Passkeys are now supported across all major platforms:

• iOS / macOS: iCloud Keychain syncs passkeys across Apple devices
• Android / Chrome: Google Password Manager handles passkey storage and sync
• Windows: Windows Hello provides passkey support
• Hardware tokens: YubiKey and similar devices support FIDO2 for organisations requiring hardware-bound credentials

Where Passkeys Are Not Yet the Full Answer

Passkeys are not a silver bullet for every scenario:

• Legacy systems: Older applications that cannot implement WebAuthn require a bridging strategy
• Shared accounts: Passkeys are designed for individual users — shared service accounts need a different approach
• Device loss: Recovery without a backup passkey or alternative method requires administrative intervention
• Organisational rollout: Users unfamiliar with biometric authentication need onboarding

The practical approach for most organisations is to offer passkeys as the preferred method while maintaining LDAP, SAML, or OAuth2 as fallbacks for integrations and edge cases — and disabling password-only login entirely where possible.

Passkeys in Email Archiving

An email archive is a natural fit for passkey authentication. Archives hold sensitive communications — legal correspondence, financial records, HR matters — and are frequently targeted in investigations and audits. The people accessing them (executives, legal teams, compliance officers, IT administrators) are exactly the users most likely to be targeted by sophisticated phishing attacks.

Enabling passkey login for your archive eliminates the risk of an attacker phishing an admin's credentials and silently accessing or exporting archived communications. Combined with SAML or OAuth2 federation for bulk user access and LDAP for directory integration, passkeys round out a defence-in-depth authentication strategy that addresses the weakest link in most security programmes: the human in front of the keyboard being tricked into handing over their credentials.

Summary

Passwords are not going away overnight, but the direction of travel is clear. Every major platform — Apple, Google, Microsoft — is actively moving users toward passkeys. The FIDO Alliance estimates that billions of passkeys are now in use, and enterprise adoption is accelerating.

For organisations reviewing their authentication stack, the practical recommendation is:

1. Enable passkeys as the primary method for privileged users and sensitive applications
2. Enforce TOTP 2FA as a minimum for any account still using passwords
3. Federate via SAML or OAuth2 for centrally managed workforce accounts
4. Integrate LDAP/AD for directory-based access control in Windows environments
5. Audit and disable password-only login wherever feasible

The goal is not to pick one method — it is to eliminate the weakest ones and give users a login experience that is both more secure and more convenient than a password they have to remember.