JavaCard applet deployment: from approved CAP file to field credential
JavaCard applet deployment is the controlled path that turns a finished, approved CAP file into working credentials in the field. The chip’s initial keys are replaced, the applet is loaded and installed over a GlobalPlatform secure channel, each card or device is personalised under HSM-held keys, its lifecycle is locked down, and it stays manageable after issuance.
Development ends at the CAP file. Deployment starts there.
Development produces a signed CAP file, its source, a functional specification and tests. Deployment answers a different question: how does that release reach thousands of chips without exposing issuer keys, and how is it managed once those chips are in users’ hands?
| If your question is… | Start here |
|---|---|
| Which applets already exist, and what do they do? | JavaCard Applets — the applet portfolio, platform specifications and form factors. |
| Can you write an applet to our specification? | JavaCard development service — requirements, design, code, tests, CAP delivery. |
| How does Java Card itself work? | JavaCard technology — the JCRE, CAP files, the applet lifecycle and memory model. |
| How is a personalisation line run? | Smart-card personalisation — the facility, throughput, key custody and issuance manifest. |
| How do approved applets reach field credentials and stay manageable? | This page. |
The deployment path, step by step
- Freeze the release. The CAP file, its package and applet AIDs and its install parameters are fixed and approved before anything touches a production chip.
- Replace the initial keys. A fresh secure element arrives with default or initial keys in its Issuer Security Domain. The first SCP03 session replaces them with the issuer’s diversified keys (PUT KEY, new key version), generated and wrapped inside an HSM. Read the key information back to confirm the replacement before the chip moves on.
- Load and install. Over the authenticated channel the CAP file is loaded (INSTALL [for load] then LOAD), an applet instance is created with its install parameters (INSTALL [for install]), and the instance is made selectable by AID. Several applets can share one chip, isolated by the JavaCard firewall.
- Personalise. Per-card keys are diversified from issuer master keys inside the HSM, and per-card identity, certificates and attestation material are written under secure messaging. The personalisation script belongs to the issuer and never leaves the line in cleartext.
- Lock the lifecycle. The card is moved to its field state (normally SECURED under GlobalPlatform 2.3.1), and from then on card-content management needs an authenticated secure channel opened by a security domain that holds the right keys.
- Record what shipped. Each chip gets a load record (chip serial, applet AIDs, key version, outcome) and a row in an HSM-signed issuance manifest that the relying party can check against attestation at registration.
- Manage in the field. Key rotation and applet updates go back through SCP03 from an authorised back end, under a new key version, with the old key set removed afterwards. They never go through the application driver or the device firmware.
Where the keys live
Issuer master keys
Generated under M-of-N control inside an HSM. Diversification happens inside it; only per-card derivatives leave, wrapped for the card.
Loader station
Opens the SCP03 session and drives readers in parallel. The CAP file and key material land inside the secure element, not in a log file.
The chip
Keys are usable but not exportable. The chip enforces its own GlobalPlatform lifecycle and the applet firewall.
Host and back end
Field firmware selects the applet and asks for operations. Only an authorised back end holding security-domain keys can reopen management.
The rule that makes this work: if field firmware could open a management channel to the chip, anyone who extracted that firmware could too. Secure-channel keys stay on the line or in a back-end key service. Secure-element host integration covers the host side of that boundary.
Cards and embedded secure elements
The same path applies whether the applet ends up on an ID-1 card, a USB or NFC key, or a secure element soldered onto a device. What changes is where loading and personalisation happen:
- Cards and keys are loaded and personalised on a personalisation line, either at the AmbiSecure facility or on a customer-controlled in-country line under the customer’s HSM.
- Embedded secure elements are personalised during manufacturing, then managed for the rest of the product’s life through an authenticated management channel. Secure-element integration covers chip selection, the host driver and field rotation.
- SIM and eUICC applets are managed over the air rather than on a line. That case is covered on the Ambimat eSIM site.
Decisions to settle before the first production batch
- Applet mix and AID layout. Which applets share the chip, and which AIDs and package versions they carry.
- Key ownership. Who generates and holds the Issuer Security Domain keys and issuer master keys, and under which key-version plan.
- Where personalisation runs. At our facility, on your in-country line, or split, with pre-personalisation by us and cardholder data written in your facility.
- Post-issuance needs. Whether keys will be rotated or applets updated in the field, and which back end is authorised to do it.
- What the relying party checks. Which manifest fields (UID, AID, AAGUID, serial) it will validate against attestation at registration.
What AmbiSecure brings to a deployment
Multi-Card Applet Loader
Bulk SCP03 CAP loading across parallel readers, with per-card load logs, partial-load detection and MES integration.
Personalisation line
In-house, in-country or split personalisation with FIPS 140-2 / 140-3 Level 3 HSM custody and a signed issuance manifest.
Applet portfolio
FIDO, PIV, OpenPGP, NDEF, IoT and more, each selectable by AID, with several able to share one chip.
Custom applet development
When the applet you need does not exist yet: specification to signed CAP file.
References and tools for deployment engineers
- GlobalPlatform reference — INSTALL, LOAD, DELETE and GET STATUS, and the status words they return.
- GP status reference — card and applet lifecycle states and the transitions each allows.
- SCP03 walkthrough — session establishment and secure messaging, step by step.
- JavaCard CAP components — what is inside the file you are loading.
- APDU parser and SW1/SW2 lookup — for reading load and install traces.
- Applet development guide — the same lifecycle from the applet author’s side.
Planning a JavaCard rollout?
Tell us your chip, the applets that share it, your volumes and where personalisation must run. We will map the deployment path and the key-custody model with you.