SOME/IP, DoIP and Automotive Ethernet Explained: 100BASE-T1 to SecOC

Automotive Ethernet is IEEE 802.3 Ethernet over a single twisted pair (100BASE-T1, 1000BASE-T1, 10BASE-T1S and faster variants). SOME/IP is the AUTOSAR middleware that carries service calls and events over it, and DoIP (ISO 13400) carries UDS diagnostics over TCP/IP. Secure them with gateway policy, SecOC, MACsec or TLS, and track every stack version.

The protocols on that Ethernet backbone were designed for a closed network inside the car, so their security depends on configuration, not on the wire format. This post goes one level deeper than our CAN vs CAN FD vs LIN comparison: the physical layers, SOME/IP and its Service Discovery field by field, DoIP routing activation, how SecOC, MACsec and TLS protect each layer, and why the communication stacks belong in the software bill of materials. Field values were checked against the AUTOSAR R25-11 specifications, IEEE SA pages, the IANA port registry and project documentation. It stays at design and hardening level, with no attack steps.

Key takeaways

• Automotive Ethernet is several PHYs, not one. IEEE 802.3bw defined 100BASE-T1 (board approval 26 October 2015), 802.3bp defined 1000BASE-T1 (30 June 2016), 802.3cg added 10 Mb/s single pair operation including the multidrop 10BASE-T1S (7 November 2019), and 802.3ch added 2.5, 5 and 10 Gb/s automotive links (4 June 2020).
• SOME/IP is a service protocol, not a security protocol. Its 16 byte header carries a Message ID, Length, Request ID, protocol version 1, interface version, message type and return code. Nothing in the header authenticates the sender.
• SOME/IP-SD is how ECUs find each other. Service Discovery messages use the Message ID 0xFFFF8100 and, by default, UDP port 30490. Offers, finds and subscriptions are trusted unless you add network security and access policy.
• DoIP moves UDS onto IP. IANA assigns port 13400 (UDP for discovery, TCP for data). A tester must complete routing activation before diagnostic messages are forwarded, and the 2019 edition of ISO 13400-2 adds TLS secured connections, which AUTOSAR models with a switch to refuse non TLS testers.
• SecOC authenticates PDUs, it does not encrypt them. It appends a freshness value and a truncated MAC (for example AES-128 CMAC under NIST SP 800-38B). Key handling and freshness management decide whether it actually stops replay.
• The stacks are supply chain components. Open source SOME/IP stacks such as COVESA vsomeip (MPL-2.0, release 3.7.6 on 17 September 2026) ship fixes in their own changelogs. If the stack is not in your SBOM, nobody will know when it needs an update.

Why are vehicles moving to Ethernet?

For decades the in vehicle network was a set of CAN buses, with LIN for simple sensors and actuators. CAN FD raised the payload to 64 bytes, which bought time but kept the model of broadcast frames on a shared bus with no sender identity. Our CAN post explains why. Three pressures pushed vehicle makers toward Ethernet.

Bandwidth. Driver assistance cameras, radar, high resolution displays and the central compute that processes them need links from hundreds of megabits to several gigabits per second.

Architecture. Vehicles are moving from one ECU per function toward zonal architectures, where zone controllers near the sensors connect over a high speed backbone to central compute. That backbone needs switched, routable networking with quality of service and time synchronisation, which Ethernet with Time-Sensitive Networking provides.

Software. With IP in the vehicle, service oriented communication, over the air updates and fast diagnostics become easier. So does the usual IP risk: anything that can reach a port can try to talk to it.

Office Ethernet cabling is too heavy and costly for a car, so IEEE 802.3 defined physical layers that run over a single balanced twisted pair, and the OPEN Alliance, an industry group for Ethernet in vehicles, publishes interoperability and conformance test suites for them.

What are 100BASE-T1, 1000BASE-T1 and 10BASE-T1S?

Each is an amendment to IEEE Std 802.3. Approved amendments are folded into the next revision of the base standard, which is why IEEE SA shows the originals as superseded; the PHYs themselves are current.

100BASE-T1 and 1000BASE-T1 are point to point, so networks are built from switches; 100 Mb/s serves many ECU to ECU and diagnostic links, and 1 Gb/s the backbone and heavier sensor paths. 10BASE-T1S matters to security architects because it brings Ethernet to the edge where CAN used to live, and its multidrop segments (enhanced by 802.3da) are a shared medium again, so shared bus trust assumptions return. Multi gigabit PHYs and the P802.3dm camera link project serve sensors and compute where a gigabit is not enough.

