Passkey Implementation Cost: FTE & Budget Breakdown

This document provides a detailed resource and effort estimation for the “build” scenario in a “build vs. buy” analysis for passkey integration. It is intended to be a practical follow-up to a more feature-level guide, grounding the decision-making process in concrete internal cost projections.

The transition to a fully passwordless state is best understood as a four-phase journey:

1. Integrate Passkeys: The initial technical implementation of passkeys as a new authentication method, co-existing with traditional logins.
2. Increase Passkey Adoption: A critical phase focused on driving user uptake through education, UI/UX optimizations, and incentives. High adoption is the prerequisite for realizing the full benefits of passkeys.
3. Remove Passwords: The strategic, gradual deprecation of passwords for users who have successfully adopted passkeys.
4. Automate Account Recovery: The implementation of secure, self-service recovery mechanisms for a fully passwordless environment.

This guide is primarily focused on providing detailed FTE (Full-Time Equivalent) calculations for the first two phases: integrating passkeys and driving adoption. The later sections of this document also provide detailed FTE breakdowns and strategic considerations for the subsequent phases of removing passwords and automating account recovery, presenting a comprehensive financial and resource analysis for the entire passwordless journey.

It is important to note that the estimates and approaches described in this guide aim to achieve an 80% solution in terms of feature depth and adoption precision when compared to a specialized, third-party passkey adoption platform like Corbado Connect. It is not realistic to assume that an in-house implementation can replicate the full feature set, pre-optimized user flows, and continuous A/B testing capabilities of a dedicated vendor solution without a significantly larger investment.

This report outlines the strategic plan and resource allocation for integrating FIDO2/WebAuthn-based passkeys into a large-scale platform. The primary objective is to implement passkeys as a secure, user-friendly authentication method on both the web and native mobile applications, operating in parallel with existing authentication flows like passwords and One-Time Passcodes (OTPs).

The successful execution of this initiative represents a significant investment, with a total estimated effort of 25–30 Full-Time Equivalent (FTE) months. This commitment is distributed across key functional areas, as detailed in the table below. The high-level breakdown is as follows:

• Product Management & Design: Approximately 5.5 FTE-months for research, user experience (UX) design, requirements definition, rollout strategy, and compliance coordination.

• Development (Engineering): Approximately 14 FTE-months across frontend web, native mobile (iOS and Android), and backend teams to build, integrate, and test the required features.

• Quality Assurance (QA): Approximately 8 FTE-months for comprehensive testing, including cross-platform validation, security audits, and automated test development.

The strategic value of this investment is substantial, delivering benefits across three core pillars. First, it provides a profound enhancement to security, as passkeys are inherently resistant to phishing attacks, a primary vector for account compromise in password-based systems. Second, it delivers a superior user experience by reducing login friction. The introduction of one-tap and biometric authentication can lead to measurable improvements in user conversion and long-term retention. Finally, this project future-proofs the authentication infrastructure, establishing the necessary foundation to transition towards a fully passwordless architecture, which promises to reduce the long-term operational costs and security complexities associated with password management, resets, and user support.

The analysis and estimates presented in this report are predicated on a set of foundational assumptions about the existing technical and business environment. Any deviation from these assumptions would require a significant re-evaluation of the project plan and resource allocation.

Key Assumptions:

1. Platform Scale: The target platform currently serves approximately 5 million users within a single country.

2. Existing Infrastructure: The platform operates with a mature, existing Identity Provider (IdP) or a comparable in-house authentication system. This plan assumes the integration of a well-tested WebAuthn library or open source framework rather than building the core cryptographic protocols from the ground up. The development estimates are only realistic under this “buy-the-core, build-the-experience” model; a from-scratch implementation would require an effort an order of magnitude larger, potentially spanning “months or even years”.

