Quick Snapshot — Where are you right now?

• Tell me briefly about your org size, industry, and the person driving the MFA decision (title + team).
• Which statement best describes why you're evaluating phishing‑resistant MFA today? Options: Failed/flagged in a cyber insurance audit, Recent credential-stuffing or account takeover incident, CISO mandate to remove SMS-based MFA, Proactive risk reduction / compliance roadmap, Other
• Which parts of your environment are top priority for this project? Options: Cloud SSO (IdP), Corporate VPN, RDP / Remote Desktop, SSH / Admin access, Legacy on-prem apps (forms/basic auth), Customer-facing portals, Other
• How mature is your IAM capability today (pick the best fit)? Options: IdP-only for SSO, no device controls, IdP + basic policies, gaps on VPN/legacy, Established IdP + MDM + conditional access, Dedicated IAM team and mature processes
• Rough timeline you're targeting for a pilot and initial decision (months)? Options: Immediate / This month, Next 1–2 months, 3–6 months, 6+ months, No set timeline

Are we comfortably ignoring the gaps—or is something already exploding?

• Which critical access points would make you lose sleep if they were compromised tonight? Options: Corporate email, VPN access for remote staff, RDP / remote admin tools, SSH to production systems, Customer portal/accounts, HR/payroll systems, Other
• Which of those high‑risk access points currently lacks phishing‑resistant MFA (be specific)? Options: Cloud SSO protected, VPN lacks phishing‑resistant options, RDP uses legacy MFA or passwords, SSH not centrally managed, Legacy apps allow password only
• Have you had incidents where attackers exploited MFA gaps (credential stuffing, SIM swap, prompt bombing)? Describe one recent example and impact.
• When you think about those incidents, what's the single hardest consequence you felt (financial, reputational, insurance, operational)? Options: Increased insurance premiums, Customer data exposure, Operational downtime, Executive escalation/reputational damage, Regulatory scrutiny, Other
• Has cyber insurance required a change in controls already, or is it a future renewal concern? Options: Already required (audit failed), Flagged as likely at renewal, Not currently required but concerned, Unsure / need to check

Who's actually responsible when the pager goes off?

• If we needed a rapid decision during the pilot, who signs off on go/no‑go (role names)?
• Which stakeholders must be consulted or will push back during rollout? Options: Security (CISO/Dir), IT Ops/Infrastructure, Helpdesk / Service Desk, Legal / Compliance, HR, Engineering / DevOps, Finance, Executive sponsor
• How does your helpdesk currently handle MFA-enrollment calls—ticketing system and average SLA? Options: In-house helpdesk (<8 agents), In-house helpdesk (8–25 agents), Shared IT support / outsourced, No formal helpdesk
• Who will be the day‑to‑day owner of the pilot (name/title) and who is the executive sponsor?
• When decisions conflict (security vs. user convenience), which team typically wins and why? Options: Security enforces, IT balances security + usability, Business units push back, Depends on exec sponsor

Where does enrollment turn into a riot—and how do we avoid it?

• Which enrollment methods are acceptable for your users in the pilot? Options: Self‑service web enrollment, IT-assisted onsite provisioning, Bulk provisioning of hardware keys, Email/phone-assisted enrollment, Other
• What percentage of your workforce is likely to have smartphones or platform biometric devices? Options: >90%, 70–90%, 50–70%, <50%, Unsure — need to inventory
• How many users can you realistically support for IT-assisted provisioning in the pilot (numeric or range)? Options: <50, 50–200, 200–500, 500–1,000, >1,000
• What is your current baseline: average daily helpdesk tickets related to legacy MFA / password resets? Options: 0–10, 11–50, 51–200, 201–500, >500, Unknown / not tracked
• Describe any groups or personas likely to resist hardware keys or biometric methods and why (field sales, contractors, manufacturing, etc.).

Technical blind spots I'd hate to find mid‑pilot

