Quick Start — What are we testing together?

• What’s the single most important outcome you want from this evaluation (e.g., reduce account takeovers, ship passwordless, improve registration conversion)? Options: Reduce account takeovers, Ship passwordless login, Enable social sign-on, Improve registration conversion, Meet data residency requirements, Other
• What timeline are you aiming for to have a working staging integration? Options: This week, 1–2 weeks, 3–4 weeks, 1–3 months, Undetermined
• Who will be directly involved in the hands-on evaluation (names/roles)?
• Which single test will make you decide to continue a full migration (pick one)? Options: Load test at peak concurrency, 2-week A/B registration test, Social provider parity check, Adaptive MFA ergonomics test, Security review/pen test

Are you okay betting your product on a DIY auth stack?

• When was the last time you experienced a production auth outage, account takeover, or credential-stuffing event? Options: Within 30 days, Within 6 months, Within 12 months, Over a year ago, Never
• Tell us briefly what happened and the business impact (user churn, revenue loss, launch delays, PR, etc.).
• How confident are you in your current defenses for large-scale credential stuffing or credential replay attacks? Options: Very confident, Somewhat confident, Neutral, Not confident, We don’t have measures in place
• Which of the following threat-detection or remediation controls are already in production? Options: Rate limiting / throttling, Credential stuffing detection, Breached-password checks, Device fingerprinting, Adaptive MFA, None of the above
• How does the security team feel about outsourcing credential detection and adaptive risk decisions to a vendor-managed platform? Options: Fully comfortable, Comfortable with SLA & audits, Needs legal/pen test evidence, Prefers in-house only, Undecided

What's silently costing you registrations and conversions?

• How large is the gap in registration or login conversion you’d consider unacceptable during an A/B test (absolute percentage points)? Options: > 5pp (large), 3–5pp (moderate), 1–3pp (small), <1pp (negligible), Don’t know
• Which parts of your current login/registration flow do you suspect are the biggest drop-off points? Options: Email entry & verification, Password complexity & resets, Social provider choices, CAPTCHA/anti-bot hurdles, MFA enrollment friction, Other
• Which social providers must be available to match your user expectations (pick all that matter)? Options: Google, Facebook/Meta, Apple, Twitter/X, LinkedIn, WeChat/QQ, Other regional providers
• Do you currently have design-system constraints that any SDK-provided UI must respect? If so, list critical elements (fonts, spacing, branding rules).
• If an SDK improved security but forced a visual change that reduces registration by 2pp, what trade-offs would you tolerate? Options: Accept short-term loss for security, Require configurable UI to maintain conversion, Need A/B proof before deciding, Unacceptable

Who will have the final say—and what keeps them up at night?

• Which stakeholders must sign off before you move beyond proof-of-concept (roles)? Options: VP Engineering, Head of Platform, CISO/Security, Product/PM, Legal/Privacy, Customer Support, Other
• What are the security team’s non-negotiables (e.g., data locality, audit logs, pen-test results, RBAC)?
• Which compliance or data-residency constraints apply to your user data today? Options: GDPR (EU), CCPA/CPRA (US), Data residency laws (specific country), HIPAA, None, Unsure
• How does the approval process work when security vetoes a vendor—what documentation or validation do they require?
• How would you describe the product team's tolerance for temporary conversion dips during an integration? Options: High (short-term ok), Moderate (small dips), Low (no dips allowed), Depends on mitigation plan

If your current authentication stack had a post-it note, what would it say?

• Do you run custom SAML parsers, proprietary password-hash algorithms, or other legacy auth logic that the current team didn’t build? Options: Yes, all three, Some legacy SAML/custom hashing, Only minor customizations, No, mostly standard implementations, Unsure
• Which bespoke authentication flows must be preserved during migration (e.g., invitation codes, legacy SSO mappings, enterprise mappings)?
• What’s the single trickiest edge-case in your current auth logic that has caused outages or support tickets?
• Which client platforms need SDKs or integration help (pick all that apply)? Options: Web (React/Vue), iOS (Swift), Android (Kotlin), Server-to-server (Node/Ruby/Python), Native desktop, Other
• How comfortable is your engineering team with a staged integration (SDK drop-in → feature flags → canary → full cutover)? Options: Very comfortable, Comfortable with vendor support, Prefer vendor integration help, Not comfortable

