Securing digital keys when your phone unlocks the car
In this interview with Help Net Security, Alysia Johnson, President of the Car Connectivity Consortium (CCC), explains how the CCC Digital Key has grown from a single-brand feature into a standard meant to work across phones, automakers, and suppliers.
She talks through what changed with Version 4, why the team focused on interoperability and testing instead of one new threat, and how NFC fallback access stays protected. She also covers fast credential revocation when a phone is lost or stolen, and how crypto agility prepares the standard for post-quantum demands over a car’s long life.
Digital car keys started as a convenience feature tied to one brand’s phones and vehicles, but the direction now is a wallet-style credential meant to travel across devices, automakers, and suppliers. From a security standpoint, what assumptions that held when a key only had to work inside one company’s own hardware no longer hold once it must work everywhere?
The main change is that trust is no longer implicit.
In a single-vendor environment, the OEM controls the entire technology stack, from the device to the vehicle and supporting infrastructure. In a multi-vendor ecosystem, trust must instead be established through standardized certification, secure hardware anchors such as secure elements, and interoperable protocols.
This shifts security from “trust your own device” to “trust any certified device” in a heterogeneous ecosystem.
From the CCC’s perspective, that’s one of the most important challenges to address in digital vehicle access. Security can no longer depend on who manufactured the device or the vehicle; it has to be consistently verifiable across the ecosystem. That’s why certification, interoperability testing, and common security requirements are foundational to the CCC Digital Key framework.
Version 3 brought ultra-wideband into the standard in 2021 to answer relay attacks against passive entry. When the working group scoped Version 4, what categories of attack did you decide v3 had left open, and which one drove the timeline hardest?
Version 3 already established a very high security baseline, particularly through the introduction of UWB-based distance bounding to address relay attacks.
When we scoped Version 4, the focus was not on addressing a major unresolved attack class. Instead, the emphasis was on improving interoperability, validation, and consistent behavior across a much broader ecosystem of devices and vehicles. As a result, the timeline was driven less by a specific new threat and more by ensuring secure, predictable operation in real-world deployments while maintaining the high security bar established in Version 3.
One reality of global standards is that security is not just about cryptography. It’s also about ensuring that implementations behave consistently across different devices, vehicle platforms, and wireless technologies. Much of the work behind Version 4 focused on strengthening that validation and interoperability layer while preserving the security properties already established in Version 3.
The updated NFC test cases also ran for the first time here. NFC tends to be the path a driver reaches for when a battery dies or the radios are unavailable. Does that fallback risk becoming the soft entry point, and how do you keep it from being the easy door?
NFC is an important part of the Digital Key architecture because it provides a reliable access method across a wide range of real-world scenarios, including situations where batteries are depleted or other radios are unavailable. However, it is not a “soft entry point.”
NFC requires very close physical proximity and explicit user action, which significantly reduces the attack surface compared with remote access technologies.
In addition, a single NFC interaction does not automatically grant unrestricted vehicle access. OEMs can enforce user-intent checks, authentication requirements, and access policies depending on the use case.
More broadly, our approach is that fallback mechanisms should meet the same security expectations as primary access methods. That’s one reason the CCC continues to expand interoperability and certification testing across NFC, Bluetooth Low Energy, and UWB implementations: to help ensure security is maintained regardless of how a user accesses the vehicle.
As a result, NFC maintains the same security principles as the broader Digital Key architecture while providing a reliable access experience across a variety of operational conditions.
A digital key lives in a phone that gets lost, sold, or compromised. From a defender’s point of view, how quickly can a key be suspended across the chain, and what assurance does an owner have that a revoked credential cannot be replayed against the car later?
CCC Digital Key supports fast revocation across the ecosystem through backend connectivity. As soon as either the phone or the vehicle reconnects, revocation information can be synchronized, and the credential is no longer accepted.
A key design principle is that vehicle owners retain control throughout the credential lifecycle, including issuance, sharing, suspension, and revocation. Even when a device remains offline, the system does not rely on a single point. Vehicle-side controls provide an additional enforcement mechanism to support revocation policies.
In addition, relay attacks are prevented through cryptographic challenge-response mechanisms, ensuring that a previously valid credential cannot simply be captured and reused later.
This combination of owner control, distributed enforcement, and cryptographic verification helps provide resilience even in scenarios involving lost, stolen, or compromised devices.
Cars stay on the road for fifteen years or longer, so the cryptography chosen now has to outlive several generations of phones. How is crypto agility engineered into v4, and is post-quantum migration part of the conversation for both the credentials and the protocols?
Digital Key Versions 3 and 4 rely on well-established cryptographic mechanisms that are widely trusted and appropriate for high-assurance applications today. At the same time, crypto agility is a key design principle, allowing algorithms and security mechanisms to evolve over the vehicle’s lifetime as requirements and threat models change.
Vehicle lifecycles are measured in decades, which makes long-term security planning particularly important for the automotive industry. The architecture is designed to support future evolution without requiring fundamental changes to the user experience or broader ecosystem.
Post-quantum readiness is actively being discussed within our member ecosystem, both at the credential and protocol level. While the current focus is on maintaining a secure and deployable baseline today, standards organizations also have a responsibility to consider long-term migration paths and ensure future cryptographic transitions can be introduced in a practical and interoperable way as the technology matures.