3. Regulatory Environment: The platform is subject to stringent security and compliance mandates, analogous to those in the finance or healthcare sectors (e.g., SOC2, ISO27001, HIPAA, Financial institution). This includes a mandatory 6-year audit log retention period* for all authentication events.

Critical Success Factors:

1. Cross-Functional Alignment: The interdependent nature of this project necessitates exceptionally tight collaboration between the Web, Native Mobile, Backend, Product, and QA teams. Siloed execution will lead to integration failures and delays.

2. Cross-Platform Testing: The project’s ultimate success is contingent upon delivering a seamless and consistent user experience across a highly fragmented ecosystem of web browsers, mobile devices, and operating systems. A comprehensive and well executed testing strategy is important.

3. Data-Driven Gradual Rollout: A phased deployment strategy, managed via feature flags and informed by robust analytics, is a core requirement to mitigate launch risk. This allows the team to monitor user adoption, identify platform-specific issues, and respond to unforeseen challenges without impacting the entire user base.

This section provides a detailed breakdown of the project into its primary workstreams. Each workstream includes its core objective, key tasks and requirements, and the estimated FTE allocation for successful delivery.

Total Effort: ~3 FTE-months (1 Dev, 2 PM)

Objective: To de-risk the project through diligent upfront investigation, prototyping, and strategic planning, ensuring the implementation is built on a solid foundation of knowledge and clear requirements.

Key Tasks & Requirements:

• Feasibility & Edge Case Research: A dedicated phase for technical leads and product managers to perform a deep dive into the WebAuthn specification and platform-specific documentation. The goal is to move beyond high-level tutorials and uncover the numerous “unknown unknowns” and edge cases inherent in a real-world implementation.

• Product & UX Design: The product team will define all user journeys, from initial registration to account recovery. This includes designing educational UI and writing clear, concise copy to explain passkeys to a mainstream audience. A core deliverable of this phase is the detailed gradual rollout strategy, defining user cohorts and success metrics for each phase.

• Technical Spike/Prototype: Development of a small-scale, throwaway proof-of-concept. This spike will validate core technical assumptions, test the integration with the existing IdP, and provide the development team with hands-on experience with the WebAuthn APIs before committing to the full-scale build.

• Compliance & Policy Planning: Collaboration with legal and compliance teams to research and document all applicable regulations. This phase also involves planning for new customer support scenarios, such as how to assist a user who has lost all their registered devices and has no password to fall back on.

Total Effort: ~8 FTE-months (5 Dev, 2 QA, 1 PM)

Objective: To implement a seamless, intuitive, and robust passkey experience on all supported desktop and mobile web browsers, ensuring graceful degradation for unsupported environments.

The frontend web implementation carries the largest single development allocation (5 FTE-months), a reflection of its complexity. This is not merely adding a new button; it involves orchestrating multiple, coexisting login flows across a diverse and often inconsistent browser landscape. The risk lies not in a single failure but in a “death by a thousand cuts” where minor UX inconsistencies across different platforms accumulate to create a confusing and frustrating user experience, ultimately hindering adoption. The success of the entire project therefore hinges disproportionately on the frontend team’s ability to master this fragmentation.

Key Tasks & Requirements:

• Registration Flows: Implementation of Passkey Creation flows designed to encourage user adoption. This includes displaying post-sign-in nudges that explain the benefits of passkeys and conditionally prompting users to create one based on their eligibility (e.g., device support, inclusion in a rollout cohort), all managed via feature flags.

• Login Flows: Development of a sophisticated, multi-faceted login experience. This requires supporting three distinct patterns:

  1. One-Tap Login: For returning users, leveraging navigator.credentials.get() with hints stored in local storage or cookies to surface a one-tap sign-in prompt.

  2. Conditional UI: For modern browsers like Chrome, using mediation: ‘conditional’ to allow the browser to automatically prompt for a passkey without requiring any user interaction.

  3. Identifier-First Flow: As a primary interaction model, the user enters their email/username first. The system then attempts to determine if a passkey is available for that user on the current device. However, prompting for a passkey login when there are no passkeys accessible on the device can easily lead to user dead-ends. In these cases, the browser or OS may display a QR code for “use another device”—but if the user doesn’t have a passkey anywhere, this QR code is unsolvable and the flow stalls. To avoid this, the system must be careful not to trigger a passkey prompt unless there is a high likelihood that the user actually has a passkey available, and must always provide a clear fallback to password entry to prevent trapping users in an unsolvable state.

