Getting Oriented

• To get started, what event or product need prompted you to evaluate a new identity platform now? Options: Recent security incident, Need to ship passwordless or social login, Drop in registration conversion, Upcoming compliance audit, Other
• Describe the application you plan to pilot in staging, including platform (web, iOS, Android), approximate monthly active users, and peak concurrent logins.
• Which stakeholder owns the final go or no-go decision for production cutover, and who else holds veto rights on security or privacy? Options: VP Engineering, Head of Platform, CISO or security leader, Product leader, Cross-functional committee, Other
• How would you prioritize the outcomes of security, conversion, and data residency for this pilot? Options: Security highest, Conversion highest, Data residency highest, Security and conversion equally, All equally important
• Estimate the target improvement or maximum allowable decline in registration completion you would accept from the two-week A B test for the pilot to be useful.
• Would you pause evaluation if the two-week A B test cannot start within 30 days? Options: Pause evaluation, Proceed with an alternate proof of concept, Proceed without the two-week A B test, Unsure

Where Login Breaks First

• Tell me about a recent outage or attack that exposed a weakness in your login flow, what failed and who felt the pain first?
• When credential stuffing or an account takeover occurs, what operational signals do you see first and how quickly do they appear after the attack starts? Options: Spike in failed login attempts, Sudden increase in support tickets, Unusual geographic or IP patterns, Massive lockouts and password resets, Internal monitoring alerts
• Which parts of your current auth stack are bespoke code that nobody on the current team originally wrote? Options: Password hashing and storage, Custom SAML or SSO parsers, Session and token services, Recovery and account linking flows, Other
• Who spends most of their time triaging login incidents and what does that day to day work look like? Options: On call SRE, Platform engineering, Security operations, Product engineers, Support team, External contractors
• What single technical or organizational failure in your current login system would immediately stop you from running a staged pilot?

The Real Cost When Login Fails

• If your peak login endpoint becomes degraded during a launch, how do you measure the downstream cost in churn, support load, or revenue lost? Options: Support tickets and handle time, Short term churn rate, Revenue per hour lost, Incident cost to engineering, Executive escalation and PR
• List the last three authentication incidents that increased support volume or churn and briefly what each cost you in time or money.
• How many additional support tickets per week or what percent monthly churn would trigger leadership to demand a replacement instead of incremental fixes? Options: >500 tickets/week, >250 tickets/week, >3% monthly churn, >10% monthly churn, Other
• Who in finance or product ties registration conversion to revenue forecasts and can sign off on A B test success criteria? Options: Head of Finance, Head of Revenue, Product leader, VP Engineering, CRO, Other
• If the pilot shows no improvement or a decline in registration conversion after two weeks, what is the likely executive reaction and timeline for escalation?

Obstacles, Risks, and Deal Killers

• Name the top three technical or policy risks that could prevent a production cutover and identify which of those is most likely to stop the deal. Options: SSO integrations breaking, Data residency mismatch, Regulatory or audit failure, Unacceptable conversion decline, Support surge
• Identify the single regulatory or data residency requirement, if unmet, that would force you to stay with the current approach. Options: EU data residency requirement, Country-specific hosting mandate, PCI or payment related restriction, Industry specific privacy regulation, No strict requirement
• Do you have internal teams or contractors actively proposing to rebuild authentication instead of buying a platform? Options: Yes, internal team, Yes, external contractors, Not currently, Discussing but not committed
• Estimate the engineering runway in calendar weeks or full time engineers required to deliver an internal rebuild that matches your pilot goals. Options: Under 2 weeks, 2 to 6 weeks, 1 to 3 months, More than 3 months
• What single integration dependency, if unavailable during the staging window, would force the pilot to be canceled?

Competitive Landscape