What would a risk-free pilot actually look like to you?

• If you could design a pilot that guaranteed zero user-impact, what guardrails must it include?
• What load-test targets do you need us to hit in staging to consider performance validated? Options: Peak concurrent logins, Sustained peak traffic for X minutes, Burst traffic profile, We’ll provide exact numbers, Unsure
• How long should the A/B test run to be statistically meaningful for your product metrics? Options: 1 week, 2 weeks, 4 weeks, Based on sample size calculation, Undecided
• Who will own test execution and results (engineer, product analyst, QA)? Options: Engineer, Product/PM, Data/Analytics, QA/Testing, Vendor-managed
• What rollback triggers would require an immediate cutback to the legacy flow (e.g., >X% conversion loss, error rate spike, security alert)?

How will you measure whether the integration actually improves your product?

• Which primary KPIs will determine a successful evaluation (rank up to three)? Options: Registration completion rate, Login success rate, Average time-to-login, Support tickets for auth, Security incidents prevented, Load performance metrics
• What delta in registration conversion would you consider a win (absolute percentage points)? Options: > 5pp, 3–5pp, 1–3pp, <1pp, No decrease allowed
• How important is adaptive MFA ergonomics (minimizing friction for returning users) versus maximizing security? Options: Ergonomics first, Security first, Balanced, Depends on user segment
• What monitoring and observability do you need during canary (error dashboards, SLO alerts, session traces)? Options: Error dashboards, SLO/SLA alerts, Real-user monitoring, Audit logs, All of the above
• Who will be responsible for post-launch incident response and vendor escalation? Options: Internal on-call, Vendor + internal, Vendor-managed with callbacks, Undecided

What risks are invisible until it’s too late?

• How many support seats do you typically handle for an auth-related spike (password resets, locked accounts) per 10k users? Options: <10, 10–50, 50–200, >200, Don’t track
• Have you experienced a surge in account lockouts or password-recovery tickets after a prior migration or major auth change? Describe briefly.
• What user segments are most sensitive to login friction (e.g., high-value customers, enterprise accounts, casual mobile users)? Options: High-value customers, Enterprise accounts, Mobile-only users, International users, All segments equally
• What’s an acceptable maximum percentage of users experiencing authentication issues during a staged cutover? Options: <0.1%, <1%, 1–3%, 3–5%, No issues acceptable
• What rollback or escalation plan would make you comfortable if things go sideways (staged rollback, DNS switch, feature flag off, support playbook)?

Show us how we earn your trust to sign a mutual commitment

• Which commercial or contractual items do you need resolved before a pilot (pricing model, SLA, data residency, breach liability)? Options: Pricing model, SLA/SLO, Data residency, Breach liability/insurance, Termination terms, Other
• Do you require proof-of-concepts like pen tests, SOC reports, or an on-site security review before production approval? Options: Yes, formal reports required, Pen test only, SOC 2 or equivalent, Prefer but not required, No
• What data-residency or tenant-isolation commitments are mandatory for your contract (regions, encryption, logging policies)?
• What migration timeline would your business consider acceptable for a full cutover (2 months, 3–6 months, 6+ months)? Options: 2 months, 3–6 months, 6+ months, Depends on user volume
• Who needs to be copied into commercial/legal conversations on your side (names/roles)?

A short checklist — what would make you feel confident to proceed this week?

• Which of the following would materially increase your confidence right now? Options: A staging SDK demo in our app, A load-test plan with dates, A two-week A/B plan and owners, Written data-residency commitments, Security artifacts (SOC2/pen test)
• What blockers, internal or external, could prevent you from starting the pilot this month? Options: Budget approval, Security sign-off, Engineering bandwidth, Legal review, Other
• Who should we schedule the next technical sync with and what’s their availability window?
• If we return with a proposed pilot plan and timelines, what decision cadence would you prefer (fast thumbs-up, review within one week, multiple internal reviews)? Options: Immediate decision, Review within 1 week, Multiple internal reviews needed, Undecided