• Passkey Management UI: Construction of a dedicated “Manage Passkeys” section within the user’s account settings. This interface will allow users to view their registered passkeys, add new ones, and securely delete existing ones, with each action triggering the appropriate WebAuthn ceremony.

• Cross-Browser Compatibility: Ensuring full functionality and a consistent experience across all target browsers: Chrome, Safari, Firefox, Edge, and Samsung Internet. This demands a progressive enhancement strategy, where features like Conditional UI are used when available, and a standard “Sign in with Passkey” button is not enough.

• IdP Integration: Close collaboration with the backend team to integrate the frontend components with the server-side IdP. This involves handling the asynchronous challenge-response lifecycle of the WebAuthn protocol, sending credential data for verification, and managing session creation upon successful authentication.

Total Effort: ~7 FTE-months (4 Dev, 2 QA, 1 PM)

Objective: To deliver a native, performant, and consistent passkey experience within the iOS and Android applications that feels integral to each platform.

The mobile implementation should be viewed not as a single workstream but as two distinct, parallel projects. The 4 FTE-months of development effort are realistically divided into 2 months for iOS and 2 months for Android. The iOS ecosystem is relatively controlled, centered around Apple’s AuthenticationServices framework and iCloud Keychain for passkey synchronization. In contrast, the Android ecosystem is highly fragmented. Developers must contend with the Android Credential Manager API, OEM-specific implementations like Samsung Pass, and a variety of third-party password managers (e.g., 1Password, Dashlane) that can act as passkey providers. This fragmentation significantly increases the complexity and risk on the Android side, demanding a more extensive QA cycle.

Key Tasks & Requirements:

• iOS Integration: Leveraging the native ASAuthorizationPlatformPublicKeyCredentialProvider APIs on iOS 16+ for passkey registration and authentication. A critical task is the correct configuration of Associated Domains (AASA), which enables seamless credential sharing between the website and the native app (e.g., a passkey created in Safari on macOS is automatically available in the iOS app).

• Android Integration: Utilizing the modern Android Credential Manager Jetpack library to unify passkey and password flows. The implementation must account for and be tested against OEM-specific UI variations from manufacturers like Samsung and Xiaomi. Unlike the web, Android apps do not currently support Conditional UI, necessitating the use of an explicit “Sign in with Passkey” button.

• Cross-Platform Consistency: Ensuring that passkeys created on one platform are seamlessly available on others through their respective cloud synchronization services (iCloud Keychain for Apple devices, Google Password Manager for Android/Chrome). This includes testing cross-device authentication flows, such as using a phone to sign into a desktop browser via a QR code scan.

• UX & Fallbacks: Designing clear, non-intrusive UI elements that offer passkeys as a convenient option without creating dead ends. The applications must gracefully handle all error conditions, such as a user canceling a biometric prompt or a device lacking biometric capabilities, by always providing a fallback path to the traditional password login.

Total Effort: ~5 FTE-months (3 Dev, 1 QA/Sec, 1 PM/Comp)

Objective: To build the secure, scalable, and compliant server-side infrastructure required to support all passkey registration, authentication, and management operations.

The backend workstream is the security and compliance backbone of the project. A particularly critical requirement is the 6-year audit log retention period, mandated by the platform’s regulatory environment. This is not a simple feature but a multi-year financial and architectural commitment. A conservative estimate for a platform with 5 million users suggests a significant data volume.

