Start here: your current MFA picture

• Briefly describe your current MFA coverage across SSO, VPN, RDP, SSH, and legacy on-prem applications.
• Select the authentication factors enrolled today for most employees Options: Password only, SMS one-time passcode, TOTP authenticator app, Platform biometrics (Windows Hello / Touch ID), Hardware security keys (FIDO2), Push with number matching, Other
• How many employees are in scope for the initial rollout? Options: Under 1,000, 1,000 to 2,499, 2,500 to 4,999, 5,000 to 9,999, 10,000 or more
• When did you last experience an authentication-related incident such as credential stuffing, SIM swap, or account takeover? Options: Within 30 days, 30 to 90 days ago, 3 to 12 months ago, Over a year ago, No known incidents
• Walk me through the typical helpdesk flow when a user cannot authenticate, from ticket creation to resolution.

Imagine the single place a bad actor walks in

• Imagine one access path remained unprotected, identify which would cause the biggest damage to your risk profile Options: Cloud SSO, Remote access VPN, RDP/remote desktop, SSH/engineering access, Legacy on-prem web app or portal, Service account or API key
• For the access types you depend on most, estimate how many authentication attempts come from external IPs versus internal networks each day. Options: I can provide counts, Estimate: external > internal, Estimate: external ≈ internal, Estimate: external < internal, Unknown
• How often do legacy apps appear in rollout work as unlisted or undocumented systems that block SSO or modern MFA? Options: Frequently, Sometimes, Rarely, Almost never, Unknown
• What specific failure — missing logs, incompatible protocol, or vendor contract clause — would force you to pause or cancel a rollout?
• Name the roles authorized to approve a temporary exception for an application during a pilot Options: Security Director, IT Operations Manager, Application Owner, CISO, Compliance Officer, Other

Approvals, owners, and who answers the pager

• In the event the pilot triggers a spike in helpdesk tickets, name who must be involved within the first hour to prevent escalation Options: IT service desk lead, Identity team engineer, Security incident lead, Application owner, Third-party vendor contact, Other
• List the groups that must sign off for a production rollout and indicate which team typically slows approvals
• Identify the owner of your identity provider configuration and list who holds the admin credentials
• If any single stakeholder refused to participate in the pilot, name which stakeholder would stop the project and why
• Describe recent internal debates you've seen about MFA choices, for example hardware keys versus mobile-first approaches and who pushed each position

The pilot that will prove coverage without breaking things

• What measurable pilot targets would make the project a clear success for both security and support leaders Options: Helpdesk ticket reduction (%), Enrollment completion (%), Coverage across app categories (%), Authentication latency change, Reduction in password resets (count), Other
• How many users and which personas will you include in the time-boxed pilot to be statistically meaningful? Options: 100-250 technical users, 250-500 mixed IT and business users, 500-1,000 broad representative sample, Other
• Mark the access types that must be included in the pilot to be convincing Options: Cloud SSO, VPN, RDP, SSH, Legacy on-prem web apps, Service accounts / APIs
• What rollout window can the pilot run within to avoid business calendar conflicts, for example 7, 14, or 30 days? Options: 7 days, 14 days, 30 days, Other
• Assuming the pilot meets your targets, list the contractual, budgetary, or procurement steps that would still block an immediate production agreement

The other options you are actively weighing

• What's the strongest reason someone on your team would prefer to stay with the incumbent or to build a solution internally instead of running an external pilot? Options: Lower apparent cost, Existing contractual ties, Belief internal team can deliver, Perceived lower operational risk, Faster timeline, Other
• Select the alternatives you have evaluated or are evaluating right now Options: Replace with another vendor, Keep incumbent and extend, Build internally, Limit MFA to cloud SSO only, Hire consultants to remediate, Other
• What single capability would have to be demonstrably true about your current approach for you to accept staying put rather than change platforms?
• Has anyone proposed solving the gap internally, and if so, outline which components they planned to keep versus replace Options: Yes, keep current IdP and add features, Yes, rebuild authentication stack, No internal proposal exists, Other
• Provide the contract owner and the earliest termination or renewal window for the incumbent solution Options: Within 30 days, 30 to 90 days, 3 to 6 months, 6+ months, No contract or unknown