None of these PHYs adds security by itself. Confidentiality, integrity and authentication all come from layers above: MACsec at layer 2, IPsec at layer 3, TLS or DTLS at the transport layer, and SecOC in the AUTOSAR communication stack.

What is SOME/IP?

SOME/IP (Scalable service-Oriented MiddlewarE over IP) is specified in the AUTOSAR Foundation standard, which holds the parts shared by the Classic Platform (the static, microcontroller oriented stack) and the Adaptive Platform (for high performance compute ECUs on a POSIX operating system). The current specification is document 696, AUTOSAR_FO_PRS_SOMEIPProtocol, release R25-11 dated 27 November 2025. It lets ECUs offer and consume services over IP instead of exchanging statically scheduled signals. A service, identified by a 16 bit Service ID, is a collection of methods, events and fields, and each running copy is an instance.

Methods, events and fields

Methods are remote procedure calls: a REQUEST answered by a RESPONSE or ERROR, or a fire and forget REQUEST_NO_RETURN.

Events are sent by the provider to subscribers, cyclically or on change. Clients subscribe to eventgroups, and every event and field notifier must belong to at least one.

Fields hold state. A field can have a getter, a setter and a notifier; unlike a plain event, the notifier also sends the current value right after a new subscription. A setter is a remote write to state held by another ECU, and whether any client may call it is a policy decision the protocol leaves to the implementation, so flag setters in the threat model.

The SOME/IP header

Every SOME/IP message starts with this header (R25-11):

Header fields are big endian. An AUTOSAR End to End (E2E) header, when used, sits after the Return Code by default; E2E guards against corruption, loss and reordering for safety, which is not sender authentication. Message IDs are assigned by the system designer and assumed unique for the whole vehicle. Session IDs let a client match responses to requests and wrap from 0xFFFF back to 0x01: that is correlation, predictable by design, not a replay defence.

Serialisation and transport

SOME/IP defines serialisation for integers, floats, strings, arrays, structs and unions, plus tag, length, value (TLV) encoding for optional members. The R25-11 change history still tightens deserialisation rules (duplicate members, invalid wire types, short messages). Parsers that trust length fields are a classic source of bugs in any stack, which is one more reason to keep implementations current.

SOME/IP runs over UDP or TCP. The specification recommends UDP payloads of 0 to 1400 bytes, leaving room for IPv6 or added security headers; larger payloads use TCP or SOME/IP-TP segmentation, flagged by bit 0x20 in the message type.

How does SOME/IP Service Discovery find services?

SOME/IP-SD (document 802, R25-11) lets clients find providers and tells subscribers where events will arrive. SD messages are SOME/IP messages with Message ID 0xFFFF8100, Protocol and Interface Version 0x01 and Message Type 0x02 (notification). The specification names UDP port 30490 as the SD port, also the COVESA vsomeip default. The payload carries entries and options.

Entries are the actions. Service entries encode FindService (type 0x00) and OfferService (0x01). StopOfferService uses the same type code with the TTL set to 0x000000, which is why the specification forbids a zero TTL on a normal offer. Eventgroup entries encode SubscribeEventgroup and its acknowledgement or negative acknowledgement. Each entry carries a TTL in seconds (a 24 bit field) that says how long the offer or subscription stays valid.

Options carry endpoint details (IPv4 or IPv6 address, protocol and port), multicast endpoints, a configuration option of name and value pairs based on DNS TXT and DNS-SD, and a load balancing option with priority and weight like DNS SRV. A reboot flag and per relation session counter let receivers detect a restarted peer.

The startup phases

For each service instance, SOME/IP-SD runs through at least three phases:

1. Initial Wait Phase. Entered when the link is up and the service is available or requested; the stack waits a random time within INITIAL_DELAY to spread out startup bursts.
2. Repetition Phase. The stack sends offers or finds up to REPETITIONS_MAX times, and the delay doubles after each message, starting from REPETITIONS_BASE_DELAY.
3. Main Phase. Servers send cyclic offers at CYCLIC_OFFER_DELAY, and the TTL must be at least that long.

