[{"data":1,"prerenderedAt":646},["ShallowReactive",2],{"blog-/blog/passkeys-modern-authentication-guide":3},{"id":4,"title":5,"body":6,"description":630,"extension":631,"meta":632,"navigation":641,"path":642,"seo":643,"stem":644,"__hash__":645,"date":633,"category":634,"tags":635,"readTime":639,"featured":640},"content/blog/passkeys-modern-authentication-guide.md","Passkeys Explained: A Practical Guide to Modern Authentication",{"type":7,"value":8,"toc":609},"minimark",[9,13,18,21,26,29,36,41,51,56,73,76,80,83,88,92,103,107,124,127,131,134,139,143,157,161,178,182,185,190,194,208,212,229,233,236,241,245,262,266,280,283,287,290,294,309,312,316,328,331,335,478,482,485,489,492,518,522,525,551,554,558,561,564,568,571,574,606],[10,11,12],"p",{},"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.",[14,15,17],"h2",{"id":16},"the-authentication-landscape","The Authentication Landscape",[10,19,20],{},"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.",[22,23,25],"h3",{"id":24},"local-username-and-password","Local Username and Password",[10,27,28],{},"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.",[10,30,31,35],{},[32,33,34],"strong",{},"How it works:"," User types a password → server compares hash → access granted or denied.",[10,37,38],{},[32,39,40],{},"Strengths:",[42,43,44,48],"ul",{},[45,46,47],"li",{},"No external dependencies — works without third-party services",[45,49,50],{},"Universally understood by users",[10,52,53],{},[32,54,55],{},"Weaknesses:",[42,57,58,61,64,67,70],{},[45,59,60],{},"Passwords are routinely weak, reused, and phished",[45,62,63],{},"Credential stuffing attacks exploit reused passwords across services",[45,65,66],{},"Breached password databases make brute-force attacks practical",[45,68,69],{},"Password resets are a major support burden and social engineering vector",[45,71,72],{},"No cryptographic proof the server is legitimate — phishing pages work perfectly",[10,74,75],{},"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.",[22,77,79],{"id":78},"two-factor-authentication-2fa-totp","Two-Factor Authentication (2FA / TOTP)",[10,81,82],{},"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.",[10,84,85,87],{},[32,86,34],{}," User submits password + TOTP code → both are verified → access granted.",[10,89,90],{},[32,91,40],{},[42,93,94,97,100],{},[45,95,96],{},"Significantly raises the bar for attackers — compromising a password alone is insufficient",[45,98,99],{},"TOTP apps (Google Authenticator, Authy) are widely available and free",[45,101,102],{},"No server-side changes to the password model required",[10,104,105],{},[32,106,55],{},[42,108,109,112,115,118,121],{},[45,110,111],{},"Still requires a password as the first factor — phishing can capture both simultaneously",[45,113,114],{},"Real-time phishing attacks (adversary-in-the-middle proxies) can intercept TOTP codes before they expire",[45,116,117],{},"TOTP codes are valid for 30 seconds — a narrow but exploitable window",[45,119,120],{},"Users find it cumbersome and often resist adoption",[45,122,123],{},"SMS-based 2FA (not TOTP) is actively exploited through SIM-swapping",[10,125,126],{},"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.",[22,128,130],{"id":129},"oauth2-social-login","OAuth2 / Social Login",[10,132,133],{},"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.",[10,135,136,138],{},[32,137,34],{}," User clicks \"Sign in with Google\" → redirected to Google → authenticates → Google issues token → application validates token → access granted.",[10,140,141],{},[32,142,40],{},[42,144,145,148,151,154],{},[45,146,147],{},"Eliminates passwords at the application level — no local credential database to breach",[45,149,150],{},"Leverages the identity provider's own security (which may include phishing-resistant MFA)",[45,152,153],{},"Reduces password fatigue — one account, many applications",[45,155,156],{},"Centralised account management: revoke access from the IdP, access is immediately gone everywhere",[10,158,159],{},[32,160,55],{},[42,162,163,166,169,172,175],{},[45,164,165],{},"Creates a hard dependency on the identity provider — if Google or Microsoft has an outage, logins fail",[45,167,168],{},"Token theft is a meaningful attack vector — stolen OAuth tokens grant access without credentials",[45,170,171],{},"Misconfigured OAuth implementations are a common source of vulnerabilities",[45,173,174],{},"Requires internet access to the IdP, which may not suit air-gapped or restricted environments",[45,176,177],{},"Users with compromised Google or Microsoft accounts lose access to everything federated to it",[22,179,181],{"id":180},"ldap-active-directory","LDAP / Active Directory",[10,183,184],{},"LDAP (and its Microsoft implementation, Active Directory) provides centralised directory authentication. The application passes credentials to the directory server for validation.",[10,186,187,189],{},[32,188,34],{}," User submits username/password → application queries LDAP server → directory validates credentials → access granted.",[10,191,192],{},[32,193,40],{},[42,195,196,199,202,205],{},[45,197,198],{},"Centralised user management — a single directory serves all internal applications",[45,200,201],{},"Integrates naturally with Windows environments",[45,203,204],{},"IT can manage access, groups, and policies from one place",[45,206,207],{},"Supports password policies, lockout rules, and expiry at the directory level",[10,209,210],{},[32,211,55],{},[42,213,214,217,220,223,226],{},[45,215,216],{},"Credentials still travel from the user's browser to the application to the LDAP server — phishing risk remains",[45,218,219],{},"LDAP over unencrypted connections (port 389) is a significant risk; LDAPS or STARTTLS is essential",[45,221,222],{},"LDAP injection is a real vulnerability in poorly implemented integrations",[45,224,225],{},"Does not eliminate the fundamental weakness of password-based authentication",[45,227,228],{},"Complexity: LDAP configuration, service accounts, and certificate management add operational overhead",[22,230,232],{"id":231},"saml-20","SAML 2.0",[10,234,235],{},"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.",[10,237,238,240],{},[32,239,34],{}," User accesses application → redirected to IdP → authenticates with IdP → IdP sends signed SAML assertion → application validates signature → access granted.",[10,242,243],{},[32,244,40],{},[42,246,247,250,253,256,259],{},[45,248,249],{},"True credential separation — the application never sees the password",[45,251,252],{},"Signed assertions are cryptographically verified — very difficult to forge",[45,254,255],{},"Supports enterprise IdPs (Azure AD, Okta, Google Workspace, ADFS)",[45,257,258],{},"Enables centralised MFA enforcement at the IdP",[45,260,261],{},"Single logout across all federated applications",[10,263,264],{},[32,265,55],{},[42,267,268,271,274,277],{},[45,269,270],{},"Complex to configure correctly — SAML has many implementation pitfalls",[45,272,273],{},"XML signature wrapping attacks have affected poorly implemented SAML libraries",[45,275,276],{},"Still dependent on whatever authentication the IdP uses — if that is a password, the phishing risk moves to the IdP login page",[45,278,279],{},"Not suitable for consumer-facing or small-team contexts",[281,282],"hr",{},[14,284,286],{"id":285},"passkeys-a-different-model-entirely","Passkeys: A Different Model Entirely",[10,288,289],{},"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.",[10,291,292],{},[32,293,34],{},[295,296,297,303],"ol",{},[45,298,299,302],{},[32,300,301],{},"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.",[45,304,305,308],{},[32,306,307],{},"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.",[10,310,311],{},"No password is transmitted. No shared secret exists that can be stolen from the server.",[22,313,315],{"id":314},"why-passkeys-are-phishing-resistant","Why Passkeys Are Phishing-Resistant",[10,317,318,319,323,324,327],{},"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 (",[320,321,322],"code",{},"archive.company.com",", for example). When a user is directed to a phishing site (",[320,325,326],{},"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.",[10,329,330],{},"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.",[22,332,334],{"id":333},"passkeys-vs-everything-else","Passkeys vs. Everything Else",[336,337,338,363],"table",{},[339,340,341],"thead",{},[342,343,344,348,351,354,357,360],"tr",{},[345,346,347],"th",{},"Method",[345,349,350],{},"Phishing-resistant",[345,352,353],{},"No shared secret",[345,355,356],{},"Offline-capable",[345,358,359],{},"User friction",[345,361,362],{},"Server complexity",[364,365,366,385,402,420,436,450],"tbody",{},[342,367,368,372,375,377,380,383],{},[369,370,371],"td",{},"Password only",[369,373,374],{},"✗",[369,376,374],{},[369,378,379],{},"✓",[369,381,382],{},"Low",[369,384,382],{},[342,386,387,390,393,395,397,400],{},[369,388,389],{},"Password + TOTP",[369,391,392],{},"Partial",[369,394,374],{},[369,396,379],{},[369,398,399],{},"High",[369,401,382],{},[342,403,404,407,410,413,415,417],{},[369,405,406],{},"OAuth2",[369,408,409],{},"Depends on IdP",[369,411,412],{},"✓ (at app level)",[369,414,374],{},[369,416,382],{},[369,418,419],{},"Medium",[342,421,422,425,427,429,432,434],{},[369,423,424],{},"LDAP",[369,426,374],{},[369,428,374],{},[369,430,431],{},"✓ (internal)",[369,433,382],{},[369,435,419],{},[342,437,438,440,442,444,446,448],{},[369,439,232],{},[369,441,409],{},[369,443,412],{},[369,445,374],{},[369,447,382],{},[369,449,399],{},[342,451,452,457,461,465,469,474],{},[369,453,454],{},[32,455,456],{},"Passkeys",[369,458,459],{},[32,460,379],{},[369,462,463],{},[32,464,379],{},[369,466,467],{},[32,468,379],{},[369,470,471],{},[32,472,473],{},"Very low",[369,475,476],{},[32,477,382],{},[22,479,481],{"id":480},"the-user-experience-advantage","The User Experience Advantage",[10,483,484],{},"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.",[22,486,488],{"id":487},"device-and-platform-support","Device and Platform Support",[10,490,491],{},"Passkeys are now supported across all major platforms:",[42,493,494,500,506,512],{},[45,495,496,499],{},[32,497,498],{},"iOS / macOS:"," iCloud Keychain syncs passkeys across Apple devices",[45,501,502,505],{},[32,503,504],{},"Android / Chrome:"," Google Password Manager handles passkey storage and sync",[45,507,508,511],{},[32,509,510],{},"Windows:"," Windows Hello provides passkey support",[45,513,514,517],{},[32,515,516],{},"Hardware tokens:"," YubiKey and similar devices support FIDO2 for organisations requiring hardware-bound credentials",[22,519,521],{"id":520},"where-passkeys-are-not-yet-the-full-answer","Where Passkeys Are Not Yet the Full Answer",[10,523,524],{},"Passkeys are not a silver bullet for every scenario:",[42,526,527,533,539,545],{},[45,528,529,532],{},[32,530,531],{},"Legacy systems:"," Older applications that cannot implement WebAuthn require a bridging strategy",[45,534,535,538],{},[32,536,537],{},"Shared accounts:"," Passkeys are designed for individual users — shared service accounts need a different approach",[45,540,541,544],{},[32,542,543],{},"Device loss:"," Recovery without a backup passkey or alternative method requires administrative intervention",[45,546,547,550],{},[32,548,549],{},"Organisational rollout:"," Users unfamiliar with biometric authentication need onboarding",[10,552,553],{},"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.",[14,555,557],{"id":556},"passkeys-in-email-archiving","Passkeys in Email Archiving",[10,559,560],{},"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.",[10,562,563],{},"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.",[14,565,567],{"id":566},"summary","Summary",[10,569,570],{},"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.",[10,572,573],{},"For organisations reviewing their authentication stack, the practical recommendation is:",[295,575,576,582,588,594,600],{},[45,577,578,581],{},[32,579,580],{},"Enable passkeys"," as the primary method for privileged users and sensitive applications",[45,583,584,587],{},[32,585,586],{},"Enforce TOTP 2FA"," as a minimum for any account still using passwords",[45,589,590,593],{},[32,591,592],{},"Federate via SAML or OAuth2"," for centrally managed workforce accounts",[45,595,596,599],{},[32,597,598],{},"Integrate LDAP/AD"," for directory-based access control in Windows environments",[45,601,602,605],{},[32,603,604],{},"Audit and disable"," password-only login wherever feasible",[10,607,608],{},"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.",{"title":610,"searchDepth":611,"depth":611,"links":612},"",2,[613,621,628,629],{"id":16,"depth":611,"text":17,"children":614},[615,617,618,619,620],{"id":24,"depth":616,"text":25},3,{"id":78,"depth":616,"text":79},{"id":129,"depth":616,"text":130},{"id":180,"depth":616,"text":181},{"id":231,"depth":616,"text":232},{"id":285,"depth":611,"text":286,"children":622},[623,624,625,626,627],{"id":314,"depth":616,"text":315},{"id":333,"depth":616,"text":334},{"id":480,"depth":616,"text":481},{"id":487,"depth":616,"text":488},{"id":520,"depth":616,"text":521},{"id":556,"depth":611,"text":557},{"id":566,"depth":611,"text":567},"Passwords have been the weakest link in enterprise security for decades. Passkeys offer a fundamentally better approach — but how do they compare to 2FA, OAuth2, LDAP, and SAML? This guide breaks it all down.","md",{"date":633,"category":634,"tags":635,"readTime":639,"featured":640},"2026-04-25","Security",[634,636,456,637,638],"Authentication","Best Practices","Enterprise","8 min read",false,true,"/blog/passkeys-modern-authentication-guide",{"title":5,"description":630},"blog/passkeys-modern-authentication-guide","aWavG89yxSPZ0GULwz0st20ATbjKXQdnWPFzP2PEnyU",1777095950662]