• Solution Experience Kickoff — Diagnosis
• Failure Modes Mapping & Risk Prioritization
• Staged Integration Plan Workshop
• POC Validation & Test Runbook
• Customer Confirmation & Mutual Sign‑off on Pilot

• Clear pass/fail criteria and an operational runbook for anomalies and rollbacks.
• Produce a signed-off staged integration plan with clear scope per phase and measurable acceptance criteria.
• Agree on owners, timelines, and the communications/escalation path for each phase.
• Establish concrete rollback conditions and a minimal-impact rollback path.
• Seller: Deliver a phase-by-phase checklist (tasks, tests, owners) within 24 hours for review.
• Customer: Provision staging accounts, sample traffic replay tool access, and designate an on-call engineering contact for pilot windows.
• Both: Schedule pilot window dates and a canary cohort definition (percentage or user segments).
• Review POC Objectives & Test Matrix
• Agreed POC test cases mapped to success signals and prioritized failure fixes.
• Instrumentation and dashboard ownership defined and accessible to both teams.
• Introductions & Objectives
• Seller: Provide load-test scripts, A/B experiment configuration files, and sample dashboards.
• Customer: Configure telemetry ingestion and grant read access to test dashboards for seller engineers.
• Both: Agree on test schedule, time windows, and responsible on-call contacts for each test run.
• Recap: Current State, Consequence & Future State
• Achieve mutual sign‑off to begin the pilot with clearly assigned owners and dates.
• Document remaining risks and concrete mitigations with owners and deadlines.
• Schedule the Pre‑Deployment Readiness meeting and confirm required artifacts for that checkpoint.
• Customer: Formally approve the pilot scope and nominate primary on-call and PM owners.
• Seller: Publish the finalized runbook, test schedule, and telemetry dashboards to the shared channel.
• Both: Lock pilot start date and calendar invites for test windows and the pre-deployment readiness review.
• Produce a single-sentence, customer-approved current-state statement.
• Agree quantified consequences (e.g., outage minutes, conversion loss, support cost) for top failure scenarios.
• Lock the evaluation success signals and acceptance criteria for the POC/pilot.
• Assign owners and deadlines for required prework artifacts.
• Customer: Share auth logs, incident postmortem, baseline conversion metrics, and peak traffic profile.
• Seller: Prepare an initial mapping template to capture failure modes and impact metrics.
• Both: Confirm list of stakeholders and primary contacts for staging access and A/B test ownership.
• Walkthrough of Collected Failure Examples
• A prioritized, customer-validated list of auth failure modes mapped to user journeys and costs.
• Clear decision on which failures are in-scope for the pilot (must-fix) vs out-of-scope (later phase).
• Assigned owners for mitigation experiments for each prioritized failure.
• Customer: Provide sample user IDs and replay data (anonymized) for top three failure modes to enable reproductions in staging.
• Seller: Draft mitigations (short-term workarounds and long-term fixes) mapped to each prioritized failure.
• Both: Agree on measurable impact metrics per failure (e.g., % conversion recovery, error-rate reduction).
• Define One‑Sentence Future State
• Walkthrough of Staged Plan & POC Proof Points
• Instrumentation & Observability Plan
• Phase Definitions & Scope
• Customer One‑Sentence Current State
• Map Failures to User Journeys & Systems
• Consequence Evidence & Quantification
• Define Success Thresholds & Exit Criteria
• Open Risks & Mitigations
• Phase Acceptance Criteria & Tests
• Quantify Frequency & Business Impact
• Sign‑off & Next Milestones
• Confirm Success Signals & Evaluation Criteria
• Responsibilities, Timelines & Communication Plan
• Prioritization & Pilot Scope Decision
• Incident Playbook & Runbook Walkthrough
• Validation Check — Customer Confirmation
• Immediate Next Steps & Owners
• Validation Confirmation
• Rollback & Escalation Playbook
• Final Q&A and Validation

• Install Web SDK and React UI Kit
• Install iOS and Android Mobile SDKs
• Deploy Branded Hosted Login and Registration Pages
• Configure Social Identity Providers (OAuth/OIDC)
• Implement Passwordless WebAuthn Authentication Flow
• Migrate and Validate Existing Password Hashes
• Enable Adaptive MFA and Risk-Based Policies
• Activate Breached-Password Detection and Blocklists
• Provision Tenant Data Residency and Regional Isolation
• Integrate SAML/Enterprise SSO and SCIM Provisioning
• Set Up Session Management and Scalable Token Service
• Deploy Account Recovery Email and SMS OTP Workflows
• Run Staging Load Test at Peak Concurrency
• Instrument Registration Flow for A/B Testing