The vsomeip documentation lists its own defaults for these settings, including a cyclic offer delay of 1000 ms, a repetition base delay of 10 ms with three repetitions, and an SD TTL default of 0xFFFFFF, which it describes as valid until the next reboot.

What SD does and does not trust

Service Discovery is a directory anyone on the multicast group can write to; no field proves an OfferService came from the intended ECU. The SD specification does expect network security: a client waits for any IPsec, MACsec or other security association before subscribing on a secured port. The protocol specification's security section adds that servers and clients may enforce policies against unauthorised peers, but that such policies are beyond its scope.

So four design decisions belong in every SOME/IP project: which nodes may offer which Service IDs, which may subscribe to which eventgroups, which may call which methods and setters, and what happens when an unexpected offer for a known service appears. A gateway or switch that enforces those rules, plus network layer authentication, is what turns SD from a trust everyone directory into a controlled one.

What is DoIP?

Diagnostics over Internet Protocol (ISO 13400) carries diagnostic services, usually UDS (ISO 14229), over TCP/IP. Our UDS SecurityAccess explainer covers how a tester unlocks protected services; DoIP gets those UDS messages to the right ECU over Ethernet. Part 2 of ISO 13400 defines the transport and network layer. Because ISO texts are paywalled, the details below follow the AUTOSAR Classic module specification AUTOSAR_CP_SWS_DiagnosticOverIP (document 418, R25-11), which cites ISO 13400-2:2019, and the IANA registry, which lists doip-disc (UDP) and doip-data (TCP) on port 13400, registered in January 2011.

The DoIP header and protocol versions

Every DoIP message starts with an eight byte generic header: a protocol version byte, its bitwise inverse (for example 0xFD when the version is 0x02), a two byte payload type and a four byte payload length. The AUTOSAR module accepts protocol version 0x02 when configured for ISO 13400-2:2012 and 0x03 when configured for ISO 13400-2:2019.

Vehicle identification and announcement

A DoIP entity announces itself after startup, and a tester can send a vehicle identification request on UDP, plain or filtered by EID (entity identifier) or VIN. The response carries the VIN, the entity's logical address, its EID and group ID, and a further action byte. In the AUTOSAR module, that byte is set to 0x10 when a routing activation with activation number 0xE0 is configured and has not yet been performed, which tells the tester an additional activation step is still pending, and to 0x00 otherwise.

Routing activation and the diagnostic gateway

A DoIP entity is often a gateway that forwards UDS requests to ECUs behind it on CAN, CAN FD or internal Ethernet. First the tester opens a TCP connection and sends a routing activation request (payload type 0x0005) with its source address, an activation type and an optional OEM specific field. The AUTOSAR module refuses activation for an unknown source address, an address already active on another socket, missing authentication, rejected confirmation, or an activation type that requires a secure socket, and closes sockets that send no activation within a configured time. Once a route is active, diagnostic messages (payload type 0x8001) flow with positive (0x8002) or negative (0x8003) acknowledgements, and alive checks keep track of which tester connections are still present.

The gateway decides which tester may reach which ECU, over which interface, in which vehicle state. Forwarding diagnostics from the wrong interface, such as an infotainment segment, undoes every other control.

TLS in DoIP

The 2019 edition of ISO 13400-2 introduced TLS secured DoIP connections. The AUTOSAR specification reflects this in several requirements. A routing activation that needs security is rejected with response code 0x07 when it arrives on an unsecured connection. A protocol version 0x02 request that tries to activate a secured route on an unsecured connection gets response code 0x06 and the socket is closed. Since R24-11 the module also has an API, DoIP_AllowNonTlsDoIPConnection, that a vehicle maker can call with FALSE so the DoIP module closes unsecured connections and requires the tester to use TLS.

That API is the clearest sign of where the industry is going: plain TCP diagnostics are a configuration choice that can be switched off once the tester fleet supports TLS. The AUTOSAR text does not name a TLS port in the passages we reviewed, and the IANA registry does not list a DoIP specific TLS port, so take the port from your vehicle maker's diagnostic specification rather than from a blog post.

How is automotive Ethernet secured?

There is no single switch for "secure automotive Ethernet". Security comes from several layers, each answering a different question. The table maps them before the details.

SecOC: authenticating PDUs

