Post-Quantum Security for FADEC: Critical Aerospace CPS Risk

Key Takeaways

• Lattice-based (LWE/SIS) cryptographic schemes must be integrated directly into FADEC real-time control loops — ciphertext expansion is not just a bandwidth problem, it is a schedulability and flight-safety constraint
• PUF-derived hardware attestation entropy and Kalman residual monitoring must evolve under a unified stochastic model, or post-quantum key renewal will destabilize closed-loop control
• Aerospace OEMs that delay PQC evaluation beyond 18 months risk entering DO-178C recertification cycles after NIST’s 2030 classical-algorithm deprecation deadline — a timeline mismatch that grounds fleets, not just IT systems

Last updated: May 2025

[IMAGE: Macro cinematic shot of a dual-spool turbofan engine core cross-section with glowing cyan lattice-grid cryptographic key structures overlaid on the FADEC control unit, deep black background with teal light refracting through titanium fan blades, 8K photorealistic, no text]

Why a Quantum Attack on a Jet Engine Is No Longer Theoretical

Picture this: a cryptographically relevant quantum computer — widely projected to emerge between 2030 and 2035 — breaks the ECDH key exchange protecting the avionics bus on a commercial turbofan. The adversary does not need real-time access. They harvested encrypted FADEC telemetry streams years earlier. Now they replay authenticated actuation commands that the engine’s Full Authority Digital Engine Control cannot distinguish from legitimate thrust inputs.

This is not a speculative scenario. It is the exact threat model that researchers at arXiv:2605.00961v1 formalized in May 2025, producing the first unified mathematical framework for post-quantum authenticated telemetry and actuation in FADEC-coupled dual-spool turbofan systems.

The attack surface here is categorically different from enterprise IT. FADEC systems operate under microsecond timing budgets on avionics buses. Every byte of ciphertext expansion, every millisecond of key-renewal latency, feeds directly into schedulability equations that determine whether the control loop remains stable — or whether the engine surges.

For CISOs at aerospace primes, Tier-1 suppliers, and defense integrators, post-quantum cryptography (PQC) is no longer a roadmap item. It is a certification-critical engineering constraint with a hard deadline.

The FADEC Attack Surface: What Makes Avionics PQC Uniquely Hard

Classical Crypto Was Never Designed for Real-Time Control Loops

Full Authority Digital Engine Control systems manage fuel flow, compressor variable geometry, and turbine temperatures across a dual-spool turbofan — all in closed-loop feedback cycles measured in milliseconds. The avionics bus connecting FADEC to sensors and actuators operates under strict timing determinism. Miss a scheduling window and the control law diverges.

Classical asymmetric cryptography — RSA, ECDSA, ECDH — was designed for connection establishment latency tolerances measured in tens of milliseconds. That is acceptable for a TLS handshake on a web server. It is catastrophic for an engine control system where a 5ms actuation delay can push compressor operating point past the surge line.

Post-quantum algorithms based on Learning With Errors (LWE) and Short Integer Solution (SIS) lattice problems carry larger public keys and ciphertexts than their classical counterparts. CRYSTALS-Kyber (now ML-KEM under NIST FIPS 203) produces ciphertexts of 1,088 bytes at the 128-bit post-quantum security level, compared to 32 bytes for an ECDH ephemeral key. That expansion is not an abstraction — it occupies bus bandwidth that FADEC schedulers have already allocated to sensor telemetry and actuator commands.

The Three Constraints That Must Be Co-Designed

The arXiv:2605.00961v1 framework identifies three interdependent constraints that any viable PQC-FADEC architecture must satisfy simultaneously:

1. Cryptographic security: Key establishment must resist quantum adversaries under LWE/SIS hardness assumptions
2. Real-time schedulability: Ciphertext expansion must fit within avionics-bus timing budgets without displacing safety-critical control traffic
3. Closed-loop stability: Key-renewal periods and authentication latency must not introduce control delays that push the plant state outside stability margins

The research demonstrates that these three constraints are not independent. Channel uncertainty — degraded RF link quality, electromagnetic interference, or adversarial jamming — directly tightens the admissible key-renewal period. A shorter renewal window means more frequent cryptographic operations, which consumes more bus bandwidth, which compresses the scheduling margin for control commands.

“We show that channel uncertainty tightens admissible key-renewal periods, that ciphertext expansion enters bus-level schedulability constraints, and that sensing and actuator limits shape integrity thresholds and allowable control delay.” — arXiv:2605.00961v1, Composable Post-Quantum Security for FADEC-Coupled Dual-Spool Turbofan Cyber-Physical Systems