• Which IdP do you use and can we get admin-level integration access for a pilot (Okta, Azure AD, Ping, other)? Options: Okta, Azure AD / Entra, Ping, Google Workspace, On-prem IdP / ADFS, Other
• What VPN/RDP/SSH vendors or protocols are in play that we must integrate with? Options: Cisco AnyConnect / ASA, Palo Alto GlobalProtect, OpenVPN / OpenConnect, Fortinet VPN, Windows RDP / RD Gateway, OpenSSH / Bastion hosts, Other
• Do you have device management or hygiene in place (MDM/endpoint manager, disk encryption, EDR)? Please list existing controls.
• Which legacy apps still accept username/password or basic auth and will require special connectors or proxies?
• What telemetry and logs can you export for pilot analysis (helpdesk ticket IDs, authentication logs, conditional access logs, VPN logs)? Options: Authentication logs (IdP), VPN logs, Helpdesk ticketing data, Device posture/MDM logs, None readily available, Other

How will we know the pilot actually worked?

• Pick the primary success signals you need to see to convince finance/security to expand. Options: Helpdesk ticket reduction (absolute), Enrollment completion rate, Full-app coverage during pilot, Reduction in successful phishing/credential attacks, Insurance attestation obtained, Compliance evidence (NIST 800-63)
• What target thresholds would you set for those signals (e.g., 75% enrollment, 40% helpdesk reduction)?
• Who must sign the pilot acceptance checklist (roles), and what would make them say 'no'?
• How frequently would you like pilot progress updates and in what format? Options: Daily dashboard, Weekly executive summary, Bi-weekly deep review, Ad-hoc on major events
• If insurance attestation is a goal, what documentation will your insurer require (explicit list if known)? Options: NIST 800-63 evidence, Positive control attestation, Enrollment and coverage metrics, Device hygiene proof, Unsure / will ask insurer

Worst-case: what could stop this from rolling beyond the pilot?

• Which risks keep you awake when you imagine a company-wide rollout? Options: Helpdesk overload, User pushback / productivity loss, Legacy app incompatibilities, Vendor or network constraints, Budget shortfall, Regulatory blockers
• Which of those risks are already funded or planned to be mitigated, and which are unknown? Options: Fully mitigated, Partially mitigated, Recognized but no plan, Unknown / need to investigate
• What is your fallback plan for users who cannot enroll (temporary bypass, emergency single-use codes, IT-provisioned keys)? Options: Temporary bypass with monitoring, IT-provisioned hardware, Helpdesk-assisted manual verification, No bypass allowed, Other
• If we identified a show-stopping compatibility issue mid‑pilot, who has the authority to pause expansion and what criteria trigger that pause?
• Assuming we clear the pilot, what are the top three priorities you want the vendor to own during expansion? Options: Reporting & compliance export, Helpdesk enablement & scripts, Hardware key logistics, IdP policy automation, Adaptive risk tuning, Other

• Current State & Business Impact Alignment
• Pilot Success Criteria & Measurement Planning
• Pilot Design: Applications, Cohort & Enrollment Flow
• Technical Integration & Adaptive Risk Mapping
• Pilot Runbook, Support Plan & Acceptance Review