Secure Onboard Communication is the AUTOSAR module that adds authentication information to a PDU so the receiver can check where it came from and that it is fresh. The Classic Platform specification is document 654, AUTOSAR_CP_SWS_SecureOnboardCommunication, at R25-11. AUTOSAR also published a Foundation protocol specification for SecOC (document 969), first released in R20-11, and the Adaptive Platform's communication management specification defines SecOC behaviour for ara::com services, including a freshness value manager interface.

The model is simple. On the sender, SecOC takes the Authentic I-PDU (the payload that needs protection) and builds a Secured I-PDU that carries the payload, an optional freshness value and an Authenticator, usually a MAC computed over a Data ID, the payload and the full freshness value with a symmetric key. On the receiver, SecOC recomputes the MAC and checks the freshness before passing the payload up. SecOC calls the AUTOSAR Crypto Service Manager for MAC generation and verification (and signatures, if configured), so the keys stay in the crypto stack, ideally inside a hardware security module.

Three design points decide whether SecOC delivers what it promises.

MAC length. Buses with small frames cannot carry a full 128 bit MAC, so SecOC allows truncation. The specification says plainly that truncation lowers the security level against forgery of single MACs, recommends a key length of at least 128 bits, and notes that NIST considers MAC sizes of 64 bits and above sufficient against guessing attacks, with any smaller size requiring careful judgement by a security expert. The predefined Profile 1, for example, uses AES-128 CMAC per NIST SP 800-38B with a 24 bit truncated MAC and an 8 bit truncated freshness value. Ethernet frames have room for much longer authenticators, so a SOME/IP message protected by SecOC rarely needs the same compromises as a CAN frame.

Freshness. The MAC proves origin and integrity; freshness is what stops an old valid message being replayed. SecOC does not prescribe one freshness scheme. It asks a freshness value manager for the current value through functions such as SecOC_GetTxFreshness, and the scheme behind that interface (monotonic counters, synchronised time, or a mix with periodic synchronisation messages) is the vehicle maker's choice. The specification's security event for a failed freshness check notes that, depending on the freshness management, it can indicate a replay attempt. Counters that reset on power cycle, freshness values that receivers accept within a wide window, or a freshness master that is itself unauthenticated all weaken the result.

Keys. SecOC uses whatever keys the crypto stack holds. How they are generated, injected at the end of line, shared between ECUs that exchange a PDU, rotated and revoked is outside the module specification. That is why "document SecOC key management" appears as its own step later in this post.

Finally, SecOC is about authenticity. If a payload is confidential, such as personal data, keys or location, it needs encryption from another layer.

MACsec on vehicle links

MACsec, IEEE 802.1AE, protects Ethernet frames hop by hop with authenticated encryption, and the MACsec Key Agreement protocol from IEEE 802.1X manages the keys. In a vehicle it suits switch to ECU and switch to switch links where every frame should be authenticated, regardless of which protocol it carries. Because it operates per link, frames are decrypted and re-encrypted at each MACsec aware hop, so a compromised switch sees plaintext. Our MACsec explainer covers the frame format and MKA in detail.

MACsec and SecOC solve different problems. MACsec says "this frame came from a device with the link key". SecOC says "this PDU came from an ECU with the key for this signal, and it is fresh". Many architectures use both: MACsec on the backbone to keep unknown devices out, SecOC on the specific messages that control safety relevant functions.

TLS and DTLS for services and diagnostics

For DoIP, TLS as defined in ISO 13400-2:2019 authenticates the tester and the vehicle and encrypts the diagnostic session. For SOME/IP on the Adaptive Platform, the communication management specification includes a (D)TLS section for securing service connections, and the SD specification's guidance on security associations covers the case where only one side may start a TLS or DTLS handshake. TLS is a natural fit for unicast TCP connections; multicast Service Discovery and multicast events cannot use it directly, which is one reason MACsec or IPsec still matter on the same network.

Gateway firewalls, segmentation and intrusion detection

The most effective control on a vehicle network is often the least glamorous: deciding which domain may talk to which. Infotainment, telematics, driver assistance, powertrain and body functions sit in separate VLANs or physical segments, and a central gateway or the zone controllers enforce which flows may cross. For automotive Ethernet that means rules at the level of IP addresses and ports (for example, TCP 13400 only from the diagnostic interface), and for SOME/IP, rules at the level of Service ID, Method ID and eventgroup. Switches can add ingress filtering, VLAN membership and rate limits on multicast discovery traffic.