This is the core insight that separates aerospace PQC from enterprise PQC migration. In enterprise IT, you can absorb Kyber’s ciphertext overhead by upgrading bandwidth. In a FADEC system, the bus is physically fixed, the timing is deterministic, and the consequence of getting it wrong is not a degraded user experience — it is loss of thrust control.

Technical Deep-Dive: The Unified Stochastic Framework

What the Model Actually Does

The framework in arXiv:2605.00961v1 places five system components under a single common filtration — a mathematical structure that allows all state variables to evolve consistently under shared uncertainty:

• Plant evolution: The physical dynamics of the dual-spool turbofan (spool speeds, temperatures, pressures)
• Communication latency: Variable delays on the avionics bus
• Leakage: Side-channel information available to an adversary observing bus traffic
• Adversarial channel quality: The attacker’s ability to inject or modify messages
• Cryptographic state: Current key material, PUF attestation entropy, authentication tags

By modeling all five under a unified stochastic hybrid system, the framework enables formal proofs that connect cryptographic security parameters to control-theoretic stability guarantees. This is not possible when cryptography and control are designed in separate engineering silos — the standard practice at most aerospace OEMs today.

PUF Attestation: Hardware Root of Trust Under Quantum Threat

Physical Unclonable Functions (PUFs) extract entropy from manufacturing variations in silicon — no two chips produce the same challenge-response pairs. The framework incorporates PUF-derived attestation entropy as a hardware root of trust for FADEC component authentication, binding cryptographic identity to physical hardware in a way that survives software compromise.

Critically, the model formally relates PUF smooth min-entropy to the adversary’s distinguishing advantage. This means the security proof degrades gracefully as PUF entropy decreases with device aging — a property that matters for avionics systems with 25-year service lives.

Kalman Residual Monitoring as a Cryptographic Integrity Signal

The framework integrates Kalman residual monitoring — a standard technique in aerospace fault detection — directly into the security model. Innovation statistics (the difference between predicted and observed sensor values) serve as integrity signals: anomalous residuals trigger conservative alarm thresholds that account for both sensor noise and potential adversarial manipulation of telemetry.

This dual-use of Kalman residuals is architecturally significant. It means the same signal processing infrastructure already present in FADEC fault detection can be extended to detect cryptographic integrity violations without adding dedicated security hardware.

The research characterizes the interaction between post-quantum security, real-time schedulability, and closed-loop stability in safety-critical aerospace control architectures — establishing formal bounds that connect all three domains for the first time.

Comparison: Classical vs. Post-Quantum FADEC Security Architecture

Industry Context: The Certification Gap Is the Real Risk

NIST Timelines Create a Hard Deadline for Aerospace

NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. The agency has signaled deprecation of classical asymmetric algorithms — RSA, ECDSA, ECDH — by 2030, with full disallowance by 2035.

For commercial avionics, the certification timeline is the constraint that makes 2030 a crisis point, not a planning horizon. A major avionics software change under DO-178C DAL A (the highest criticality level, applicable to FADEC) requires 18–36 months of verification and validation activity before regulatory approval. An OEM that begins PQC integration in 2028 cannot realistically achieve FAA or EASA certification before the deprecation window closes.

Defense programs face an additional layer: NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) mandates PQC for all national security systems by 2030, with ML-KEM and ML-DSA as the required algorithms. FADEC systems on military aircraft fall squarely within this mandate.

Who Is Moving — and Who Is Lagging

Aerospace primes have begun internal PQC assessments, but public commitments remain sparse. The gap between enterprise IT PQC migration (where Google, Cloudflare, and Apple have made measurable progress) and embedded avionics PQC migration is significant. Enterprise systems can absorb algorithm transitions through software updates. FADEC systems require hardware-in-the-loop validation, environmental qualification, and regulatory re-certification.

The research community is ahead of industry practice. The arXiv:2605.00961v1 framework represents the state of academic formalization — but no publicly documented FADEC implementation using NIST-standardized PQC algorithms exists as of May 2025. The certification pathway for PQC in flight-critical software remains undefined at FAA and EASA.

The Economic Case: Cost of Inaction vs. Cost of Migration

The cost of a post-quantum FADEC compromise is not measured in data breach notification costs. It is measured in airworthiness directives, fleet groundings, and potential loss of life. The liability exposure for an aerospace OEM that ships FADEC systems with known quantum-vulnerable cryptography after 2030 — when the threat is formally acknowledged and NIST standards are available — is categorically different from pre-standard exposure.