This volume of data necessitates more than just cheap archival storage. It requires a robust, scalable logging pipeline capable of ingesting, indexing, securing, and making this data searchable for audits. The associated cloud service, data engineering, and operational costs represent a long-tail financial liability that extends for years beyond the project’s initial launch. The backend architecture must be designed from day one to handle this requirement in a cost-effective manner.

Key Tasks & Requirements:

• WebAuthn Server Endpoints: Development of the core API endpoints to manage the WebAuthn ceremony. This includes four key server-side operations: generating a registration challenge, verifying a new credential; and generating an authentication challenge, verifying a login assertion.

• Database & IdP Integration: Extending the existing user database schema to support a one-to-many relationship between users and passkey credentials. This involves storing the public key, credential ID, and a signature counter for replay attack prevention. The login logic must be updated to issue a valid session token upon successful passkey authentication.

• Security & Compliance: Implementation of essential security controls, including rate limiting on authentication endpoints. The central task is the creation of a comprehensive audit logging system that records every passkey-related event (registration, login, success, failure) with sufficient detail (UserID, timestamp, device info) to satisfy auditors. This system must enforce the 6-year retention policy.

• Analytics & Monitoring: Instrumenting the backend with detailed event tracking for all passkey operations. This data will feed into analytics dashboards, providing the product team with critical insights into adoption rates, success/failure trends by platform, and user behavior, which is essential for managing the gradual rollout.

• Penetration Testing & Audits: Scheduling and executing a formal security review, including penetration testing and threat modeling of the new authentication flows, before any public launch. This is a mandatory step to identify and remediate potential logic flaws or vulnerabilities.

Total Effort: ~4.5 FTE-months (3 QA, 1 Dev Support, 0.5 PM/User Testing)

Objective: To guarantee a high-quality, secure, accessible, and bug-free user experience across the vast and fragmented landscape of user devices and platforms.

Key Tasks & Requirements:

• Cross-Platform Matrix Testing: Execution of a comprehensive test plan against a detailed matrix of supported environments. This includes the latest and older supported versions of Chrome, Safari, Firefox, and Edge on desktop, as well as top mobile devices from Apple, Google, and Samsung. A key part of this is testing with popular third-party password managers like 1Password and Dashlane, especially on Android where they can act as the primary credential provider.

• Edge Case & Failure Scenario Testing: Systematic validation of non-happy-path scenarios. This includes testing user cancellations at every stage of the flow, network errors, API timeouts, and ensuring the UI provides clear, helpful error messages in every case.

• Security Testing: In addition to the formal penetration test, the QA team will conduct its own security-focused testing. This includes attempting to bypass security controls, testing for replay attacks by re-submitting old assertions, and verifying that origin-binding is correctly enforced by the browser and server.

• Usability & Accessibility Testing: Conducting formal usability testing sessions with real users to gather feedback on the clarity of the UI, the effectiveness of the educational copy, and the overall user journey. The implementation must also be tested for accessibility compliance to ensure it is usable by individuals with disabilities, for example, via screen readers.

Total Effort: ~1.5+ FTE/year (0.5 Dev, 1 QA, 0.5 PM)

Objective: To manage the controlled release of the passkey feature to the entire user base and to ensure its long-term operational health, security, and continuous improvement.

Key Tasks & Requirements:

• Gradual Rollout Management: Active management of the feature flag configuration to execute the phased rollout. This will likely start with a small cohort (e.g., 5% of users on iOS 17 and latest Chrome) and gradually ramp up as the team gains confidence from monitoring key metrics.

• Monitoring & Analytics: Continuous, real-time monitoring of the analytics dashboards established during development. The team will track adoption rates, login success vs. failure rates (segmented by platform, browser, and OS version), and system performance metrics.

• User Support & Documentation: Training customer support teams on the new feature and equipping them with scripts to handle common user questions and issues. This also includes creating and maintaining comprehensive public-facing FAQs and help documentation.

