In operational technology (OT) networking, the reliability and availability of industrial processes trumps everything, even cybersecurity. But what happens when an OT networking protocol designed to ensure speedy availability of safety-critical communications also embeds a security weakness into the architecture?
Without a full slate of cyber controls folded in, that reliability mechanism could itself become a vehicle for the kinds of industrial failures it’s supposed to help prevent.
“Availability and security are very close to one another,” says Luca Cremona, senior security researcher for Nozomi Networks which Mitsubishi Electric acquired in a roughly $1 billion deal that closed in January. “A protocol that is not secured is not guaranteed to be available.”
Cremona and his colleagues demonstrated this dynamic at play with recent findings they unveiled at Black Hat USA last week in an on-demand-only recorded session that’s available to attendees through September 14. The team showed how weaknesses in Time-Sensitive Networking (TSN) protocols could be abused to ultimately manipulate all the industrial systems it touches.
“What we show in the recorded session is that we can tamper with all of the process variables within the TSN network,” he says. “We can start and stop robotic arms, for example making them open pliers and let the object they’re holding fall down. You can do whatever you want, basically.”
The robotic arm example is the most impactful scenario described, says Cremona. But there are other, quiet attack scenarios their findings demonstrate. This also includes subtly tampering with OT synchronization clocks to inject damaging changes in scheduling of processes.
“You can basically inject some small drift to the clock that’s hard to see or detect, but after an amount of time you will see the effect of. But it will be hard to go back and see when the attack was done,” he explains.
TSN’s Role in Modern Industrial Automation
An up-and-coming timing protocol family in industrial automation that’s crucial for keeping operational technology (OT) reliably available, TSN protocols are basically industrial traffic flow orchestrators. They help solve one of the big challenges with industrial automation today. Namely, that when so many critical process communications and IT network signals share the proverbial Ethernet plumbing, traffic contention becomes a serious safety issue.
In a normal enterprise networking situation, when two packets arrive simultaneously, it’s easy enough to retransmit without any repercussions. But when operational technology (OT) safety communications or synchronized control messages overlap, the collision can create unplanned stoppages that can have real physical consequences in an industrial facility. These messages need to be delivered within microseconds of transmission between controllers and field devices or they risk tripping watchdog timers that put machines into protective shutdown.
TSN was devised as a set of amendments to IEEE bridging specs to provide deterministic communication over standard Ethernet to more sensibly integrate industrial control logic into manufacturing environments. They facilitate prioritization of the most critical traffic classes above all others.
“For example, if you’ve got safety signals for emergency buttons, those are the highest priority and you need to be sure that message is not being blocked by other best-effort traffic that is in that moment congesting the network,” Cremona explains. “So those safety signals need to pass at all costs. And this is managed by TSN.”
Targeting Integrity of One Key TSN Protocol
As Cremona explains, TSN is a fairly new set of protocols. His team’s research is nascent, focusing on one particular protocol, CC-Link IE TSN. This is a Mitsubishi Electric protocol that is among the more widely deployed TSN implementations—and one developed by Nozomi’s own corporate parent. Mitsubishi Electric completed its acquisition of Nozomi in January 2026, six months before the Black Hat session. Nozomi says it operates independently as a wholly owned subsidiary and maintains a vendor-neutral roadmap. Nevertheless, it helped that Nozomi had a working installation of the CC-Link IE TSN available in their security research lab.
As they started to analyze traffic of the protocol, Cremona says that he noticed similarity to an energy distribution system protocol called GOOSE, which has had known problems where a timing sequencing was predictable. Following a hunch, he tried to reproduce attack techniques used against GOOSE in CC-Link IE TSN, eventually finding success with some tinkering. The team reverse-engineered synchronization behavior to predict valid values and manipulat cyclic I/O signals. What the work yielded was a vulnerability in the protocol that makes it possible to inject specially crafted signals into the correct time slot so that they’re received as seemingly legitimate scheduled communications. This flaw was recently warned about in a July 30 CISA ICS advisory.
“And then basically the question was, “Yeah, but to do this attack, I need to be in the TSN network,” he says. “So, I need to be allowed to see and inject traffic in the TSN network that usually is not exposed to external.”
From there, he and his colleagues started stress testing Phoenix Contact TSN switches and through some good-old-fashioned vulnerability research discovered some previously undiscovered bugs that moved the attack chain along. The flaws allowed them to tap into the process port of the switch from the remote management interface that engineers use.
“The most important entry point is the management interface of the TSN switch. So either it is exposed on a broader network or it can be also maybe be reached by a fake device or a tampered device near the network,” he explains. “Once you have access to the management interface of the switch and the switch is vulnerable, like we show in the research, basically you are done.”
Ultimately, their findings show that even though this particular protocol does have a security model and optional cryptographic protection of user data, its shortcomings in Layer 2 safeguards gives attackers an easier path to inject traffic into the communication stream.
Moving Forward to Bolster TSN Security
While the research is limited to a single TSN protocol, Cremona believes that it provides a good starting point for his team and the rest of the industry to start prodding for weaknesses in other protocols that rely on TSN primitives.
On the most immediate level, Cremona says that industrial cybersecurity teams should use this research as a great reminder to keep the firmware of all of their OT network devices as updated as possible. In demonstrated attack scenario, there’s already a firmware patch available for the Phoenix Contact TSN switch management interface flaws that enable the extended attack scenario.
He reports that the Nozomi team is collaborating with its parent company to create long-term remediation for the underlying TSN weaknesses that allow for injection of tampered messages.
“We are considering adding some cryptographic primitives to protect the network and also to prove that the messages are coming from the correct sender,” he says, explaining the challenges comes back to that tension between performance and security. “Adding encryption to a system that needs to be fast is always a pain and in a network that is given a time precision of less than one micro second, it’s harder to add cryptographic primitives that are fast enough to support this.”
However, early testing has proven out that the cryptographic suggestion his team is working on could be feasible.
“We’re collaborating to find the best solution to optimize the trade-off between security timing and constraints,” he says.
As of now, though, the best protection for OT networks is very robust network segmentation for TSN networks.
“Right now, the only way to protect the network is through network segregation,” he says. “You need to keep very separated the networks in order to avoid (attackers) jumping from one network to another without the correct permission.”
Comments are closed