• List the alternatives you are actively comparing, including internal options, the incumbent, and other vendor categories, and indicate which of them would survive your security team's review. Options: Incumbent vendor, Internal rebuild, Other modern CIAM platforms, Auth-as-a-library, Open source solution, Not sure
• Under what conditions would your team decide to keep the current solution rather than migrate to a vendor?
• Has anyone internally argued for a full rebuild of authentication instead of piloting an external platform, and what is their primary rationale?
• Should a shortlisted vendor fail to demonstrate required social provider coverage or regional data residency in staging, would you continue evaluation or halt the project? Options: Continue evaluation with remediation plan, Halt the project, Ask for immediate remediation, Pivot to alternate vendor
• Rank the evaluation criteria you will weight most heavily when choosing between vendors: conversion impact, security posture, operational overhead, data residency, SDK flexibility, cost. Options: Conversion impact, Security posture, Operational overhead, Data residency, SDK flexibility, Cost

Integration and Readiness Reality Check

• Identify any integration dependency that, if unavailable to your team during the staging window, would stop the pilot before it begins. Options: Primary user database access, SSO connector endpoints, Social provider credentials, Event or message bus, Payment gateway
• Name the person or team that owns the third party APIs, SSO mappings, and social provider credentials the staging integration requires.
• Are staging environments available that mirror production peak load, and if not, which best describes the gap? Options: Exact production mirror available, Partial mirror available, No mirror available
• Provide how many engineering sprints or calendar weeks your team can dedicate to the pilot during the staging window. Options: 1 sprint, 2 to 3 sprints, 4 to 6 sprints, More than 6 sprints
• Is a named security reviewer or compliance approver available to sign required attestations within the pilot window? Options: Yes, available in window, Yes, but not within window, No

Acceptance Criteria and Next Steps

• Assume the staging test shows a 10 percent lift in registration completion and no increase in security incidents, what immediate commercial decision would you expect leadership to make? Options: Sign contract within 2 weeks, Request an extended pilot, Enter commercial negotiation, Delay decision for legal review
• Provide the measurable acceptance criteria the two-week A B test must meet, including target conversion delta, peak load latency thresholds, acceptable adaptive MFA false positive rates, and any regional residency checks.
• Please indicate the named production owner and the deployment owner who will be responsible for the cutover checklist if the pilot succeeds.
• Choose your preferred target window for a staged rollout following a successful pilot. Options: Within 2 weeks, 2 to 6 weeks, 6 to 12 weeks, More than 12 weeks
• Detail the remaining internal approvals and the estimated time each would take if the pilot meets the acceptance criteria tomorrow, for example legal sign off, procurement, or security attestations.

• Solution Experience Session

• Confirm the current state and its cost
• You confirm the demonstrated integration pattern preserves your design system and eliminates UI constraints that were reducing registration conversion.
• Provision a regional staging tenant preconfigured with the proposed SDK settings and test credentials.
• You confirm the adaptive MFA behavior shown matches your desired returning-user friction and the security team's threat tolerance.
• Integration pattern walkthrough for your staging app
• Deliver an integration diagram and the exact SDK configuration snippet for the buyer's staging app.
• You confirm the proposed data residency configuration meets your regulatory and contractual requirements.
• Run an initial peak-load test against the staging tenant and share the results and any tuning recommendations before the full acceptance test.
• Live flows in staging, using your design variations
• You agree to the measurable acceptance criteria for the staging test, including peak-load targets, conversion delta threshold, and social provider coverage.
• Adaptive MFA and fraud mitigation scenarios
• Provide peak concurrent login metrics, the top social providers to cover, and a single app and owner for the staging integration.
• Define and document acceptance thresholds for conversion impact, MFA false-positive tolerance, and social provider coverage for the two-week A/B test.
• Data residency and compliance mapping
• Performance and load plan overview
• Validate outcomes and confirm next-step acceptance criteria

• Solution Experience Session
• Solution Experience Deck
• Solution Brief

• meeting
• slides
• document

• Integrate SDK for Web, iOS, and Android
• Deploy Production-Grade Login Flow
• Configure Social Identity Providers
• Enable Passwordless Authentication Flows
• Deploy Adaptive MFA and Risk Policies
• Credential-Stuffing Detection and Automated Mitigation
• Breached-Password Screening and Password Hygiene
• Tenant Isolation and Data Residency Configuration
• Migrate User Accounts and Password Hashes
• Migrate Single Sign-On and Federation Integrations
• Provision Staging Tenant and Peak Load Testing
• Run A/B Test for Registration Conversion

