The Security Challenge
Passwords are broken
by design
Stolen credentials are behind the majority of organisational breaches. Passkeys eliminate the credential entirely.
81%
of data breaches involve stolen or weak passwords
Verizon DBIR 2024
$4.9M
average cost of a data breach involving compromised credentials
IBM Cost of Breach 2024
0
successful phishing attacks possible against passkey-protected accounts
By cryptographic design
🔑
Traditional Passwords
What most organisations use today
  • ❌Stored on the server - one breach exposes everyone
  • ❌Phishable - users can be tricked into entering them on fake sites
  • ❌Reused across services - one breach cascades
  • ❌Weak by human nature - guessable, predictable
  • ❌SMS MFA codes can be intercepted via SIM-swap
  • ❌Help desk reset is a major social engineering vector
VS
🛡️
Passkeys / FIDO2
The modern replacement
  • ✅Nothing stored on the server that can be stolen - only a public key
  • ✅Phishing-proof - cryptographically bound to the exact website domain
  • ✅Unique per service - one compromise never cascades
  • ✅No secrets to guess - based on public key mathematics
  • ✅Biometric is local only - Face ID never leaves your device
  • ✅No credential to reset - eliminates help desk attack vector
The Mechanism
How passkeys work
Two ceremonies - a one-time setup and a fast daily login. No password ever involved.
💡

The core principle: Consider a padlock and key. During registration, the user provides the service a padlock (public key) and retains the corresponding key (private key) securely on their device. At sign-in, the service locks a unique challenge with that padlock and sends it to the user - only the device key can open it. The private key never leaves the device, so there is nothing of value held on the server side to steal or compromise.

