RESEARCH NOTE 01
Scientific foundations: connected critical embedded systems, OTA/RF surfaces and resilience to PDoS attacks
Conceptual framework, architectures, exposure vectors and research positioning
ABOUT THIS NOTE
A living research document.
This note constitutes the first in-depth work associated with the research programme “Resilience of embedded systems to PDoS attacks”.
It constitutes neither a thesis chapter nor a peer-reviewed scientific publication. It sets the conceptual framework from which threat models, experimental protocols, detection methods and recovery mechanisms will be progressively developed.
Established by literatureMethodologically proposedTo be validated experimentally
SUMMARY
Conceptual framework of Note 01
The digital transformation of physical systems is accompanied by a profound evolution of their security architecture. Connected vehicles, drones, industrial equipment, medical devices, IoT gateways, edge platforms, mobile terminals and space systems now integrate complex software, remote update mechanisms and different wireless communication interfaces.
This connectivity improves maintainability, allows rapid deployment of fixes and promotes the functional evolution of equipment after it is put into service. However, it modifies the nature of their exposure. An interface that legitimately allows you to download firmware, modify a configuration, send a command or administer equipment can also become the path by which an attacker seeks to reach its persistent state.
In this context, Permanent Denial of Service — PDoS attacks occupy a special position. Unlike a traditional denial of service, the effect of which generally disappears with the end of the saturation or disruption, a PDoS aims for a sufficiently deep degradation of the system so that availability cannot be restored by ordinary operating mechanisms. The damage may involve the firmware, the boot process, a persistent configuration, a critical software component, or in some scenarios, the hardware itself. Recovery may then require a privileged procedure, an out-of-band reflash, restoration from a trusted image, intervention from the manufacturer or, in the most severe cases, replacement of components. This design directly aligns with NIST's work on firmware resilience, structured around three capabilities: protect, detect and recover.
This note establishes the conceptual foundations of the research programme. It defines the category of systems considered, analyzes the distinct roles of Over-The-Air — OTA and Radio Frequency — RF communications, describes the layers likely to be affected by persistent compromise, and examines several representative application environments. It also specifies the place of this issue in the current repositories of firmware resilience, secure update and cybersecurity of connected equipment.
The objective is not, at this stage, to demonstrate the existence of a universal detection or recovery architecture. It is necessary to establish sufficiently precisely what must be observed, protected and recovered before constructing the experiments which will then allow the project's hypotheses to be tested.
01 — FOUNDATIONS
From an isolated embedded device to a connected, evolving system
An embedded system can be defined, in its general sense, as a computer system integrated into larger equipment and designed to provide one or more specific functions.
Its purpose is therefore not to offer a general IT platform but to participate directly in the operation of a device: regulate a motor, control an actuator, execute a control law, monitor a patient, manage a radio communication, process data from a sensor or ensure a safety function.
This definition nevertheless covers a great deal of diversity.
A microcontroller using a few tens or hundreds of kilobytes of memory, a flight controller, an embedded Linux gateway and an edge computer equipped with a multi-core SoC all belong to the embedded world, but their constraints and their defense capabilities are radically different.
Three transformations have particularly modified their security model.
The first is connectivity.
Many formerly isolated systems now have Wi-Fi, Bluetooth Low Energy, cellular links, proprietary radio interfaces, industrial networks or other means of communication enabling external interactions.
The second is software-defined evolution.
A growing part of the functional capabilities of the equipment depends on software that can be modified after its deployment: firmware, applications, artificial intelligence models, configurations or operational parameters.
The third is remote maintenance.
When millions of devices are distributed geographically, their manual maintenance becomes economically or operationally impossible. Remote update mechanisms then become a normal part of the life cycle.
These three evolutions produce a fundamental change: the equipment can continue to evolve after leaving its design environment and this evolution can be triggered remotely.
This is a major operational advantage.
It is also a new frontier of trust.
Connected critical embedded system: operational definition
The term “criticism” should be used with caution.
Not all connected systems are critical systems, and not all embedded systems have the same consequences when they become unavailable.
In this research, criticality is considered according to several complementary dimensions:
potential consequences for physical security; interruption of an essential service; loss of operational capacity; cost or difficulty of recovery; loss of equipment that is difficult to access; attack on the integrity of a cyber-physical process; dependence of other systems on the compromised equipment. Proposed operational definition
For the purposes of the research programme, we will designate as a connected critical embedded system a system:
1. whose software or firmware operation directly contributes to a function whose loss could result in a significant operational consequence;
2. having at least one interface allowing remote interaction, directly or indirectly;
3. having persistent software or configuration state that is subject to modification;
4. and for which corruption of this state can produce lasting unavailability or make recovery significantly more difficult than a simple restart.
This definition is deliberately oriented towards the problem studied.
It does not seek to replace the normative definitions specific to the automobile, medical, space or industrial sectors.
It is used to identify common properties necessary for the study of PDoS scenarios.
| Family | Typical architecture | Dominant constraints | Examples |
|---|---|---|---|
| MCU constrained | Cortex-M/RISC-V MCU | Memory, energy, real time | Controllers, sensors, connected objects |
| Cyberphysical controllers | MCU+RTOS | Determinism, safety, actuation | Pixhawk, robotics, drones |
| Embedded Linux | Cortex-A/SBC | Larger software surface | Gateways, edge devices |
| Edge AI | Multi-core SoC + accelerator | Power, software complexity | Jetson Orin |
| Mobile platforms | SoC + complex OS | Boot chain, OTA, isolation | Android |
| Specialized systems | Specific architectures | Accessibility, safety, endurance | Space, industrial, medical |
Heterogeneity of platforms and consequences for security
The first scientific difficulty of this research is due to heterogeneity.
Two devices exposed to the same category of attack may have completely different boot chains, update mechanisms and recovery capabilities.
Several architectural families can be distinguished.
Family Typical architecture Dominant constraints Examples Constrained MCU Cortex-M, RISC-V MCU memory, energy, real time controllers, sensors, connected objects Cyberphysical controllers MCU + RTOS determinism, safety, actuation Pixhawk, robotics, drones Embedded Linux Cortex-A / SBC larger software surface gateways, edge devices Edge AI Multi-core SoC + power accelerator, software complexity Jetson Orin Mobile platforms SoC + OS complex boot chain, OTA, Android isolation Systems specialized specific architectures accessibility, safety, endurance spatial, industrial, medical
The consequence is immediate: a method designed for Linux cannot be assumed to be applicable as is to a microcontroller.
Conversely, a method that is lightweight enough for an MCU may not have the richness of observation available on a Linux system.
The portability sought in this programme should therefore not be understood as the identical reproduction of the same code or the same model on each system.
It rather corresponds to the search for a portable methodological base:
categories of observable signals; principles of detection; decision architecture; evaluation metrics; recovery logic; method of experimentation.
Implementations may remain specific to each platform.
02 — ARCHITECTURE
Generic functional architecture
Despite this heterogeneity, a common conceptual representation can be constructed.
For this research, a connected system likely to be exposed to a PDoS can be represented by six layers.
Layer 1 — Hardware
It includes the processor or microcontroller, volatile and non-volatile memories, peripherals, internal buses, hardware security components and radio interfaces.
It constitutes the physical root of the system.
Layer 2 — Root of Trust and Bootstrapping
This layer may include, depending on the architecture:
Boot ROM; bootloader; Secure Boot mechanisms; hardware rooted keys; TPM or similar components; Trusted Execution Environment; integrity verification mechanisms.
Its role is critical because a sufficiently deep compromise of the boot chain can prevent higher layers from reestablishing a trusted state.
Layer 3 — Firmware / operating system
It includes the main firmware, the RTOS or embedded OS as well as certain critical components running with elevated privileges.
Layer 4 — Applications and business logic
This layer carries out the operational function of the system.
In a cyber-physical environment, it can be directly linked to physical actuators or decisions.
Layer 5 — Management and updating
This layer brings together the administration, configuration, provisioning, FOTA/SOTA, recovery and software lifecycle management mechanisms.
Layer 6 — Communication interfaces
It represents the means by which data and commands reach the system:
Wi-Fi, BLE, Ethernet, cellular, dedicated radio, USB, local buses, application protocols, remote maintenance interfaces, etc.
This distinction is important because the communication channel and the mechanism actually operated must not be confused.
An attack can use a radio link as a means of access while exploiting a vulnerability located in an application or in the OTA process.
03 — OTA SURFACE
OTA: updating a system means granting it the right to transform
Remote updating has become a normal part of security.
Unmaintainable equipment is difficult to protect over time: vulnerabilities discovered after its deployment must be able to be corrected.
The OTA allows in particular:
fix vulnerabilities; to improve the functioning of the system; to renew keys or certificates; to modify a configuration; add features; to address problems discovered after marketing.
OTA is therefore not a security problem in itself.
On the contrary, a properly designed OTA mechanism is an essential security mechanism.
The paradox is that it has, by definition, the ability that an attacker would also look for: modifying the persistent software state of the equipment.
The chain of trust for an update
An update should not be considered as a simple file download.
This is a chain of trust.
It may include:
production of the image → signature → publication → distribution → reception → verification → installation → start-up → validation → possible recovery
Compromise can occur at different levels.
It may concern:
the construction system; signing keys; the publishing server; distribution infrastructure; the communication protocol; the parser or update manager; cryptographic verification; the version mechanism; writing in memory; the choice of boot partition; the rollback procedure; the recovery system.
This approach is particularly important because TLS alone is not a sufficient guarantee of firmware security.
Transport protection does not replace verification of the delivered object.
Modern secure update frameworks seek precisely to maintain trust in metadata, versions and artifacts even when certain components of the distribution system are compromised. In the automotive sector, Uptane is a particularly structured example: its model aims in particular to limit the consequences of the compromise of certain components and to facilitate recovery when a compromise occurs. [R3]
Security properties expected from an OTA mechanism
For the analysis carried out in this programme, several properties must be distinguished.
Authenticity
The system must be able to determine whether the update comes from an authorized authority.
Integrity
The installed artifact must match exactly the one that was approved.
Freshness and versioning
An authentic but vulnerable image does not necessarily have to be reinstallable.
Hence the importance of appropriate anti-rollback mechanisms.
Atomicity of the installation
An interruption while writing should not leave the system in an unrecoverable state.
Separation of active state and recovery state
A/B architectures, recovery partitions or other redundant mechanisms reduce the risk that a faulty update simultaneously destroys the active system and its means of recovery.
Verification after installation
A correctly written image is not necessarily functional.
Health checks may be necessary before considering the new version as valid.
Recovery
A secure update mechanism must also predict what happens when protection fails.
It is precisely this last dimension that brings OTA security closer to firmware resiliency.
Firmware resilience: protecting is not enough
Traditional cybersecurity legitimately emphasizes prevention.
But destructive attacks require us to consider the following hypothesis:
what happens when protection is bypassed?
NIST SP 800-193 builds firmware resilience around three fundamental properties: [R2]
Protection: prevent unauthorized modifications;
Detection: identify a modification when it has nonetheless occurred;
Recovery: Quickly restore the system to a known healthy state.
This logic is central to this research.
An architecture that can prevent 99% of changes but cannot recover from the remaining 1% can remain extremely vulnerable to a PDoS scenario.
Resilience therefore does not replace preventive security.
It constitutes its extension when prevention fails.
04 — RF SURFACE
Radio communications: distinguishing medium, protocol and function
Radio communications occupy an important place in this programme, but their role must be precisely defined.
The term RF here designates the radio frequency dimension of the communication channel.
A so-called “via RF” attack can, however, exploit very different layers.
- For example :
- Physical layer interference, interference, modulation or signal characteristics
- Link layer management frames, association, local authentication
- Network layer or transport IP sessions, routing, protocols
- Application layer orders, telemetry, provisioning
Software or firmware update maintenance layer carried by the channel.
This separation will prevent common confusion: radio support is not necessarily vulnerability.
A malicious packet transmitted over Wi-Fi can exploit a scanning vulnerability in the application.
A MAVLink command can be transported over a radio, UDP or serial link.
MAVLink is therefore a message protocol, not an RF technology. MAVLink 2 also has a signature mechanism allowing message authentication, although its use depends on the system configuration. [R4]
Relevant connectivity families
Several families will be considered in the state of the art, without assuming that they all present the same PDoS risk.
Bluetooth/BLE proximity communications; WiFi; NFC; IEEE 802.15.4 and related technologies. Long-range communications cellular networks; LPWAN; proprietary radio links; drone communications. Specialized communications industrial telemetry; wireless control systems; space communications.
The determining criterion will not simply be technology.
The question will rather be:
Does the channel remotely provide a path to reach a component whose persistent modification may affect availability?
It is this condition that makes communication relevant to the PDoS problem.
05 — FROM DoS TO PDoS
From DoS to PDoS: persistence as a central criterion
The term PDoS can be misleading if the word “Permanent” is interpreted only as permanent physical destruction.
Recent work on the subject describes PDoS as attacks seeking lasting or irreversible degradation, notably through the corruption of firmware, the boot process or other essential components. The dedicated literature nevertheless remains much less abundant than that devoted to traditional DoS.
For this research, the distinction will be mainly based on the mode of recovery.
Temporary DoS
The service returns when:
the attack ceases; the resource is released; the system restarts normally; communication is reestablished. Persistent degradation
The system remains unavailable after the attack disappears and requires:
privileged administrative intervention; a restoration; a reflash; an out-of-band reset; secure rollback; a recovery procedure. Severe PDoS
Normal recovery is no longer available and may require:
hardware access; programmeming equipment; a manufacturer intervention; replacement of a component or system.
This gradation is more useful experimentally than a simply binary classification.
| Kind | State after the attack disappears | Recovery mode |
|---|---|---|
| Transient disruption | Normal return | Stopping the attack / restarting normally |
| Persistent degradation | Unavailability maintained | Recovery / rollback / reflash |
| Severe PDoS | Normal recovery not possible | Privileged intervention / manufacturer / replacement |
Operational definition of PDoS retained for the project
The following working definition will be used in the first experiments:
A PDoS attack is an intentional action whose objective or effect is to cause a persistent loss of availability by altering critical software, firmware, configurational, or hardware state such that restoration of service requires a recovery procedure different from normal system operation or restart.
This definition has several advantages.
It makes it possible to distinguish a PDoS:
a simple network flooding; temporary interference; a software crash followed by a successful automatic restart; of a power interruption without persistent corruption.
It also makes it possible to study several levels of gravity without systematically requiring the physical destruction of the equipment.
Another necessary distinction: PDoS and persistent compromise
A persistent compromise is not necessarily a PDoS.
An attacker can maintain lasting access to equipment while keeping it operational.
Conversely, a PDoS may aim specifically to prevent the system from functioning.
The objectives are different:
Persistence attack: maintain control.
PDoS: destroy or permanently neutralize operational capacity.
There is, however, an area of overlap.
A persistent implant can be used in a second phase to trigger sabotage, corrupt firmware, or prevent recovery.
This distinction will be important when building the threat model.
Particularly sensitive persistent surfaces
Several components deserve special attention.
Firmware
Firmware corruption can directly affect the operation of the equipment.
Bootloader
A bootloader compromise can occur before the main system loads and compromise superior recovery mechanisms.
Critical startup data
Partitions, metadata, tables, boot configuration or other information essential to launching the system.
Persistent configuration
In some cyber-physical systems, inconsistent configuration can prevent a return to an operational state even if the code remains intact.
Trusted keys and data
Loss or corruption of some keys may prevent the equipment from accepting legitimate updates in the future.
Recovery environment
An attacker who manages to simultaneously compromise the core system and the recovery mechanism turns an already serious compromise into a resilience problem.
This is why a recovery architecture must be considered as a trust boundary in its own right.
06 — EXPOSED ENVIRONMENTS
From critical systems to experimental platforms
The old research scope identified six areas.
They remain useful as areas of reflection and comparison, but they should no longer be confused with the three experimental benches actually envisaged.
16.1 Automotive and assisted driving systems
The modern vehicle constitutes a major example of a complex cyber-physical system.
It combines:
dozens of calculators; internal networks; telematics interfaces; sensors; actuators; OTA mechanisms; software from many suppliers.
The consequences of a compromise are therefore not limited to confidentiality.
They may concern:
functional availability; safety; ability to start; maintenance; integrity of certain computers.
Automotive cybersecurity is now the subject of a structured framework. ISO/SAE 21434 addresses the management of cybersecurity risks throughout the lifecycle of vehicle electrical and electronic systems, while UN Regulation R155 introduces requirements for automotive cybersecurity management systems. [R5] [R6]
The Uptane framework also provides a particularly interesting reference case for securing vehicle software updates.
In this programme, Jetson Orin will not be presented as a working ADAS calculator.
It will serve as an experimental platform representative of a relatively powerful embedded Linux/edge AI environment.
Drones and flight controllers
The drone probably constitutes the most directly cyberphysical bench of the project.
Its software is linked to:
inertial sensors; engines; controllers; navigation; communications; immediate physical decisions.
An inappropriate security response can therefore itself have negative consequences.
The problem is not just detecting a suspicious order.
It is necessary to determine:
Which response will best preserve the safe state of the system?
For a flight controller, abruptly cutting a function is not always acceptable.
An answer may have to favor:
ignoring an order; a change of fashion; capacity limitation; automatic return; a controlled landing.
This bench will thus make it possible to study the border between cybersecurity, resilience and operational safety.
Medical devices
Medical devices illustrate this convergence between security and safety particularly well.
The FDA now explicitly considers cybersecurity risks in the life cycle of certain “cyber devices” and requires in particular, for the devices concerned, capabilities for managing vulnerabilities and patches. Its cybersecurity guidelines for medical devices were further updated in 2025 and then in 2026. [R7]
In this area, availability cannot be analyzed independently of patient safety.
This constraint produces a particularly interesting problem:
Can a cybersecurity countermeasure be considered correct if it neutralizes a vital function to prevent compromise?
The answer is obviously context dependent.
This is precisely why a logic of graduated response and safe state must be analyzed with caution.
Biomedical will nevertheless remain, in the first phase of this programme, a field of literature study and not a real experimental bench.
IoT and edge equipment
IoT equipment and gateways represent a particularly interesting environment because they often combine:
permanent connectivity; firmware modifiable; remote maintenance; material constraints; long lifespan; strong heterogeneity of manufacturers.
One of the most well-known examples of PDoS targeting connected devices is the BrickerBot story in 2017. The attack explicitly sought the destruction or corruption of functions and storage of compromised equipment in order to render it unusable. However, it must be described precisely: certain figures widely reported online on the total number of equipment destroyed do not always have the same documentary solidity. [R10]
IoT architectures are also an area covered by several security benchmarks. The ITU-T X.1361 recommendation, for example, analyzes threats affecting devices, gateways, networks and platforms/services and describes various associated security capabilities. [R8]
Android terminals as a comparative platform
The Android smartphone deserves special treatment.
A modern smartphone is not necessarily a “critical embedded system” in the strict sense used in the safety-critical domains.
It nevertheless constitutes an excellent comparative platform for this research due to the sophistication of its software chain.
Android allows you to study:
start string; sheet music; verification mechanisms; A/B updates across devices; recovery; logs; WiFi; Bluetooth; cellular connectivity; persistent storage.
The Android smartphone will therefore play an important methodological role:
test the ability of the approach to move from a cyberphysical controller or a Linux edge environment to a complex industrial mobile platform.
Space and systems that are difficult to recover
Space environments represent a particularly instructive limiting case.
When equipment is physically inaccessible, recovery becomes a critical property of its architecture.
A software error or compromise that would be repairable in minutes on a ground system can become catastrophic in a remote environment.
Modern spatial architectures therefore place strong emphasis on:
redundancy; safe mode; watchdogs; remote ; recovery ; fault tolerance.
Space will not be part of the first experimental wave.
It nevertheless remains an excellent area of comparison for the notion of resilience in the face of loss of physical access.
The three experimental benches selected
The experimental programme deliberately begins with only three environments.
NVIDIA Jetson Orin
Main objective:
study the chain on an embedded Linux platform with significant computing resources.
This platform will be used in particular for the initial prototyping of:
telemetry collection; preprocessing; detection models; decision logic; experimental recovery mechanisms. Pixhawk / MAVLink
Main objective:
introduce the cyberphysical dimension and real-time and security constraints.
Android
Main objective:
study portability to an industrial mobile system presenting a boot chain and more complex OTA mechanisms.
These three platforms obviously do not represent all embedded systems.
They constitute sufficiently different anchor points to test the generalizability of the method.
07 — OBSERVABILITY & RESILIENCE
Observe, detect, decide and recover
A persistence attack does not necessarily produce a single indicator.
Depending on its nature, it can modify:
software behavior; memory accesses; execution time; CPU load; consumption; temperature; startup sequences; traffic; newspapers; certain physical signals.
One of the central axes of the project will therefore be to compare several categories of observation.
Software data system events; errors; logs; configuration changes; sensitive calls or operations; process status. CPU performance data; memory ; I/O; time limit ; restraint; timings. Network events communication data; command sequences; frequency of messages; protocol errors. Physical data
When accessible:
fluent ; tension ; temperature ; electromagnetic activity.
This last category constitutes a particularly interesting hypothesis but must be treated with caution.
An observable electromagnetic signature is not automatically an attack signature.
One of the objectives will be precisely to determine whether it provides discriminating information beyond the data already available in the software.
Why consider a multi-source fusion?
The main motivation for fusion is not to multiply sensors to artificially increase complexity.
It is based on a simple hypothesis:
the deeper an attack acts on a system, the more it can simultaneously modify several dimensions of its behavior.
A flash operation can, for example, have consequences:
software; temporal; energy; possibly thermal.
But that doesn't mean all of this data will be useful.
The research will therefore have to answer several questions:
Which signals are really discriminating?
Which signals are redundant?
What is the cost of acquiring them?
Does fusion really improve detection?
Is it portable?
Does removing a source significantly degrade performance?
This is where future ablation studies will have a critical role.
Place of TinyML in the programme
TinyML should not become a decided answer before experimentation.
This is a technological option to be evaluated.
The reasoning is as follows.
Centralized detection may require:
permanent transmission of telemetry; connectivity; external infrastructure; additional latency.
Local detection can reduce some of these dependencies.
But it imposes other constraints:
memory ; CPU; energy ; storage ; complexity of the model; maintainability.
The project will therefore compare several families of methods, potentially:
deterministic thresholds; statistical methods; classic machine learning; lightweight networks; sequential models where relevant.
TinyML will be selected when its benefit can be measured, and not simply because it constitutes an attractive technology.
Detecting is not deciding
- An important architectural principle of the project consists of separating two functions:
- detection
- And
the response decision.
A model can produce an anomaly probability or score.
This result does not automatically mean:
isolate the system.
A decision must take into account:
model confidence; persistence of the anomaly; criticality of the action; operational status; availability of a safe mode; consequences of a false positive.
This separation is particularly critical for cyber-physical systems.
A detection error must not itself become a cause of accident or unavailability.
Graduated response principle
The project will study a graduated response policy.
At this stage, this gradation constitutes a conceptual architecture, and not a validated mechanism.
Level 0 — Observation
Normal operation and collection.
Level 1 — Suspicion
Increasing telemetry and creating an event.
Level 2 — Restriction
Temporary limitation of a sensitive function.
Level 3 — Insulation
Neutralization of the suspected surface when the context allows it.
Level 4 — Recovery
Return to a configuration or image known to be reliable.
Level 5 — Safe state
Maintaining the system in a minimal state considered safe until intervention or validation.
Each platform will need to have its own interpretation of these levels.
The safe state of a drone is not that of a Linux gateway.
Minimum continuity and safety
This research does not consider availability solely as a binary variable.
A system can be:
fully operational; partially degraded; isolated ; in emergency mode; recoverable; not recoverable.
This distinction is particularly important in cyber-physical systems.
The best response to a compromise is not necessarily one that maximizes IT security in the strict sense.
It can be that which preserves a minimum function long enough to reach a safe physical state.
Here, cybersecurity meets operational safety directly.
Capacity-constrained environments and technological sovereignty
A complementary dimension of this research concerns environments where the capacity for evaluation and maintenance of equipment is limited.
This question is particularly relevant for many deployments in countries where:
much of the complex equipment is imported; the firmware remains under the control of the manufacturer; laboratory capacities are limited; replacement cycles are long; update mechanisms depend on external providers.
However, we must avoid an overly general conclusion that these environments are necessarily “less secure”.
The scientific problem can be formulated more precisely:
How can we assess the resilience of equipment when the organization that operates it does not control its development chain or its firmware?
This question goes beyond just analyzing vulnerabilities.
It concerns:
insurance; transparency; approval; certification; purchasing requirements; the support cycle; the right to receive corrections. 30. A regulatory development which confirms the importance of equipment cybersecurity
The requirements relating to the cybersecurity of connected products are gradually strengthening.
In the European Union, cybersecurity requirements added to the Radio Equipment Directive for certain categories of radio equipment are now supported by the harmonized EN 18031 series; the Commission published the corresponding references in January 2025. The standards were developed under a mandate addressed to CEN and CENELEC. [R9]
In the automobile industry, ISO/SAE 21434 and UN regulation R155 already structure a significant part of the cybersecurity risk management processes.
In the medical sector, FDA requirements and recommendations relating to “cyber devices” also reinforce expectations relating to vulnerability management, software life cycle and patches.
These developments show that the security of connected equipment is no longer just a network configuration problem.
It becomes a property of the product life cycle.
What current defenses already know how to do
It would be incorrect to present PDoS as a problem without defense mechanisms.
Many bricks already exist.
Secure Boot
It can prevent untrusted code from starting.
Firmware signing
It allows the distributed artifact to be authenticated.
Anti-rollback
It limits the return to a version that has become vulnerable.
A/B update
It allows you to prepare a new version without immediately overwriting the known functional state.
Recovery
It provides a path to restoration.
Watchdog
It allows you to recover from certain execution failures.
Certification and measurement
They can help determine the state of integrity.
IDS and monitoring
They make it possible to identify certain abnormal behaviors.
The scientific question is therefore not:
“Why didn’t anyone think about protecting the firmware? »
The real question is much more interesting.
08 — SCIENTIFIC GAP
The problem is not the absence of defenses
The problem studied is located at the intersection of several domains already mature separately:
- secure update
- firmware resilience
- anomaly detection
- cyber-physical security
- embedded machine learning
- radio communications
recovery and safe state.
The research seeks to determine whether these dimensions can be combined in a coherent enough architecture to allow:
- 1. observe precursor behavior or associated with persistent compromise
- 2. to locally estimate the level of anomaly
- 3. to distinguish as much as possible an attack from a benign failure
- 4. to decide on a proportionate reaction
- 5. to preserve or restore a reliable operational state
6. and apply the same methodological reasoning to several architectures.
This last point is probably the most difficult.
What this research should not assume
Several attractive hypotheses will have to remain open.
It should not be assumed that:
all PDoS attacks produce an early signature; physical signals systematically improve detection; TinyML will always be preferable to a deterministic approach; a model trained on one platform will work on another; an automatic response will always be safer than external intervention; a universal architecture exists; Any firmware corruption can be recovered.
On the contrary, demonstrating that one of these hypotheses is false could constitute a useful scientific result.
First formulation of the research space
At this point, the programme can be summarized by six objects.
Object 1 — Threat model
Identify the pathways that can lead from OTA or remote exposure to persistent degradation.
Object 2 — Observability
Identify signals available before and during compromise.
Object 3 — Detection
Determine whether these signals allow sufficiently reliable classification.
Object 4 — Embedded feasibility
Measure the real cost of this detection.
Object 5 — Decision
Transform a probabilistic detection into a controlled operational decision.
Object 6 — Recovery
Measure the ability of the system to return to a known state of integrity.
These six objects will constitute the guiding principle of the following work.
09 — CONTINUED WORK
Open questions and next step
This note naturally leads to several questions.
At what level of persistence should an unavailability be considered PDoS?
How to distinguish a destructive attack from a breakdown producing the same symptoms?
What events are observable before irreversible corruption?
Does a fusion of software and physical telemetry actually improve this detection?
What trade-off exists between detection time and false positive rate?
Can we deploy this detection locally without disrupting the main function of the system?
How to automatically decide on a rollback or a safe mode when a classification remains probabilistic?
How much of the pipeline can actually be ported from Jetson to Pixhawk to Android?
These are the questions that will gradually transform the project from a conceptual framework into an experimental programme.
Positioning of next steps
At the end of this first note, the logical continuation of the work does not yet consist of immediately training a TinyML model.
The next step should be building a formal threat model.
This must define:
assets ; boundaries of trust; adversary capabilities; preconditions; OTA surfaces; communication surfaces; persistence mechanisms; alteration scenarios; recovery states; conditions of success and failure.
This work should also make it possible to construct a precise taxonomy distinguishing:
initial access → compromise → persistent modification → loss of availability → recovery or non-recovery.
Only after this step can an experimental plan be properly derived.
Synthesis
This first note establishes several principles.
The systems studied have become deeply dependent on modifiable software and remote communications.
This development makes software updating essential, but also transforms the maintenance chain into a critical area of trust.
The radio channel must be considered as a communication vector whose real exploitation can be at different layers.
PDoS is primarily distinguished from temporary denial of service by the persistence of the unavailable state and the complexity of recovery, rather than by the requirement for physical destruction.
Relevant defenses are not limited to preventing the attack.
They must be thought of in a broader chain:
protect → observe → detect → decide → contain → recover → verify
The scientific difficulty finally lies less in the individual existence of each of these mechanisms than in their coherent integration under embedded constraints and in their portability between heterogeneous systems.
It is on this problem that the rest of the programme focuses.
EVOLVING DOCUMENT
Status of Note 01
Work already started
Definition of the conceptual scope; DoS/PDoS distinction; initial analysis of OTA and RF surfaces; identification of the main persistent layers; framing of application environments; identification of the three experimental benches; first articulation with the resiliency firmware.
Remaining work
Systematic review of PDoS literature; complete taxonomy of persistence mechanisms; OTA/RF threat model; mapping of trust boundaries; definition of experimental scenarios; choice of instrumentation; definition of metrics; validation of scientific terminology.
REFERENCES
Principal references for this version
- [R1]
S. Abaimov, Understanding and Classifying Permanent Denial-of-Service Attacks, Journal of Cybersecurity and Privacy, vol. 4, no. 2, pp. 324–339, 2024. This recent work proposes a classification of PDoS and confirms that the subject remains significantly less documented than traditional denials of service.
- [R2]
A. Regenscheid, NIST SP 800-193 — Platform Firmware Resiliency Guidelines, National Institute of Standards and Technology, 2018. Central reference for Protection — Detection — Recovery logic applied to potentially destructive attacks against firmware.
- [R3]
Uptane Community, Uptane Standard for Design and Implementation 2.1.0. Automotive software update security framework designed with compromise resilience and recovery logic in mind.
- [R4]
MAVLink, Message Signing. Documentation of the MAVLink 2 signature mechanism intended to enable authentication of the origin of messages.
- [R5]
ISO/SAE 21434:2021, Road Vehicles — Cybersecurity Engineering. Cybersecurity engineering framework applicable to the life cycle of vehicle electrical and electronic systems.
- [R6]
United Nations Economic Commission for Europe, UN Regulation No. 155 — Cyber Security and Cyber Security Management System.
- [R7]
FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, current guidance.
- [R8]
ITU-T X.1361, Security Framework for the Internet of Things Based on the Gateway Model.
- [R9]
European Commission, Implementing Decision (EU) 2025/138 on harmonized standards supporting the cybersecurity requirements of the Radio Equipment Directive, in particular the EN 18031 series.
- [R10]
Radware, BrickerBot Results in Permanent Denial-of-Service, 2017, as a historical benchmark for destructive attacks targeting IoT equipment.
PDoS PROGRAM
Continue with the full scope of the research.
This note is part of an independent programme dedicated to observability, embedded detection, graduated response and recovery of systems exposed to persistent compromises.