Gideon resource library

Phishing-Resistant Access Readiness Checklist

A 20-point readiness checklist for replacing passwords and OTP-based MFA with phishing-resistant workforce authentication.

Overview

Readiness gaps often surface after a rollout starts: an application depends on an undocumented authentication path, a lost authenticator triggers a phishable recovery method, or a successful pilot has no measurable acceptance criteria. Use this checklist to find those gaps before setting a production rollout date.

Identity and application inventory

  • Inventory every identity provider, WebAuthn relying party, and application that authenticates workforce users, including applications federated through a legacy identity provider.
  • Trace the end-to-end authentication path for each application. Record whether it uses WebAuthn directly, federates to an identity provider that enforces phishing-resistant authentication, or retains a password or OTP-based exception.
  • Identify service accounts, shared logins, and non-human identities that sit outside normal workforce authentication flows, and assign separate controls to them.

Device and authenticator posture

  • Confirm which endpoint platforms, mobile devices, virtual desktops, and browser combinations are in scope and whether each supports an approved platform or roaming authenticator.
  • Set a risk-based policy for enterprise-controlled synced passkeys and device-bound passkeys, including roaming security keys, for privileged, regulated, and general workforce roles.
  • Require the appropriate local user verification, such as a biometric or PIN, and document retry limits, accessibility options, and any permitted fallback behavior.
  • Keep credential properties separate from managed-device trust. Define which posture signals are checked at enrollment and at access time, how fresh they must be, and what happens when signals are missing or stale.

Recovery, lifecycle, and exception paths

  • Define break-glass access for identity-provider or authenticator outages, with restricted scope, strong authorization, complete logging, and time-boxed expiration.
  • Document recovery for a lost, stolen, or wiped authenticator, including identity-proofing requirements and a path that does not fall back to SMS, email links, knowledge-based questions, or temporary passwords.
  • Define how users register an additional device or replace a credential, and require an existing phishing-resistant authenticator or an approved administrative process for high-assurance roles.
  • Maintain a server-side credential inventory and define revocation, replacement, account offboarding, entitlement removal, and termination of active application sessions.
  • Set controlled policies for contractors, seasonal staff, bring-your-own devices, shared endpoints, and kiosk-mode devices that do not fit the standard enrollment path.
  • Test help-desk procedures to confirm that social engineering cannot turn support or recovery into a bypass of phishing-resistant authentication.

Rollout sequencing and ownership

  • Align security, IT, the help desk, application owners, and procurement on scope, timing, dependencies, and ownership of enrollment and recovery support.
  • Pilot with a representative group that includes remote users, bring-your-own devices, privileged roles, supported platform combinations, and at least one legacy or federated application path.
  • Prepare enrollment communications, support runbooks, escalation paths, rollback criteria, and an explicit process for approving and expiring temporary exceptions.

Success measures

  • Set a target enrollment-completion rate, rollout deadline, and date for disabling legacy password and OTP-based authentication where the application path supports replacement.
  • Track sign-in success, authentication latency, recovery completion, and support-ticket volume during the pilot and production rollout.
  • Define phishing resistance for reporting purposes, including the approved authentication methods, required user-verification behavior, policy outcomes, and treatment of exceptions.
  • Retain an audit trail for registration, authentication, recovery, replacement, revocation, and policy decisions, and associate authentication events with the credential record used without treating a synced credential as proof of a specific physical device.

How to use this resource

Work through the sections with security, IT, the help desk, application owners, and procurement. Document current-state gaps, assign an owner and deadline to each one, pressure-test recovery and exception paths, and convert the success measures into acceptance criteria before committing to a production rollout date.

Back to topic hub