How Passkeys Prevent Phishing in iOS 16

Apple introduced passkeys in iOS 16 as a replacement for traditional passwords, utilizing public-key cryptography to eliminate common vulnerabilities. By binding authentication credentials directly to verified web domains, passkeys make it mathematically and structurally impossible for users to be tricked into handing over their credentials on fraudulent websites. This article explains the underlying mechanics of passkeys, how domain-bound cryptographic keys function, and why this design effectively eliminates phishing and credential-harvesting attacks.

The Foundation of Passkey Technology

Passkeys are built on the FIDO Alliance and W3C WebAuthn standards. Instead of a text string known by both the user and the server, a passkey relies on an asymmetric cryptographic key pair:

  • Private Key: Stored securely on the user’s device (and synced via end-to-end encrypted iCloud Keychain) and never shared with anyone.
  • Public Key: Registered and stored on the website or service's server.

When a user signs in, the server issues an authentication challenge. The iOS device signs this challenge using the private key, and the server verifies it using the public key. At no point in this exchange is a secret password transmitted across the internet.

Cryptographic Domain Binding

The primary mechanism that stops phishing attacks is domain binding. When a passkey is created, the operating system securely associates it with the fully qualified domain name (FQDN) of the website or the verified app identifier.

In a traditional phishing scenario, an attacker tricks a user into visiting a spoofed site (such as bank-login.com instead of bank.com). If the user enters a password, the attacker captures it.

With iOS 16 passkeys:

  1. The Safari browser or operating system detects the exact domain of the active webpage.
  2. The operating system only offers to use a passkey if the domain strictly matches the origin tied to the private key.
  3. Because the spoofed phishing domain does not match the legitimate domain, the device refuses to present the passkey.

Because this verification happens at the system level, human error is removed from the process. Even if a user is completely convinced that a phishing website is authentic, iOS 16 will not provide the credential to the fake site.

Elimination of Shared Secrets and Interception

Traditional two-factor authentication (2FA) methods, such as SMS codes or one-time passwords (OTPs), remain vulnerable to adversary-in-the-middle (AitM) reverse-proxy phishing attacks. In these attacks, a proxy server relays credentials and one-time codes in real time to gain access to an account.

Passkeys resist AitM attacks because:

  • No Reusable Credentials: The signature created by the private key is unique to a single challenge and a specific domain. An attacker intercepting the response cannot use it to log in elsewhere or replay the transaction.
  • No Manual Codes: Users never see, copy, or type a code that could be relayed to an attacker.

Local Biometric Enforcement

To sign the cryptographic challenge, the user must authenticate locally using Face ID, Touch ID, or their device passcode. This ensures that physical possession and biometric presence are mandatory for every login request, preventing remote malicious actors from silently using stored credentials without the user's active participation.