Intrusion detection on the vehicle network watches for behaviour outside the configured matrix: an unexpected offer for a known Service ID, a burst of SD messages, a diagnostic session at speed, or SecOC verification failures. AUTOSAR provides an Intrusion Detection System Manager and security event reporting; the DoIP module, for example, reports a security event when a routing activation check fails. Detection only helps if someone reads the events, so plan the path from the vehicle's security event memory to whoever runs vehicle security operations.

Access policies inside SOME/IP stacks

Some stacks add their own access control. The COVESA vsomeip documentation describes a security implementation based on UNIX credentials for local connections: when enabled, each local client is authenticated with its user and group IDs, and policies allow or deny which service instances and methods it may request and which it may offer. Two defaults deserve attention. If the security section is present but check_credentials is false, the stack runs in an audit mode that logs violations and allows them. And allow_remote_clients defaults to true, so remote requests and subscriptions reach local services unless you say otherwise. Both are reasonable defaults for development and both are worth reviewing before production.

Where do UN R155, R156 and ISO/SAE 21434 come in?

At concept level, three documents frame everything above.

UN Regulation No. 155 requires a vehicle maker to run a certified Cyber Security Management System and to show, for each vehicle type, that cyber risks were identified and mitigated, including risks in communication channels and diagnostics. Automotive Ethernet, SOME/IP and DoIP are exactly the kind of in vehicle interfaces that risk assessment has to cover.

UN Regulation No. 156 requires a Software Update Management System. Over the air updates are frequently delivered over the Ethernet backbone and installed through diagnostic services, so the integrity of update packages and the access control on the diagnostic path are part of meeting it.

ISO/SAE 21434:2021 is the engineering standard for cybersecurity across the vehicle lifecycle. It is where threat analysis and risk assessment, cybersecurity goals and supplier interfaces (the cybersecurity interface agreement) live. Decisions such as "this SOME/IP setter needs SecOC" or "DoIP must require TLS in production" should trace back to a goal in that analysis.

Our UNECE WP.29 post covers these regulations and their timelines in detail; this post does not repeat them. For background on how software fits into the physical product, see how a car is made.

CAN FD, SOME/IP over Ethernet and DoIP compared

The table makes one point clear. Moving from CAN FD to Ethernet removes the bandwidth constraint that forced truncated MACs, but it does not add authentication by itself. The opportunity is that Ethernet has room for strong authenticators and standard security protocols; the work is configuring them.

Where does SOME/IP live in AUTOSAR Classic and Adaptive?

In the Classic Platform, SOME/IP is not one module but a configuration of several. Signals and PDUs flow from the communication stack through the PDU router to the Socket Adaptor, which maps PDUs to UDP or TCP sockets. A SOME/IP transformer serialises data, SOME/IP-TP handles segmentation, and the Service Discovery module implements SOME/IP-SD. SecOC sits on the PDU path and can protect PDUs whatever the bus. Everything is configured statically, and the communication matrix is generated from the system description.

In the Adaptive Platform, applications use the ara::com communication API, and SOME/IP is one of several network bindings. The R25-11 communication management specification also covers a DDS network binding and signal based bindings, along with SOME/IP-SD handling, identity and access management integration, and secure communication through SecOC and (D)TLS. Adaptive applications run as processes on a POSIX operating system, so the SOME/IP implementation is a library linked into or alongside them.

Open source stacks and what they mean for SBOMs

The best known open source SOME/IP implementation is vsomeip, maintained under the COVESA (Connected Vehicle Systems Alliance) GitHub organisation and licensed under the Mozilla Public License 2.0. Its README describes four shared libraries: the core SOME/IP library (libvsomeip3.so), a configuration module, a Service Discovery library and an E2E protection module. It builds with CMake, needs a C++20 compiler and Boost 1.75.0 or later, and reads its configuration from /etc/vsomeip.json by default.

The project releases regularly. Release 3.7.6, published on 17 September 2026, lists in its changelog among other items a fix for an integer overflow in a payload deserialiser and a fix described as an Android logging vulnerability. Nothing about that is unusual; any active protocol stack fixes parser and logging bugs over time. The point is that a vehicle program which pulled vsomeip in three years ago and never updated it is carrying three years of unapplied fixes, and the only way to know is to have recorded which version shipped.

