CCC Digital Key 3.0 is the release that turned the phone into a passive entry device, and it is still the version most vehicle programmes in production today were built against. Version 4.0 is now published and being tested across the ecosystem, and the questions arriving at OEM and Tier 1 engineering teams are practical ones. Does moving to v4 mean a new secure element. Does it break the vehicle side. Does it reopen certification. How much of the CCC Digital Key 3.0 stack survives.
The short answer is that v4 is an interoperability release rather than an architectural reset. The trust model, the secure element applet, the public key infrastructure and the transaction flows established in CCC Digital Key 3.0 all carry forward. What changes is how reliably the system behaves across devices from different vendors, how a key moves between an iPhone and an Android phone, and how tightly Bluetooth Low Energy and ultra wideband cooperate during an approach.
That is a smaller change on paper than the jump from Release 2.0 to Release 3.0, and a larger one in programme terms than most planning documents assume, because interoperability failures surface late and they surface at the integration gate.
This article sets out what actually changed, what it costs to absorb, and how to sequence the work.
What CCC Digital Key 3.0 introduced, and why it is still the baseline
The Car Connectivity Consortium published Digital Key Release 3.0 on 13 July 2021. Release 2.0, published in May 2020, had standardised the phone as a key using near field communication and a public key infrastructure, which worked but required the driver to present the phone to a reader. Release 3.0 removed that gesture.
It did so by adding two radios to the architecture. Bluetooth Low Energy handles discovery and authentication between the vehicle and the device. Ultra wideband performs secure distance measurement, so the vehicle knows not just that an authenticated key is nearby but exactly how far away it is and roughly where. Daniel Knobloch, then CCC President, framed the outcome plainly at publication: “With Release 3, the user experience just got even better…you can leave your mobile device in your bag or pocket when approaching to unlock and start your vehicle.”
The security consequence matters more than the convenience one. Distance measurement in CCC Digital Key 3.0 is built on IEEE 802.15.4z secure ranging, which timestamps a cryptographically scrambled sequence rather than inferring proximity from signal strength. A relay attacker can amplify and forward a Bluetooth signal to make a phone in a hallway look adjacent to a car on a driveway. Forwarding a UWB ranging exchange without adding measurable time of flight is a far harder problem, which is why distance bounding became the anchor of keyless entry security rather than an optional extra.
Everything else in the architecture stayed where Release 2.0 put it. Keys live in a secure element on the device. The digital key applet inside that secure element performs the security critical processing, holds the credentials, and executes owner pairing, key sharing, key termination and key suspension. Vehicle side implementations remain proprietary to each OEM and Tier 1.
Any team that has shipped against CCC Digital Key 3.0 already owns the expensive parts: a certified secure element path, a working UWB ranging implementation on chosen silicon, an anchor placement design, and a vehicle side stack that survives a Plugfest. None of that is thrown away by version 4.
What version 4.0 changes
The CCC now offers both the V3.1.4 and the V4.0.0 specifications through its specification download page, so v4 is no longer a roadmap item. What it delivers is narrower and more specific than the version number suggests.
Version 4.0 does not introduce a new radio. It continues to build on near field communication, Bluetooth Low Energy and ultra wideband, with participating devices required to support at least one of these wireless modes. It does not replace the secure element model or the certificate hierarchy. Its stated purpose is to improve cross platform interoperability and cross version compatibility, which in engineering terms means three things.
The first is tighter coupling between Bluetooth Low Energy and ultra wideband during the approach sequence, so that the handover between BLE discovery and UWB ranging degrades gracefully when the UWB link is weak at longer distances rather than dropping the transaction.
The second is cross platform key sharing, so that an owner can pass a key to a friend or family member whose phone runs a different operating system.
The third is explicit backward compatibility, so a v4 vehicle works with a v3 device and a v4 device works with a v3 vehicle. That sounds administrative. It is the single most consequential clause in the release for anyone running a vehicle programme, because it defines the size of your test matrix for the next several years.
One point worth flagging for silicon selection: the CCC has not confirmed official support for the low rate pulse repetition mode in version 4.0. The high rate pulse mode remains the secure default the consortium defines. Teams evaluating LRP capable parts on the assumption that v4 blesses them should treat that as unconfirmed until the specification text says otherwise.
Here is the release progression in one view.
| Aspect | Release 2.0 (May 2020) | CCC Digital Key 3.0 (July 2021) | Version 4.0 (current) |
|---|---|---|---|
| Primary interaction | Tap the phone to a reader | Passive entry, phone stays in pocket or bag | Passive entry, improved reliability at range |
| Radios | NFC | NFC, BLE, UWB | NFC, BLE, UWB, at least one required per device |
| Ranging basis | None, proximity by NFC coupling | IEEE 802.15.4z secure ranging | IEEE 802.15.4z secure ranging, closer BLE and UWB coordination |
| Key storage | Secure element, applet based | Secure element, applet based | Unchanged |
| Key sharing | Within ecosystem | Within ecosystem | Across platforms, iOS to Android and back |
| Headline engineering problem | Reader integration and PKI | UWB anchor design and ranging accuracy | Interoperability across devices, vehicles and versions |
The BLE and UWB relationship is the biggest engineering change
If you strip the marketing away, the technical delta that costs the most engineering time sits in the approach sequence.
In a CCC Digital Key 3.0 implementation, Bluetooth Low Energy establishes the connection and authenticates, then ultra wideband sessions are set up to measure distance. When the UWB link is marginal, which happens at the outer edge of the approach envelope, in a car park full of metal, or with the phone deep in a coat pocket against the body, the ranging exchange can fail to produce enough good measurements. The vehicle then has an authenticated device it cannot safely locate, and the driver reaches a door that does not open.
Version 4.0 addresses this by integrating the two radios more closely, so that the overall sequence is less likely to fail when the UWB signal is weak at longer distances. For a firmware team, that is not a configuration change. It means revisiting the state machine that governs discovery, session setup, ranging round scheduling and fallback, on both the device side and the vehicle side, and re validating anchor placement against the new behaviour.
The physics constraint behind all of this is worth understanding, because it explains where the standard is heading. Current UWB ranging is limited by link budget at the distances a passive entry system wants to cover. The IEEE is addressing this in 802.15.4ab, which introduces multi millisecond packets and new data rates that together offer roughly 20 dB of link budget improvement, enough to change what range is achievable. Teams designing anchor layouts now should understand what 802.15.4ab will allow before they commit to a fixed anchor count per vehicle, because the economics of anchor placement change when range improves.
The second area to review is relay attack resistance. Any change to how BLE and UWB cooperate touches the boundary where distance bounding is enforced. A fallback path that lets the system act on BLE proximity when UWB measurements are unavailable is a convenience feature and an attack surface at the same time. The correct behaviour is to fail closed and require the driver to touch the handle or use the phone actively, not to relax the distance requirement.
Cross platform key sharing changes your backend more than your firmware
Key sharing existed in earlier releases. What version 4.0 adds is sharing that crosses ecosystems, so an owner with an iPhone can issue a key to a family member using an Android device.
Inside the secure element, sharing is already an accounted for function of the certified applet, alongside owner pairing, transactions, key termination and key suspension. The firmware change is therefore modest. The programme change is not, because cross platform sharing exercises parts of the system that most OEMs treat as separate projects.
Sharing across platforms means your key issuance backend has to speak to two device ecosystems with different provisioning flows, different attestation formats and different revocation timing. It means the owner facing app has to represent a shared key whose lifecycle it does not fully control. It means customer support needs a story for a shared key that works on one platform and fails on the other, and it means legal needs a position on what a shared key permits.
The teams that struggle here are the ones that scoped key sharing as an app feature. The ones that move quickly scoped it as a backend and lifecycle programme with an app surface on top.
Certification, the Interoperability Device List, and what gets retested
This is where the honest answer to “how much does v4 cost us” lives.
CCC certification exists to guarantee that a key from any compliant device works with any compliant vehicle. Certification runs through Authorized Test Laboratories vetted by the consortium, and it is free for CCC members with some restrictions, which means the cost is engineering time and calendar rather than lab fees.
Security certification is a separate track and a longer one. The CCC Digital Key applet is evaluated against a dedicated Common Criteria Protection Profile at EAL4 augmented with ALC_DVS.2 and AVA_VAN.5, in strict conformance mode, composed on top of a PP0084 certified integrated circuit and a PP0099 certified Java Card platform. The protection profile was authored by Red Alert Labs, with BSI Germany as certification body. Crucially, that profile covers the applet in the secure element. It does not extend to the vehicle side, which remains each manufacturer’s own responsibility, and that asymmetry is where programme risk concentrates.
The practical picture for a v3 to v4 move looks like this.
| Workstream | Certified under CCC Digital Key 3.0 | What v4 typically requires | Where it bites |
|---|---|---|---|
| Secure element and applet | Common Criteria EAL4+, composition on certified IC and Java Card platform | Carries forward. Re evaluation only if the applet itself changes | Low, unless you change SE vendor at the same time |
| Device side stack | CCC certification via Authorized Test Laboratory | New v4 test cases, plus v3 interoperability runs | Medium, driven by test matrix size |
| Vehicle side stack | Proprietary, validated at Plugfest and by the OEM | Approach sequence rework, then re validation | High, this is the main effort |
| Anchor design and RF | Vehicle specific, validated on production hardware | Re validation against new BLE and UWB coordination | Medium to high, needs production vehicles |
| Backend and key lifecycle | Ecosystem specific | Cross platform issuance, attestation and revocation | High for OEMs adding sharing |
| Interoperability evidence | v3 Interoperability Device List entries | Candidate IDL devices for v4 being identified now | Timing risk, not effort risk |
The Interoperability Device List deserves attention. At Plugfest #18, held in June 2026 at the DEKRA Lausitzring test centre in Germany, 16 organisations including Apple, BMW Group, Google, Hyundai Motor Company, JLR and Robert Bosch worked through new v4 test cases, interoperability testing between v3 and v4 devices, and identification of candidate IDL devices for v4. The event also introduced updated NFC test cases for the first time at a Plugfest, alongside Bluetooth LE sniffing techniques and both remote keyless entry and passive entry scenarios.
Alysia Johnson, President of the CCC, described it as an important step forward for v4 “as we expand testing across devices, vehicles, and supporting technologies”. Read as a programme signal, that tells you the v4 reference device population is still being assembled. If your validation plan assumes a mature IDL, check the current list before you commit the date.
One more dependency sits underneath all of this. In November 2023 the CCC and the FiRa Consortium formed the Joint UWB MAC PHY Working Group to jointly develop and maintain the UWB specifications used in the Digital Key, chaired by Apple’s Jinjing Jiang. The stated aim is long term interoperability and scalability as the underlying IEEE 802.15.4 standards evolve. For an implementer, that means UWB behaviour in Digital Key is now maintained jointly, and FiRa certification and CCC certification are converging rather than diverging. We have written separately about how FiRa and CCC are unifying digital key requirements.
What this means for programme timelines
Version 4.0 is not a reason to restart a CCC Digital Key 3.0 programme. It is a reason to change what you validate and when.
A vehicle programme already in production on CCC Digital Key 3.0 should treat v4 as a mid cycle software update with an RF revalidation attached. The specification’s backward compatibility commitment means v3 vehicles keep working with v4 devices, so there is no cliff edge. The pressure comes from the device population moving faster than the vehicle population, which is the usual pattern: phones update annually, vehicles update on a five to seven year cycle.
A programme currently in development should target v4 directly and build the v3 interoperability cases into the test plan from the start rather than adding them later. Retro fitting an interoperability matrix to a test framework designed for a single version is one of the more expensive discoveries a wireless programme can make at the integration gate.
The sequencing that works looks like this. Confirm silicon first, since HRP remains the defined secure default and LRP support in v4 is unconfirmed. Then rework the approach state machine, because it drives anchor design. Then revalidate anchors on production hardware rather than mules, because RF behaviour on a production body is not the behaviour on a development vehicle. Then run interoperability against current IDL candidates. Then submit. Teams that invert the last two steps discover conformance gaps after the submission window opens, and a failed cycle costs a quarter.
Where needCode fits
needCode builds phone and card as key passive entry to Car Connectivity Consortium Digital Key Release 3.0 and 4.0, integrating FiRa and CCC stacks on target silicon through to certification. The team works across Qorvo QM33 and QM35, NXP Trimension, Nordic nRF54, STMicroelectronics and Infineon parts, as well as legacy DW1000 and DW3000 designs, and is a certified Qorvo partner of more than eight years, a Nordic Semiconductor Design Partner for EMEA, and a UWB Alliance member. The company holds ISO/IEC 27001:2022 and ISO 9001:2015.
The work that tends to matter most on a v4 migration is the unglamorous middle: the approach state machine, the anchor revalidation on production bodies, and an interoperability test plan that covers both versions without doubling the calendar. That is the part we are usually brought in for. Our automotive and SDV practice covers digital key, secure ranging, in cabin radar and OTA as one programme rather than four.
If you are scoping a move from CCC Digital Key 3.0 to version 4.0 and want a second opinion on sequencing, book a discovery call.
Frequently asked questions
In most cases no. Version 4.0 continues to use near field communication, Bluetooth Low Energy and ultra wideband, and it does not replace the secure element architecture that Release 2.0 established and CCC Digital Key 3.0 carried forward. A device or vehicle already built to Release 3.0 with a compliant secure element and a UWB subsystem based on IEEE 802.15.4z secure ranging has the hardware foundation it needs. The exception is silicon selection for new designs. The consortium has not confirmed official low rate pulse repetition support in version 4.0, and the high rate mode remains the defined secure default, so parts chosen on an assumption of LRP blessing should be re examined. Anchor placement may also need revalidation, not because the hardware changed but because the coordination between Bluetooth and ultra wideband during the approach did.
Yes, and this is a deliberate design goal of the release rather than a side effect. Cross version compatibility is one of the stated purposes of version 4.0, and it is being actively validated. At Plugfest #18 in June 2026, interoperability testing between version 3 and version 4 devices was one of the three headline activities, explicitly described as supporting backward compatibility. For an OEM with vehicles in the field, this means there is no forced migration deadline and no cliff edge for existing owners. It also means your test matrix now has to cover four combinations rather than one: v3 device to v3 vehicle, v3 device to v4 vehicle, v4 device to v3 vehicle, and v4 device to v4 vehicle. Budget test calendar accordingly.
They answer different questions and run on different timelines. CCC certification establishes that a product interoperates correctly with the rest of the ecosystem. It is performed through Authorized Test Laboratories vetted by the consortium and is free for CCC members with some restrictions, so the cost is calendar and engineering time. Common Criteria certification establishes that the security critical component resists attack. The CCC Digital Key applet is evaluated against a dedicated Protection Profile at EAL4 augmented with ALC_DVS.2 and AVA_VAN.5 in strict conformance mode, composed on a PP0084 certified integrated circuit and a PP0099 certified Java Card platform, with BSI Germany as certification body. That security evaluation covers the applet inside the secure element. It does not cover the vehicle side implementation, which stays the manufacturer’s responsibility.
Bluetooth proximity is inferred from received signal strength, which an attacker can manipulate. A relay pair can capture the signal near a key and reproduce it near a vehicle, making a phone that is fifty metres away appear adjacent. Ultra wideband in CCC Digital Key 3.0 and later measures time of flight using IEEE 802.15.4z secure ranging, timestamping a cryptographically scrambled sequence so the measurement cannot be replayed or predicted. Because radio waves travel at a fixed speed, adding relay hardware to the path adds propagation delay that shows up directly in the distance result. The system can therefore set a distance threshold and enforce it. The design rule that follows is to fail closed: when ultra wideband measurements are unavailable, the correct behaviour is to require an active gesture from the driver rather than falling back to Bluetooth proximity alone.
The dominant variable is not firmware, it is revalidation on production hardware. The secure element and applet carry forward, and the device side stack is a test matrix problem more than a rewrite. The work that sets the schedule is reworking the approach state machine that governs Bluetooth discovery, ranging session setup and fallback, then revalidating anchor placement on production bodies rather than development mules, then running interoperability against current Interoperability Device List candidates for version 4. Because the v4 reference device population is still being assembled through the Plugfest programme, availability of certified reference devices can gate the schedule independently of your own engineering readiness. Confirm the current list before committing a date to a launch plan.
