A Secure Dual-MCU Architecture for Robust Communication of IIoT Devices

Dominik Merli; Georg Sigl; Matthias Niedermaier

REVIEW 3 major objections 4 minor 12 references

A Secure Dual-MCU Architecture for Robust Communication of IIoT Devices

T0 review · 3 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A two-microcontroller split isolates a PLC's physical process from network attacks.

desk verdict Measured timing isolation is real, but the paper's central security claim outstrips the evidence and needs a rewrite. read the letter →

arxiv 1908.04133 v1 pith:LJKJLAUW submitted 2019-08-12 cs.CR

Matthias Niedermaier , Dominik Merli , Georg Sigl This is my paper · ORCID

classification cs.CR

keywords dualmicrocontrollerarchitectureIIoTsecurityPLCcycletimedenialofservicenetworkfloodingreal-timecontrolSPIisolationindustrialsystems

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that the safest way to build an IIoT controller such as a PLC is to give it two microcontrollers: one that faces the network and one that alone touches the physical inputs and outputs. The network-facing chip can be slowed, flooded, or compromised without changing what the control chip does, because the control chip runs a fixed 1 ms loop and treats every exchange with the network chip as a bounded, 500 µs timeout. The authors demonstrate this with a proof-of-concept built from a Cortex-M7 network board and a Cortex-M0 IO shield, and they measure the cycle time under an hping3 flooding attack: their setup stays within roughly 1% jitter while a commercial Wago PLC slows by up to a factor of ten. The paper's concluding claim, that even weak points in network software leave the physical process unaffected, is presented as the architectural consequence of this timing isolation.

What carries the argument

The central mechanism is the timed SPI boundary between the two MCUs. The IO MCU implements a constant-cycle control loop in which the communication phase is a blocking transaction with a hard 500 µs timeout, and a wait state absorbs any remaining time up to the 1 ms cycle budget. This turns the network side into a best-effort producer: it can be busy, crash, or be flooded, but it cannot delay the physical outputs beyond the fixed budget. The bare-metal IO program, with no interrupts or DMA in the communication path, is what makes the timing predictable.

What would settle it

Drive the network MCU, or an emulator in its place, to saturate the SPI link: repeatedly start transactions that run to the full 500 µs timeout, hold chip-select low, or send continuous invalid data, while measuring the IO MCU's output-toggle period over 60 s. If the cycle time leaves the 1 ms budget by more than the observed ~1% jitter, or outputs stop updating, the paper's central isolation claim is falsified.

Watch

Extended reading notes

Core claim

The paper claims that splitting an IIoT device into a network MCU and an IO MCU makes control robust against network-side influence. The IO MCU runs a bare-metal cycle with a fixed 1 ms period: read inputs, perform a blocking SPI exchange with the network MCU under a 500 µs timeout, calculate the new output states, pad with a wait delay to reach exactly the configured cycle time, then write outputs. Because the timeout bounds the communication phase, the network MCU has no way to stretch the control loop; if a transmission is missed, the IO MCU proceeds with the cycle and simply uses the previous data. Benchmarking with hping3 flooding shows the cycle time of the proof of concept varying by about 1%, while the compared commercial PLC's cycle time is measurably delayed. The paper concludes that physical controlling is not affected by vulnerabilities in the network stack or operating system, and that the dual-MCU design is a feasible solution against DoS-type network attacks.

Load-bearing premise

The design depends on the IO MCU always finishing its read-SPI-calculate-write loop inside the chosen 1 ms cycle, with the 500 µs SPI timeout as the hard bound on communication; if a compromised network MCU can make SPI exchanges consume more than that bound or stall the bus, the constant cycle time is no longer guaranteed.

Editorial extensions

If this is right