Install Web SDK and React UI Kit

• Which web frameworks and versions does your application use (framework and version)? Options: React (specify version), Next.js, Vue, Angular, Other
• Do you currently use a design system or CSS framework that the UI Kit must match? Options: Yes - provide design tokens, No, Partially (mix of custom and library)
• Which pages or flows should the Web SDK replace or instrument in staging (login, register, MFA, account settings)? Options: Login, Registration, Account Settings, Password Recovery, Other
• Are there existing client-side customizations (e.g., custom field validators, CAPTCHA, consent checkboxes) the SDK must support or preserve? Options: Yes - list them, No
• What deployment pattern do you prefer for the Web SDK integration? Options: Embed components (React), Overlay hosted widget, Server-rendered integration, Hybrid
• Who owns the implementation work and what is the expected timeline for a staging integration?

Install iOS and Android Mobile SDKs

• Which mobile platforms and minimum OS versions must be supported? Options: iOS (specify min), Android (specify min), Both
• Do you use native UI or a cross-platform framework (React Native, Flutter) for your mobile apps? Options: Native iOS/Android, React Native, Flutter, Other
• Which mobile-specific auth features are required (biometric, device-bound keys, push notifications for MFA)? Options: Biometric (FaceID/TouchID), Device-bound keys, Push MFA, SMS/OTP, None
• Do you need SDK support for background/refresh token handling and silent re-auth during app resume? Options: Yes, No, Unsure
• Are there existing mobile SSO or provider integrations that must be preserved (Apple Sign In, Google Sign-In)? Options: Apple Sign In, Google Sign-In, Facebook, Other, None
• What CI/CD and App Store review constraints or timelines affect the rollout of mobile SDK updates?

Deploy Branded Hosted Login and Registration Pages

• Will you use a custom domain or our hosted domain for login pages? Options: Custom domain (CNAME), Hosted domain, Subdomain
• Which brand assets and localization support are required (logos, fonts, languages)? Options: Logos and colors, Custom fonts, Multi-language support, RTL languages, Other
• Do hosted pages need to embed custom fields, business logic, or third-party scripts? Options: Yes - specify, No
• Are there accessibility or design-system constraints the hosted pages must meet (WCAG level)? Options: WCAG AA, WCAG A, No formal requirement, Other
• Do you require the hosted pages to integrate with your analytics, tag manager, or custom pixel? Options: Yes, No
• What is the expected staging-to-production path and approval process for hosted page branding changes?

Configure Social Identity Providers (OAuth/OIDC)

• Which social providers do you need supported in the pilot and full migration? Options: Google, Facebook, Apple, Twitter/X, LinkedIn, GitHub, Other
• Do you have existing client IDs and secrets for those providers or do we need to create them? Options: We have them, We need help creating them, Mixed
• What profile attributes from social providers must be mapped into your user model (email, name, picture, locale, phone)? Options: Email, Name, Avatar/Photo, Locale, Phone, Other
• Do you have policies for account linking (auto-link by email vs. manual user confirmation)? Options: Auto-link by verified email, Require user confirmation, Do not link
• Are there regional or privacy constraints for any providers (e.g., Apple Sign In mandatory for iOS apps)? Options: Yes - specify, No
• Do you require scoped permissions (additional OAuth scopes) for provider sign-ins? Options: Yes - list scopes, No

Implement Passwordless WebAuthn Authentication Flow

• Do you want WebAuthn as primary auth, optional second factor, or as a progressive enhancement? Options: Primary, Optional/Alternative, Progressive upgrade
• Which authenticators should be allowed (platform authenticators, roaming/security keys, passkeys)? Options: Platform authenticators (TouchID/FaceID), Roaming keys (YubiKey), Passkeys, All
• What fallback flows should be provided when WebAuthn is unavailable (SMS OTP, email link, password digest)? Options: SMS OTP, Email magic link, Password fallback, Customer support recovery
• Do you require attestation or verification policies (e.g., require attestation for hardware tokens)? Options: Yes - require attestation, Optional attestation, No
• Will you allow users to register multiple authenticators per account (per-device trust)? Options: Yes, No, Limit to N devices (specify)
• Are there privacy/regulatory constraints for storing public keys or authenticator metadata in certain regions? Options: Yes - specify region, No