• Ongoing Maintenance: Budgeting for the ongoing effort required to maintain the feature. This is a critical, non-trivial component of a “build” approach that involves continuously adapting to a rapidly evolving ecosystem. Key activities include:

  • Proactive Re-testing: Continuously re-testing the implementation against new operating system releases (e.g., iOS 26) and browser updates to catch breaking changes.

  • New Functionality Adoption: Integrating new WebAuthn features as they become available to maintain a modern user experience (e.g., Windows synched passkeys, the WebAuthn Signal API).

  • OEM and Third-Party Bug Mitigation: Actively monitoring for and developing workarounds for platform-specific issues, such as bugs introduced in specific OS updates (e.g., iOS 17.4 creation bug), OEM software releases (e.g., Vivo June release), or third-party password managers.

  • Metadata Management: Regularly updating the internal AAGUID list and associated authenticator icons to ensure new passkey providers are correctly identified and displayed.

  • Log Monitoring and Analysis: Continuously monitoring log files from both web and native applications to identify and troubleshoot buggy environments and failed login patterns.

  • Standard Evolution: Following the weekly evolution of the WebAuthn standard to anticipate future changes and deprecations. The official W3C WebAuthn GitHub repository is a critical resource for this: https://github.com/w3c/webauthn/issues

To optimize resource utilization and manage project risk effectively, a phased approach to execution is recommended. This strategy aligns team focus with the evolving needs of the project lifecycle.

• Phase 1: Foundation (Months 1-2): This initial phase is dedicated to building the project’s cornerstone. The focus will be on Backend API development, database schema design, and the setup of the logging infrastructure. In parallel, the Product and Design teams will finalize all user journeys and UI mockups, while technical leads conduct spikes to resolve any remaining unknowns. The core team will consist of Backend engineers, Product Managers, and senior architects/tech leads.

• Phase 2: Feature Development (Months 3-7): This is the primary build phase, with parallel development tracks for Web, iOS, and Android. The team composition will scale to its maximum size, with full allocation of Frontend, Mobile, and Backend developers. The QA team will begin building out the comprehensive test plan and developing automated tests during this phase.

• Phase 3: Integration & Testing (Months 8-10): The focus shifts from feature creation to stabilization and hardening. This phase is dominated by end-to-end testing, intensive bug fixing, performance tuning, and the execution of the formal security audit. The team will be heavily weighted towards QA engineers, with developers providing support to resolve issues identified during testing.

• Phase 4: Rollout & Monitoring (Months 11-12+): This final phase covers the live deployment of the feature. The Product Manager will lead the execution of the gradual rollout plan, closely monitoring analytics dashboards for any anomalies. A core team of SRE/Ops, developers, and product personnel will be on hand to monitor system health and provide rapid response to any production issues.

The following table outlines the most significant risks identified for this project, along with their potential impact and recommended mitigation strategies.

The successful completion of this project should not be viewed as an endpoint, but rather as a critical first step on the strategic path toward a fully passwordless future. The infrastructure, user education, and organizational experience gained will create the opportunity to fundamentally transform the platform’s security posture and user experience.

By achieving significant user adoption of passkeys, the organization can begin to strategically deprecate passwords. The following sections provide a detailed breakdown of the effort required for the subsequent phases of this journey.

Total Effort: ~9 FTE-months (1.5 PM/Analytics, 6 Dev, 1.5 QA)

With a critical mass of users enrolled in passkeys, this phase focuses on gradually phasing out passwords. The process is carefully orchestrated to ensure a seamless transition for users who have adopted passkeys, guided by robust analytics, controlled by feature flags, and safeguarded by well-designed fallback options.

Key Tasks & Requirements:

• Instrumentation & Analytics for Login Flows: Implement full instrumentation of all login events to capture detailed telemetry on every authentication attempt. This includes tracking success/failure rates, fallback usage, error codes, and funnel metrics to pinpoint drop-off points. This data enables the calculation of core metrics like the Passkey Login Rate, which directly reflects adoption and correlates with reduced support overhead.