Network flooding that only loads the communication side will not stretch the physical control cycle, so output timing stays within the configured 1 ms budget.
The IO-side code is deliberately small and simple, which the paper argues reduces testing and certification effort for the safety-critical portion of the device.
Because the IO MCU is a cheap standard part, the added cost of the second microcontroller is small compared with the price of a typical PLC.
Multiple-of-1 ms cycle times can be configured, so the design can match the response-time requirements of commercial PLCs.
A unidirectional link from the IO MCU to the network MCU would allow monitoring of the process without giving the network side any path to influence it.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The benchmark floods only the Ethernet side; a natural next test is to make the network MCU itself hostile and force the SPI transaction to consume its full 500 µs timeout every cycle, or to hold the SPI bus, and see whether the 1 ms cycle budget still holds.
Timing isolation is separate from data integrity: a compromised network MCU could send a plausible but wrong value over SPI, and the IO loop would write it out on schedule. The paper's measured claim covers timing, not authenticity of the data.
The same two-chip split could extend beyond PLCs to any real-time field device whose network latency can be bounded by a timeout, such as drives or remote I/O units.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The paper is worth a look for the measured timing isolation, but the security claim attached to it is broader than what the experiment supports.

What's new: a concrete dual-MCU PoC on cheap off-the-shelf parts, showing a 1 ms IO cycle with jitter under ~1% while the network MCU is being flooded with hping3. That is a solid engineering data point, and the comparison with a Wago PLC makes the point vividly. The delay-compensation calculation in Eq. 2 is trivial, but the implementation detail of a 500 µs SPI timeout on the IO side is a reasonable way to bound communication time.

The soft spot is the conclusion. The paper says a vulnerability in the network stack or OS cannot affect the physical process, and in Section 4 it asserts 'the SPI communication cannot influence the IO MCU.' That is not established. The NW MCU is the SPI master, sends data to the IO MCU without any authentication, and runs a web server that can change output cycle-time configuration. A compromised NW MCU can send forged output values or configuration frames, and the IO MCU will act on them. The benchmark only floods Ethernet; it never exercises adversarial SPI content. So the evidence supports timing isolation under one attack type, not integrity or availability under a compromised communication peer.

The fix is straightforward: either add a one-way data diode or authenticate every SPI frame and limit the configuration interface, or rewrite the claims to say the architecture protects timing against network flooding. The current phrasing overreaches.

This is a preliminary engineering report, not a finished security architecture. The right audience is embedded/ICS security people looking for low-cost hardening patterns. I'd send it to peer review, but with the expectation of major revision. The reviewer should push on the SPI trust model.

Referee Report

3 major / 4 minor

Summary. The paper proposes a dual-MCU architecture for IIoT devices such as PLCs, in which a network MCU handles Ethernet/Modbus communication and a separate IO MCU runs the time-critical control loop on a fixed 1 ms cycle. The authors implement a proof-of-concept using an STM32F767 network board and a custom STM32F030 IO shield, with SPI as the inter-MCU link and a delay-compensation mechanism (Eq. 2) to keep the IO cycle time constant. They benchmark the implementation under hping3 flooding, report cycle-time jitter of about 1%, and compare it with a Wago PLC that shows much larger cycle-time degradation. The conclusion claims that, even with vulnerabilities in the network stack or OS, the physical process is not affected.

Significance. If the narrow claim is accepted, the paper provides a low-cost and conceptually simple architecture that isolates the timing of the physical control loop from network-side flooding, which is a practical concern for PLCs. The PoC is clearly described, the delay equation is straightforward, and the oscilloscope measurements directly support the timing-isolation result under the tested attack. However, the paper's broader security claim—that a compromised network stack cannot affect the physical process—is not supported by the experiments, which cover only Ethernet flooding and treat the SPI link as unauthenticated and potentially manipulable. The architecture could be a useful building block, but its security contribution is currently overstated.

major comments (3)

[Section 5 (Conclusion), also Abstract and Section 1] The central claim that 'even with weak points in the software implementation, e.g. vulnerabilities in the network stacks or the operating system, the physical process is not affected' exceeds the measured evidence. The experiments demonstrate only that the IO MCU's cycle time is stable under hping3 flooding on the network side; they do not demonstrate protection of the physical process against data manipulation by a compromised network stack. Because the NW MCU is the SPI master and transmits unauthenticated control data (Section 3.2.1), and the web server can change the output cycle-time configuration (Figure 3), a network-stack code-execution vulnerability could send forged output values or configuration frames that the IO MCU would act upon. The conclusion should be narrowed to 'the timing of the physical control loop is not affected by network flooding' or the architecture must add integrity protections (e.g., authenticated commands or a one-way data diode) to justify the stronger statement.
[Section 4 (Benchmarking)] The sentence 'the SPI communication cannot influence the IO MCU' is asserted without a mechanism and is contradicted by the architecture itself. Section 3.2.2 describes how the IO MCU reads SPI data and uses it to compute output states, and the paper explicitly states that 'the current PoC is not protected by cryptographic mechanisms.' If the NW MCU is compromised, it can write arbitrary values to the SPI link, and those values directly determine the physical outputs. The assertion should be removed or replaced with a precise statement about timing isolation, not causal influence.
[Section 3.2.2 and Section 4] The timing-isolation result rests on the assumption that the IO MCU always completes its loop within the 1 ms cycle, bounded by the 500 µs SPI timeout. The benchmark, however, only exercises Ethernet flooding with hping3 and never tests adversarial behavior on the SPI bus, such as holding the bus, sending repeated SPI timeouts, or flooding frames from a compromised NW MCU. If the NW MCU is malicious, it could attempt to delay the IO MCU past its deadline, and the paper provides no measurements or worst-case analysis for this scenario. Without such evidence, the robustness claim for the dual-MCU separation is incomplete.

