Passwords and the one-time codes added to them can be phished, replayed and reset away, yet most organisations still rely on them for staff and customers long after a stronger, cheaper and faster alternative became mainstream. This briefing is for directors, chief executives, finance and audit committee members, CISOs and digital leaders deciding whether and how fast to move to passkeys and passwordless sign-in. It covers the business case, the decisions that only leadership can make (which users get which type of passkey, how much help desk risk to accept, when passwords are switched off), the questions that test a programme and a 90-day plan. It complements the Identity Threat Executive Briefing, which explains why stolen logins drive breaches; the engineering detail is in the Passwordless and Passkeys Guide.
The risk in one paragraph
A passkey is a sign-in credential based on the FIDO2 and WebAuthn standards: a cryptographic key pair where the private key stays on the user's device or in their platform's protected keychain, unlocked with a fingerprint, face or PIN. The key is bound to the genuine website or application, so a fake login page receives nothing it can use, and there is no shared secret on the server to steal. Passwords and traditional multi-factor methods fail in exactly the places passkeys do not: users type them into convincing fake pages, approve push prompts they did not request, or lose phone numbers to SIM swaps. The residual risk after a passkey rollout moves elsewhere: to account recovery and the help desk, to applications that still accept a password as a fallback, and to session tokens stolen after sign-in. A board that funds passkeys without closing those routes buys less protection than it thinks.
Why this is a board-level issue now
- Phishable MFA is behind well-known losses. At Uber in September 2022 an attacker with a contractor's purchased password sent repeated approval requests until one was accepted, then reached internal tools including Slack and a finance tool. At MGM Resorts in 2023 a help desk phone call led to identity administrator access and an estimated $100 million impact. See the Uber breach analysis and the MGM Resorts breach analysis.
- Government guidance now sets the bar at phishing resistance. CISA describes FIDO/WebAuthn as the only widely available phishing-resistant authentication, treats one-time codes and push approvals as phishable and says SMS and voice should be used only as a last resort. US federal policy (OMB M-22-09) requires phishing-resistant MFA for agency staff, contractors and partners. NIST SP 800-63B-4 requires verifiers to offer at least one phishing-resistant option at authentication assurance level 2 (AAL2).
- The technology is mainstream, not experimental. The FIDO Alliance Passkey Index 2026 (October 2026) reports that 36% of successful sign-ins at participating services used a passkey, up from 26% in 2025. Microsoft reported in May 2025 nearly a million passkeys registered every day and made new consumer accounts passwordless by default.
- It is one of the few security investments that also improves the customer experience. The same Passkey Index reports passkey sign-ins succeeding 93% of the time against 78% for passwords with traditional MFA, nearly three times faster, and every participant that measured it reported lower SMS one-time code costs. Microsoft reported about 98% sign-in success for passkey users against about 32% for password users.
- Doing nothing has a visible cost. Password resets, SMS codes, abandoned sign-ups and account takeover fraud all appear on the profit and loss account. The Snowflake breach analysis shows how passwords stolen by infostealer malware years earlier still opened customer environments that had no MFA.
The decisions leadership has to make
Most of a passkey programme is engineering, but four choices carry business risk and belong with leadership.
| Decision | Options | Trade-off | Typical choice |
|---|---|---|---|
| Which passkey type for which users | Synced passkeys (in Apple, Google or other password managers) or device-bound passkeys (security keys, authenticator apps) | Synced passkeys are cheap and easy to recover but the key can be copied across the user's devices; device-bound keys give stronger assurance and attestation but cost money and create lost-key support load | Synced for most staff and customers; device-bound for administrators, regulated roles and high-value approvals |
| Recovery when a passkey is lost | Self-service re-enrolment from another device, identity verification, help desk with call-back, temporary access pass | Easier recovery means lower cost and more help desk social engineering risk | Strict verification for privileged users, proportionate checks for others |
| When to remove passwords | Keep as fallback, hide from sign-in, disable entirely | Every remaining fallback is an attack path; removing it too early strands users on unsupported devices | Hide first, disable for privileged users within months, then by population |
| Customers: offer or require | Optional passkeys, passkey-first sign-in, passkeys required for high-risk actions | Requiring too early risks abandonment; optional adoption grows slowly without nudges | Offer at sign-up and after successful sign-in; require for high-risk actions over time |
NIST SP 800-63B-4 allows syncable authenticators up to AAL2 but not at AAL3, because the private key must be exportable to sync. Microsoft's Entra ID documentation recommends device-bound passkeys or FIDO2 security keys for highly regulated industries and users with elevated privileges, and synced passkeys for most other users; when attestation is enforced in an Entra passkey profile, only device-bound passkeys are allowed. These sources give boards a defensible basis for a two-tier policy rather than one rule for everyone.
How sign-in methods compare
| Method | Resists fake login pages | Resists push bombing and SIM swap | User experience | Board view |
|---|---|---|---|---|
| Password only | No | Not applicable | Poor: resets and lockouts | Retire |
| Password plus SMS or voice code | No | No | Slow, per-message cost | Last resort only |
| Password plus app code or push with number matching | No | Partly | Moderate | Interim |
| Synced passkey | Yes | Yes | Fast, survives device loss | Default for most users |
| Device-bound passkey or security key | Yes | Yes | Fast; lost keys need recovery | Required for privileged and regulated roles |
| Certificate-based smart card | Yes | Yes | Good where infrastructure exists | Keep where already deployed |
In MITRE ATT&CK terms, phishing-resistant sign-in removes the value of techniques such as Multi-Factor Authentication Request Generation (T1621) and much credential phishing (T1566), but not Steal Web Session Cookie (T1539), which happens after sign-in. See the Phishing-Resistant MFA Guide and the Device-Bound Session Credentials (DBSC) Guide.
Five questions for the board to ask
- What share of staff and administrator sign-ins are phishing resistant today, and what is the target date for 100% of administrators? A good answer separates registration from actual use and reports by population, because a registered passkey alongside a still-accepted password protects little.
- How does a user who has lost every device get back in, and could an impersonator do the same? Ask to see the recovery process for privileged users step by step. Recovery is where attackers go once sign-in is strong. See the Passkey account recovery guide.
- Which applications cannot use passkeys, and what protects them? Legacy applications, remote desktop, shared workstations and frontline devices often cannot use passkeys directly. A good answer lists them with compensating controls and a retirement or federation plan.
- When will passwords stop working, not just stop being prompted? Ask for dates by population and the evidence that fallbacks have been closed.
- What is the business case for customers? Ask for baseline sign-in success, password reset volume, SMS spend and account takeover losses, and how each will be measured after launch.
Red flags in management answers
- "We have MFA": without saying which methods, this usually means phishable codes or push approvals.
- Registration counts reported as success: enrolment without enforcement leaves the password path open.
- Help desk can reset anything on a phone call: this undoes the programme. See the Help Desk Identity Verification Policy Template.
- Administrators last: rollouts that start with general staff for convenience leave the most dangerous accounts phishable longest. CISA recommends starting with administrators and help desk staff.
- No exception register: every user exempted "temporarily" becomes a permanent weak point. See the MFA Exception Register Template.
- Session lifetimes unchanged: strong sign-in followed by month-long sessions shifts attackers to cookie theft.
What good looks like
| Area | Weak position | Good position |
|---|---|---|
| Privileged users | Password plus push | Device-bound passkeys or security keys only, enforced by policy, with attestation where supported |
| General workforce | Password plus app code | Synced or device-bound passkeys enforced through conditional access, passwords hidden then disabled |
| Recovery | Help desk resets on knowledge questions | Verified identity checks, call-back to known numbers, temporary access passes, notification to the user on every new credential |
| Legacy applications | Ignored | Fronted by single sign-on or remote access gateways that enforce passkeys, with a retirement plan |
| Customers | Password plus SMS | Passkeys offered at sign-up and after sign-in, SMS reduced to recovery, step-up for risky actions |
| Measurement | Enrolment counts | Share of sign-ins by method, fallback use, reset volume and takeover losses |
Where to invest first
- Administrators and IT support: issue device-bound passkeys or security keys to identity, cloud and help desk administrators and enforce them. This is small in number and large in risk reduction.
- Recovery and help desk process: fund identity verification for resets before scaling, because scaling passkeys without it scales the bypass.
- Single sign-on coverage: bring applications behind the identity provider so one passkey policy covers them.
- Workforce rollout with enforcement: move staff population by population, enforcing phishing-resistant authentication strength rather than only offering it.
- Customer passkeys: where account takeover or SMS cost is material, add passkeys to the sign-in journey and measure the effect.
Small and large organisations: a small business on a cloud identity provider can usually enable synced passkeys for everyone and buy security keys for a handful of administrators within weeks; the main work is recovery and removing passwords. A large enterprise with legacy applications, shared devices, unions and regulated roles needs a phased programme by persona over 12 to 24 months, a device strategy for staff without smartphones and a communications plan. See the Passkey Rollout Guide and the Passwordless and MFA Buyer's Guide.
Metrics to track
- Phishing-resistant sign-in share: percentage of sign-ins using passkeys, security keys or certificates, by population. Target 100% for administrators.
- Password fallback use: number of sign-ins still using a password where a passkey is registered, trending to zero.
- Exceptions: count and age of users exempt from phishing-resistant authentication.
- Recovery events: volume of credential resets and the share verified to the required standard; any reset of a privileged user reviewed.
- Help desk cost: password and MFA reset tickets per thousand users, before and after.
- Customer outcomes: sign-in success rate, SMS spend and account takeover losses.
Report these quarterly next to the identity threat metrics. See the Passkey Adoption Statistics for external benchmarks.
A 90-day plan
- Days 1 to 15, decide and baseline: appoint an executive owner; agree the two-tier policy (device-bound for privileged and regulated roles, synced for most others); baseline sign-in methods, reset volumes, SMS spend and the list of applications outside single sign-on.
- Days 15 to 40, protect administrators: issue security keys or device-bound passkeys to every identity, cloud and help desk administrator, with at least two registered per person; enforce phishing-resistant authentication strength for administrator roles.
- Days 30 to 60, fix recovery: publish a verified recovery process, require call-back or in-person checks for privileged users, notify users of every new credential and test the process with a simulated impersonation call.
- Days 45 to 80, pilot the workforce: enable passkeys for a pilot group across the main device platforms, measure success and support load, then expand by population with conditional access in report-only mode before enforcement.
- Days 60 to 90, plan password removal and customers: set dates to hide and then disable passwords by population, open the exception register, and, where relevant, scope a customer passkey launch with agreed success measures. Report baseline and progress to the board.
Rollback and safety: keep a tested break-glass process for administrators (stored security keys, monitored emergency accounts) and use report-only policies before enforcement, so a policy error does not lock out the organisation.
Where identity fits
Passkeys solve human sign-in. They do not touch the service accounts, API keys, OAuth tokens and automation credentials that often outnumber people and never prompt for MFA. A passwordless programme that leaves those static secrets in place moves attackers to them. Plan the machine side in parallel: workload identity federation, short-lived tokens and owned, rotated secrets. See the Board Briefing: NHI Risk.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-03 | Users, services and hardware are authenticated |
| NIST CSF 2.0 | GV.OV-01 | Leadership reviews risk strategy outcomes |
| NIST SP 800-53 Rev. 5 | IA-2, IA-2(1), IA-2(2), IA-5 | Identification and authentication, MFA for privileged and non-privileged accounts, authenticator management |
| NIST SP 800-63B-4 | AAL2, AAL3, syncable authenticators | Assurance levels and where synced passkeys are allowed |
| OWASP ASVS 5.0 | V6 Authentication | Verification requirements for authentication, including hardware-based phishing-resistant factors at level 3 |
| MITRE ATT&CK | T1621, T1566, T1539 | Techniques passkeys defeat and the one they do not |
Common failure patterns
- Passkeys added, passwords kept: attackers simply choose the password path.
- Recovery weaker than sign-in: help desk resets on information found on social media, as in the help desk attacks on MGM.
- One device per administrator: a lost security key becomes an emergency reset with relaxed checks.
- Synced passkeys for regulated or privileged roles without a policy decision: acceptable for many users, but a choice the organisation should make deliberately against NIST AAL requirements.
- Frontline and shared-device staff forgotten: users without personal smartphones are left on passwords indefinitely.
- Machine credentials out of scope: static secrets remain the easiest way in. See the Cloudflare breach analysis, where credentials left unrotated after an earlier incident were used.
Practitioner checklist
- Adopt a written two-tier passkey policy: device-bound for privileged and regulated roles, synced for most others.
- Enforce phishing-resistant authentication for every administrator, with at least two credentials each and a break-glass process.
- Require verified identity checks for credential recovery, stricter for privileged users, with notification on every new credential.
- Report sign-ins by method, not enrolment counts.
- Keep an exception register with owners and expiry dates.
- Set dates to hide and disable passwords by population and verify fallbacks are closed.
- Shorten session lifetimes for sensitive applications and monitor for session token reuse.
- Inventory service accounts and API keys alongside the human programme.
Standards and references
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- CISA: Implementing Phishing-Resistant MFA
- US OMB: M-22-09 Moving the US Government Toward Zero Trust Cybersecurity Principles
- Microsoft Learn: Passkeys (FIDO2) authentication in Microsoft Entra ID
- FIDO Alliance: Passkey Index 2026
- NIST: Cybersecurity Framework 2.0
- Microsoft Security Blog: Pushing passkeys forward
How NHI Mgmt Group can help
We provide independent identity risk assessments, board briefings and programme initiation support covering both human sign-in and the non-human identities that passwordless programmes leave behind. Our NHI Foundation Level Training Course helps security and IAM teams govern service accounts, API keys and secrets. Contact us to arrange a briefing.
Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Passkey Rollout Guide · Phishing-Resistant MFA Guide · Identity Threat Executive Briefing