• Seller to deliver detailed authentication flow diagrams per access path and a test-case matrix linked to KPIs.
• Agree helpdesk fallback flows and escalation paths to limit ticket blow-up during enrollment.
• Customer to provide application owners and a short checklist of current auth methods for each target app.
• Seller to produce a visual single-enrollment user flow for review and sign-off.
• Customer to nominate helpdesk POCs and provide current SLA/ticket handling stats for baseline comparison.
• Integration Inventory
• Produce a per-access-path authentication map that shows where phishing-resistant factors and adaptive risk apply and what data will prove outcomes.
• Agree a suite of prioritized test cases that, when executed, will constitute the 'proof' portion of the Solution Experience.
• Identify all technical blockers and assign owners with deadlines to remove them before pilot start.
• Confirm fallback recovery flows and that helpdesk scripts are sufficient for the identified failure modes.
• Introductions & Objectives
• Customer IT to provision test accounts and grant needed access to connectors or a staging environment.
• Create helpdesk runbook drafts for the defined failure modes for review in the Pilot Runbook meeting.
• Wave Scheduling & Owner Assignments
• Finalize a detailed pilot runbook with wave dates, owners, monitoring dashboard links, and helpdesk SLAs.
• Confirm the exact set of exportable reports and evidence required for NIST 800-63 mapping and insurer attestation.
• Agree the go/no-go decision rule, signatories, and the post-pilot expansion path if successful.
• Ensure communications and change management assets are assigned and scheduled for release aligned to wave starts.
• Seller to produce the final pilot runbook PDF including dashboards, wave schedule, and acceptance checklist.
• Customer to schedule helpdesk staffing for pilot waves and provide a primary escalation contact.
• Both parties to confirm the date/time for a pilot kick-off call and the go/no-go review meeting at pilot end.
• Produce a single-sentence Current State that accurately captures coverage gaps and failure modes.
• Quantify consequence into 2–3 measurable KPIs (helpdesk ticket delta, enrollment rate target, insurer attestation requirement).
• Agree a one-sentence Future State that the pilot must prove operationally.
• Identify the primary decision-maker and approvers for pilot success criteria.
• Customer to provide current baseline metrics: weekly auth-related helpdesk tickets, legacy app list, current MFA methods per app.
• Seller to draft one-sentence Current State, Consequence, and Future State and circulate for sign-off.
• Schedule Pilot Design Workshop with technical and business stakeholders.
• Review agreed Future State
• Agree a concise list of 4–6 pilot KPIs with numeric targets and measurement methods.
• Confirm telemetry sources and responsibility for each data feed required to prove outcomes.
• Define the acceptance rule (how many metrics must meet target for pilot to pass) and reporting cadence.
• Identify any missing instrumentation gaps and assign owners to close them before pilot start.
• Seller to provide a KPI measurement template that maps each KPI to data source, owner, and extraction method.
• Customer to grant access to sample logs or a sandbox IdP account for telemetry validation.
• Assign an analytics owner (customer or seller) responsible for producing pilot reports.
• Pilot Scope Review
• Produce an agreed pilot scope listing applications, connectors, and cohort makeup.
• Finalize the enrollment flow that will be used in the pilot and an estimated enrollment completion time per user.
• Define policy groups and key adaptive risk rules to be exercised during the pilot.
• Define Pilot KPIs
• Enrollment Monitoring & Live Metrics
• Authentication Flow Mapping
• Cohort Selection & Enrollment Method
• Current State Diagnosis (forced statement)
• Single-Enrollment Experience Flow
• Telemetry & Data Sources
• Test Cases & Proof Points
• Helpdesk Staffing & Escalation
• Consequence Quantification
• Policy Groups & Adaptive Risk Rules
• Define Future State (one sentence)
• Acceptance Checklist & Go/No-Go
• Reporting & Evidence for Attestation
• Failure Mode & Recovery Drills
• Validation Methodology
• Communications & Change Management
• Validation & Next Steps
• Helpdesk & Fallbacks
• Timeline & Resource Check

• Integrate with Identity Provider (SAML/OIDC/SCIM)
• Deploy Self-Service Enrollment Portal
• Provision FIDO2 Hardware Keys and Registration
• Enable Platform Biometrics (Windows Hello/Touch ID)
• Activate Push MFA with Number Matching
• Deploy VPN and RDP Authentication Connectors
• Integrate SSH Certificate-Based Access
• Install Legacy App Access via Reverse Proxy
• Integrate Device Posture and Health Signals
• Enable Adaptive Risk Policies and Step-up
• Configure IT-Assisted Enrollment and Kiosk
• Generate Exportable Compliance Reports (NIST/Insurance)

Integrate with Identity Provider (SAML/OIDC/SCIM)

• Which identity provider(s) do you currently use or plan to integrate? Options: Okta, Azure AD, OneLogin, Ping, Google Workspace, Custom SAML/OIDC, Other (describe)
• Which protocols are required for integration? Options: SAML, OIDC/OAuth2, SCIM (user provisioning)
• Do you require automated user provisioning (SCIM) or will you manage users manually? Options: Require SCIM provisioning, Manual provisioning only, Hybrid (some groups SCIM)
• Are there existing service accounts, certificates, or technical contacts available for IdP integration (provide ARNs/IDs or contact role)?
• What is the expected number of identities / MAUs in the pilot scope? Options: <100, 100-500, 501-2,000, 2,000+
• Are there session or SSO timeout policies that must be preserved or overridden? Options: Preserve existing policies, Override with platform policies, Need to discuss per-application

Deploy Self-Service Enrollment Portal

