Español 
English 
Yes, they can support both cryptocurrency wallet signing and FIDO2 authentication. As long as they have sufficient storage space, the necessary cryptographic algorithms, an appropriate FIDO2 transmission mechanism, and a lifecycle architecture that keeps the two applications independent, a Java Card crypto card can fully support both cryptocurrency wallet signatures and FIDO2 authentication on the same secure element. For cryptocurrency use cases, we offer Java Card solutions (such as the J3R180 and J3R452 Java Cards) that support ECC, wallet functionality, and FIDO/FIDO2 capabilities.
Therefore, engineering teams need to consider more than whether these two functions can fit on a single card. They also need to ensure that both functions can coexist throughout the card’s lifecycle, maintain proper isolation, communicate through the necessary interfaces, and remain securely managed.
Wallet Signatures and FIDO2 Can Coexist, but Should Remain in Separate Security Domains
Wallet applications and FIDO2 authenticators perform similar underlying operations—both protect private keys and generate cryptographic signatures—but they rely on fundamentally different trust models.
Cryptocurrency wallets sign blockchain transactions. Private keys represent control over digital assets; therefore, the signing process must adhere to the wallet’s transaction rules, blockchain algorithms, and user authorization policies.
FIDO2 operates differently. FIDO2 combines WebAuthn and Client-to-CTAP. The authenticator creates public-key credentials for an online service and uses them for anti-phishing authentication. The FIDO Alliance has developed the CTAP2 specification for communication between the platform and external authenticators via transmission methods such as USB, NFC, and BLE.
This distinction should be reflected in the card architecture design.
| Function | Wallet Applet | FIDO2 Application |
|---|---|---|
| Main purpose | Sign blockchain transactions | Authenticate users to online services |
| Private-key scope | Blockchain account or wallet | Service-specific FIDO credential |
| Typical algorithms | secp256k1, secp256r1, Ed25519 depending on ecosystem | Algorithms allowed by the FIDO implementation |
| Key usage | Transaction signing | Authentication challenge signing |
| Credential lifecycle | Wallet creation, backup policy, account use | Registration, authentication, credential deletion |
Even if applications share the same chip, credentials should be isolated from one another
FIDO2-enabled cryptographic cards should not allow FIDO apps to access wallet private keys, and wallet apps should not be able to read FIDO credentials. Java Card technology provides a robust foundation for this architecture. The Java Card runtime environment requires isolation between applets and enforces an applet firewall mechanism; unless an explicit sharing mechanism is provided, objects belonging to one applet are generally inaccessible to another applet.
In practical applications, teams treat these two applications as independent security workloads:
Wallet applet → Wallet keys → Blockchain signing policy
FIDO2 Mini-Program → FIDO Credentials → Authentication Policy
Although they may share the same secure processor and hardware cryptographic engine, the sensitive objects within them should remain logically independent. This distinction matters because securely supporting both applications is fundamentally different from placing two CAP files on the same Java Card.
The Real Design Constraint: Java Card Crypto Card Resources and Interface Support
Once a coexistence mechanism is established, the next question is whether the target Java Card has enough resources to run both applications reliably.
No hard-and-fast rules exist, such as “FIDO2 requires an additional 30 KB of space”; memory usage depends on the specific implementation. A FIDO2-enabled smart card may require additional storage space to accommodate the FIDO applet itself, attestation material, credential metadata, PIN codes or user authentication status, and various credentials stored on the authenticator. Meanwhile, a wallet application may include multiple blockchain applets, HD wallet functionality, certificates, transaction strategies, or additional cryptographic libraries.
Estimating Required Memory Based on a Fully Loaded Java Card Crypto Card Configuration
Regarding available memory, we need to assess:
How much storage capacity remains after installing, initializing, and personalizing the e-wallet signature and FIDO2 authentication?
This estimate should cover the following:
- Wallet applet code and wallet-related data;
- FIDO2 application code and authentication data;
- Private keys and certificates;
- GlobalPlatform and security management data;
- Space reserved for future credentials or application updates.
For consumer-facing cards that support only a small number of wallet applications and FIDO credentials, the J3R180 offers a cost-effective Java Card solution with 180 KB of EEPROM. For more complex enterprise-level configurations, the J3R452 is a suitable choice, offering approximately 450 KB of application storage, broader cryptographic support, and the ability to run multiple applications.
If you can manage application resource consumption effectively, a smaller-capacity card may be sufficient; however, if a project involves multiple wallet functions, FIDO2, additional authentication applications, or future post-issuance feature expansions, a higher-capacity platform offers more value.
FIDO2 Also Requires the Correct Communication Path
This is one of the most easily overlooked points.
Although a Java smart card may contain the cryptographic logic required for FIDO authentication, that doesn’t mean the finished card automatically becomes a usable FIDO2 authenticator. The CTAP2 specification defines communication with external authenticators via transmission methods such as USB, NFC, or BLE.
Therefore, NFC technology is particularly critical for card-based products. With the complete FIDO2 protocol stack and host integration in place, a dual-interface Java smart card can use its ISO/IEC 14443 contactless interface for NFC-based authentication.
Never assume that traditional contact-based smart card interfaces inherently support native FIDO2 interoperability. Teams must comprehensively validate the entire product architecture, including the card, card reader or NFC interface, host software, CTAP implementation, and WebAuthn environment.
This distinction helps avoid a common misconception:
A FIDO-compliant secure element ≠ a finished product that automatically supports FIDO2 functionality.
Wallet Signing and FIDO2 Must Remain Separate During Daily Use and Updates
Java Card crypto cards can support both wallet signing and FIDO2 authentication, but these two functions must remain separate throughout the card’s entire lifecycle.
This separation should extend beyond private key storage. Teams should also establish clear rules for the applet and FIDO2 application covering personalization, credential creation, updates, deletion, and recovery. Changes to the FIDO2 application should not render the blockchain wallet inoperable, and updates to wallet functionality should not leak or overwrite FIDO credentials. Therefore, for production-grade cards, teams should evaluate these two applications as independent security workloads running on the same secure element.
A viable design should ensure that the following four aspects remain independent:
| Area | Wallet Function | FIDO2 Function |
|---|---|---|
| Credentials | Blockchain private keys | FIDO credentials |
| Authorization | Transaction approval | User authentication |
| Application data | Wallet/account data | Relying-party credential data |
| Update process | Wallet applet management | FIDO2 applet management |
Java Card Cryptographic Card That Supports Both Functions
Yes. Java Card crypto card can support both wallet signing and FIDO2 authentication on the same secure element.
Support for both wallet signing and FIDO2 authentication is possible when the following four conditions are met:
Applications and credentials are mutually independent → Sufficient storage space and encryption capabilities are available → A valid FIDO2 transmission mechanism is supported → Controlled application lifecycle management is in place
Although wallet private keys and FIDO credentials share the same secure hardware, they must remain mutually isolated. Assess storage space requirements based on the fully loaded configuration, not just the applet file size.