CEREMONY 1 - ONE-TIME SETUP (Enrolment)
Step 1
🖥️
User initiates passkey registration
The application requests the device to create a new FIDO2 credential
Step 2
👆
User verifies identity locally
Biometric (Face ID / fingerprint) or PIN confirms the legitimate device owner
Step 3
🔐
Device generates a cryptographic key pair
Private key is sealed within the device's secure chip. Public key is transmitted to the server.
Step 4
🗄️
Server stores only the public key
No password or secret is stored. A server breach yields nothing exploitable.
CEREMONY 2 - EVERY LOGIN (Authentication)
Step 1
🔒
Server issues a unique challenge
A cryptographically random nonce - unique per attempt, never reusable by an interceptor.
Step 2
👁️
User provides a local gesture
Biometric or PIN unlocks the private key within the device's secure chip
Step 3
✍️
Secure chip signs the challenge
The private key produces a cryptographic signature. Only this response is transmitted - never the key itself.
Step 4
✅
Server verifies - access granted
The stored public key validates the signature. Identity is confirmed without any shared secret.
🛡️
Why phishing is defeated by design: Every credential is cryptographically bound to the exact origin domain registered at enrolment. A fraudulent site produces a different challenge binding - the resulting signature will fail verification at the legitimate server regardless of whether the user was deceived. Protection is architectural, not dependent on user vigilance.
Business Case
Why this matters to the organisation
🛡️
Eliminates phishing
No credential exists to steal. A phishing email cannot capture a passkey. Even a compromised server leaks nothing useful - only a public key that is mathematically useless without the device.
Phishing success rate against passkeys
0%
⚡
Streamlined authentication experience
Users authenticate via biometric or device gesture - no credentials to type, no MFA application to switch between, no recovery flows to navigate. Login friction is materially reduced, with measurable productivity benefit across large user populations.
Faster than password + MFA
4×
📉
Reduces IT support overhead
Password reset requests are eliminated by design. MFA lockout recovery workflows are no longer required. Credential-related incidents - which represent a significant share of IT support volume at most organisations - are structurally removed from the support queue.
Typical credential support tickets eliminated
~30%
🏛️
Regulatory alignment
FIDO2/passkeys satisfy NIST AAL2/AAL3, CISA phishing-resistant MFA requirements, and PCI-DSS v4.0 MFA mandates. Increasingly required for cyber insurance qualification and government contracts.
MFA frameworks satisfied
NIST · PCI · CISA
🔒
Hardware-grade security
On YubiKeys and modern devices, the private key lives in a tamper-resistant chip (Secure Enclave / TPM). Physical extraction is nation-state territory. Software cannot access the key - only the device chip can use it to sign.
Private key ever transmitted
Never
🌐
Open industry standard
Defined by the FIDO Alliance and W3C. Supported across all major platforms, browsers, and operating systems. Not proprietary to any single vendor - the same standard operates across any compliant identity provider.
Industry adoption
Universal
Deployment Options
Authenticator options available to organisations
Two categories of FIDO2 authenticator - both implement the same underlying standard
📱
Synced Passkeys
Built into your phone, laptop, or tablet. Backed up to iCloud, Google, or Microsoft account. Uses Face ID, fingerprint, or PIN.
ExamplesiPhone (iCloud), Android, Windows Hello
CostFree - uses existing device
Lost device recoveryAutomatic via cloud sync
Shared workstationNot suitable
Phishing resistantYes
AAGUID (hardware ID)Unverified without attestation
Best forKnowledge workers with personal devices
🔑
Hardware Security Keys (YubiKey)
Physical USB / NFC token carried by the user. Requires touch to authenticate. Works on any device, any OS, any browser.
ExamplesYubiKey 5 NFC, FIDO2 security keys
Cost~$55-85 per key (+ spare)
Lost device recoveryPre-register spare key
Shared workstationIdeal - user carries key
Phishing resistantYes
AAGUID (hardware ID)Cryptographically verified
Best forPrivileged users, shared PCs, admin accounts
🏢
Recommended Deployment Strategy
Risk-tiered authenticator requirements aligned to access sensitivity
General Workforce
Synced passkeys on corporate or personal devices. Low operational friction, cloud-recoverable, and satisfies the phishing-resistant MFA bar for standard application access. Attestation enforcement recommended for new enrolments.
Privileged & Administrative Accounts
Hardware security key required. Device-bound, non-exportable private key. Functions across shared workstations. Attestation and PIN enforcement mandated in identity provider policy. Spare key pre-registration required per user.
Shared & Kiosk Workstations
Hardware security key exclusively. The user inserts their personal key, authenticates, and removes it on departure. No credential is retained on the workstation. Eliminates shared-password risk at the architectural level.
Policy Transition Considerations
Tightening attestation policy -
what breaks and why
When an organisation moves from an open FIDO2 posture (no attestation, synced passkeys permitted) to an enforced posture (attestation required, device-bound or allowlisted only), existing credentials must be assessed carefully before policy is applied.
What Carries Over
Existing credentials remain cryptographically valid
The public key, credential ID, and signature counter stored at registration are unaffected by a policy change. Provided the Relying Party ID (domain) is unchanged, users can continue authenticating. The policy transition does not invalidate the underlying cryptographic material.
✓ Same domain = credentials authenticate
✓ Public key and signature chain intact
Key Risk
Apple iCloud Keychain passkeys carry no hardware identifier
Apple deliberately transmits an all-zeros Authenticator Attestation GUID (AAGUID) for iCloud Keychain credentials - regardless of browser, operating system version, or identity provider. This is a privacy-preserving design choice by Apple, not a platform deficiency. When enrolled under a policy without attestation enforcement, these credentials are stored with no verifiable hardware identity. Enabling an AAGUID allowlist after the fact will reject them, as 00000000-0000-0000-0000-000000000000 will not appear on any approved device list.
⚠ AAGUID stored as all-zeros by design
⚠ Cannot be retroactively verified
Key Risk
Hardware token AAGUIDs enrolled without attestation are unverified claims
Hardware security keys enrolled under a no-attestation policy may have transmitted a real AAGUID - and most identity providers stored it. However, without an attestation certificate chain verified at registration time, there is no cryptographic basis for trusting that AAGUID. The stored value is an unverified self-declaration. An allowlist that matches on these values provides a usability control but not a security guarantee for pre-existing credentials.
⚠ AAGUID present but cryptographically unverified
⚠ Allowlist matching is advisory, not enforced
Action Required
Attestation enforcement must apply to new enrolments - not retroactively
Enabling attestation enforcement on an existing credential population will not retroactively verify historical enrolments. The only path to a fully verified FIDO2 estate is a managed re-enrolment programme in which users register new credentials under the updated policy. Legacy credentials should be grandfathered for a defined transition period, then retired.
⚡ Define a re-enrolment window (60-90 days)
⚡ Communicate before policy enforcement date
Critical questions before enforcing the new policy
1
Does the AAGUID allowlist apply to authentication of existing credentials, or only to new registrations?
If it gates authentication, any user with an Apple passkey or an unverified AAGUID will be locked out immediately upon policy activation.
2
Does the identity provider support requesting direct attestation for new enrolments?
Without configuring attestationConveyancePreference: direct, Apple devices will continue returning an all-zeros AAGUID even for new registrations post-policy change.
3
Is a grace period or grandfather flag available for pre-policy credentials?
A time-bounded exemption for legacy credentials enables a phased re-enrolment programme without a disruptive hard cutover on the policy activation date.
⚠️

Apple iCloud Keychain Passkeys - No Retroactive Resolution

The all-zeros AAGUID stored for Apple iCloud Keychain credentials is a function of Apple's platform design and cannot be patched, inferred, or administratively corrected without compromising the integrity of the credential record. The only technically sound resolution is to re-enrol affected users under a policy that requests direct attestation, and to add the verified Apple platform AAGUIDs to the identity provider's allowlist for future enrolments. Plan accordingly and communicate to affected users well in advance of the enforcement date.