Integrate SDK for Web, iOS, and Android

• Which SDK(s) will you integrate into your staging application? Options: Web (React/Vanilla), iOS (Swift), Android (Kotlin), Server-side only
• Which web framework does the staging front end use (so we can confirm the correct SDK binding)? Options: React, Next.js, Vue, Angular, Other
• Which native mobile frameworks and minimum OS versions must the mobile SDKs support for your iOS and Android apps?
• Do you require the SDK to render a fully hosted login UI or to supply UI primitives for your design system? Options: Fully hosted, UI primitives only, Hybrid (hosted + customizable)
• How much UI customization is permissible for the SDK integration to avoid breaking your design system (colors, fonts, layout hooks)? Options: Minor CSS theming only, Full component-level theming, We need to embed custom components
• Who on your team will own the SDK integration tasks in staging (name and role)?
• Provide the expected CI/CD branch or staging URL where the SDK will be installed so we can validate SDK bundle and error reporting.

Deploy Production-Grade Login Flow

• Which existing authentication flows do you need matched in staging (registration, email verification, password reset, social sign-on)? Options: Registration, Email verification, Password reset, Social sign-on, Progressive profile
• Do you require a drop-in login page hosted by the platform or an SDK-driven embedded flow for your production look and feel? Options: Platform-hosted page, Embedded SDK flow, Both for A/B
• What maximum end-to-end login latency (95th percentile) do you require for users on your primary region during peak traffic? Options: < 300 ms, < 500 ms, < 1 s, Custom
• How should session lifetime and refresh token behavior map to your existing session policy (session duration and idle timeout in minutes)?
• List the UX flows you consider critical to preserve for conversion (one-tap social, email-first registration, phone verification).
• Who will be the owner for validating production-grade behavior (name, role) during the staging run?

Configure Social Identity Providers

• What social identity providers must be available in staging to match your user population (e.g., the providers your analytics show as primary acquisition channels)?
• Do you require coverage of regional social providers or enterprise identity brokers used by your users? Options: Yes, regional providers, Yes, enterprise brokers, No
• Which redirect URIs and callback endpoints will you register for each social provider in your staging tenant?
• Who will supply the client IDs and secrets for social provider configuration, and are these stored in a secrets manager? Options: We will supply and store in secrets manager, We need help generating/storing secrets, Other
• How do you expect social account linking to behave when a user has an existing email/password account in your system? Options: Auto-link by verified email, Prompt user to link, Create separate account
• Provide the acceptance criterion for social provider coverage you expect to test in staging (number of providers or specific provider list).

Enable Passwordless Authentication Flows

• Which passwordless methods do you want to enable for the staging flow (email magic links, SMS OTP, WebAuthn/FIDO2)? Options: Email magic link, SMS one-time passcode, WebAuthn / FIDO2, Authenticator app (TOTP)
• Do you have rate limits or carrier restrictions for SMS you need the platform to respect during staging? Options: Yes, No
• What session creation behavior should apply after a passwordless sign-in (immediate session, require second factor, progressive profiling)? Options: Immediate session, Require MFA on first use, Progressive profiling
• Provide sample email templates or brand guidelines we must apply to magic links to avoid brand mismatch in the registration flow.
• How should lost-magic-link or expired-link UX behave to minimize support tickets (resend after X minutes, show help link)? Options: Resend after 1 minute, Resend after 5 minutes, Show help link and contact support
• Who will validate passwordless flows in staging and confirm they do not regress conversion metrics (name and role)?

Deploy Adaptive MFA and Risk Policies