Technical gates and practical readiness

• Identify missing technical dependencies that would block integration, for example lack of IdP admin access, unsupported VPN protocol, or no SSH bastion access Options: Admin access to IdP, VPN gateway lacks RADIUS/SAML support, RDP gateway not integrable, SSH access behind unsupported jump host, No documented credential store for legacy apps, Hardware key provisioning process missing, None — dependencies available
• Do you have a current inventory of applications with owner, auth protocol, and last-tested date? Options: Complete and current, Mostly complete with gaps, Partial inventory, No inventory
• Confirm the team or person that manages IdP connectors and whether they can dedicate time during a 2 to 4 week pilot Options: Owner available full time, Owner available part time, No dedicated owner, Unknown
• If legal or compliance requires an attestation within 30 days, can you produce the required evidence and who would sign it? Options: Yes, evidence ready and signer available, Can produce with vendor support in 1 to 2 weeks, Cannot meet 30 day attestation, Unknown
• List the internal resources available for IT-assisted provisioning and estimate how many full-time equivalents you can assign during rollout

Plan for minimizing helpdesk shock

• Should enrollment double your helpdesk volume for two weeks, what automated or human mitigations must be in place to keep service levels?
• Pick the helpdesk metrics you track today that we should use as baseline Options: Ticket volume per day, Time to resolve (MTTR), Reopen rate, Cost per ticket, First contact resolution rate, Other
• Estimate the monthly authentication-related ticket volume you currently see across a cohort the size of the pilot Options: Under 50, 50 to 199, 200 to 499, 500 to 999, 1,000 or more, Unknown
• What is the maximum acceptable increase in helpdesk tickets during the pilot before leadership demands rollback? Options: 0 percent, 0 to 25 percent, 25 to 50 percent, 50 to 100 percent, Over 100 percent
• List who can authorize IT-assisted provisioning and indicate whether standard operating procedures exist Options: SOPs exist and are current, SOPs partial, No SOPs, Unknown

Acceptance criteria, timeline, and next moves

• When the pilot demonstrates expected coverage and helpdesk reduction, what would need to change in budget or contract terms to enable immediate production rollout?
• Choose up to five measurable acceptance criteria you will require to sign off the pilot Options: Coverage across SSO, VPN, RDP, SSH, legacy (%), Enrollment completion within window (%), Helpdesk ticket reduction (%), Authentication success rate (%), No critical outages, Compliance evidence mapped to NIST 800-63, Other
• Specify the individual or role required to sign final acceptance and the expected signoff window after pilot completion Options: Security Director, CISO, IT Operations Head, Compliance Officer, Procurement, Other
• What timeline constraints do you have for production rollout, for example insurance renewal, audit, or regulatory deadlines? Options: Insurance renewal within 3 months, Audit within 6 months, Regulatory deadline, No immediate deadline, Other
• Would you be open to a week-long technical proof with a defined rollback plan before a time-boxed pilot? Options: Yes, Maybe, No

• decision_readiness
• stakeholders
• current_state
• desired_state
• success_criteria
• gaps
• decision_readiness
• gaps
• current_state
• desired_state
• stakeholders
• success_criteria
• decision_readiness
• stakeholders
• desired_state
• success_criteria
• current_state
• gaps
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness

• Connect Identity Provider (SSO & SCIM)
• Deploy Self-Service Enrollment Portal
• IT-Assisted Provisioning for Non-Smartphone Users
• Ship and Provision FIDO2 Hardware Keys
• Enable Platform Biometrics and Device Registration
• Activate Push Authentication with Number Matching
• Protect Cloud SSO Applications
• Protect VPN and RDP Access
• Protect SSH and Command-Line Access
• Secure Legacy On-Prem Applications
• Configure Adaptive Risk Policies
• Set Per-Application Policy Groups and Roles
• Enrollment Progress Dashboard and Reporting
• Export Compliance Reports (NIST 800-63 & Insurance)

