Cybersecurity is one of the hottest topics in heavy-duty and off-highway system design—and one of the most popular sessions at our recent Innovation Summit. As vehicles become more connected and software-driven, there’s increasing demand for practical, standards-based ways to secure CAN networks.
This is exactly what Raptor Development Team Member Collin Spencer’s session focused on: how emerging standards, J1939-22 and J1939-91C, are reshaping secure communication—and how New Eagle’s Raptor ecosystem enables developers to implement authenticated network architectures today.
Why J1939-22 & J1939-91C Matter for Securing CAN-Based Systems
Back in 2015, a Jeep was famously forced off the road by a white hat hacker team. It continues to be the go-to illustration of how vulnerable classic CAN networks can be and necessary layered protections are. These four layers of protection are preventing external intrusion, isolating traffic through secure gateways, authenticating network communication, and ensuring the integrity of individual ECUs.
This post focuses on the last two layers—authenticated CAN communication and ECU-level protections—and how J1939-22 and J1939-91C make them possible.
The Foundation: Understanding J1939-22
The transition from classic J1939-21 to J1939-22 is based not only in security but also flexibility. Traditional CAN frames are limited to 8-byte payloads with fixed PGN structures. J1939-22 builds on CAN FD so payloads are extended up to 64 bytes. There’s a special PGN embedded in the CAN ID, and it’s even possible to package multiple PGNs into the same CAN frame.
J1939-22 ultimately lays the groundwork for J1939-91C, which—keep in mind—is a network security specification still in the draft stage and has not yet been finalized. It depends on extended payload space, flexible header, and CAN FD bandwidth to deliver authenticated and optionally encrypted messages at usable frequencies.
Enter J1939-91C: Securing Network Communication
The goals of J1939-91C in defining how authenticated CAN FD communication works are straightforward: ensure message freshness, guarantee message authenticity through CMAC, optionally encrypt sensitive data, and establish a consistent, secure method for joining and maintaining trust in a network.
The Three Pillars of J1939-91C
There are three main aspects to network security: network formation, the “rekey,” and secure messaging.
1. Network Formation
Network formation is how nodes in the network establish trust. Each network has a leader, and all other ECUs join as followers, validated through a unique byte sequence acting as proof that it’s communicating with a legitimate node. If any step fails, the device isn’t admitted. If an ECU misbehaves or transmits invalid messages, network reformation can occur to reset trust relationships without taking down the entire system.
2. The Rekey Process
Session keys don’t last forever. To maintain security and prevent issues when freshness counters roll over, the leader periodically triggers a rekey. Each follower processes the new key to keep communication authenticated and synced. Essentially, this is how the network maintains trust while it executes, with different factors, such as frequency, network size, and replay-protection requirements, influencing how often a rekey occurs.
3. Secure Messaging
Finally, secure messaging is how each individual message is secured and sent through the network. Once the network is formed and keys are established, each message includes an assurance header containing the freshness value and a CMAC field. If something is off, the message is ignored rather than allowing the network to be compromised.
These processes, together, ensure that all of the participating ECUs can prove each message is fresh and authentic—and that they know who they’re talking to.
Raptor’s Approach: Implementing J1939-22 and J1939-91C
Raptor also has the ability to function as a J1939-91C gateway. To make secure CAN FD communication practical for developers, New Eagle implements the J1939-22 and J1939-91C layers directly within the Raptor platform.
Raptor Protocol Blocks and Network Security Configuration
A typical J1939-91C frame in Raptor begins with the standard J1939-22 payload, followed by its assurance header—freshness, CMAC, and flags indicating whether the payload is encrypted. Supporting PGNs for rekeying, joining, and secure message exchange are handled through dedicated Raptor protocol blocks.
Raptor’s J1939 channel block supports both gateway and server roles while ensuring compatibility with CAN FD hardware, providing a predictable interface for managing traffic between secure and non-secure subnetworks.
The security configuration block, where secure network behavior is defined, allows developers to register callbacks for debugging, respond to network-formation decisions, or log misbehavior events. Raptor also supports plaintext key provisioning during development and is actively expanding support for hardware security modules (HSMs) to enable fully protected key storage in production environments.
Gateway Functionality
Projects often require isolating subsystems while allowing controlled information flow. Raptor ECUs can act as secure gateways that form subnetworks using J1939-91C, passing only authenticated and authorized traffic between domains. Gateway statistics blocks support monitoring link health, key synchronization status, and message counts—crucial for validating secure network behavior.
Message Transmission, Reception, and Handling Invalid Messages or Rekeys
Raptor’s transmit and receive blocks allow engineers to configure PGNs, attach end-to-end or functional safety (FuSa) metadata, and apply cybersecurity assurance automatically. Built-in FuSa violation reporting ensures that issues are surfaced early and logged consistently, improving diagnosability in complex systems.
One major advantage to Raptor’s implementation is that invalid rekeys or misbehaving nodes do not collapse the entire network. Instead, the problematic ECU is ignored while the broader system continues operating securely, so traffic is only lost from that ECU. One compromised node won’t compromise the entire machine.
What This Means for Developers
The takeaway for controls engineers and system architects? Understanding J1939-22 is essential before implementing J1939-91C. Fortunately, secure CAN FD communication is fully achievable now using Raptor tools to combine authentication, gateway isolation, and structured network-formation logic. Developers don’t need to wait to deploy practical cybersecurity defenses into heavy-duty systems.
Dive Into More Cybersecurity Resources
Regulations on cybersecurity will only get stronger, so it’s important to prepare today to be ready for tomorrow. New Eagle will continue to lead the way in delivering real, deployable cybersecurity solutions that comply with J1939-22 and J1939-91C standards. Whether you missed our recent Innovation Summit or want to refresh your memory on a session, you can dig deeper into the resources available in our Innovation Summit Content Hub—tools, example models, even full Summit sessions.