• Which risk signals should trigger adaptive multi-factor authentication (MFA) in staging: new device, IP reputation, impossible travel, credential stuffing score)? Options: New device, IP reputation, Impossible travel, High credential-stuffing score, High-risk country
• What MFA factors do you want available for users (TOTP, push, SMS fallback, hardware key)? Options: TOTP, Push notifications, SMS fallback, Hardware security key (FIDO2)
• How should adaptive MFA behavior treat returning users who previously opted out of MFA? Options: Respect prior opt-out, Re-prompt if risk threshold exceeded, Force MFA on next login
• Specify the numerical risk threshold or score range that should escalate to step-up MFA during staging. Options: Low, Medium, High, Custom numeric threshold
• Who on your security team must approve the adaptive MFA policy used in staging (name and role)?
• Describe how adaptive MFA decisions should be logged and exported for your audit pipeline (log fields, SIEM endpoint).

Credential-Stuffing Detection and Automated Mitigation

• Which account takeover signals do you want monitored in staging (rapid failed logins, large-IP fanout, password spray patterns)? Options: Rapid failed logins, IP fanout, Password spray, Device fingerprint anomalies
• Do you require automated mitigation actions on detection (rate limiting, progressive delays, IP blocking, forced password reset)? Options: Rate limiting, Progressive delays, IP block, Force password reset, Notify security team
• Provide the threshold for failed-attempt rate per account or per IP that should trigger mitigations during peak load. Options: 5 attempts / minute, 10 attempts / minute, Custom
• How should false positives be handled in staging to avoid blocking legitimate users (auto-unblock window, manual review)? Options: Auto-unblock after window, Manual review required, Notify user and allow secondary verification
• Who will receive automated mitigation alerts and own incident response during the staging window (name and role)?
• Specify whether you want credential-stuffing telemetry exported to your SIEM or retained only in the platform for 30/90/365 days. Options: Export to SIEM, Retain 30 days, Retain 90 days, Retain 365 days

Breached-Password Screening and Password Hygiene

• Which breached-password sources do you require screening against in staging (shared breach feeds, NIST hashed list, proprietary corporate list)? Options: Public breach feeds, NIST-equivalent hashed list, Upload proprietary list, None
• What enforcement action should occur when a user attempts to set a breached password (block, warn and allow with reset, require alternate factor)? Options: Block, Warn and force different password, Allow with MFA required
• How often do you want breached-password feeds refreshed for staging and production (daily, hourly, weekly)? Options: Hourly, Daily, Weekly
• Do you require password strength policies to be enforced at registration and reset (min length, composition, banned substrings)? Options: Yes, enforce at registration, Yes, enforce at reset, No
• Who on your product or security team will review password hygiene reports after the staging run?
• Describe any compliance requirements that affect password storage or screening (for example, GDPR, PCI DSS, or other regional rules).

Tenant Isolation and Data Residency Configuration

• Which data residency region(s) must be used for your tenant (EU, UK, US regional, APAC), and do you require physical isolation for production data? Options: EU, UK, US, APAC, Multi-region with isolation
• Do you need true tenant-level isolation (dedicated cluster) or logical isolation in shared clusters for your production tenant? Options: Dedicated cluster, Logical isolation in shared cluster, Undecided
• Specify which data types must remain in-region (authentication logs, user PII, session tokens) for compliance. Options: Authentication logs, User personal data, Session tokens, All of the above
• Provide the acceptance evidence required to validate data residency in staging (region-bound logs, IP address ranges, SOC attestations).
• Who on your compliance team will verify tenant isolation and sign off on residency controls?
• Do you require encryption key management integration with your key management service during staging and cutover? Options: Yes, KMS integration, No, platform-managed keys, Undecided

Migrate User Accounts and Password Hashes

• How many user accounts do you plan to migrate in the initial cutover wave (estimate count or range)? Options: < 10k, 10k-100k, 100k-1M, 1M+
• Which password hash algorithms are present in your current store (bcrypt, scrypt, argon2, PBKDF2, custom) and what are their parameters? Options: bcrypt, scrypt, argon2, PBKDF2, Custom
• What migration strategy do you prefer for passwords: online lazy migration on first login, bulk re-hash with secret, or forced reset by email? Options: Lazy migration on first login, Bulk re-hash with credentials, Forced password reset campaign
• What minimum migration success rate will you accept before proceeding to next wave (successful auth against migrated accounts)? Options: 95%, 98%, 99%, Custom
• Who is responsible for providing the export of user records and password hashes, and does that export require an encrypted transfer method? Options: We provide export and encrypted transfer, We need assistance, Other
• Describe how you want account identifier mapping handled for duplicates or merged users during migration (email normalization, external ID mapping).