Connect Identity Provider (SSO & SCIM)

• Describe the identity provider (IdP) you will integrate with including vendor type and authentication protocol (SAML, OIDC, SCIM token access),
• List the SCIM user attributes and group mappings your directory requires for provisioning (e.g., employeeNumber, department, manager),
• How will you verify SCIM provisioning and SSO assertion exchange are successful (expected user sync count, sample SAML assertion, and SCIM provisioning logs)?
• Specify the admin contacts and API credential owner who will approve connector configuration and provide service account credentials,
• Confirm whether your IdP requires certificate rotation windows or IP allowlist entries for the integration connector, Options: Certificate rotation required, IP allowlist required, Both, Neither
• Provide your expected timeline for test tenant to production cutover for the IdP connector (days), Options: 3 days, 7 days, 14 days, Custom

Deploy Self-Service Enrollment Portal

• Identify the user populations you want to include in self-service enrollment for the pilot (engineering, IT, customer support, executive), Options: Engineering, IT, Customer support, Executive, All staff, Other
• Specify the enrollment methods you want enabled in the portal (hardware key registration, platform biometric enrollment, mobile authenticator), Options: Hardware key, Platform biometric, Mobile authenticator, One-time backup codes
• Describe the help content or step-by-step artifacts you will publish in the portal (screenshot guides, video walkthroughs, printable quickstart),
• Confirm whether you require custom branding and single sign-on into the portal using your corporate domain, Options: Standard portal branding, Custom branding and SSO required
• Estimate the expected enrollment completion rate for the pilot cohort within the time-boxed window (%), Options: Less than 50%, 50-75%, 76-90%, 91-100%
• Select fallback options you want available from the portal when users cannot self-enroll (IT-assisted request, onsite kiosk, mailed hardware key), Options: IT-assisted request, Onsite kiosk, Mailed hardware key, Temporary access token

IT-Assisted Provisioning for Non-Smartphone Users

• Identify the criteria that qualify a user for IT-assisted provisioning (no smartphone, remote worker without secure mail, accessibility need), Options: No smartphone, Remote without secure mail, Accessibility need, Other
• Specify the hands-on provisioning workflows you want IT to perform (on-behalf hardware key enrollment, manual credential binding, kiosk enrollment), Options: On-behalf hardware key enrollment, Manual credential binding, Kiosk enrollment, Temporary bypass code
• Provide the CSV or ticketing attributes we should accept for bulk IT-assisted onboarding (user principal name, employee ID, office location),
• Confirm expected SLA for IT-assisted provisioning requests during pilot (time to complete), Options: Same business day, 24 hours, 72 hours, Custom
• Indicate required audit fields for each IT-assisted provisioning action (provisioner name, device serial, ticket ID),
• Estimate the percent of pilot users you expect will need IT-assisted provisioning (%), Options: 0-5%, 6-15%, 16-30%, 31%+

Ship and Provision FIDO2 Hardware Keys

• Specify the hardware key quantity and packaging you require for the pilot including spares and replacements,
• Identify whether keys should be pre-provisioned with user bindings or provisioned at first use by the user, Options: Pre-provisioned with bindings, Provisioned at first use, Mixture
• Indicate shipping constraints such as delivery addresses allowed and required delivery SLA for key distribution, Options: Corporate address only, Home addresses allowed, Onsite pickup required
• Name the inventory owner who will receive serial numbers and manage key lifecycle for the pilot,
• Detail the tamper and chain of custody controls you require for key provisioning and custody logging,
• Select desired recovery and replacement policies for lost keys during pilot (IT-assisted reprovision, temporary OTP, mailed replacement), Options: IT-assisted reprovision, Temporary OTP, Mailed replacement, Require new purchase

Enable Platform Biometrics and Device Registration

