Chery rolled digital car keys out across 20 production vehicle models on every major standard and every mainstream Mobile OEM — with 3 million digital keys issued to date.
Chery's starting point for digital car keys was clear from day one: not a single flagship-vehicle demo, but a feature that works across the entire lineup, on every mainstream phone, with no dependency on a specific hardware vendor.
The hard part was never "can a phone unlock the door." It was that the in-vehicle hardware, the phone wallet, the wireless protocols, the security standards, the assembly-line provisioning, the aftermarket operations, and the vehicle OTA pipeline all had to come together at once. If any one link in that chain stayed broken, digital keys would never leave the prototype stage.
Chery chose the most uncompromising path — no phased rollout, no flagship-vehicle approach. Every model in the lineup would support every major standard and every phone brand from launch. No Chinese automaker had taken this approach to digital car keys before.
CCC, ICCOA, and ICCE each define their own security model and cryptographic system. The Apple ecosystem requires CCC plus MFi; mainstream Android OEMs align around ICCOA and ICCE; and automakers still ship BLE-based proprietary key systems of their own. Covering the full phone install base means supporting all of these in parallel — but the certificate hierarchies, key systems, applets, and certification flows are entirely distinct, so nothing reuses cleanly.
NFC handles tap-to-unlock at close range, BLE handles connection, wake-up, and data transfer, and UWB handles secure ranging. Each has its own integration profile on the vehicle and the phone — and they have to operate as a single coherent system in the same product.
Apple manages its own security domains and runs its own MFi certification. Android OEMs each maintain independent wallet stacks. Digital keys only become a standard automaker offering when they cover every mainstream phone, not just a subset.
Chery's vehicle lineup uses different SE, MCU, and ECU combinations across Tier 1 suppliers, and OTA cadences are not aligned. If every model started from zero, digital keys would stay project-bound — never a reusable platform capability.
CCC and ICCOA are anchored on certificate-chain trust; ICCE is anchored on symmetric keys. The two cryptographic models would normally be built and operated separately. OnBoard consolidates them into a single security infrastructure: PKI manages the full certificate chain from Root CA down to the vehicle and phone, KMS manages ICCE key generation and distribution, and all key material stays within the hardware boundary of an HSM (FIPS 140-3 Level 3). The infrastructure is shared — adding a new standard extends the existing stack instead of rebuilding it.
OnBoard delivered end-to-end onboarding into Apple Wallet and every mainstream Android Mobile OEM Wallet, including the SE applet and SDK deliverables for CCC, ICCOA, and ICCE. Apple requires MFi certification; each Android OEM has its own onboarding pipeline. OnBoard already had relationships on both sides and ran the two tracks in parallel, so Chery's engineering bandwidth wasn't consumed by certification cycles. The BLE path was tuned per device for antenna characteristics, so passive-entry behavior stays consistent across the lineup in production.
Chery's vehicles ship with different SE chips and different combinations of supported standards. OnBoard developed the SE applets for each standard independently and then built a cross-chip reuse model on top: matching chip-and-standard combinations drop straight onto a validated applet, and per-vehicle differences are handled as incremental configuration on a known baseline. The MCU layer carries embedded integration and bring-up across the lineup. Digital-key updates are not pushed as standalone packages — they ride the vehicle OTA train via the SEMS offline path (SCP 11C scripts), on the same cadence as the rest of the vehicle.
Digital-key capability ultimately has to be written into every car as it leaves the line. SEMS manages the lifecycle of security domains and applets on the in-vehicle SE, and provisions keys, certificates, and applets at production cadence. Every write is traceable; every result is auditable. This is the last gate between "digital key as a feature" and "digital key in mass production" — and the direct reason Chery can ship the capability across the entire lineup, vehicle after vehicle.
The Chery digital car key now runs in steady-state across 20 production vehicle models, with 3 million digital key credentials issued to date. Standard support, mobile OEM onboarding, and security infrastructure are consolidated at the platform layer — bringing a new vehicle online no longer starts from zero.