JavaCard vs MULTOS

JavaCard vs MULTOS

JavaCard and MULTOS are the two principal open multi-application smart card platforms. Both support loading and running multiple applications in isolated security domains on the same chip. They compete most directly in high-security, multi-application scenarios such as banking, government identity, and payment cards.

Overview

JavaCardJavaCardSoftwareJava applet platform for smart cards.Click to view → uses a Java bytecode virtual machine (JCVM) on the card. Applets are written in a subset of Java, compiled to bytecode, converted to JavaCard CAP files, and loaded via GlobalPlatformGlobalPlatformSoftwareCard application management standard.Click to view → secure channel. JavaCard is governed by Oracle (specification) and GlobalPlatform (lifecycle management). It is the dominant multi-application platform globally — most EMVEMVApplicationGlobal chip payment card standard.Click to view → payment cards, SIMSIMApplicationSmart card for mobile network authentication.Click to view → cards, and government eIDeIDIdentityNational ID with embedded chip.Click to view → cards run JavaCard.

MULTOSMULTOSSoftwareHigh-security multi-app card OS.Click to view → (Multi-application Operating System) uses a MULTOS Executive and supports multiple application languages: MEL (MULTOS Executable Language, a low-level bytecode), and optionally C or Java via certified compilers. MULTOS is governed by MULTOS International. Applications are loaded via MULTOS ALU (Application Load Unit) signed by the MULTOS CA — no application can be loaded without MULTOS CA authorization, providing stronger supply chain control than GlobalPlatform's open loading model. MULTOS has strong adoption in UK and European banking card programs.

Key Differences

• Platform VM: Java bytecode / JCVM (JavaCard) vs. MEL bytecode / MULTOS Executive (MULTOS)
• Governance: Oracle spec + GlobalPlatform (JavaCard) vs. MULTOS International (MULTOS)
• Application loading authorization: GlobalPlatform security domain with issuer keys (JavaCard) vs. MULTOS CA-signed ALU required (MULTOS)
• Language support: Java subset (JavaCard); MEL, C, Java-to-MEL (MULTOS)
• Security certification: JavaCard chips — CC EAL4–6+; MULTOS — historically strong CC EAL4-5+ focus
• Market share: JavaCard — dominant globally (EMV, SIM, eID); MULTOS — strong in UK/EU banking, niche elsewhere
• Application ecosystem: JavaCard — thousands of certified applets from hundreds of vendors; MULTOS — smaller but curated ecosystem
• Multi-app isolation: Both provide hardware-enforced application firewall

Use Cases

JavaCard is the default for: - EMV payment cards (virtually all) - SIM/eSIMeSIMApplicationProgrammable embedded SIM chip.Click to view → (ETSI mandates JavaCard-compatible platform) - Government eID and PIVPIVIdentityUS federal identity card standard.Click to view →/CACCACIdentityUS DoD identification smart card.Click to view → - Transit cards requiring contact or dual-interface - Any deployment requiring access to the large global JavaCard applet ecosystem

MULTOS is preferred for: - UK bank card programs that historically standardized on MULTOS (Barclays, HSBC legacy programs) - High-security banking deployments where MULTOS CA application authorization is a security feature - Deployments prioritizing MEL-level performance (MEL bytecode executes faster than JCVM bytecode for some operations)

Verdict

JavaCard is the safe default for new deployments due to its dominant market position, larger applet ecosystem, and ubiquitous toolchain support. MULTOS offers a genuine security advantage in its CA-controlled application loading model, which prevents unauthorized applets from being loaded even if the card's security domain keys are compromised. For UK financial institutions with existing MULTOS programs, continuity makes sense. For new deployments globally, JavaCard's ecosystem breadth and standards compliance make it the logical choice unless MULTOS's specific security model addresses a documented threat scenario.