• Do you want self-service enrollment enabled for the pilot cohort? Options: Yes, fully self-service, No, IT-assisted only, Hybrid: self-service with IT fallbacks
• Which enrollment channels should be available? Options: Web portal, Mobile app (iOS/Android), Email invite, On-prem kiosk/desktop
• Do you require branding, custom instructions, or multiple language support on the portal? Options: Branding only, Branding + multilingual (list languages), No custom branding
• What user identity verification step is required during enrollment (e.g., SSO auth, SMS verification, IT code)? Options: SSO-authenticated, Email link, SMS/phone verify, IT-issued code, Other (describe)
• Are there accessibility, legal, or privacy constraints to enforce on the enrollment UI? Options: Yes (describe), No
• What enrollment success metrics do you want tracked during the pilot (e.g., time-to-enroll, completion rate, helpdesk calls)? Options: Time-to-enroll, Completion rate, Helpdesk ticket count, User satisfaction, Other (describe)

Provision FIDO2 Hardware Keys and Registration

• Will the pilot include physical FIDO2 key issuance? Options: Yes — org-provided keys, No — user-owned keys only, Optional/Varies by user
• Which FIDO2 form factors do you plan to support? Options: USB-A, USB-C, NFC-enabled, Bluetooth, Platform authenticators (TPM)
• How many keys will be procured for the pilot and what is the procurement timeline?
• Do you require key lifecycle management features (inventory, attestation, replacement, revocation)? Options: Yes, No, Partial — only replacement/revocation
• What is your lost/stolen key policy and recovery path for users without a second factor? Options: IT re-issue after verification, Temporary OTPs, Kiosk re-provisioning, Other (describe)
• Do certain user groups require hardware-only (no platform biometrics) for compliance reasons? Options: Yes (list groups), No

Enable Platform Biometrics (Windows Hello/Touch ID)

• Which platform biometric methods should be enabled during the pilot? Options: Windows Hello (PIN/biometrics), macOS Touch ID, Android Biometric API, iOS Face ID/Touch ID
• Do endpoints need to be managed via MDM for platform biometric enforcement? Options: Yes — MDM required, No — allow unmanaged devices, Partial — corporate devices only
• Are there regulatory or privacy constraints around biometric use in your organization or regions? Options: Yes (describe), No
• How many devices are expected to support platform biometrics in the pilot cohort? Options: <50, 50-200, 200-1,000, 1,000+
• What fallback authentication should be allowed when platform biometric is unavailable? Options: FIDO2 key, Push with number matching, Temporary OTP, IT-assisted re-enroll
• Do you require telemetry on biometric enrollments and failures exported to security teams? Options: Yes, No

Activate Push MFA with Number Matching

• Do you want push notifications with number-matching enabled as part of the pilot? Options: Yes, No, Optional/Hybrid
• Which mobile platforms must be supported for push notifications? Options: iOS, Android, Both, Other (describe)
• Should number matching be enforced everywhere or only for high-risk or legacy apps? Options: Enforce for all push auths, Enforce only for step-up/high-risk, Do not enforce
• Do you need push delivery failover (SMS/OTP) for offline or push-blocked devices? Options: Yes — SMS fallback, Yes — OTP fallback, No fallback allowed
• Are there enterprise mobility management constraints affecting push tokens or background delivery? Options: Yes (describe), No
• What privacy/consent messaging should be presented to users when enabling push notifications?

Deploy VPN and RDP Authentication Connectors

• Which VPN solutions and versions need connectors (e.g., Palo Alto GlobalProtect, Cisco AnyConnect, Fortinet)?
• Do you require RDP protection for direct RDP, RD Gateway, or third-party gateway solutions? Options: Direct RDP, RD Gateway, Bastion / Jump host, Other (describe)
• Are connectors deployed on-premises (connector appliance) or in cloud-hosted environments? Options: On-prem connector, Cloud-hosted connector, Both
• Will the VPN/RDP connector need to support legacy authentication (NTLM/kerberos passthrough) or only modern auth? Options: Legacy passthrough required, Modern auth only, Mixed — per-application
• What is your expected peak concurrent VPN/RDP sessions during the pilot? Options: <50, 50-200, 200-1,000, 1,000+
• Are network/firewall changes required to allow connectors to communicate with the platform (egress rules)? Options: Yes — changes required, No — open already, Unsure — need assessment