Migrate Single Sign-On and Federation Integrations

• List the single sign-on (SSO) and federation protocols and identity providers in scope for migration (SAML 2.0, OpenID Connect, enterprise IdP list).
• Do any existing SSO connections require custom claim mapping or attribute transformations during cutover? Options: Yes, custom mappings, No, standard attributes only, Undecided
• Which SSO integrations are business-critical and must remain available during staged rollout (list provider or application names)?
• How should SSO session handoff and logout be handled to avoid orphaned sessions during migration? Options: Preserve existing session tokens, Re-establish sessions post-migration, Custom logout orchestration
• Who will own testing SSO flows in staging with corporate IdP test tenants and provide test accounts?

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

• Subscription Agreement
• Order Form
• Data Processing Agreement (DPA)
• Data Residency Addendum
• Security Attestation & Compliance Exhibit
• Service Level Agreement (SLA)
• Cutover Acceptance Criteria & Go/No-Go Agreement
• Support & Escalation Addendum
• Export and Cross-Border Transfer Addendum

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• 90-day Realization Review
• Quarterly Operational Review (ongoing)

• Schedule the next quarterly review and any interim technical check-ins for high-risk items.
• Schedule a follow-up measurement after remediation and confirm the data sources to be used for re-evaluation.
• Restate acceptance criteria from Solution Scope
• Document which Solution Scope targets are met, which remain unmet, and the concrete remediation plan for each unmet item.
• Ensure all security incidents since go-live have recorded RCA and closure timelines.
• Establish a prioritized shared backlog for enhancements and incident fixes with target windows.
• Publish the 90-day outcome report that maps each Solution Scope criterion to measured results and remediation status.
• Create the prioritized shared backlog with effort estimates and target release windows.
• Schedule any security follow-up workshops required to close outstanding incident remediation items.
• Trend review for conversion and security metrics
• Confirm the solution continues to meet operational expectations for login conversion and security blocking activity, or record deviations and remediation timelines.
• Keep the shared backlog prioritized and assign target windows for the top 3 items.
• Agree any needed SLO or monitoring changes to reduce false positives or missed incidents.
• Update the shared backlog with the quarter's priorities and target windows for the top items.
• Adjust monitoring thresholds or SLOs as agreed and document the rationale.
• Re-confirm deployment scope and owners
• Deployment validated across environments and early telemetry shows no critical regressions.
• Critical blockers and rollback triggers logged with remediation windows.
• Incumbent decommission plan confirmed or retained-read-only with archive timeline.
• Publish a deployment validation report that lists completed checks and outstanding defects.
• Log critical defects in the shared backlog with resolution target dates.
• Execute the planned rollback drill or prove rollback path within the agreed window.
• Data presentation against Solution Scope targets
• Confirm whether registration completion rate and login conversion rate are trending toward Solution Scope targets or identify the gap magnitude.
• Agree a prioritized list of corrective actions with resolution windows to close identified gaps.
• Verify security signals are within acceptable bounds or record emergency remediations required.
• Create a prioritized remediation plan for funnel drop-offs and UI/SDK issues with target completion dates.
• Instrument additional monitoring for adaptive MFA challenge rate and social provider success rates.
• Open incident and high-priority backlog review
• Present outcome data and gap analysis
• Deployment and migration validation
• Root-cause diagnosis for metric gaps
• Early adoption and stability signals
• SLO and monitoring adjustments
• Security signal review
• Security and incident retrospective
• Agree corrective actions and timeline to acceptance gate
• Critical blockers and incident triage
• Shared backlog triage
• Operational housekeeping and next-quarter commitments
• Agree ongoing monitoring and escalation paths
• Incumbent system wind-down checkpoint
• Agree near-term remediation actions