• Identify which endpoints should allow platform biometrics for login (company laptops by OS, managed mobile devices), Options: Managed Windows laptops, Managed macOS laptops, Managed Android, Managed iOS
• Specify device registration limits such as max devices per user and allowed device types, Options: 1 device, 2 devices, 3+ devices, Custom limit
• Provide required device posture checks that must pass before device registration (disk encryption, OS patch level, MDM enrollment), Options: Disk encryption, OS patch level, MDM enrollment, Antivirus present
• Confirm whether biometric templates remain on-device only and whether you require attestation from platform authenticators, Options: On-device only with attestation, On-device only without attestation, Do not allow platform biometrics
• Estimate the percent of pilot endpoints already enrolled in your device management platform (percent), Options: 0-25%, 26-50%, 51-75%, 76-100%
• Describe any accessibility accommodations needed for biometric enrollment during the pilot (alternate factor flows),

Activate Push Authentication with Number Matching

• Select the user groups and application contexts where you want push with number matching enabled (high risk apps, SSO, VPN), Options: High risk apps, SSO, VPN, Company-wide
• Specify allowed fallback methods when push delivery fails (backup code, SMS one-time code, IT-assisted override), Options: Backup code, SMS OTP, IT-assisted override, Temporary bypass
• Indicate whether push notifications should include contextual information such as IP, location, and device name, Options: Include IP and location, Include device name only, Minimal context
• Provide expected acceptance thresholds for push delivery success rate during pilot (% of pushes delivered within 10 seconds), Options: >95%, 90-95%, 80-89%, <80%
• Describe your plan for users who experience prompt fatigue or accidental denials and the remediation flow you prefer,
• Name the incident owner for push authentication delivery issues and the escalation path into your networking team,

Protect Cloud SSO Applications

• Identify the cloud SSO applications to include in the pilot by application hostname and SSO connector type (e.g., SAML app A.example.com),
• Specify which application access rules should trigger step-up authentication (admin console, billing, customer data exports), Options: Admin console, Billing, Customer data exports, All sensitive actions
• Provide any application-specific integration constraints such as IdP-initiated versus SP-initiated flows or custom claim mappings,
• Indicate whether you require application-specific user segmentation for different MFA policies (contractors vs full time staff), Options: Yes, No
• Estimate the number of cloud SSO connectors to validate during the pilot by exact count, Options: 1-5, 6-10, 11-20, 21+
• Detail rollback criteria for an SSO application if the pilot causes access issues (restore previous SAML cert, disable policy),

Protect VPN and RDP Access

• List the VPN vendors and remote access gateways in scope including appliance model and firmware version,
• Specify the RDP gateway topology and whether bastion hosts or jump servers are used for remote desktop access, Options: Direct RDP gateway, Bastion hosts, Jump servers, Other
• Provide the authentication insertion point for VPN and RDP (RADIUS, SAML, client certificate) and any existing proxy behavior, Options: RADIUS, SAML, Client certificate, Other
• Indicate connection load and concurrent session estimates for pilot users to size connector capacity, Options: Low (1-50), Medium (51-300), High (300+)
• State the fail-open or fail-closed preference for VPN policy enforcement during pilot and acceptable outage window, Options: Fail-open with logging, Fail-closed, Controlled maintenance window
• Describe any legacy client compatibility needs such as old VPN clients or thin-clients that must be supported,

Protect SSH and Command-Line Access

• Identify SSH entry points and bastion host hostnames that will be in scope for MFA enforcement,
• Specify whether you prefer FIDO2-backed SSH keys, PAM module enforcement, or agent-based step-up for command-line sessions, Options: FIDO2-backed SSH keys, PAM module, Agent-based step-up, Other
• Provide the target user groups and service accounts that require non-interactive SSH access exclusions or special handling,
• Indicate the tooling used for SSH key rotation and whether the MFA integration must trigger key rotation workflows, Options: In-house rotation script, Key management system, Manual rotation, None
• Estimate expected automation impact on CI/CD agents that perform SSH operations and any required allowlist entries,
• Detail required audit logging fields for SSH session attestation (user, key ID, FIDO assertion),

Secure Legacy On-Prem Applications