Integrate SSH Certificate-Based Access

• Do you currently use SSH key-based authentication, password SSH, or a mix? Options: Key-based, Password-based, Mixed
• Do you have an existing internal CA/PKI for SSH certificate issuance or require the platform to provide a CA workflow? Options: Existing internal CA, Platform-managed CA, Need recommendations
• Which server classes and environments should be included (production, staging, developer laptops, containers)? Options: Production, Staging/QA, Developer workstations, Containers/ephemeral
• Do you need automated short-lived certificate issuance tied to user MFA at SSH session start? Options: Yes — short-lived certs required, No — long-lived keys OK, Optional
• Are jump hosts or bastions in scope and do they require federation/integration? Options: Yes — include bastions, No
• What rotation and revocation policy is required for SSH credentials? Options: Automatic short-life rotation, Manual rotation, On-demand revocation only

Install Legacy App Access via Reverse Proxy

• Which legacy apps need coverage via reverse proxy (list app names, hostnames, auth types)?
• What authentication methods do the legacy apps use today (form-login, NTLM, header-based, custom tokens)? Options: Form-based login, NTLM/Integrated Windows Auth, Header-injection SSO, Custom/Proprietary
• Are there session-sharing or cookie-scope constraints the proxy must preserve? Options: Yes (describe), No, Unsure — need assessment
• Do any legacy apps require client-side agents or special ports that the proxy must support? Options: Yes (describe), No
• Is in-app single sign-on required after proxying, or is re-authentication acceptable? Options: True SSO post-proxy, Re-authentication acceptable, Hybrid per-app
• Do you require phased rollout per-app with smoke-testing windows and rollback procedures? Options: Yes — phased with rollback, No — full cutover, Undecided

Integrate Device Posture and Health Signals

• Which device posture attributes are required for access decisions? Options: OS patch level, Disk encryption, Antivirus/EPP status, MFA enrollment, Jailbreak/root detection
• Do you have an MDM (Intune, Jamf, Workspace ONE) or EDR (CrowdStrike, SentinelOne) to integrate with? Options: Microsoft Intune, Jamf, Workspace ONE, CrowdStrike, SentinelOne, Other (describe), None
• How should non-compliant devices be handled? Options: Block access, Step-up to higher auth, Allow with warning, Quarantine with limited access
• Are BYOD devices in-scope for posture checks or only corporate-owned devices? Options: BYOD included, Corporate devices only, Hybrid by user group
• What telemetry and reporting on device posture do security/compliance teams require? Options: Real-time alerts, Periodic reports, Dashboard only, Exportable audit logs
• What remediation UX is preferred (self-remediation steps, IT ticket, automated patching)? Options: Self-remediation steps, IT ticket creation, Automated remediation, Other (describe)

Enable Adaptive Risk Policies and Step-up

• Which risk signals should be considered for adaptive policies? Options: Impossible travel, New device, Network reputation, Unusual app access, High-risk geolocation
• For sensitive applications, what step-up authentication methods are acceptable? Options: FIDO2 hardware key only, Platform biometrics, Push with number matching, SSH cert issuance
• What tolerance for false positives is acceptable (i.e., how often can legitimate users be stepped up)? Options: Low tolerance — avoid disruptions, Moderate — some step-ups OK, High — strict risk blocking
• Do you require separate policy tiers for user groups (IT, engineers, execs, contractors)? Options: Yes — per-group policies, No — uniform policy, Some groups only
• Are there regulatory or insurer-driven risk controls that must be enforced by policy? Options: Yes (describe), No
• How should policy changes be tested and approved before org-wide enforcement? Options: Pilot-only testing, Staged rollout with rollback, Immediate enforcement after approval

• Non-Disclosure Agreement (NDA)
• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Commercial Terms & Order Form
• Payment Schedule & Invoicing
• Pilot Acceptance Criteria
• Roles & Responsibilities (RACI)
• Timeline & Milestones
• Go/No-Go Decision Plan
• Data Processing Agreement (DPA)
• Compliance & Insurance Attestation
• Support & Escalation Agreement (SLA)
• Change Order & Scope Management
• Termination & Exit Plan
• Renewal & Expansion Option
• Technical Onboarding & Access Checklist
• Hardware Provisioning & Logistics