Migrate and Validate Existing Password Hashes

• What hashing algorithms are present in your legacy store (bcrypt, scrypt, PBKDF2, Argon2, custom)? Options: bcrypt, scrypt, PBKDF2, Argon2, Custom/Other
• Can you provide access to the password hashes and metadata (salt, iterations) for validation during migration? Options: Yes - accessible, Yes - with restrictions, No - cannot provide
• Do you prefer a phased migration (verify on login, silent rehash) or an upfront bulk re-hash strategy? Options: Phased (on-login rehash), Bulk re-hash, Hybrid
• What is the user volume to migrate in the pilot and full migration (estimate)? Options: <10k, 10k-100k, 100k-1M, >1M
• Are there service windows or blackout periods we must avoid for migration actions? Options: Yes - provide windows, No
• Do you have compliance constraints about storing legacy hash formats or audit logging for migration events? Options: Yes - specify, No

Enable Adaptive MFA and Risk-Based Policies

• Which signals should trigger risk-based MFA (IP reputation, device fingerprint, geolocation change, velocity)? Options: IP reputation, Device fingerprint, Impossible travel/geolocation, Login velocity, Known breached device
• Which MFA methods do you want available when risk is detected? Options: TOTP (authenticator app), Push notification, SMS OTP, WebAuthn, Email OTP
• Do you want persistent trust on safe devices (remember device) and how long should trust persist? Options: Yes - 1 day, Yes - 7 days, Yes - 30 days, No
• Should certain user groups be exempted from adaptive MFA (admins, service accounts)? Options: Yes - list groups, No
• What is the acceptable false-positive tolerance for risk policies (how often can legitimate users be challenged)? Options: Low tolerance (strict), Medium, High tolerance (conservative)
• Who will approve and test adaptive MFA policy changes during pilot?

Activate Breached-Password Detection and Blocklists

• Do you want to enable real-time breached-password checks at registration/login or periodic scans of stored credentials? Options: Real-time checks, Periodic scans, Both, None
• Are there custom or corporate blocklists that must be enforced (common passwords, leaked corp accounts)? Options: Yes - provide list, No
• What action should be taken when a breached password is detected (block, force reset, warn user)? Options: Block and force reset, Warn and require change, Allow with warning
• Do you require integration with specific external breach feeds or commercial blocklist providers? Options: Yes - specify provider, No
• Are there privacy or legal constraints around sending hashes for breach checks (PII restrictions)? Options: Yes - restrict, No
• Who owns the support and user communication plan if many accounts are forced to reset?

Provision Tenant Data Residency and Regional Isolation

• Which regions must be available for tenant data residency (US, EU, APAC, specific country)? Options: US, EU, UK, APAC, Other
• Which data classes must be regionally isolated (PII, auth logs, backups, analytics)? Options: PII, Auth logs, Backups, Analytics, Other
• Do you require physical isolation (dedicated cluster) or logical isolation within our regional service? Options: Physical/dedicated cluster, Logical isolation, Unsure - need guidance
• Are there legal or contractual data residency commitments we must include in SLA/contract? Options: Yes - provide details, No
• What is your expected failover behavior for region outages (cross-region failover allowed or restricted)? Options: Allow cross-region failover, Restrict to region only, Allow with notification
• Who are the stakeholders for residency decisions and which compliance certifications are required (e.g., GDPR, SOC2)?

Integrate SAML/Enterprise SSO and SCIM Provisioning