• List legacy on-prem application names, hostnames, and authentication mechanisms that need adapter protection (form-based, LDAP bind, header injection),
• Specify any required agents or reverse proxy placements for application-level protection and required server access rights,
• Indicate whether you will allow header-based SSO, agent injection, or adapter-based brokering for these apps, Options: Header-based SSO, Agent injection, Adapter brokering, Other
• Provide the expected number of legacy apps to retrofit during pilot and any critical business hours to avoid for changes, Options: 1-3, 4-10, 11-25, 25+
• Describe backup authentication pathways for legacy apps during enrollment rollouts (local admin accounts, emergency tokens),
• Clarify compliance needs tied to any on-prem apps such as PCI or PHI that require special logging or retention, Options: PCI, PHI, None, Other

• Subscription Agreement
• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Service Level Agreement (SLA)
• Data Processing Agreement (DPA)
• Pilot Acceptance Certificate
• Mutual Responsibilities Agreement
• Change Order Agreement
• Regulatory Compliance Addendum (conditional)
• Invoice & Payment Schedule

• Go-live Health Check
• First Measurement Review
• Acceptance Gate, Production Readiness and Incumbent Wind-down
• Quarterly Success Review

• Schedule any required compliance evidence exports and confirm receipt for external attestations.
• Implement agreed corrective actions and log progress in the shared workspace ahead of the acceptance meeting.
• Collect sample helpdesk ticket threads and resolution times for audit at the acceptance gate.
• Restate acceptance criteria and numeric targets
• Produce a clear acceptance record showing pass/fail status per acceptance criterion recorded in Pilot Evaluation.
• Confirm the incumbent system is decommissioned or retained-read-only and that data and contract actions are scheduled or completed.
• List remediation items for any failed criteria with resolution dates and closure conditions.
• Publish the formal acceptance record with pass/fail status and the named buyer signatory.
• If decommissioning, schedule the incumbent system shutdown, data archive verification, and contract termination steps.
• Open remediation tickets for each conditional item with clear acceptance tests and completion deadlines.
• Review operational trends for core metrics
• Validate that helpdesk ticket volume and enrollment completion remain within acceptable bounds versus Pilot Evaluation targets or trigger remedial action if not.
• Ensure compliance attestation evidence is complete for the defined application set and identify any missing documentation.
• Keep the enhancement backlog prioritized and timeboxed so operational risk is minimized.
• Publish a quarterly metrics summary showing trends against Pilot Evaluation targets and circulate for asynchronous review.
• Create backlog tickets for prioritized enhancements with targeted delivery quarters.
• Re-confirm agreed success criteria and owners
• Confirm deployment components are operational and any configuration gaps are documented.
• List and prioritize open blockers with targeted resolution windows before the first measurement meeting.
• Confirm owners for each acceptance criterion as recorded in Pilot Evaluation.
• Publish a short remediation plan listing each blocker, the required fix, and the planned completion date.
• Capture early helpdesk themes and sample support tickets for trend analysis in the first measurement meeting.
• Validate and document production integration values used by the deployment team for operational runbooks.
• Present outcome data for core metrics
• Determine whether percentage of target applications protected and helpdesk ticket volume are progressing toward Pilot Evaluation targets.
• Identify root causes for the top 2 metric shortfalls and commit corrective actions with dates.
• Confirm the next measurement window and acceptance gate schedule.
• Produce a short findings pack showing metric baselines, current values, and the gap to Pilot Evaluation targets.
• Present outcome data against each criterion
• Compliance attestation and evidence review
• Deployment and configuration validation
• Enrollment completion and acceptance signals
• Document pass/fail per criterion and execute acceptance decision
• Early adoption signals and qualitative feedback
• Open issues burn-down and escalation status
• Diagnose root causes for gaps
• Enhancement requests and backlog prioritization
• Incumbent system wind-down confirmation
• Blockers, incidents, and open issues
• Agree corrective actions and timelines
• Confirm timeline to acceptance gate
• Agree remediation items and resolution timeline
• Short operational checklist and next steps
• Agree immediate remediation actions