That is the SBOM question for in vehicle communication. A supplier's software for a zone controller or central compute unit commonly includes:

• a SOME/IP stack (open source or a commercial AUTOSAR implementation),
• a TCP/IP stack and, on POSIX platforms, the operating system's network stack,
• a TLS library for DoIP and service security,
• a crypto library or crypto driver behind the Crypto Service Manager,
• serialisation code generated from the service interface description,
• Boost or similar libraries the stack depends on.

Each one has a version, a licence and its own security fixes. Under the MPL-2.0, if you distribute modified versions of vsomeip's own files, those modifications have to be made available under the same licence, which makes the stack a compliance item as well as a security one. An SBOM that lists these components lets the vehicle maker and supplier answer, quickly and with evidence, whether a newly published vulnerability in one of them affects a given ECU software version.

For Linux based ECUs built with the Yocto Project, the OpenEmbedded build system already generates SPDX SBOM data by default through the create-spdx class, writing an image level .spdx.json file to the deploy directory. Many teams have that file and never send it anywhere.

Step by step: what a supplier should do

The steps below are for a Tier 1 or Tier 2 supplier delivering ECU software that uses automotive Ethernet. They are defensive: inventory, configuration review, bench verification of the controls you designed, and SBOM delivery.

Step 1: Inventory every communication stack and its version

List each stack per ECU software release, with version, source and licence. For CMake projects, search for the package imports; for a Yocto image, read the SBOM the build already produced.

# Find SOME/IP stack imports in CMake projects
grep -rn "find_package(vsomeip3" --include=CMakeLists.txt .

# If vsomeip was installed with its pkg-config file
pkg-config --modversion vsomeip3

