Most explanations of the CCC Digital Key stop at the marketing layer. The phone becomes the key, the car unlocks as you walk up, everyone is happy. That description is accurate and useless to anyone who has to build it, because the interesting part of the CCC Digital Key is not any single radio. It is the choreography between three of them, a secure element on each end, and a vehicle access controller that has to make a lock or unlock decision in a few hundred milliseconds without ever trusting a signal strength reading.
This article walks the full path: how a key gets provisioned into the phone before any radio is involved, how Bluetooth Low Energy finds the vehicle and carries the authentication, how Ultra Wideband turns that authenticated session into a distance the vehicle is willing to act on, where NFC takes over when the other two cannot run, and what the vehicle side actually has to contain for any of it to work. It is written for the engineering and product teams who have to turn the specification into shipped hardware.
If you want the version history instead, the differences between releases are covered in our companion piece on CCC Digital Key 3.0 vs 4.0. This article stays on architecture.
The three radios and what each one is actually for
The first thing to correct is a common assumption that UWB replaced NFC and BLE. It did not. In the Car Connectivity Consortium Digital Key architecture each radio holds a distinct job, and a compliant implementation carries more than one of them because each one fails in a different way.
NFC is the original path. Release 1.0 and Release 2.0 were NFC only, and the phone taps a reader in the door handle or B-pillar to authenticate. Release 3.0 added the BLE and UWB combination for hands free operation while keeping NFC in the architecture. The CCC use case documentation is explicit that NFC provides battery independent access, which matters because a phone in power reserve can still complete an NFC transaction long after its Bluetooth radio has stopped.
BLE is the control plane. It handles discovery, connection, and the whole cryptographic authentication exchange. Every hands free unlock in the CCC Digital Key begins with a BLE connection, and the UWB ranging session cannot start until BLE has produced the material it needs.
UWB is the measurement plane. It does one thing: it produces a distance the vehicle can trust, using time of flight rather than signal strength. That distinction is what makes relay attacks hard, and it is the reason UWB exists in the specification at all.
| NFC | BLE | UWB | |
|---|---|---|---|
| Role in the CCC Digital Key | Tap authentication, fallback path | Discovery, connection, authentication | Secure ranging and localisation |
| Typical operating range | 0 to 4 cm | 10 to 30 m | 0 to 30 m usable for access |
| What it measures | Presence by proximity of field | Nothing trustworthy for distance | Time of flight |
| Applet routing | Direct to the secure element applet | Via the device Digital Key framework | Via the ranging subsystem, keyed from BLE |
| Works with a flat phone battery | Yes, in power reserve | No | No |
| Relay attack exposure | Very low, physical proximity required | High if used alone for distance | Low, distance bounded by physics |
| Status in Release 3.0 | Retained from earlier releases | Required for hands free | Required for hands free |
The practical reading of that table is that a vehicle programme picks a combination, not a winner. A cost sensitive trim might ship NFC plus BLE and skip UWB, accepting that hands free entry becomes a tap. A flagship ships all three.
Before any radio talks: provisioning, pairing and the secure element
A CCC Digital Key does not start life over the air at the vehicle. It starts as a credential created through the OEM backend and installed into a secure element applet on the phone.
The applet is the anchor of the whole trust model. The Common Criteria protection profile for the CCC Digital Key describes the target of evaluation as the secure element hardware, its dedicated software, the Java Card runtime, the GlobalPlatform framework and the Digital Key applet itself. That document is worth reading in full if you are on the security side of a programme, because it is the clearest public statement of what the applet is required to protect and what it is allowed to expose.
Two roles matter at provisioning time. The owner device is the phone that holds the master credential and controls all other access. Friend devices receive derived, restricted credentials. Fleet operators can replace the owner device entirely with a server held owner key, which is how rental and car sharing programmes work without a physical handover.
Owner pairing establishes the shared trust. The owner device and the vehicle generate key pairs and establish shared secrets through an initial authenticated exchange, after which the vehicle knows which public key belongs to its owner. Key sharing then works by attestation rather than by copying: the owner device creates a sharing invitation, the friend device generates a key signing request, and the owner produces an attestation package over the friend public key carrying the entitlements attached to it. Those entitlements are granular in the Car Connectivity Consortium Digital Key specification, covering time windows, trunk only access, engine disable and speed limits.
Deletion is handled with the same rigour. When a key is revoked, the applet creates a deletion attestation and the key is securely deleted before that attestation is transferred, so the backend gets cryptographic evidence that the credential is gone rather than a hopeful status flag.
On the vehicle side, the mirror of this is a second secure element. NXP’s explanation of secure elements in digital key systems is a useful reference here, including the detail that automotive secure elements in this class carry Common Criteria EAL6+ hardware certification. The end to end security property that the CCC Digital Key claims is secure element to secure element, not phone to ECU.
BLE discovery: how the vehicle and the phone find each other
Hands free operation begins with Bluetooth. The vehicle and the device discover one another over BLE advertising, establish a connection, and then run a transaction against the Digital Key applet. Everything cryptographic happens here. UWB is downstream of it.
The CCC Digital Key defines two transaction types, and understanding the difference explains most of the latency behaviour users notice.
A standard transaction is the full mutual authentication. Both sides generate ephemeral key pairs, perform a Diffie Hellman key agreement to produce a shared symmetric session key, and the vehicle signs its ephemeral public key so the device can authenticate the vehicle rather than only the other way round. The output is not one key but a set of derived secure channels, separated by purpose: one for the NFC exchange, one for the BLE exchange, and keying material for the UWB ranging session.
A fast transaction reuses what the standard transaction left behind. The device authenticates with a cryptogram computed over a secret shared during an earlier standard transaction, which removes the signature verification and the full key agreement from the critical path. This is why the first unlock after pairing feels slower than every unlock after it.
| Standard transaction | Fast transaction | |
|---|---|---|
| When it runs | First approach, or when stored context is missing or rejected | Every subsequent approach with valid stored context |
| Authentication method | Ephemeral key agreement plus vehicle signature | Cryptogram over a previously shared secret |
| Mutual authentication | Yes, full | Yes, implicitly through the shared secret |
| Relative latency | Higher, signature verification on the critical path | Lower |
| Produces new persistent context | Yes | No, consumes existing context |
| Typical user experience | Slight pause on first use | Door releases as the handle is touched |
The design consequence for a vehicle programme is that your fast transaction path is the one users will judge you on, and it is the one that has to survive a cold access ECU, a phone that has just come out of a pocket, and a Bluetooth stack that has been idle. Getting the standard transaction working in the lab is the easy half.
UWB ranging: turning an authenticated session into a trusted distance
Once BLE has authenticated the device, the vehicle activates its UWB anchors and a ranging session begins. The key material for that session comes out of the BLE exchange, which is the structural reason UWB in the CCC Digital Key cannot be attacked independently of the authentication: an attacker who cannot complete the BLE transaction never obtains valid ranging keys.
The security of the ranging itself rests on the Scrambled Timestamp Sequence defined in IEEE 802.15.4z. The STS is a sequence of uniformly spaced UWB pulses with pseudo random polarities, generated by an AES-128 deterministic random bit generator running in counter mode from a 128 bit key and a 128 bit initial value. Because the receiver knows the sequence and an attacker does not, an attacker cannot predict the waveform well enough to inject a convincing early arrival and pull the measured distance in. The academic treatment in Secure Ranging with IEEE 802.15.4z HRP UWB is the reference to read if you are evaluating a UWB subsystem, because it shows that the security property depends on receiver design and not only on the presence of STS. Earlier receivers that made their decision by simple thresholding of the channel impulse response were shown to be vulnerable to adaptive distance reduction attacks, while a correctly designed receiver bounds the false acceptance rate.
That matters commercially. A chipset datasheet that says it supports 802.15.4z STS is not by itself evidence that its ranging is attack resistant. The receiver algorithm behind the STS is the thing being bought, and it is rarely documented in a datasheet.
Anchor count determines what the vehicle can know. One anchor gives distance only. Several anchors give angle as well, which is what separates “the key is within three metres” from “the key is outside the driver door” and therefore what separates a working hands free implementation from one that unlocks when the owner walks past the boot. Interior anchors extend the same infrastructure to occupant sensing, which is why UWB investment tends to pay for more than one feature once it is in the vehicle.
Time is the other constraint. Ranging rounds are scheduled, the phone and the vehicle have to agree when to listen, and that schedule is negotiated over the BLE link. If the BLE connection is unstable, ranging does not degrade gracefully, it stops.
NFC fallback: the path that has to work when nothing else does
NFC in the CCC Digital Key is the deterministic path. It is a tap, it works at a few centimetres, and it does not depend on the phone’s application processor being awake or its main battery holding charge, because modern devices route power to the secure element and NFC front end in power reserve mode.
Architecturally NFC is also the most direct. In the protection profile model, the NFC interface is routed straight to the applet, while BLE reaches the applet indirectly through the device Digital Key framework. A shorter path through less software is part of why NFC remains the compliance baseline.
For the vehicle this means a physical design decision that cannot be undone later. The NFC reader has to be somewhere a user can find without instruction and reach with a phone in one hand, which in practice means the driver door handle, the B-pillar, or both, plus a second reader inside the cabin for start authorisation when the phone cannot be located by UWB. Programmes that treat the interior reader as optional tend to rediscover it during validation, when a tester’s phone goes flat inside a locked car.
Calling NFC a fallback describes how it is used, not its status in the specification. It is a peer method that happens to be the one users fall back to.
Vehicle integration: what the OEM actually has to build
Here is where a digital key programme stops being a protocol exercise. The vehicle side contains, at minimum:
A vehicle secure element holding the vehicle key material and running the counterpart applet. This is a supply chain decision with a long lead time and a security certification attached, so it is usually the first component locked.
An access controller that owns the decision logic. It consumes the authentication result from the BLE transaction and the distance and angle estimates from the UWB subsystem, applies the zone policy, and issues the lock, unlock or start command onto the vehicle network. Its timing budget is unforgiving because the user has already pulled the handle.
A BLE subsystem, typically one module with an antenna position chosen for coverage around the vehicle rather than for range. Coverage uniformity matters more than maximum range in a CCC Digital Key deployment, because a dead spot at the driver door is a customer complaint while an extra ten metres of range is worth nothing.
A UWB anchor set, cabled or networked to the access controller, with a time synchronisation scheme between them. Antenna delay calibration on each anchor is a production line step, not a development step, and skipping it produces systematic range bias that survives into the field.
NFC readers, exterior and interior, with the field strength and antenna tuning validated against the diversity of devices in the field rather than one reference phone.
Two integration issues are consistently underestimated. The first is 2.4 GHz coexistence: the BLE link that carries your authentication shares a band with the vehicle’s Wi-Fi, the occupants’ phones and their headsets, and a coexistence scheme that was tuned for infotainment can starve the access link at exactly the moment it matters. The second is cold start behaviour, because a vehicle that has been parked for three days has to bring up BLE, complete a transaction and run a ranging session from a low power state fast enough that the user does not reach for the handle first.
| Symptom in the field | Most likely cause | Where to look first |
|---|---|---|
| Unlock works on approach but not after a long park | Cold start wake path too slow | Access controller power states, BLE advertising interval on wake |
| Distance reads consistently long or short on one door | Antenna delay not calibrated per anchor | End of line calibration records for that anchor |
| Works on one phone model, fails on another | Device diversity in BLE timing or NFC field tuning | Interoperability test logs, device specific connection parameters |
| Hands free unlocks from the wrong side of the vehicle | Insufficient anchors for angle, or zone policy too coarse | Anchor placement and zone boundary configuration |
| Intermittent failure with occupants streaming audio | 2.4 GHz coexistence starving the access link | Packet traffic arbitration configuration, BLE connection interval |
| First unlock after pairing slow, later ones fine | Expected behaviour, standard versus fast transaction | Confirm persistent context is actually being stored |
Diagnosing most of these needs protocol visibility on both radios at once, which is why programmes that invest early in a capture setup covering BLE and UWB together find integration bugs weeks earlier than programmes that rely on vehicle logs. Our write up on what sits inside a UWB test bench covers that tooling in detail.
Certification and interoperability
Building a CCC Digital Key that works with your own phone is a milestone. Building one that works with every phone is the programme.
The CCC certification programme launched in 2023 and certified its first products in 2024, initially covering only the NFC components. In March 2025 the consortium extended certification coverage to Bluetooth LE and UWB, adding remote access, passive entry and passive start to the certifiable functionality. That programme incorporates requirements from the NFC Forum, the Bluetooth SIG and the FiRa Consortium, so a CCC Digital Key implementation inherits three other certification regimes rather than replacing them.
FiRa matters specifically for the ranging layer. FiRa Consortium UWB certification covers interoperability and secure ranging behaviour between devices from different vendors, and it is the mechanism by which a phone from one manufacturer and an anchor from another agree on how a ranging round is structured. Passing 802.15.4z conformance does not deliver that on its own.
Alongside certification sit the plugfests. At Plugfest #18 in June 2026, held at the DEKRA Lausitzring test centre, sixteen organisations including Apple, BMW Group, Google and Hyundai tested version 4 cases, backward compatibility between version 3 and version 4 devices, and candidate entries for the Interoperability Device List. Updated NFC test cases appeared at a plugfest for the first time and BLE validation used improved sniffing techniques. For a supplier, plugfest attendance is the cheapest interoperability testing available, and the gap between a device that passes conformance and one that appears on the IDL is where most programme delay accumulates.
Where needCode fits
needCode builds the embedded side of vehicle access systems, which in a CCC Digital Key programme means the parts that are hardest to outsource in pieces: the BLE and UWB firmware on the vehicle side, the integration between the access controller and the secure element, the anchor calibration and production test strategy, and the protocol capture tooling that makes the whole thing debuggable.
Relevant work sits across digital key and access development, vehicle access system engineering, relay attack prevention and UWB engineering. Teams who want the architecture in longer form before committing to a design can start with our free e-book on the smartphone as a car key, which covers the three radio model and the key lifecycle in more depth than an article allows.
If you are choosing between UWB and phase based alternatives for the ranging layer, our comparison of Channel Sounding and UWB for vehicle access sets out where each one stands today. For programmes already past architecture and into validation, end to end testing is the practical next step. Talk to us if you want a second opinion on a design already in flight.
Frequently asked questions
No. NFC alone satisfies the earlier releases and is still a valid implementation, but hands free passive entry requires the BLE and UWB pair working together. Most production programmes ship NFC plus BLE plus UWB so that the convenience feature and the fallback both exist.
Classic BLE distance estimation uses received signal strength, which an attacker can manipulate by amplifying and relaying the signal. UWB measures time of flight, so the measured distance is bounded by the speed of light and a relay cannot make the phone appear closer than it is. That property is what the CCC Digital Key relies on for relay attack resistance.
NFC continues to work while the device holds enough reserve power to energise its secure element and NFC front end, which on current phones is a window of hours after the screen goes dark. The user taps the door handle reader instead of walking up to the vehicle. This is why an interior NFC reader for start authorisation is not optional in a well designed vehicle.
Certification duration depends on how much of the stack is reused. Programmes bringing a new secure element, a new UWB subsystem and new access controller firmware together should plan for plugfest cycles across multiple events, because interoperability findings against specific phone models typically surface there rather than in conformance testing. Reusing a previously certified secure element and applet removes the longest pole.
Cross platform sharing is the direction of travel in version 4 and is handled through the backend attestation flow rather than at the radio layer, so the constraint is ecosystem support rather than protocol design. Confirm current device support with your platform partners before committing a feature date, since this is the area that has moved most in the last two years.