Decision Framework
What Organisations Need to Decide
01
Enable attestation enforcement from the outset
Attestation is the cryptographic mechanism that confirms an authenticator is genuine hardware from an approved manufacturer. Without it, hardware identity claims (AAGUID) are self-declared and unverifiable. All downstream controls - allowlists, hardware tiering, compliance reporting - depend on attestation being enforced at enrolment. This is the foundational configuration decision.
→ Configure prior to first production enrolment
02
Manage the transition through a phased re-enrolment programme
Credentials enrolled under a prior policy without attestation cannot be retroactively verified. Define a formal transition window - typically 60 to 90 days - during which legacy credentials remain valid and users re-register under the updated policy. Legacy credentials should be administratively retired at the close of the window. User communications and help desk readiness are essential inputs to this plan.
→ Develop communications plan and helpdesk brief
03
Define a clear policy position on Apple iCloud Keychain passkeys
Apple iCloud Keychain passkeys cannot be enrolled with a verifiable hardware identifier under the current Apple platform design. Three policy positions are available: (a) permit Apple passkeys with verified attestation for new enrolments only, adding Apple's platform AAGUIDs to the allowlist; (b) restrict all users to hardware security keys; or (c) accept Apple passkeys for lower-assurance user populations with compensating controls. There is no retroactive resolution for existing zero-AAGUID credentials.
→ Security policy decision required from CISO
04
Implement risk-tiered authenticator requirements
Authenticator assurance requirements should be calibrated to access risk. General workforce accessing standard applications: synced passkeys with attestation are appropriate. Privileged and administrative accounts: hardware security keys with PIN enforcement and attestation are required. Shared and kiosk workstations: hardware security keys only, with user-carried keys. This tiering should be enforced through Conditional Access policy, not relied upon solely at the identity provider level.
→ Align with existing privileged access tier model
🎯
Summary: Passkeys eliminate the credential as an attack surface - there is nothing to steal, nothing to phish, and nothing to reset. Tightening from an open to an enforced attestation posture is the right direction, but requires a managed transition. Apple iCloud Keychain passkeys enrolled prior to attestation enforcement cannot be retroactively verified and must be re-enrolled. Enable attestation before the next enrolment cycle and treat the transition as the opportunity to establish a fully verified FIDO2 credential estate.
Action Required
Sources & Further Reading
References
All sources cited in this briefing
01
Verizon Data Breach Investigations Report (DBIR) 2024
81% of hacking-related breaches involve stolen or weak credentials. Verizon Business, 2024.
verizon.com/business/resources/reports/dbir/
02
IBM Cost of a Data Breach Report 2024
Average cost of a data breach involving compromised credentials: $4.9M USD. IBM Security, 2024.
ibm.com/reports/data-breach
03
W3C Web Authentication (WebAuthn) Level 2 Specification
The W3C standard defining the browser-to-server authentication API. World Wide Web Consortium, 2021.
w3.org/TR/webauthn-2/
04
FIDO Alliance - FIDO2 Overview and Specifications
FIDO2 framework specifications including Client to Authenticator Protocol (CTAP2). FIDO Alliance.
fidoalliance.org/fido2/
05
FIDO Alliance Metadata Service (MDS)
Registry of certified authenticator metadata and AAGUID entries used for attestation verification.
fidoalliance.org/metadata/
06
NIST SP 800-63B - Digital Identity Guidelines: Authentication and Lifecycle Management
Defines Authenticator Assurance Levels (AAL1, AAL2, AAL3) and requirements for phishing-resistant MFA. NIST, 2017 (updated 2022).
pages.nist.gov/800-63-3/sp800-63b.html
07
CISA - Implementing Phishing-Resistant MFA
Guidance on deploying phishing-resistant multi-factor authentication in federal and enterprise environments. Cybersecurity and Infrastructure Security Agency, 2022.
cisa.gov - Implementing Phishing-Resistant MFA (PDF)
08
PCI Security Standards Council - PCI DSS v4.0
Requirement 8.4 mandates MFA for all non-console administrative access and for remote access. PCI SSC, 2022.
pcisecuritystandards.org/document_library/
09
Apple Platform Security - iCloud Keychain and Passkeys
Documentation covering iCloud Keychain encryption, passkey sync architecture, and Apple attestation format. Apple Inc., 2024.
support.apple.com - Platform Security Guide
10
Yubico - YubiKey 5 Series Technical Manual
Hardware architecture, FIDO2 implementation, Secure Element specification, and CTAP2 protocol support for YubiKey 5 series devices. Yubico AB.
docs.yubico.com/hardware/yubikey/yk-tech-manual/
11
Microsoft - FIDO2 Security Keys and Windows Hello for Business
Deployment guidance for FIDO2 security keys and passkeys in Microsoft Entra ID, including attestation enforcement and AAGUID allowlisting. Microsoft Learn.
learn.microsoft.com - Passwordless Security Key
Statistics cited (81% credential breach rate, $4.9M average cost) are sourced from publicly available industry reports for the 2024 reporting period. All FIDO2 and WebAuthn technical specifications are subject to ongoing revision by the W3C and FIDO Alliance.