# Yocto: the image SBOM is generated by default by create-spdx
ls tmp/deploy/images/${MACHINE}/*.spdx.json

# Pull package names and versions out of the SPDX document
jq -r '.. | objects | select(has("name") and has("versionInfo")) | "\(.name) \(.versionInfo)"' \
  tmp/deploy/images/${MACHINE}/core-image-minimal-${MACHINE}.spdx.json | sort -u | head -50

Record commercial AUTOSAR stacks the same way: vendor, product, version and patch level, even if you cannot list their internals. The SPDX layout differs between Yocto releases, so adjust the jq filter to your output.

Step 2: Write down the communication matrix and its security level

For every SOME/IP service, record the Service ID, instances, which ECU offers it, which ECUs consume it, which methods and setters exist, and the required protection (none, E2E, SecOC, MACsec on the link, TLS). For DoIP, record which interfaces may originate a routing activation, which activation types exist and which require TLS. This matrix is what the gateway rules, SecOC configuration and stack policies are generated or checked against.

Step 3: Document SecOC key management

A one page record per key family avoids most later surprises:

Step 4: Review stack configuration

For vsomeip, check the security and discovery settings in the configuration file before a release. The JSON keys below are documented in the project's configuration guide.

# Is the security section present, is it enforcing, and are remote clients restricted?
jq '.security | {present: (. != null), check_credentials, allow_remote_clients}' /etc/vsomeip.json

# Service Discovery settings: multicast group, port, TTL and offer cycle
jq '."service-discovery" | {enable, multicast, port, protocol, ttl, cyclic_offer_delay}' /etc/vsomeip.json

A production configuration should have check_credentials set to true with explicit policies, allow_remote_clients set deliberately rather than left at its default, and an SD TTL that matches the cyclic offer delay rather than the default that lasts until reboot. For Classic Platform stacks, run the equivalent review in your configuration tool and export the result as evidence.

Step 5: Enforce gateway and switch rules

On a Linux based gateway or zone controller, the network filter is part of the product. The example below is a minimal nftables policy that only lets new DoIP TCP sessions cross from a dedicated diagnostic interface to one internal zone. Interface names are placeholders; adapt them and the zone list to your matrix.

# /etc/nftables.d/doip-gateway.nft  (example only; review against your communication matrix)
table inet vehicle_gw {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iifname "diag0" oifname "zone_front" tcp dport 13400 ct state new accept
  }
}

Many gateways terminate DoIP themselves rather than forwarding it, in which case the equivalent control is the DoIP module's configuration: which testers are known, which activation types require authentication or TLS, and whether non TLS connections are allowed at all.

Step 6: Bench test the controls you designed

Verification should prove the controls work, using your own test equipment on your own bench. Typical test cases:

Keep the results with the software release. They are evidence for the vehicle maker's R155 type approval work and for your own ISO/SAE 21434 activities.

Step 7: Deliver the SBOM with the release

Ship an SBOM (SPDX or CycloneDX) for each ECU software release, listing the communication stacks, TLS and crypto libraries and their versions. Agree in the cybersecurity interface agreement how vulnerability notifications flow between supplier and vehicle maker, and how fast a fix for a communication stack will be delivered.

Common mistakes

DoIP reachable from infotainment or the OBD port without gateway policy. The diagnostic gateway is meant to be the single, controlled entry point. If a routing activation can originate from a segment that also runs third party apps, or if the external diagnostic interface reaches every ECU without authentication, the gateway is not doing its job.

Leaving non TLS DoIP enabled forever. Plain TCP diagnostics are often kept for compatibility with older testers. Set a date to turn them off in production configurations, and use the module's switch to enforce it.

SecOC freshness handled loosely. Counters that reset at power on, acceptance windows wide enough to admit old messages, or a freshness master whose synchronisation messages are not themselves authenticated all reduce SecOC to a checksum with a key.

MAC truncation chosen by habit. Short MACs were a CAN constraint. On Ethernet there is room for longer authenticators. Choose the length per message with a written rationale.

Trusting SOME/IP-SD announcements blindly. If any node can offer any Service ID and consumers accept the first offer they see, discovery becomes the weakest link. Restrict who may offer which services at the switch, gateway or stack level, and alert on unexpected offers.

Treating Session IDs or E2E as authentication. Session IDs correlate requests and responses; E2E protects against faults. Neither proves who sent a message.

Leaving stack security in audit mode. Audit modes exist to build policies. Shipping with violations logged but allowed is an easy oversight.

Unsigned or unverified updates over Ethernet. A fast backbone makes software updates practical; it does not make them safe. Verify package signatures and versions on the target before installation, as UN R156 processes expect.

Leaving the communication stack out of the SBOM. The SOME/IP library, TLS library and crypto code are often delivered as part of a platform and never listed. When a fix appears, nobody knows which ECUs carry the old version.

FAQ

What is the difference between SOME/IP and DoIP?

SOME/IP is the runtime protocol ECUs use to call each other's methods and subscribe to events while the vehicle operates. DoIP is the transport for diagnostic services, mainly UDS, between a tester and the vehicle's ECUs, used in workshops, at the end of the production line and for software updates. Both run over automotive Ethernet; they solve different problems.

Why does automotive Ethernet use a single twisted pair?

Weight, cost and packaging. Office Ethernet at 100 Mb/s and 1 Gb/s uses multi pair cabling, while IEEE 802.3bw and 802.3bp define full duplex operation over one balanced twisted pair designed for the automotive environment. The OPEN Alliance publishes interoperability and conformance test suites for these PHYs.

Which port does DoIP use?

IANA registers port 13400 for DoIP, with UDP for discovery (doip-disc) and TCP for data (doip-data). TLS secured DoIP from ISO 13400-2:2019 is configured per vehicle program, so check your vehicle maker's diagnostic specification for the secured port.

Which port does SOME/IP Service Discovery use?

The AUTOSAR SOME/IP-SD specification names UDP port 30490 as the current SD port, and COVESA vsomeip uses 30490 as its default. SOME/IP services themselves use whatever ports the system designer assigns.

Does SOME/IP have built in security?

No. The header has no authentication field, and the specification leaves access policies to implementations. Security comes from SecOC, MACsec, IPsec, (D)TLS, gateway rules and stack level policies.

Does SecOC encrypt messages?

Not by default. SecOC provides integrity, data origin authentication and freshness through a MAC (or signature) and a freshness value. Use another layer, such as MACsec with confidentiality or TLS, when the content must also be kept secret.

Can MACsec replace SecOC?

Not entirely. MACsec authenticates every frame on a link, so it keeps unknown devices off the network, but it terminates at each hop. SecOC authenticates a specific PDU from end to end, from the sending ECU to the receiving ECU across gateways. Many architectures use both.

Is 10BASE-T1S a replacement for CAN?

It can replace some CAN segments because it supports multidrop topologies at 10 Mb/s with Ethernet framing, which avoids gateways between CAN and Ethernet. It does not automatically bring security: a multidrop segment is a shared medium, so authentication still has to come from higher layers.

What does UN R155 require for SOME/IP and DoIP?

UN R155 does not name specific protocols. It requires a certified cyber security management system and evidence that risks to the vehicle type were assessed and mitigated, which includes communication channels and diagnostic access. See our WP.29 post for the regulation itself.

Should a SOME/IP library be listed in an SBOM?

Yes. A SOME/IP stack is a software component with a version, a licence and security fixes, like any other library. Listing it per ECU software release is what lets a vehicle maker and supplier tell whether a newly published fix applies.

Where Safeguard fits

Safeguard's fit here is indirect, and it is better to say so plainly. Safeguard does not configure vehicle networks, analyse ECU firmware, monitor SOME/IP traffic, test DoIP gateways or manage SecOC keys. It does not generate hardware bills of materials. What it does is software supply chain security for the software your team builds and ships. For an automotive supplier, that includes the SBOMs your build already produces (SPDX or CycloneDX, such as the Yocto image SBOM), the container images used on Linux based compute platforms and in development pipelines, and the repositories for tools, test harnesses and backend services that surround the vehicle software. Safeguard can ingest those SBOM files, scan those repositories and images, show which projects contain a given component and version, match components against vulnerability data, rank findings by reachability and, when a fixed version exists in a supported ecosystem, open a pull request to upgrade it. Commercial AUTOSAR stacks and microcontroller firmware still get their fixes from the vendor that supplies them.

A vehicle's communication software is built from open source parts such as SOME/IP stacks, TLS and crypto libraries, Boost and the Linux network stack on central compute, and every rebuilt ECU image pulls those components again. When one of them has a known vulnerability, the fix still has to reach the build that goes into the ECU, and the steps below cover the open source parts you build yourself.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It asks the assistant to fix a lodash CVE in a JavaScript repository: the CLI reads the finding and advisory, asks before any command that changes something, edits the manifest, runs the install and tests with your approval and pushes nothing. The same flow applies to the services and tools around vehicle software, such as a diagnostic backend, a test harness or a build tool, where a vulnerable dependency needs a version bump and a test run.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. For a supplier, that means a scan can run next to the build that produced an ECU image, against the SBOM file the build wrote, without moving source code off the build host.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how to choose which tools Claude can use. It is a way to ask, from a chat, which projects or SBOMs still list a given version of a library such as a SOME/IP stack or TLS library.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard or read the CLI documentation.

Quick check

Sources

• AUTOSAR standards overview (Classic, Adaptive and Foundation)
• AUTOSAR FO R25-11: SOME/IP Protocol Specification (document 696)
• AUTOSAR FO R25-11: SOME/IP Service Discovery Protocol Specification (document 802)
• AUTOSAR CP R25-11: Specification of Secure Onboard Communication (document 654)
• AUTOSAR FO R24-11: Specification of Secure Onboard Communication Protocol (document 969)
• AUTOSAR CP R25-11: Specification of Diagnostic over IP (document 418)
• AUTOSAR AP R25-11: Specification of Communication Management
• IEEE 802.3bw-2015: 100BASE-T1
• IEEE 802.3bp-2016: 1 Gb/s over a single twisted pair copper cable
• IEEE 802.3cg-2019: 10 Mb/s over a single balanced pair
• IEEE 802.3ch-2020: 2.5, 5 and 10 Gb/s automotive electrical Ethernet
• OPEN Alliance
• IANA Service Name and Transport Protocol Port Number Registry
• NIST SP 800-38B: Recommendation for Block Cipher Modes of Operation, the CMAC Mode for Authentication
• COVESA vsomeip on GitHub
• vsomeip configuration documentation
• vsomeip 3.7.6 release and changelog
• Yocto Project: Creating a Software Bill of Materials
• UNECE: UN Regulation No. 155, Cyber security and cyber security management system (archived copy)
• UNECE: UN Regulation No. 156, Software update and software update management system (archived copy)

Last reviewed: 25 October 2026. AUTOSAR publishes new releases each November and IEEE amendments are folded into IEEE 802.3 revisions; check the current release before citing a requirement or clause.