minor comments (4)

[Section 3.2.2 and Figure 7] Figure 7's caption says 'A constant cycle time is set to 10ms during all phases,' while the text states the IO MCU's cycle time is 1 ms and the output is toggled every 10 cycles. Please clarify whether the measured quantity is the 1 ms internal cycle or the 10 ms output period, as the current wording is confusing.
[Section 4] The benchmark description does not specify the hping3 command, packet rate, packet size, or network topology, which are essential for reproducing the measurement. Please include these details, and report the number of independent runs and any confidence intervals for the jitter measurements.
[Section 3.1.1] There is a typo in the hardware description: 'Arudino™ Uno V3' should be 'Arduino™ Uno V3'.
[Title and Abstract] In the preprint, the title appears as 'A Secure Dual-MCU A RCHITECTURE for Robust Communication of II OT D EVICES' with odd spacing; please ensure the final version has correct formatting. Also, the abstract contains the phrase 'II OT' instead of 'IIoT.'

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the dual-MCU design is benchmarked against flooding, and Eq. 2 is an explicit time-filling identity rather than a fitted prediction.

full rationale

The paper's derivation chain is self-contained. Eq. 1 defines the cycle time as the sum of four phases; Eq. 2 defines the inserted delay as the residual needed to reach a chosen cycle time. This is an implementation control equation, not a quantity fitted to the benchmark and then renamed a prediction. The PoC hardware and software are described before measurement; the hping3 benchmark then directly measures whether the IO cycle remains constant. No parameter used in the security claim is fitted from the benchmark outcome. Prior self-citations ([2], [4]) motivate the problem by showing that single-MCU PLCs can be slowed by network traffic, but they do not enter the architecture derivation or the PoC measurement, so they are not load-bearing. The conclusion's overreach (inferring integrity protection from a flooding/availability test) is a scope-of-evidence issue, not a circularity issue; the central engineering claim is supported by an independent PoC measurement.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The central claim rests on the assumption that the cycle-time decomposition and the SPI timeout mechanism are valid and that hardware separation prevents all network-side timing influence. No numbers are fitted to data; the 1 ms cycle time is a design choice, not a fitted parameter.

assumptions (3)

domain assumption A PLC cycle time is the sum of input read, communication, calculation, and output write phases.
Used in Section 2 to justify the delay formula (Eq. 1 and Eq. 2); assumes these phases are sequential and measurable.
ad hoc to paper SPI communication between the two MCUs can be bounded by timeouts such that the IO MCU always completes within its 1 ms cycle.
The PoC relies on the 500 us SPI timeout and the bare-metal loop to maintain the fixed cycle, but no adversarial SPI test is provided.
domain assumption The two MCUs are electrically isolated enough that network-side events cannot interrupt the IO MCU.
The architecture assumes hardware separation is sufficient; the paper mentions power supply separation as future work, so currently this is not guaranteed.

how reviews work

0 comments

Cite this review

Pith. "Pith review of A Secure Dual-MCU Architecture for Robust Communication of IIoT Devices." pith.science (2026). https://pith.science/paper/LJKJLAUW

@misc{pith2026190804133,
  author       = {Pith},
  title        = {Pith review of: A Secure Dual-MCU Architecture for Robust Communication of IIoT Devices},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LJKJLAUW}},
  note         = {Machine review of arXiv:1908.04133}
}

