Overview
Multi-Factor Authentication (MFA) adds an extra layer of security to user wallets by requiring users to verify their identity through a secondary authentication method.TOTP
Time-based codes from authenticator apps like Google Authenticator, Authy, or 1Password
SMS
Verification codes sent via text message to the user’s phone
Passkey
Biometric or device authentication (Face ID, Touch ID, security keys) via WebAuthn. Web only.
Passkey MFA is supported in web environments only. TOTP and SMS work across all platforms.
How it works
1
Enrollment
- Authenticator app: User scans a QR code and registers the app in their authenticator app
- Text message: User provides their phone number in E.164 format (e.g.,
+14155552671) - Passkey: User completes a single browser prompt (Face ID, Touch ID, or security key); no code to enter
2
Verification
- Authenticator app: User confirms by entering a 6-digit code
- Text message: User confirms by entering a 6-digit code sent via SMS
- Passkey: User confirms with a single browser prompt
3
Future authentication
- Authenticator app: User provides a 6-digit code for sensitive operations
- Text message: User receives a new 6-digit code via SMS for sensitive operations
- Passkey: User re-confirms with a browser prompt for sensitive operations
Users must be authenticated (signed in) before they can enroll in MFA. Users can enroll in multiple methods (TOTP, SMS, and passkey) for maximum flexibility, and can register more than one passkey.
Configuration
Configure which MFA methods (TOTP, SMS, or passkey) are available for your project in the CDP Portal. You can update these settings at any time; changes apply to new enrollments only and don’t affect users who are already enrolled.Passkey has one prerequisite: the origin your app runs on must be one of the project’s configured CORS origins, and each passkey is scoped to that exact host. See Passkeys for details.
For TOTP and SMS, portal settings only control what the pre-built components display. If you’re using hooks or the Core SDK directly, you can initiate enrollment for either method regardless of portal configuration. Passkey is the exception: enrollment is rejected while passkey is off for the project.
MFA-protected operations
The following actions automatically trigger MFA verification when the user is enrolled:EVM
EVM
signEvmHashsignEvmTypedDatasignEvmMessagesignEvmTransactionsendEvmTransactionsendUserOperationcreateEvmKeyExportIframe
Solana
Solana
signSolanaMessagesignSolanaTransactionsendSolanaTransactioncreateSolanaKeyExportIframe
MFA session behavior
After a user successfully verifies MFA, their verified session is cached so they are not re-prompted for every protected operation. How this session is scoped depends on your authentication method:Custom authentication
Custom authentication
MFA sessions are scoped to the user identity. This means:
- A single MFA verification satisfies all active sessions for that user
- Verifying in one client satisfies MFA for all clients using the same user identity
- This matches the custom authentication model where you control your own token lifecycle
Supported authenticator apps
Any TOTP-compatible authenticator app works. These are commonly used:Quickstart
If you’re using@coinbase/cdp-react, use the pre-built enrollment component to let users enable MFA:
- Detecting when MFA verification is needed
- Showing the verification modal
- Completing the operation after successful verification
What to read next
Enrollment
Set up MFA for your users with pre-built components or custom UI
MFA Prompts
Handle MFA prompts for sensitive operations
Passkeys
Enable passkey MFA and use the passkey SDK surface
Customizing Triggers
Learn what triggers MFA and how to customize behavior
Best Practices
Security recommendations and UX considerations