Lightweight Zero Trust via Automotive SDN Friedrich Wiemer1
arXiv:2609.09817v1 [cs.CR] 9 Sep 2026
1
, and Florian Wagner2
Robert Bosch GmbH, Stuttgart, Germany [email protected] 2 ETAS GmbH, Stuttgart, Germany [email protected]
Abstract. Zonal in-vehicle networks ship Ethernet, MACsec, and TSN, but treat the network itself as trusted: once configured at the factory, there is no standardized runtime way to easily revoke access, rotate keys, or contain a compromised ECU. Zero Trust Architecture targets exactly that gap, yet existing automotive ZTA proposals bolt on dedicated infrastructure that duplicates the SDN management plane already required to enable SDVs. Thus, ZTA is not yet adopted in the automotive domain, and the question remains: can we do better? We answer this in two steps. Step 1 analyses what Open Alliance TC17 v1.0 MACsec/MKA with pre-shared CAKs already provides in terms of NIST SP 800-207 ZTA tenets. Step 2 adds CORECONF/YANG management as proposed in Open Alliance TC19, maps the SDN Controller and Agents one-to-one onto NIST’s PE, PA, and PEP. We then instantiate this with two YANGbased mechanisms: a network-access-control flow and a key-management scheme. The result fully covers five and two partially of the seven tenets with no ZTA-specific infrastructure added. Keywords: Zero Trust Architecture · Software-Defined Networking · CORECONF · YANG · In-Vehicle Network Security
1
Introduction
The automobile is in the middle of an architectural reinvention. Domain-oriented electrical/electronic (E/E) architectures, with their heterogeneous patchwork of CAN, LIN, FlexRay, and Automotive Ethernet networks stitched together by central gateways, are giving way to zonal architectures in which a small number of high-performance vehicle computers communicate with zone controllers over a switched Automotive Ethernet backbone [11]. With this shift, the in-vehicle network (IVN) inherits the full stack of enterprise-grade mechanisms that the Ethernet ecosystem provides: VLAN segmentation, Time-Sensitive Networking (TSN) for deterministic real-time traffic, and IEEE 802.1AE MACsec for line-rate link-layer cryptographic protection [17]. At the same time, regulators have closed the door on shipping vehicles without a credible cybersecurity story: UN R155 mandates a certified Cybersecurity Management System over the entire vehicle
2
F. Wiemer and F. Wagner
lifecycle [34], and ISO/SAE 21434 codifies the engineering process expected to satisfy it [20]. Despite this technological and regulatory momentum, the IVN itself is still treated as a trusted medium. Once an ECU has been assembled at the factory, it is implicitly authorised to source and consume any traffic its configuration allows for the remainder of a 15-year-plus service life – a lifetime over which the threat landscape, the software stack, and in the future even the supplier ecosystem of a vehicle will change repeatedly. The fragility of this assumption has been demonstrated repeatedly, e.g., recently by CAN-injection attacks against modern vehicles, which show that physical access to a peripheral wiring harness is a realistic threat and suffices to impersonate trusted ECUs to command safetycritical functions.3 Recent surveys confirm that Automotive Ethernet inherits a comparable attack surface unless its security features are actively used [9]. The signal-oriented countermeasure used today, Secure On-Board Communication (SecOC), scales linearly with the number of authenticated signals and is already approaching the limit of what OEMs can configure and maintain by hand as signal counts grow exponentially with every vehicle generation.4 What is missing is not another security control, but a systematic, standards-based framework that turns the IVN from a statically trusted medium into a continuously verified network. Zero Trust Architecture (ZTA), as formalised by NIST SP 800-207 [31], is exactly such a framework: its guiding principle of “never trust, always verify” replaces perimeter trust with per-request authentication, authorisation, and policy enforcement. Applying ZTA to the IVN is therefore an obvious target, and several recent proposals have explored the design space, both for in-vehicle and vehicle-to-edge scenarios [14,1,32,19]. A common pattern in these works, however, is to introduce a dedicated Zero Trust control plane – additional policy engines, agents, and identity infrastructure – placed alongside the networking and SDV management stack that the OEMs are already building. The result is duplication of mechanism, duplication of integration effort, and, in practice, yet missing adoption. The question we ask in this paper is therefore not whether ZTA should be brought into the vehicle, but how lightly this can be done, if one is willing to reuse infrastructure that the zonal, software-defined vehicle requires anyway. Two-step approach. Our central claim is that a meaningful Zero Trust posture for the IVN can be reached incrementally, using only standards and infrastructure that are already on the automotive roadmap, in two separated steps. Step 1 – what is achievable today. Automotive Ethernet with MACsec/MKA using pre-shared CAKs, as standardised by Open Alliance TC17 [29,28], combined with VLAN isolation and TSN, already delivers a surprising fraction of the NIST ZTA tenets: per-link cryptographic authentication and confidentiality, deny-bySee, e.g., Tindell’s analysis of the 2022/2023 keyless-theft CAN-injection campaigns against several OEMs. 4 As argued, e.g., in Volvo Cars’ keynote at the Automotive Ethernet Congress 2024. 3
Lightweight Zero Trust via Automotive SDN
3
default at the link layer, and strong segmentation – all from static, design-time configuration, with no additional runtime infrastructure. Step 2 – what CORECONF/YANG-managed SDN adds tomorrow. Layering a CORECONF/YANG management plane (in the spirit of Open Alliance TC19) on top of Step 1 closes the remaining ZTA gaps – dynamic policy distribution, centralised key lifecycle management, and runtime reconfiguration in response to incidents – and does so by mapping the SDN Controller and on-device Agents oneto-one onto NIST’s Policy Engine, Policy Administrator, and Policy Enforcement Points. In other words, the SDN control plane is the ZTA control plane; no separate Zero Trust infrastructure is required. This split matters in practice. Step 1 can be deployed, resp. is already under deployment, on vehicles entering production within the current development cycle, using exclusively static configuration that fits the existing release process. Step 2 unlocks standardized, dynamic capabilities – key rotation, ECU revocation, on-the-fly policy updates – that long-lived, over-the-air-updated vehicles demand, but only once a YANG-based SDN management plane is available. Treating the two as a single architectural roadmap, rather than competing alternatives, lets OEMs realise immediate security benefits without precluding the more dynamic posture that the Software-Defined Vehicle will eventually require. Contributions. Concretely, this paper makes the following contributions: 1. A systematic analysis of which NIST SP 800-207 tenets can be satisfied at the IVN layer using only MACsec/MKA with pre-shared CAKs, VLANs, and TSN (Step 1 ). 2. A one-to-one mapping of a CORECONF/YANG-based automotive SDN architecture onto the NIST ZTA reference components, showing that the SDN management plane can serve as the Zero Trust control plane without additional infrastructure (Step 2 ). 3. A gap analysis that makes explicit which ZTA requirements are already met by Step 1 and which strictly require the dynamic capabilities introduced in Step 2. 4. Two concrete YANG-based mechanisms that instantiate Step 2: a networkaccess-control flow that replaces the 802.1X/EAP/RADIUS stack with a CORECONF-native interaction, and a key-management scheme that standardises the MACsec CAK lifecycle across the vehicle. Taken together, these contributions cover six of the seven NIST ZTA tenets at the network layer without introducing any ZTA-specific infrastructure beyond what an SDN-managed zonal vehicle already needs. Paper structure. Section 2 reviews the relevant background on ZTA, MACsec/MKA, and CORECONF/YANG-based SDN, and positions the paper against prior automotive ZTA work. Section 3 develops Step 1 and analyses the ZTA properties of static MACsec deployments. Section 4 introduces the SDN-managed Step 2 and details the two YANG-based mechanisms. Section 5 concludes our paper.
4
2
F. Wiemer and F. Wagner
Background and Related Work
This section recalls relevant background and related work for the remaining work. 2.1
Zero Trust Architecture
NIST SP 800-207 [31] is the reference for Zero Trust Architecture (ZTA). It replaces perimeter-based trust with three guiding principles: 1. verify explicitly, 2. enforce least privilege, and 3. assume breach. A concrete ZTA deployment is decomposed into three logical components: 1. a Policy Engine (PE) that decides whether a given subject may access a given resource, 2. a Policy Administrator (PA) that translates those decisions into actionable configuration, and 3. Policy Enforcement Points (PEPs) that gate the data plane accordingly. The seven tenets of §2.1 of the standard provide the evaluation rubric we use throughout the paper. The companion implementation guide NIST SP 1800-35 [21] and the CISA Zero Trust Maturity Model [8] refine these tenets into deployment maturity levels but do not change the underlying model. A comprehensive survey of enterprise ZTA deployments is given by Syed et al. [33]; Ramezanpour and Jagannath [30] provide a methodologically close mapping of the same NIST components onto 5G/O-RAN, which inspired the SDN mapping in Section 4. 2.2
MACsec, MKA, and the Automotive TC17 Profile
IEEE 802.1AE (MACsec) [17] provides authenticated encryption at the Ethernet link layer between adjacent peers. The associated MACsec Key Agreement (MKA) protocol, defined as part of IEEE 802.1X [18], derives short-lived Secure Association Keys (SAKs) from a longer-lived Connectivity Association Key (CAK) shared by the members of a connectivity association (the group into which MACsec peers are organized). The CAK itself can be provisioned in two ways: dynamically through an EAP exchange (e.g., EAP-TLS [25]), or statically as a pre-shared key (PSK). Open Alliance TC17 v1.0 [29,28] assumes the latter for the Automotive MACsec Profile: each MACsec-protected link in the vehicle has a CAK assigned at production time, and MKA runs peer-to-peer without any authentication server. This profile is the foundation of Step 1 (Section 3). Lauser et al. [23] systematically compare SecOC, MACsec, IPsec, and TLS for in-vehicle use; we adopt their conclusion that MACsec is the natural link-layer security primitive for the zonal Ethernet backbone, leaving end-to-end primitives like SecOC and TLS for application-layer concerns out of scope. De Vincenzi et al. [9] provide the threat-landscape reference for Automotive Ethernet and motivate the need for active use of these mechanisms. Wiemer et al. [39] show how the same MACsec/MKA construction extends to CAN XL (“CANsec”), which makes the mechanisms of Step 2 applicable beyond the Ethernet backbone. 2.3
SDN and CORECONF/YANG for In-Vehicle Networks
Software-Defined Networking (SDN), since OpenFlow [26] and the survey by Kreutz et al. [22], separates a programmable control plane from packet-forwarding
Lightweight Zero Trust via Automotive SDN
5
data planes. In enterprise and carrier networks, the de-facto management toolchain has converged on YANG-modelled configuration [5] carried by NETCONF [10] or RESTCONF [4], with [7] as the standard reference. Neither protocol is a good fit for in-vehicle ECUs: both assume XML/JSON parsing and TCP/TLS, which is incompatible with the footprint of a typical peripheral ECU. CORECONF [36] closes this gap by re-using YANG as the data model, but encoding instances in CBOR [35] and transporting them over CoAP/DTLS. Bhat et al. [3] benchmark CORECONF against NETCONF and RESTCONF and show order-of-magnitude reductions in message size and ROM footprint on constrained devices. The application of SDN inside the vehicle was opened up by Häberle et al. [13], who proposed SDN as the softwarisation lever for automotive E/E architectures. Häckel et al. [15,14] extended this line of work to secure SDN-managed TSN, including an analysis of trust zones inside the vehicle, and Nam et al. [27] used SDN to simplify TSN stream reservation. Open Alliance TC19 is currently consolidating these ideas into an automotive SDN profile; we are convinced it should leverage the existing CORECONF/YANG management plane and treat it as the substrate of Step 2. 2.4
Threat Model
We assume a Dolev–Yao adversary with physical access to the in-vehicle wiring harness: any link can be tapped, frames can be observed, modified, replayed, or injected, and an attacker may insert a rogue node on any segment. On top of this network-level capability we admit one fully compromised peripheral ECU whose software stack is under attacker control, but whose HSM-resident keys remain non-extractable. In particular, we assume the following: 1. Every ECU carries an HSM with non-extractable key storage and a key-wrap primitive, as the vast majority of current-generation automotive microcontrollers do; 2. Every ECU holds a unique certificate and private key, injected out of band before or at production together with all other long-term key material, plus a path along which the vehicle computer obtains revocation information – several OEMs already operate such a per-ECU PKI for diagnostics, component protection, and V2X provisioning; 3. A CORECONF/YANG management plane exists in the vehicle for TSN, QoS, VLAN, and MACsec configuration irrespective of Zero Trust; and 4. The vehicle computer hosting the SDN controller and the per-node HSMs are trusted – their compromise, physical attacks on the controller, and side-channel or fault-injection attacks on cryptographic accelerators are out of scope. 2.5
Related Work and Positioning
Three threads of prior work are directly adjacent. 1. [32] is the closest match: they propose a ZTA for automotive networks, but realise it as a dedicated policy infrastructure alongside the existing communication stack; [1,16] apply ZTA to connected vehicles and platoon control respectively, both outside the Ethernet backbone, and all three treat ZTA as an additional layer rather than as a re-use
6
F. Wiemer and F. Wagner
of the SDN management plane already required for TSN, MACsec, and VLAN configuration. 2. On the SDN-managed MACsec side, [6] replace standard MKA with a centralised, multi-hop key exchange; we take the opposite stance and keep MKA standards-conformant, leaving the SDN controller responsible only for CAK lifecycle and policy via CORECONF/YANG. 3. Outside automotive, SDN-toZTA mappings have been explored for enterprise networks [12], smart cities [19], and ML-augmented SDN deployments [2,24]; these confirm the methodology but do not address production key provisioning, constrained ECUs, vehicle lifetimes, or co-existence with TSN.
3
Step 1: MACsec based Zero Trust
Analysing “Zero Trust in the vehicle” separately, leads one to reach for new infrastructure: identity servers, dedicated policy engines, certificate hierarchies tailored to ECUs. In our first step, we instead look at a ZTA in the context of the existing system: how much of NIST’s Zero Trust Architecture is already achieved by the security mechanisms that today’s vehicles carry on every Ethernet link? The answer, as this section will show, is “more than is usually assumed” – but, equally importantly, “not enough”. The resulting gap then motivates our next Step 2. 3.1
System Model
The Step 1 system is a stripped zonal Ethernet backbone, for the ease of exposition. A Vehicle Computer (VC) connects to a small number of Zone Controllers (ZCs), each ZC in turn aggregating the sensors and actuators that happen to sit in its physical proximity. Every point-to-point Ethernet link – both VC↔ZC and ZC↔peripheral – carries exactly one MACsec connectivity association. The associated CAK is provisioned out-of-band at production time, in line with [29,28], and stored in the ECU’s HSM. At power-on, MKA runs peer-to-peer on each link and distributes fresh, short-lived SAK; thereafter every frame on the wire is MACsec-protected. VLAN assignments are written into the switch’s static configuration at the same time as the CAKs. There is no SDN controller, nor SDN agent, no RADIUS or authentication server, and no runtime management channel of any kind. All security-relevant configuration is baked in at build time; nothing changes after the vehicle leaves the factory unless an ECU is reflashed. Figure 1 captures this minimal world. 3.2
Zero Trust Properties Achieved
Even this stripped-down system already satisfies, or partially satisfies, three of the seven NIST SP 800-207 tenets (T1 to T7) at the network layer. A MACsec receiver drops every frame that lacks a valid SecTAG and ICV. Since MKA will only derive a SAK between peers that both prove possession of the same CAK, an ECU without the correct CAK simply cannot place legitimate
Lightweight Zero Trust via Automotive SDN Factory: CAKs + VLANs
VC
Mgmt C
K1
A
C
K4
A K 5
CA
CA K 3
Ctrl
ZC-Body
ZC-Front
Cam-F
absent at runtime
K 2
C
Mirror-FL
Door-R
MKA per link
CAK6
A
Brk-RR
Rogue ECU MKA fail ⇒ drop
VLANs:
ADAS
Body
7
Data MACsec-protected Ethernet | gPTP
Chassis
Fig. 1. Step 1 at a glance. Left: reference zonal topology (1 VC, 2 ZCs, peripherals attached by physical proximity) with one MACsec connectivity association per link: Cam-F (front camera) and Mirror-FL (front-left mirror) on ZC-Front; Door-R (rear door module) and Brk-RR (rear-right brake actuator) on ZC-Body, alongside a rogue ECU. Edge colour denotes the static VLAN of the attached ECU; every solid edge carries a pre-shared CAK. ECUs of different VLANs share the same zone controller – zones are defined by topology, not by domain – and the dashed red node illustrates a rogue ECU dropped by MKA because no CAK is provisioned for its link. Right: the data and control planes are populated by MACsec and per-link MKA, while the management plane is absent at runtime – all parameters (CAKs, VLANs, ACLs) are baked in at production time.
traffic onto the link. The drop is observable via the standard MACsec counters (InPktsNoSCI, InPktsNotValid, . . . ), so the attempt is auditable even though it never reaches a higher protocol layer. In ZT vocabulary, the link itself enforces deny-by-default, without any cooperation from a higher-level policy decision point, paying towards T3, T6. As for how T2, communication secured regardless of location, is satisfied, consider the following. Once MKA has succeeded, all data-plane traffic on the link is authenticated and (optionally) encrypted hop by hop. The “regardless of location” clause of NIST tenet T2 is satisfied trivially: there is no “trusted inside” on the wire – the same MACsec frame format protects backbone and zone links alike. A man-in-the-middle inserted on a harness segment cannot eavesdrop or modify traffic without holding the corresponding CAK, and a compromised peripheral ECU can decrypt only the connectivity associations it is itself a member of. The blast radius of any single compromise is therefore bounded by the set of links to which that ECU holds keys – in the worst case a single peripheral connection. Besides, T3, asking for least-privilege per-session access, is satisfied partially by the combination of static VLANs and switch-port ACLs at the ZC. These restrict each peripheral to the small subset of the network that its function requires. Critically, and as Fig. 1 illustrates, ZCs are topological aggregators,
8
F. Wiemer and F. Wagner
not domain controllers: a single ZC typically hosts ECUs belonging to different VLANs, and the VLAN boundary is, what limits reachability. This is least privilege at the link layer. Eventually, T6 requiring a dynamic and strict access control, is insofar satisfied by the same combination of static VLANs, ACLs, and MACsec that a strict access control is implemented. The dynamic part is missing, due to the non-existence of reconfiguration during runtime. Two observations are worth pinning down. First, the security posture above is achieved without any management plane at runtime. That is precisely what makes Step 1 deployable right now. Second, the qualifier “no SDN at runtime” is not the same as “no SDN ever”: Step 1 still requires an out-of-band, design-time provisioning step that writes CAKs and VLAN tables into each ECU and switch. The next subsection makes explicit why the absence of a runtime counterpart to that provisioning step is what bounds Step 1’s fulfillment of NIST’s ZTA tenets. 3.3
Remaining Gaps
Four gaps remain, that Step 1 cannot fully satisfy: G1 No dynamic policy: VLANs, ACLs, and CAKs are fixed at design time and there is no in-band path to a policy update. G2 No standardized and centralised key lifecycle: A CAK lives as long as the ECU it was provisioned into; rotation needs a reflash or workshop visit, and revocation is not a first-class operation. Currently no standardized solution to this exist. G3 No runtime visibility or audit: MACsec counters are local; no vehicle-wide instance can query which ECUs are currently authenticated on which associations, nor reconcile that view against an intended policy. G4 No identity beyond key possession: TC17 v1.0 equates “holds the CAK” with “is the legitimate party” – no certificate, no revocation list. Each of these gaps is, on closer inspection, a missing management plane capability: dynamic policy distribution, centralised key management, runtime state queries, and certificate-based identity. This bridges to Step 2. A vehicle that wants to close these gaps need not invent ZTA infrastructure from scratch; it needs a management plane. And, as we will argue in Section 4, the SDN management plane that the zonal vehicle already requires for TSN, MACsec, and VLAN configuration is exactly that management plane.
4
Step 2: SDN-Managed Zero Trust
Step 2 builds on top of Step 1: the MACsec/MKA/VLAN data and control plane is kept verbatim and a CORECONF/YANG-based SDN management plane – of the kind already on Open Alliance TC19’s roadmap for network configuration, e.g. for TSN and QoS configuration – is added on top. The key claim of this section is that this management plane, once present, is the ZTA control plane: it closes all five Step 1 gaps without replacing any link-layer mechanism and without introducing a second infrastructure dedicated to Zero Trust.
Lightweight Zero Trust via Automotive SDN
9
SDN Controller (runtime) Mgmt
VC with SDN Ctrl
CORECONF/YANG over DTLS
Ctrl
ZC-Front
ZC-Body
SDN Agent
SDN Agent
MKA per link
Data MACsec | gPTP Cam-F
Mirror-FL
Door-R
Brk-RR
Fig. 2. Step 2: SDN management plane overlaid on the Step 1 topology of Fig. 1. Solid edges and VLAN colours (violet=ADAS, teal=Body, brown=Chassis) are unchanged; dashed blue arrows are CORECONF/DTLS sessions, all originating at the SDN controller on the VC and terminating at each SDN agent. The previously empty Mgmt lane on the right is now driven by the runtime SDN controller.
4.1
System Model Extension
The Step 2 system, see Fig. 2, reuses the topology, the connectivity associations, and the static VLAN assignments of Step 1. Three SDN roles are added on top: the VC additionally hosts an extended SDN controller (SDN controller plus the policy logic that turns ZTA decisions into YANG edits), each ZC hosts an SDN agent; the ZC doubles as a Policy Enforcement Point, and each peripheral ECU hosts an SDN agent that receives its own identity material and CAKs and reports local state back to the controller. With these roles in place the three planes finally separate cleanly: management is CORECONF over DTLS, control remains per-link MKA, and the data plane carries MACsec-protected Ethernet (with e.g. gPTP for time synchronisation). None of the Step 1 mechanisms are replaced; the empty management lane of Fig. 1 is simply filled in. 4.2
Worked Example: Dynamic Reconfiguration
Consider the topology of Fig. 2 at runtime. An on-board distributed IDPS hosted on the ZCs and VC observes – on ZC-Body – that the rear-right brake actuator Brk-RR is sourcing traffic patterns that no longer match its role; this detection step happens locally on the ZC, outside the SDN planes. The local IDS sensor forwards the alert to the IDPS instance on the VC, which evaluates the event against the active policy and instructs the SDN controller to quarantine the actuator (management plane). The decision is realised through three small YANG edits pushed over the same CORECONF/DTLS session: revoking the actuator’s CAK from the ZC-Body keystore, moving its switch port to a quarantine VLAN, and adding a matching ACL on ZC-Body. ZC-Body then terminates the affected MKA session (control plane), so no further frames from Brk-RR reach the backbone (data plane); safety-critical traffic on every other link – including the entire ADAS path through ZC-Front – continues unaffected.
10
4.3
F. Wiemer and F. Wagner
SDN-to-ZTA Component Mapping
The mapping onto NIST SP 800-207 [31] is direct. The SDN controller is both Policy Engine – it evaluates the active policy against the current network state – and Policy Administrator – it translates each decision into a YANG configuration edit. The SDN agent on every ZC and the agent on every peripheral are the Policy Enforcement Points: they own the keys, the MACsec block, and the switch ports through which data-plane traffic must pass. YANG is the policy language, CORECONF over DTLS is the ZTA management plane, MKA and MACsec remain the enforcement primitives, now under dynamic management. Trust-algorithm inputs – IDPS alerts, attestation status, YANG library queries – reach the controller over the same channel. NIST’s deployment-model taxonomy applies as a hybrid: ZCs are the gateways between zones (gateway-based ), while the per-link MACsec connectivity associations and VLAN boundaries provide the micro-segmentation that a gateway model on its own does not enforce. A useful sanity check on the “no new infrastructure” claim is to enumerate the enforcement primitives at the PEP. There are exactly four, and all four are already required by an SDN-managed automotive Ethernet: MACsec for per-link authentication and encryption; VLAN assignment for static and dynamically reconfigurable segmentation, including the quarantine case above; MKA for session-key derivation, whose teardown is the runtime equivalent of “revoke access”; and switch-level ACLs for port- and protocol-granularity filtering. With this mapping the four Step 1 gaps close as follows: G1 by the runtime CORECONF push of Section 4.2; G2 by the YANG-based key lifecycle of Section 4.5; G3 by YANG library queries that double as the NIST “asset database”; G4 by binding each agent to a certificate verified during DTLS mutual authentication, with CRL checking centralised on the controller. 4.4
YANG-based Network Access Control
The component mapping above leaves two questions open: how does an agent first prove it is entitled to talk to the SDN controller at all, and how does it obtain its first CAK? The default networking answer is the 802.1X/RADIUS port-based network access control (PNAC) stack: an EAPoL exchange between the edge node (supplicant) and the switch (authenticator) tunnels EAP through to a back-end RADIUS server, which validates the supplicant’s credentials and ships the resulting CAK back to the switch over RADIUS attributes. We argue that this stack is redundant once the SDN management plane is in place, and can be replaced by a CORECONF/YANG flow that, as we argue below, preserves the authentication and authorisation guarantees it provides. Three observations motivate the replacement. 1. deploying 802.1X / RADIUS alongside the SDN management stack duplicates the asymmetric crypto, the certificate handling, and the per-node secure channel that CORECONF / DTLS already requires – the two stacks solve the same problem twice on the same wire. 2. 802.1X requires each switch to fetch and check CRLs independently, which presupposes connectivity to the central VC, to an off-board back-end or the
Lightweight Zero Trust via Automotive SDN
11
RADIUS server. 3. today’s CAK provisioning lives in OEM-proprietary toolchains; re-expressing it as YANG configuration edits standardises it on infrastructure that becomes part of the vehicle with the SDN management. Operationally, the centralised flow has four steps. The agent authenticates to the controller via DTLS mutual authentication using its X.509 certificate; the controller checks the certificate and the active policy and decides whether the node is authorised; on success, the controller distributes the relevant CAK as a YANG configuration edit (wrapped as described in Section 4.5); standard MKA then derives the SAK and MACsec activates. Until MACsec is up the switch enforces deny-by-default with one bootstrap exception: CORECONF management frames and MKA control frames are permitted, every other Ethertype is dropped. This keeps the management and control planes reachable during cold start while the data plane stays silent. Authorisation can even be implicit: if the controller never distributes a matching CAK, no MKA session can form on that link, and no explicit ACL push is required. For deployments where the controller is temporarily unreachable – early startup of a deeply embedded sub-domain, or a multi-hop bootstrap path – a decentralised fallback based on EAP-TLS [25] between edge node and switch can be realised, with the controller pre-distributing credentials and the local authorisation policy in advance. From MKA’s perspective the distributed CAK remains a pre-shared key, so the flow stays within the Open Alliance TC17 v1.0 PSK recommendation while adding what static proprietary PSK provisioning lacks: revocation, runtime rotation, and an auditable key lifecycle. 4.5
YANG-based Key Management
The NAC flow above assumes that, once the controller authorises a node, a CAK can simply be “distributed as a YANG configuration edit”. This subsection makes that step concrete. To avoid exposing cleartext cryptographic material during transmission or within the volatile memory (RAM) of the application software, we implement a two-stage key lifecycle strategy utilizing hidden and wrapped key configurations. Phase 1: Factory provisioning During the ECU production phase, a long-term master Key Encryption Key (KEK) is securely programmed directly into a dedicated, write-protected hardware slot of the HSM via a trusted physical interface (e.g., secure JTAG or UDS bootloader routines). Crucially, within the ECU’s active YANG startup configuration, this key is instantiated as a hidden key using the framework specified by the ietf-keystore model [37]. The management plane acknowledges the existence, identifier, and cryptographic algorithm of KEK, but any attempt to read its value via the management protocol yields an empty or null reference. The actual key material never leaves the HSM boundary. Phase 2: Runtime provisioning At runtime, when a Zone Controller establishes a secure MACsec link with another network node via MKA, it requires a shared CAK.
12
F. Wiemer and F. Wagner
The provisioning protocol flows as Payload = EKEK (CAK), executed in four steps: (1) the SDN controller generates a random 128- or 256-bit CAK for the MKA session; (2) it encrypts the CAK under the designated KEK; (3) the resulting ciphertext (encrypted-value) plus a reference to the wrapping key (asymmetric-/symmetric-key-ref) is encapsulated into a YANG configuration instance against ietf-keystore [37] with cryptographic types drawn from ietf-crypto-types [38]; (4) the instance is serialised into CBOR and transmitted to the ZC over a secure CORECONF/DTLS session. 1
{
" ietf - keystore : keystore " : { " symmetric - keys " : { 4 " symmetric - key " : [ 5 { 6 " name " : " master - kek -01 " , 7 " hidden " : [ null ] 8 } ] } } } 2 3
Listing 1.1. YANG initial key injection (conceptual JSON representation) 1
{
" ietf - keystore : keystore " : { " symmetric - keys " : { 4 " symmetric - key " : [ 5 { 6 " name " : " mka - cak - zone -1 " , 7 " encrypted - key " : { 8 " encrypted - by " : { 9 " symmetric - key - ref " : " master - kek -01 " 10 }, 11 " encrypted - value - format " : " ietf - crypto - types : cms encrypted - data - format " , 12 " encrypted - value " : " BASE64 - CMS - ENCRYPTED - DATA - DER " 13 } } ] } } } 2 3
Listing 1.2. YANG runtime key configuration (conceptual JSON representation)
Listings 1.1 and 1.2 show the conceptual example representation of the start configuration and runtime payload required to provision the MKA CAK.5 Upon receiving the CBOR payload, the embedded CORECONF agent parses the data structure and invokes, e.g., the AUTOSAR CSM to execute the keyunwrap routine. The decryption job is handed over to the HSM, which uses the KEK stored in its secure internal memory to decrypt the CAK and persists it in its secure key storage. Bootstrapping for latency. Note that a fresh CORECONF/YANG configuration is not required to be pushed on every power cycle. Each SDN agent persists its YANG datastore to non-volatile memory and re-reads it locally at boot. 5
Analogously an asymmetric KEK can be used, following [38].
Lightweight Zero Trust via Automotive SDN
13
The HSM also persists its secure key storage, so the KEK and any previously unwrapped CAKs remain available across power cycles. A cold start therefore reduces to loading the cached configuration, booting the HSM, and running MKA. Relative to Step 1 this adds no additional operation. The full DTLS handshake and CORECONF push only occur when something actually has to change: initial commissioning, scheduled key rotation, certificate renewal, or a runtime policy edit triggered by, e.g., Section 4.2. 4.6
Tenet coverage
With these flows in pace, NISTs tenets are satisfied as Table 1 summarises. Table 1. Step 2 coverage of NIST SP 800-207 tenets. Tenet Step 1 Step 2 Comment T1 T2 T3 T4 T5 T6 T7
5
– H – – H
H H
–
Addressable YANG resources MACsec and MKA per link least-privilege per-session access trust algorithm for decision logic out of scope continuous monitoring; no device attestation dynamic trust algorithm; strictly enforced by MACsec, dynamically per YANG edit Mgmt channel closes telemetry loop
Conclusion
Does automotive Zero Trust require dedicated infrastructure or can a SDN management plane carry the load? Our two-step construction gave a lightweight answer. Step 1 shows that Open Alliance TC17 v1.0, static MACsec and MKA with pre-shared CAKs extended with VLAN segmentation, already satisfies one NIST SP 800-207 tenet outright (T2, secure communication) and partially two more (T3, least-privilege per-session access; T6, strictly enforcing access), and is deployable today. Step 2 fills the residual gaps by overlaying a CORECONF/YANG management plane in line with the TC19 direction, in which the SDN controller doubles as Policy Engine and Policy Administrator and every SDN agent on a ZC or peripheral ECU acts as Policy Enforcement Point. A YANG-based network access-control flow subsumes the 802.1X/RADIUS stack while preserving the authentication guarantees it provides, and a YANG-based key-management scheme distributes CAKs as wrapped values whose decryption never leaves the HSM.
14
F. Wiemer and F. Wagner
Together the two steps cover five of the seven NIST tenets fully at the network layer (T1–T3, T6, T7) and the remaining two partially (T4, T5) without introducing a single new protocol stack: MACsec, MKA, VLANs, ACLs, DTLS, PKI certificates, CORECONF, and the IETF YANG keystore and crypto-types models are all repurposed rather than reinvented. Adding a trust algorithm and device attestation to the Step 2 controller will close the remaining gaps. These will still make use of the same SDN management plane and thus not introduce any dedicated ZTA infrastructure.
Limitations. However, we do not achieve a complete automotive Zero Trust architecture, and the following limitations remain: (L1) Network layer only: We secure links, ports, and connectivity associations; application-layer authorisation inside the ECU is not addressed. An ECU authorised on its link may still misbehave within the traffic profile its VLAN and ACLs permit. (L2) Identity is delegated to the PKI. Node identity is exactly as strong as the per-ECU certificate assumed in Section 2.4, and we do not contribute a provisioning scheme for it (we assume it is injected or generated during production). (L3) Per-session authorisation (T3) stays partial. MACsec frames are authorised by possession of a symmetric key, and runtime rotation narrows but cannot close that gap without restrictions on the start up time. (L4) No trust algorithm. Step 2 provides inputs, but the interplay and scoring rules that NIST SP 800-207 §3.3 expects remain to be designed. (L5) Resilience is not analysed. Persisted datastores let a vehicle boot and operate with an unreachable controller, so management-plane availability is not on the critical path; controller redundancy, an explicit fail-safe policy, and the degradation logic that must gate revoking a safety-relevant actuator remain open, as it belongs to SDN resilience concepts. Beyond these, the trust assumptions of Section 2.4 apply. Three threads stand out for future work: 1. An end-to-end proof-of-concept on representative automotive hardware; 2. A concrete trust algorithm that consumes the management-plane telemetry already collected in Step 2 and emits CORECONF policy edits as its actions; and 3. An extension of the same YANG models beyond Ethernet, where CANsec on CAN XL is the natural next link layer to fold in, leaving the authentication, authorisation, and key-provisioning flow unchanged.
Take-away. OEMs need not choose between deployability and Zero Trust. Step 1 is available now; Step 2 is incremental on top of an SDN management plane that the move to software-defined vehicles requires anyway. Security, in this construction, comes by design rather than by addition.
Lightweight Zero Trust via Automotive SDN
15
References 1. Anderson, J., Huang, Q., Cheng, L., Hu, H.: A zero-trust architecture for connected and autonomous vehicles. IEEE Internet Computing 27(5), 7–14 (2023). https: //doi.org/10.1109/MIC.2023.3304893 2. Bashaa, M.H., Bhaya, W.S., Al-aaraji, N.H.K.: Integration of zero trust architecture and machine learning for improving the security of software defined networking: A review. Journal of Intelligent Informatics, Networking, and Cybersecurity 1(1) (2025). https://doi.org/10.65445/3106-1192.1000 3. Bhat, M.G., Bhattacharjee, S., Gündoğan, C., Alexandris, K., Gogolev, A.: CORECONF, NETCONF, and RESTCONF: Benchmarking network orchestration in constrained IIoT devices. IEEE Internet of Things Journal 11(7), 13082–13090 (2024). https://doi.org/10.1109/JIOT.2023.3338470 4. Bierman, A., Björklund, M., Watsen, K.: RESTCONF protocol. RFC 8040 (2017). https://doi.org/10.17487/RFC8040 5. Björklund, M.: The YANG 1.1 data modeling language. RFC 7950 (2016). https: //doi.org/10.17487/RFC7950 6. Choi, J.H., Min, S.G., Han, Y.H.: MACsec extension over software-defined networks for in-vehicle secure communication. In: Proceedings of the IEEE International Conference on Ubiquitous and Future Networks (ICUFN). IEEE (2018). https: //doi.org/10.1109/ICUFN.2018.8436957 7. Claise, B., Clarke, J., Lindblad, J.: Network Programmability with YANG: The Structure of Network Automation with YANG, NETCONF, RESTCONF, and gNMI. Addison-Wesley (2019) 8. Cybersecurity and Infrastructure Security Agency: Zero trust maturity model, version 2.0. Tech. rep., CISA (2023) 9. De Vincenzi, M., Costantino, G., Matteucci, I., Fenzl, F., Plappert, C., Rieke, R., Zelle, D.: A systematic review on security attacks and countermeasures in automotive ethernet. ACM Computing Surveys 56(6), 1–38 (2024). https://doi. org/10.1145/3637059 10. Enns, R., Björklund, M., Bierman, A., Schönwälder, J.: Network configuration protocol (NETCONF). RFC 6241 (2011). https://doi.org/10.17487/RFC6241 11. ETAS GmbH and TTTech Auto AG and Robert Bosch GmbH: Software-defined vehicles with TSN and SDN. White paper, ETAS GmbH (Feb 2025) 12. Guo, X., Xian, H., Feng, T., Jiang, Y., Zhang, D., Fang, J.: An intelligent zero trust secure framework for software defined networking. PeerJ Computer Science 9, e1674 (2023). https://doi.org/10.7717/peerj-cs.1674 13. Häberle, M., Heimgärtner, F., Lohr, H., Nayak, N., Menth, M.: Softwarization of automotive E/E architectures: A software-defined networking approach. In: Proceedings of the IEEE Vehicular Networking Conference (VNC). IEEE (2020). https://doi.org/10.1109/VNC51378.2020.9318381 14. Häckel, T., Meyer, P., Korf, F., Schmidt, T.C.: Secure time-sensitive softwaredefined networking in vehicles. IEEE Transactions on Vehicular Technology 71(2), 2168–2181 (2022). https://doi.org/10.1109/TVT.2021.3133591 15. Häckel, T., Schmidt, A., Meyer, P., Korf, F., Schmidt, T.C.: Strategies for integrating control flows in software-defined in-vehicle networks and impact on network security. In: Proceedings of the IEEE Vehicular Networking Conference (VNC). IEEE (2020). https://doi.org/10.1109/VNC51378.2020.9318398 16. Huang, D., Na, Y., Liu, Y., Zhang, Z., Mi, B.: Overview of cooperative fault-tolerant control driven by the full information chain of intelligent connected vehicle platoons
16
F. Wiemer and F. Wagner
under the zero-trust framework: Opportunities and challenges. IEEE Intelligent Transportation Systems Magazine 16(1), 22–39 (2024). https://doi.org/10.1109/ MITS.2023.3319344 17. IEEE: IEEE 802.1AE — MAC security (MACsec). IEEE Standard (2018) 18. IEEE: IEEE 802.1X — port-based network access control. IEEE Standard (2020) 19. Iftikhar, A., Hussain, F.B., Qureshi, K.N., Shiraz, M., Sookhak, M.: Securing edge-based smart city networks with software defined networking and zero trust architecture. Journal of Network and Computer Applications 244, 104341 (2025). https://doi.org/10.1016/j.jnca.2025.104341 20. ISO/SAE: ISO/SAE 21434:2021 — road vehicles — cybersecurity engineering. ISO/SAE International Standard (2021) 21. Kerman, A., Borchert, O., Rose, S., Tan, A., Souppaya, M., et al.: Implementing a zero trust architecture. Special Publication 1800-35, National Institute of Standards and Technology (2025). https://doi.org/10.6028/NIST.SP.1800-35 22. Kreutz, D., Ramos, F.M.V., Veríssimo, P.E., Rothenberg, C.E., Azodolmolky, S., Uhlig, S.: Software-defined networking: A comprehensive survey. Proceedings of the IEEE 103(1), 14–76 (2015). https://doi.org/10.1109/JPROC.2014.2371999 23. Lauser, T., Zelle, D., Kern, D., Krauß, C., Völker, L.: Security protocols for ethernetbased in-vehicle communication. In: Proceedings of the IEEE Vehicular Networking Conference (VNC). pp. 148–155. IEEE (2024). https://doi.org/10.1109/VNC61989. 2024.10575984 24. Liang, G., Han, P., Zhao, S.: Research on zero trust architecture based on SDN. In: ACM SPCCNC (2024). https://doi.org/10.1145/3712335.3712403 25. Mattsson, J.P., Sethi, M.: EAP-TLS 1.3: Using the extensible authentication protocol with TLS 1.3. RFC 9190 (2022). https://doi.org/10.17487/RFC9190 26. McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S., Turner, J.: OpenFlow: Enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review 38(2), 69–74 (2008). https: //doi.org/10.1145/1355734.1355746 27. Nam, S.K., et al.: Simplified stream reservation protocol over SDN for in-vehicle TSN. IEEE Access 9, 127295–127311 (2021). https://doi.org/10.1109/ACCESS. 2021.3112056 28. Open Alliance Technical Committee 17: Automotive MKA specification. Version 1.0 (2024), https://opensig.org/wp-content/uploads/2025/03/OA_MACsec_ Automotive-MKA-v1.pdf 29. Open Alliance Technical Committee 17: Automotive MACsec specification. Version 1.0 (2025), https://opensig.org/wp-content/uploads/2025/05/ Automotive-MACsec-Specification-v1.0.pdf 30. Ramezanpour, K., Jagannath, J.: Intelligent zero trust architecture for 5G/6G networks: Principles, challenges, and the role of machine learning. Computer Networks 217, 109358 (2022). https://doi.org/10.1016/j.comnet.2022.109358 31. Rose, S., Borchert, O., Mitchell, S., Connelly, S.: Zero trust architecture. Special Publication 800-207, National Institute of Standards and Technology (2020). https: //doi.org/10.6028/NIST.SP.800-207 32. Shipman, M.E., Millwater, N., Owens, K., Smith, S.: A zero trust architecture for automotive networks. In: SAE Technical Paper. SAE International (2024). https://doi.org/10.4271/2024-01-2793 33. Syed, N.F., Shah, S.W., Shaghaghi, A., Anwar, A., Liang, Z., Camtepe, S.: Zero trust architecture (ZTA): A comprehensive survey. IEEE Access 10, 57143–57179 (2022). https://doi.org/10.1109/ACCESS.2022.3174679
Lightweight Zero Trust via Automotive SDN
17
34. UNECE: UNECE WP.29 R155 — cybersecurity management system. UN Regulation (2021) 35. Veillette, M., Petrov, I., Pelov, A., Bierman, A.: CBOR encoding of data modeled with YANG. RFC 9254 (2022). https://doi.org/10.17487/RFC9254 36. Veillette, M., van der Stok, P., Pelov, A., Bierman, A., Petrov, I.: CoAP management interface (CORECONF). Internet-Draft draft-ietf-core-comi-21 (2024), work in Progress 37. Watsen, K.: A YANG data model for a keystore. RFC 9642 (2024). https://doi. org/10.17487/RFC9642 38. Watsen, K., Li, H.: YANG data types and groupings for cryptography. RFC 9640 (2024). https://doi.org/10.17487/RFC9640 39. Wiemer, F., Mutter, A., Ndop, J., Göppert, J., Sikora, A., Walrant, T.: Beyond ethernet: Reusing MACsec for CANsec. Cryptology ePrint Archive, Paper 2025/2224 (2025), https://eprint.iacr.org/2025/2224