read the original abstract

The Industrial Internet of Things (IIoT) has already become a part of our everyday life be it water supply, smart grid, or production, IIoT is everywhere. For example, factory operators want to know the current state of the production line. These new demands for data acquisition in modern plants require industrial components to be able to communicate. Nowadays, network communication in Industrial Control Systems (ICSs) is often implemented via an IP-based protocol. This intercommunication also brings a larger attack surface for hackers. If an IIoT device is influenced by attackers, the physical process could be affected. For example, a high network load could cause a high Central Processing Unit (CPU) load and influence the reaction time on the physical control side. In this paper, we introduce a dual Microcontroller Unit (MCU) setup to ensure a resilient controlling for IIoT devices like Programmable Logic Controllers (PLCs). We introduce a possible solution for the demand of secure architectures in the IIoT. Moreover, we provide a Proof of Concept (PoC) implementation with a benchmark and a comparison with a standard PLC.

Figures

Figures reproduced from arXiv: 1908.04133 by the authors.

**Figure 2.** Rendered controller shield that is placed on top of the network MCU board. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

**Figure 3.** Website, running on the network MCU, showing some information and allowing configuration of the network [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Figures from the paper (7 more)

**Figure 4.** Figure 4: Program sequence to have a defined time behavior of the IO MCU. The dashed circle “Wait time” is the [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]

**Figure 5.** Figure 5: Image showing the complete setup with the network MCU board and the IO shield. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

**Figure 6.** Figure 6: Time plot of the 1ms cycle time during pre-idle, attack, and post-idle of our secure implementation. The [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]

**Figure 7.** Figure 7: Boxplot of the cycle time of our approach during hping3 attack. A constant cycle time is set to [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]

**Figure 8.** Figure 8: Boxplot of cycle time of the Wago PLC during hping3 attack, with variances during idle and influences [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]

**Figure 9.** Figure 9: Density plot of the 10ms cycle time of our implementation during hping3 attack. 7 [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]

**Figure 10.** Figure 10: Density plot of the cycle time of the Wago PLC during hping3 attack influenced during the attack. [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

12 extracted references · 12 canonical work pages

[1]

Exploiting Siemens Simatic S7 PLCs,

D. Beresford, “Exploiting Siemens Simatic S7 PLCs,” Black Hat USA, vol. 16, no. 2, pp. 723–733, 2011

work page 2011
[2]

PropFuzz - An IT-security Fuzzing Framework for Proprietary ICS Protocols,

M. Niedermaier, F. Fischer, and A. von Bodisco, “PropFuzz - An IT-security Fuzzing Framework for Proprietary ICS Protocols,” in 2017 International Conference on Applied Electronics (AE), Pilsen , pp. 1–4, 2017

work page 2017
[3]

ICS/SCADA Security Analysis of a Beckhoff CX5020 PLC,

G. Bonney, H. H ¨ofken, B. Paffen, and M. Schuba, “ICS/SCADA Security Analysis of a Beckhoff CX5020 PLC,” in Information Systems Security and Privacy (ICISSP), 2015 International Conference on , pp. 1–6, IEEE, 2015

work page 2015
[4]

You Snooze, You Lose: Measuring PLC Cycle Times under Attacks,

M. Niedermaier, J.-O. Malchow, F. Fischer, D. Marzin, D. Merli, V . Roth, and A. von Bodisco, “You Snooze, You Lose: Measuring PLC Cycle Times under Attacks,” in 12th USENIX Workshop on Offensive Technologies (WOOT 18)

work page
[5]

Research Challenges for the Security of Control Systems.,

A. A. C ´ardenas, S. Amin, and S. Sastry, “Research Challenges for the Security of Control Systems.,” inHotSec, 2008

work page 2008
[6]

Secure Control: Towards Survivable Cyber-Physical Systems,

A. A. C ´ardenas, S. Amin, and S. Sastry, “Secure Control: Towards Survivable Cyber-Physical Systems,” in Distributed Computing Systems Workshops, 2008. ICDCS’08. 28th International Conference on , pp. 495–500, IEEE, 2008

work page 2008
[7]

Design and Implementation of Modbus Slave based on ARM Platform and FreeRTOS Environment,

T.-S. Nguyen and T.-H. Huynh, “Design and Implementation of Modbus Slave based on ARM Platform and FreeRTOS Environment,” inAdvanced Technologies for Communications (ATC), 2015 International Conference on, pp. 462–467, IEEE, 2015

work page 2015
[8]

Protection of Control Networks Using a One-way Link,

A. Zilberstein and L. Frenkel, “Protection of Control Networks Using a One-way Link,” Jan. 19 2010. US Patent 7,649,452

work page 2010

Show all 12 references

[9]

Analysis of a Denial of Service Attack on TCP,

C. L. Schuba, I. V . Krsul, M. G. Kuhn, E. H. Spafford, A. Sundaram, and D. Zamboni, “Analysis of a Denial of Service Attack on TCP,” in Security and Privacy, 1997. Proceedings., 1997 IEEE Symposium on , pp. 208–223, IEEE, 1997

1997
[10]

Safety Evaluation of Physical Human-Robot Interaction via Crash-Testing,

S. Haddadin, A. Albu-Sch ¨affer, and G. Hirzinger, “Safety Evaluation of Physical Human-Robot Interaction via Crash-Testing,” inRobotics: Science and Systems , vol. 3, pp. 217–224, 2007

2007
[11]

Secured Microcontroller Architecture,

T. L. Fruehling and T. L. Helm, “Secured Microcontroller Architecture,” Dec. 27 2005. US Patent 6,981,176

2005
[12]

Embedding Encryption and Machine Learning Intrusion Prevention Systems on Programmable Logic Controllers,

T. Alves, R. Das, and T. Morris, “Embedding Encryption and Machine Learning Intrusion Prevention Systems on Programmable Logic Controllers,” IEEE Embedded Systems Letters , 2018. 8

2018

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [1]

Exploiting Siemens Simatic S7 PLCs,

D. Beresford, “Exploiting Siemens Simatic S7 PLCs,” Black Hat USA, vol. 16, no. 2, pp. 723–733, 2011

work page 2011

[2] [2]

PropFuzz - An IT-security Fuzzing Framework for Proprietary ICS Protocols,

M. Niedermaier, F. Fischer, and A. von Bodisco, “PropFuzz - An IT-security Fuzzing Framework for Proprietary ICS Protocols,” in 2017 International Conference on Applied Electronics (AE), Pilsen , pp. 1–4, 2017

work page 2017

[3] [3]

ICS/SCADA Security Analysis of a Beckhoff CX5020 PLC,

G. Bonney, H. H ¨ofken, B. Paffen, and M. Schuba, “ICS/SCADA Security Analysis of a Beckhoff CX5020 PLC,” in Information Systems Security and Privacy (ICISSP), 2015 International Conference on , pp. 1–6, IEEE, 2015

work page 2015

[4] [4]

You Snooze, You Lose: Measuring PLC Cycle Times under Attacks,

M. Niedermaier, J.-O. Malchow, F. Fischer, D. Marzin, D. Merli, V . Roth, and A. von Bodisco, “You Snooze, You Lose: Measuring PLC Cycle Times under Attacks,” in 12th USENIX Workshop on Offensive Technologies (WOOT 18)

work page

[5] [5]

Research Challenges for the Security of Control Systems.,

A. A. C ´ardenas, S. Amin, and S. Sastry, “Research Challenges for the Security of Control Systems.,” inHotSec, 2008

work page 2008

[6] [6]

Secure Control: Towards Survivable Cyber-Physical Systems,

A. A. C ´ardenas, S. Amin, and S. Sastry, “Secure Control: Towards Survivable Cyber-Physical Systems,” in Distributed Computing Systems Workshops, 2008. ICDCS’08. 28th International Conference on , pp. 495–500, IEEE, 2008

work page 2008

[7] [7]

Design and Implementation of Modbus Slave based on ARM Platform and FreeRTOS Environment,

T.-S. Nguyen and T.-H. Huynh, “Design and Implementation of Modbus Slave based on ARM Platform and FreeRTOS Environment,” inAdvanced Technologies for Communications (ATC), 2015 International Conference on, pp. 462–467, IEEE, 2015

work page 2015

[8] [8]

Protection of Control Networks Using a One-way Link,

A. Zilberstein and L. Frenkel, “Protection of Control Networks Using a One-way Link,” Jan. 19 2010. US Patent 7,649,452

work page 2010