Migration costs are real: re-certification under DO-178C for a DAL A software component runs $10M–$50M per platform depending on scope. But that cost is a one-time investment against a perpetual vulnerability. Organizations that begin now can amortize PQC integration across planned software updates rather than forcing emergency re-certification under regulatory pressure.

The BeQuantum Perspective: Co-Design Is the Only Viable Path

Most PQC migration guidance treats cryptography as a layer — swap the algorithm, update the library, redeploy. That model works for web servers. It fails for cyber-physical systems where the cryptographic layer is mechanically coupled to the control layer.

The arXiv:2605.00961v1 framework validates what BeQuantum’s engineering approach has been built around: security and control must be co-designed under a unified formal model, not integrated sequentially. When BeQuantum’s PQC Layer is deployed in safety-critical embedded contexts, the design process begins with the schedulability budget and stability margins — then works backward to select lattice parameters that fit within those constraints, rather than forward from algorithm selection to hoping the overhead is acceptable.

For FADEC-class systems specifically, BeQuantum’s Digital Notary capability addresses the attestation problem directly. By anchoring cryptographic identity in PUF-derived hardware entropy and maintaining a tamper-evident audit chain of key-renewal events and authentication decisions, operators gain the forensic visibility needed to detect harvest-now-decrypt-later attacks on historical telemetry — before a quantum adversary can weaponize that data.

The IceCase hardware security module extends this to the physical layer: air-gapped key material storage with PUF binding ensures that even a fully compromised software stack cannot exfiltrate the root keys protecting FADEC command authentication.

The organizations that will navigate this transition successfully are those that treat PQC not as a cryptography project, but as a systems engineering project with cryptographic, control-theoretic, and hardware attestation dimensions that must be resolved together.

What Your Organization Should Do in the Next 90 Days

Step 1: Map your FADEC cryptographic dependencies (Days 1–30) Audit every avionics bus interface, ground-link telemetry channel, and maintenance data loader connection that uses asymmetric cryptography. Identify which algorithms are in use, which hardware security modules hold key material, and which DO-178C software components would require re-certification upon algorithm change. This inventory does not exist at most OEMs — building it is the prerequisite for everything else.

Step 2: Quantify your schedulability margin for PQC overhead (Days 30–60) For each identified interface, calculate the available bus bandwidth margin and the maximum tolerable authentication latency given current control loop timing budgets. This analysis will immediately reveal which interfaces can absorb ML-KEM ciphertext expansion within existing schedules and which require architectural changes — informing your certification scope and cost estimate.

Step 3: Engage your certification authority on PQC pathways (Days 60–90) FAA and EASA have not yet published PQC-specific guidance for DO-178C or DO-326A. That does not mean the conversation cannot start. Issue Papers and Special Conditions are the established mechanism for novel technology certification. Organizations that open these discussions now will shape the guidance — and gain first-mover advantage on certification timelines — rather than waiting for prescriptive rules that may not fit their architecture.

Frequently Asked Questions

Q: Can we just use a PQC VPN tunnel over the avionics bus to avoid modifying FADEC software? A: No. A VPN tunnel protects data in transit between network endpoints, but FADEC authentication requires end-to-end integrity verification between the engine controller and the specific actuator or sensor — not between network gateways. A tunnel terminating at a gateway leaves the bus segment between the gateway and the FADEC unprotected, and does not provide the hardware-bound attestation that PUF-based schemes deliver. More critically, the tunnel’s cryptographic overhead still consumes bus bandwidth and introduces latency that affects schedulability, so the co-design problem does not disappear.

Q: Do NIST’s finalized PQC standards (ML-KEM, ML-DSA) apply directly to avionics, or do we need aerospace-specific variants? A: The NIST standards define the algorithm specifications and security levels, but they do not address real-time scheduling constraints, avionics bus protocols (ARINC 429, MIL-STD-1553), or DO-178C qualification requirements. Aerospace deployment requires parameter selection and implementation choices that satisfy both NIST security levels and avionics timing budgets simultaneously — which is precisely the gap that frameworks like arXiv:2605.00961v1 are beginning to formalize. Expect FAA and EASA to reference NIST standards in future guidance while adding aerospace-specific implementation requirements.

Q: How long does PUF entropy remain reliable in a FADEC environment given temperature cycling and radiation exposure? A: PUF reliability under harsh environmental conditions is an active research area. The arXiv:2605.00961v1 framework explicitly models PUF smooth min-entropy degradation and relates it to the adversary’s distinguishing advantage — meaning the security proof accounts for aging. In practice, avionics-grade PUF implementations require environmental qualification testing (temperature range, radiation tolerance) equivalent to other FADEC hardware components, and key-renewal policies should be designed conservatively to account for entropy reduction over the platform service life.