Engineering & Architecture Brief Published: 2026-11-15
With a centralized freshness value manager, every authenticated PDU on the bus depends on one ECU broadcasting synchronization messages. A distributed design gives each sender its own monotonic counter in non-volatile memory, and no single node can stall the network's authentication. Both designs stop replay attacks equally well while everything is running. They behave very differently once the gateway browns out, an ECU loses its NVM, or a workshop swaps a module, and whichever failure your vehicle cannot afford should decide your architecture.
Two ways to keep a counter honest In the centralized scheme, a master, usually the central gateway, owns a trip counter and a reset counter and broadcasts them in a dedicated sync message. Each sender builds its freshness value from those received high-order parts plus a local message counter that clears on every reset tick. Only the low bits go on the wire next to the truncated CMAC, and the receiver rebuilds the full value from the last sync it saw. The appeal is operational. Senders never persist the fast-moving part of the counter, so NVM wear stays out of the picture, a replaced ECU picks up the current state from the next broadcast, and cybersecurity engineering standards such as ISO/SAE 21434 get one clearly bounded asset to argue about. The distributed alternative removes the master. Every sender keeps a full-width counter per secured PDU, writes it to NVM on a schedule that survives power loss without going backwards, and each receiver tracks the last accepted value for every sender it listens to.
The failure that decides it The centralized scheme is fine as long as the master keeps ticking. When the gateway reboots, hangs in a watchdog loop or drops off a partitioned bus, the reset counter freezes, and every sender keeps incrementing its local message counter with nothing to clear it. Once that counter hits the top of its range, the sender has no fresh value left that it could legitimately use. It can either stop authenticating, which means receivers drop its frames, or roll over, which reopens exactly the replay window SecOC exists to close. So the real limit is headroom: the message counter range multiplied by the PDU cycle time. For a brake or steering torque request sent every 10 ms with a narrow message counter, that headroom can be only a few seconds (an estimate, depending on the counter width you allocate), and a gateway cold boot with secure boot verification can easily take longer.
Where the choice flips Here is the rule: work out the headroom for every safety-relevant secured PDU, compare it with the longest master outage your degraded-mode concept must ride through until a safe stop or a limp-home state is established, and choose distributed counters for any PDU whose headroom is shorter, because below that point the central master is a single point of failure for the actuator chain. Above that point the centralized design is the better choice. Its weaknesses all show up during service and power cycling, which is when distributed counters cause the most trouble: an ECU whose NVM write was lost to a brownout restarts below its last transmitted value and gets rejected by every receiver, and a factory-fresh replacement module needs a key and counter provisioning step that dealers get wrong. Many programs end up with a mix. Chassis and powertrain control loops run independent counters with a generous acceptance window, and comfort and body traffic stays on the master, which keeps the NVM write budget limited to the few PDUs that actually need it.
Widening the message counter looks like a cheap way out, but each extra bit sent in the PDU costs payload on a classic CAN frame that is already holding a truncated MAC, so on legacy CAN the bus load budget, and not the crypto, often decides which side of the boundary a signal ends up on.
Technical FAQ: Can the receiver simply accept frames without verification while the freshness master is down? Only if the safety case explicitly allows unauthenticated operation for that signal, and most cybersecurity concepts will not, because an attacker who can force a gateway reset would then get a guaranteed window with no authentication. A safer pattern is to let receivers fall back to a widened acceptance window for a bounded time, and then to a defined safe state when that time runs out.