• Dashboards & Real-Time Telemetry: Develop product dashboards to visualize adoption KPIs and system health in real time. These dashboards will display passkey vs. password login trends, fallback usage, and error distributions. Real-time alerts will be configured for critical anomalies, guiding go/no-go decisions for expanding the passwordless rollout to new user cohorts.

• Gradual Rollout via Feature Flags: Implement a per-user “passwordless” flag to disable password login for specific accounts, enforcing passkey-only authentication. The rollout will begin with small, highly-engaged cohorts and expand based on data-driven thresholds. A global “kill-switch” will also be implemented to re-enable password login for all users as a critical safety mechanism in case of unforeseen issues.

• Continuous Monitoring & Automated Policy Evolution: Establish automated processes to continuously evaluate KPIs against predefined thresholds. These systems can automatically flag users or cohorts as ready for password removal, adapting the rollout pace based on live performance data. This ensures the journey to passwordless is data-driven and responsive.

• User Experience & Fallback Safeguards: Design and implement clear fallback paths for users who are unable to use their passkey. The UI will provide a discreet “Trouble signing in?” link that could trigger a one-time recovery flow (e.g., magic link) or direct the user to support. This ensures no user is ever completely locked out, maintaining trust in the system.

• QA & Testing for Cohorts and Edge Cases: Develop a comprehensive QA plan for testing accounts in various states (e.g., password-only, password+passkey, passkey-only). Testing will be conducted across a matrix of real devices and clients to validate cohort-based rollouts and ensure fallback flows trigger correctly under all edge-case scenarios.

Total Effort: ~4 FTE-months (1 PM/Compliance, 2 Dev, 1 QA)

In the final phase, the platform achieves a fully passwordless ecosystem by providing robust, automated account recovery methods. This phase emphasizes the integration of proven, third-party identity verification services to replace traditional password resets, ensuring users can securely regain access without reintroducing password-related vulnerabilities. The total effort for this phase is highly dependent on the chosen development stream and vendor complexity.

Key Tasks & Requirements:

• Third-Party Recovery Methods Integration: Integrate with high-assurance identity verification providers to implement modern recovery workflows. This typically involves government ID scanning and selfie biometrics with liveness detection to provide a strong, phishing-resistant proof of identity.

• Modular, Vendor-Agnostic Architecture: Design the recovery system with a modular architecture to avoid vendor lock-in. An internal service interface will abstract the verification flow, allowing the platform to switch between different identity verification vendors with minimal engineering effort.

• Mobile-First UX with High Assurance & Accessibility: Design a mobile-first user experience for the recovery process, as most users will use a smartphone camera for ID scanning. The flow will be optimized for small screens with clear instructions, real-time feedback, and accessibility features to support all users.

• Compliance and Audit Logging: Ensure all recovery processes and data handling comply with relevant regulations (e.g., HIPAA). Every recovery attempt will generate a detailed, immutable audit trail for security and compliance purposes, with strict data retention policies.

• Effort and Integration Strategy: Focus effort on vendor evaluation, API/SDK integration, and UX orchestration rather than building identity verification technology in-house. This includes prototyping with multiple vendors, building the integration glue code, and training customer support on the new, secure recovery processes.

The FTE estimates and strategic roadmap presented in this document represent a best-effort estimation based on extensive experience with large-scale passkey deployments. It is important to recognize that the actual effort may differ based on the specific complexity, scale, and technical debt of your current setup.

However, the core building blocks outlined—from foundational research and multi-platform implementation to a data-driven adoption strategy and secure, passwordless recovery—represent the most critical components required for a successful transition. By addressing each of these phases thoughtfully, an organization can effectively navigate the journey to a more secure, user-friendly, and cost-effective passwordless future.