• How many SAML IdPs or enterprise SSO integrations are in scope for the pilot and production? Options: 1, 2-5, 6-20, 20+
• Which attributes and mappings are required from SAML assertions to your user model (email, username, groups, roles)? Options: Email, Username, Groups, Roles, Other
• Do you require SCIM user and group provisioning/deprovisioning, and which identity source will be authoritative? Options: Yes - SCIM provisioning, No, Partial
• Are there certificate rotation, metadata, or SSO testing windows we must coordinate with IdP teams? Options: Yes - provide windows, No
• Do you need Just-In-Time (JIT) provisioning or pre-provisioning via SCIM for pilot users? Options: JIT provisioning, SCIM pre-provisioning, Both, Neither
• What is the rollback plan if SSO mapping changes cause login failures during cutover?

• Commercial Terms & Quote
• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Service Level Agreement (SLA)
• Data Processing Agreement (DPA)
• Data Residency Addendum
• Security & Compliance Attestation
• Migration & Cutover Plan
• Rollback & Incident Escalation Plan
• Acceptance & Pilot Criteria
• Support & On‑call Agreement
• Change Order Process
• Intellectual Property & Licensing
• Termination & Data Exit Plan
• Renewal & Expansion Terms

• Success Review: Outcomes vs Success Signals
• Retrospective & Root-Cause Learnings (Blameless)
• Operations Handover & Shared Channel Governance
• Roadmap & Enhancement Prioritization (Post-Pilot)

• Create and provision the shared issue channel (Slack/MSTeams) and assign primary liaisons from both teams.
• Capture a prioritized, time-bound backlog of fixes and process changes to prevent recurrence.
• Identify root causes for each failure or shortfall and agree remediation paths.
• Agree on verification steps and success criteria for each remediation item.
• Publish a blameless postmortem document with root causes, impact, and remediation plan.
• Create tickets for top 3 technical fixes (with acceptance tests) and assign owners.
• Schedule follow-up verification sessions after fixes are implemented.
• Update integration runbooks and staging-checklist to close process gaps identified.
• One-sentence Current State of Ops Readiness
• Have a documented, agreed-upon operational model with SLAs and escalation paths.
• Ensure monitoring dashboards and runbooks are in place and owners are identified.
• Establish rules and access for the shared channel that will be used for day-to-day issues and enhancements.
• Provision shared channel, invite defined stakeholders, and post the triage template and SLA matrix.
• Build or share monitoring dashboards for key signals and grant viewer/editor access to owners.
• Finalize and version the runbook and rollback procedure in a shared document repository.
• Schedule an on-call handover rehearsal to validate escalation paths.
• One-sentence Recap of Outcome & Priority Gaps
• Produce a mutually agreed, prioritized roadmap with target dates and acceptance criteria.
• Align on resource commitments and any necessary funding or scope trade-offs.
• Schedule the next success checkpoint and verification gates for roadmap items.
• Publish the prioritized roadmap with acceptance tests and milestone dates.
• Create feature tickets and capacity estimates for the top-priority items.
• Confirm resource allocations and any commercial adjustments required to support the plan.
• Schedule the next outcomes review checkpoint aligned to roadmap milestones.
• Determine, against documented success signals, whether the pilot is accepted, needs remediation, or should be rolled back.
• Ensure the customer explicitly validates each success signal with accompanying evidence.
• Assign clear owners and timelines for any remediation or next deployment steps.
• Establish the persistent shared channel and point-of-contact for ongoing issues.
• Produce a one-page Outcomes Report mapping each success signal to the evidence and customer validation (accept/reject), deliver within 48 hours.
• If remediation required, create a prioritized remediation plan with owners and dates.
• If accepted, document cutover criteria and schedule for wider rollout.
• One-sentence Current State
• One-sentence Current State Recap
• Explicit Consequence Summary
• Impact Assessment
• Timeline of Key Events & Incidents
• Monitoring & Alerting Signals
• Prioritization Exercise
• Defined Future State (Acceptance Criteria)
• Severity Definitions & SLAs
• Root Cause Analysis
• Proposed Release Plan & Timelines
• Escalation Path & On-call Roster
• Proof: Metrics Walkthrough
• Process & Tooling Gaps
• Tiebacks: Problem → Proof
• Shared Channel Workflow
• Mutual Commitments & Funding/Resources
• Customer Experience Impact Review
• Action Backlog & Prioritization
• Validation Checkpoint
• Runbook & Rollback Review
• Next Milestones and Checkpoints
• Decision & Next Step Options
• Compliance & Data Residency Ownership
• Owners & Timelines