• Pilot Outcomes Review (Diagnosis & Validation)
• Compliance & Insurance Impact Review
• Org-wide Rollout Planning Workshop
• Go / No-Go Decision & Executive Sign-off
• Operational Handoff & Shared Channel Setup (Support & Enhancements)

• Ensure finance and executive stakeholders are aligned on budget and timeline implications of the decision.
• Owner to produce one-page 'residual gaps' summary with root causes and proposed fixes.
• Helpdesk lead to deliver sample ticket logs and average handling times for pilot cohort.
• One-sentence Compliance Current State
• Map pilot outputs to the exact evidence insurers and auditors require for phishing-resistant MFA attestation.
• Agree the delta work and owners needed to obtain formal attestation and estimate insurer premium impact timeline.
• Secure commitment from insurer-facing stakeholders to engage with provided evidence and confirm acceptance criteria.
• Generate NIST 800-63 mapping document linking exported reports to specific controls.
• Assign an owner to coordinate with the insurer and schedule a joint evidence review call if required.
• Produce an insurer-ready attestation packet (reports + executive summary) for the customer's broker/CISO review.
• Future State One-Liner
• Produce a wave-based rollout plan with explicit acceptance gates, owners, timelines, and staffing requirements.
• Confirm enrollment methods and fallback provisioning to ensure broad coverage without undue user friction.
• Define KPIs and numeric thresholds that will be validated at the end of each wave before expansion.
• Draft the detailed wave schedule (weeks, cohorts, apps) and circulate for stakeholder feedback.
• Helpdesk to create wave-specific runbooks and a training calendar for frontline staff.
• Procurement to confirm timeline and quantities for any required hardware keys or kiosks.
• Re-state Acceptance Criteria
• Secure formal, documented approval to proceed (or to pause) with the org-wide rollout based on evidence.
• Identify and assign remediation items if decision is conditional and set deadlines for re-review.
• One-sentence Current State Confirmation
• Publish signed decision record with attached evidence and remediation plan (if applicable).
• Notify all key stakeholders and schedule the kickoff for the first expansion wave (if Go).
• If No-Go, schedule focused remediation sprints and a re-evaluation date within X days.
• One-sentence Operational State
• Establish a single shared operational channel and governance model for issues, incidents, and enhancement requests.
• Ensure runbooks, SLAs, and monitoring handoffs are documented and owners are assigned for operational continuity.
• Seed the backlog with prioritized items and confirm the triage cadence and owners for ongoing improvements.
• Create the shared Slack channel (e.g., #mfa-rollout) and invite stakeholders; link the JIRA project and Confluence space.
• Publish the operational runbook and incident playbook to the agreed Confluence space and assign maintainers.
• Open initial JIRA tickets for prioritized enhancements and assign triage owners and SLAs.
• Validate the pilot delivered measurable outcomes that map to the defined future state (enrollment, coverage, reduced tickets).
• Agree on the specific residual gaps and their quantified business consequences.
• Produce a short remediation task list with owners and dates that must be complete before go/no-go.
• Export and share the pilot metrics dashboard (CSV/PDF) showing enrollment, ticket delta, and per-app coverage.
• Key Metrics Dashboard Walkthrough
• Shared Channel & Workspace Setup
• Evidence Walkthrough (Exportable Reports)
• Evidence Tally vs Criteria
• Scope & Wave Definition
• Helpdesk & Support Impact
• Insurance Attestation Discussion
• Escalation & Incident Playbooks
• Enrollment Experience & Methods
• Risk & Contingency Review
• Enhancements & Issue Backlog Process
• Adaptive Risk & Policy Behavior
• Commercial & Budget Confirmation
• Support & Training Plan
• Gap Remediation for Attestation
• Risk Residuals & Compensating Controls
• Monitoring, Reporting Cadence & KPIs
• Telemetry, KPIs & Acceptance Gates
• Decision & Documented Outcome
• Failures, Exceptions, and Residual Coverage Gaps
• Consequence Analysis
• Timeline, Owners & Dependencies
• Communication Plan for Decision
• Sign-off Criteria & Timeline for Attestation
• Knowledge Transfer & Documentation Handoff