The Airbus A320 ELAC Emergency

A technical, regulatory, and lifecycle view of a rare but instructive event

Dec 02, 2025

When a JetBlue A321 experienced a sudden, severe nose‑down pitch on 30 October 2025, investigators quickly focused on the A320‑family flight‑control system. The event, traced to an interaction between solar radiation and a specific software standard in the elevator aileron computer (ELAC B L104), led Airbus and regulators to order a global rollback of that software and temporarily ground or restrict a very large portion of the A319/A320/A321 fleet.

The response crystallized in two key documents:

An Airbus Alert Operator Transmission (AOT) A27N022‑25, instructing operators to remove ELAC B units running standard L104 on thousands of aircraft and revert to standard L103+.
An EASA Emergency Airworthiness Directive (EAD) 2025‑0268‑E, which made those actions legally mandatory in Europe and effectively set the global baseline for corrective action.

What follows is a technical deep dive into what those documents really mean, what went wrong, and what this episode says about modern control‑software engineering, certification, and aircraft lifecycle management.

What an EAD is, and why this one matters

An Airworthiness Directive (AD) is a legally binding instruction issued by an aviation authority when an unsafe condition is found in a type‑certificated product. The AD mandates specific actions, with defined compliance times, to restore an acceptable level of safety. In the US, this is primarily governed by 14 CFR Part 39; in Europe, the equivalent regime is set out in Regulation (EU) 748/2012 and Part 21.

An Emergency Airworthiness Directive (EAD) is the most urgent variant. It is issued without the usual comment period and typically has compliance times measured in hours or “before next flight”. Airlines cannot negotiate the timeline retrospectively; operating out of compliance is illegal.

In this case, EASA EAD 2025‑0268‑E defines:

Affected ELAC: ELAC B units running software standard L104.
Serviceable ELAC: ELAC B units at standard L103+ or better, which Airbus has shown not to exhibit the vulnerability.

The directive requires that affected aircraft in “Group 1” – essentially A319/A320/A321 aircraft with susceptible hardware and software – must have the L104‑standard ELACs removed and replaced or reconfigured to L103+ before further passenger service.

The key point: regulators concluded that continued operation with ELAC B L104 presented an unacceptable risk of structural overload due to potential uncommanded elevator movement.

What an AOT is, and how it relates to an EAD

An Airbus Alert Operator Transmission (AOT) is an OEM‑level emergency communication channel to operators. An AOT is not the law in itself, but it is the technical and procedural reference that ADs and EADs frequently “lock in”. EASA’s EAD explicitly defines “The AOT: Airbus Alert Operator Transmission (AOT) A27N022‑25” and then requires compliance with that AOT as the means of accomplishing the mandated actions.

Practically:

The AOT provides detailed effectivity (which serial‑number aircraft and computers), configuration logic, and step‑by‑step maintenance procedures, including data loading instructions and functional checks.
The EAD upgrades those instructions from OEM guidance to legal obligation for operators under Part 121‑equivalent regimes.

An AOT is therefore the technical backbone, while the EAD is the legal wrapper.

A320 flight‑control architecture and the ELAC’s role

The A320 family introduced a fully digital fly‑by‑wire Electrical Flight Control System (EFCS). Pilot sidestick commands are interpreted by computers, which compute desired aircraft responses and then drive actuators on the control surfaces.

Primary EFCS computers on a classic A320 include:

Two Elevator Aileron Computers (ELACs)
- Primary pitch control: elevators and stabilizer in normal operation.
- Primary roll control: ailerons.
Three Spoiler Elevator Computers (SECs)
- Control roll spoilers and act as standby pitch actuators if ELACs are lost.
Two Flight Augmentation Computers (FACs)
- Rudder control, yaw damping, turn coordination, rudder travel limiting, and some envelope protection.
Two Flight Control Data Concentrators (FCDCs)
- Data aggregation and interface to display and maintenance systems.
Plus dedicated computers for slats/flaps (SFCC), flight management and guidance (FMGC), etc.

The ELACs sit at the center of this architecture. They host the core control laws that map pilot inputs and autopilot commands, combined with sensor data, into elevator and aileron commands, and they implement a large part of Airbus’s envelope protection logic in pitch and roll.

The ELAC B units involved here are a specific hardware generation within that family. Different software standards (such as L103+ and L104) represent major software baselines, each tied to a set of certified requirements and test evidence.

L103+ versus L104: what actually changed

L103+ and L104 are not cosmetic revisions. L104 is part of Airbus’s “Safety Beyond Standard” program, incorporating additional protections in degraded configurations, especially in alternate law. Flightglobal’s reporting and Airbus briefing material indicate that L104 introduced, among other things:

A more sophisticated pitch‑attitude and load‑factor limiting function in specific failure scenarios, aimed at reducing stall risk and preserving structural margins when normal law protections are lost.
Enhanced logic for how the ELAC reacts to anomalous sensor data and failure combinations, particularly around angle‑of‑attack and inertial data.

L103+ is an earlier standard that lacks some of those additional protections but has a long service history without the specific failure mode discovered after the JetBlue event. The EAD explicitly defines L103+ as serviceable, which in regulatory terms means that reverting to L103+ restores an acceptable level of safety, even if it is not “Safety Beyond Standard” in the marketing sense.

The vulnerability appears tied to how L104’s new protections interact with corrupted internal data following a radiation‑induced upset in the ELAC B hardware. Airbus’s AOT describes a worst-case scenario in which, under certain failure preconditions and exposure to extreme solar activity, the combination of ELAC B hardware and L104 software could generate uncommanded elevator deflections large enough to threaten structural integrity.

In plain engineering terms, the extra sophistication of L104 created a corner case that was not fully bounded under the assumed radiation fault model. L103+ simply never executes that logic, so it cannot express that particular failure signature.

Single‑event effects, solar radiation, and “software” failures

The underlying physical mechanism is not mysterious. At typical cruise altitudes, aircraft are immersed in a flux of high‑energy particles originating both from the Sun and from galactic cosmic rays. These particles strike the atmosphere, creating showers of secondary particles, including neutrons, that can interact with semiconductor devices.

When a sufficiently energetic particle crosses a sensitive volume in a memory cell or logic node, it can deposit charge and flip a bit. This is a Single Event Upset (SEU), one class of broader Single Event Effects (SEE) that also includes latch‑ups and burn‑outs.

Several important subtleties arise:

The hardware misbehaves, the software “looks wrong.”
From the CPU’s perspective, an SEU may change an instruction, a data value, or a state bit in SRAM or registers. The code itself is unchanged on disk or PROM, but the executing state diverges. To observers, the system behaves as if there were a software defect. This is why such events are often reported as “software glitches” even though the root cause is physical.
SEEs were known long before 2015
Avionics designers and regulators have studied the effects of atmospheric radiation for decades. IEC 62396‑1 and related parts, first issued as technical specifications and later as full standards, provide detailed guidance on modelling the avionics radiation environment and designing for SEE resilience in hardware and systems. EASA’s Safety Information Bulletin 2012‑09R1, updated in 2021, explicitly calls out SEEs as a main threat for avionics electronics during solar radiation storms.
Formal regulatory expectations matured after L104’s original development.
EASA issued Certification Memorandum CM‑AS‑004, “Single Event Effects (SEE) Caused by Atmospheric Radiation”, in 2018. It references IEC 62396 and sets expectations on SEE analysis and testing for avionics equipment, including quantitative methods and documentation of SEE envelopes. The FAA’s 2015 Single Event Effects Mitigation Techniques Report (TC‑15‑62) similarly describes SEE risk and mitigation methods, but again as guidance rather than hard‑coded regulation.

For ELAC B L104, Le Monde and other reporting indicate that the software standard entered service around 2015 without qualification against the specific sort of extreme solar‑storm SEE scenario that later became a focus of regulators.

So it is not that no standards existed in 2015, but that:

SEE effects were addressed mainly through guidance and best practice.
Formal EASA certification expectations for SEE (CM‑AS‑004) were only issued later, and
The particular ELAC L104 combination exposed a system‑level vulnerability that the then‑existing qualification regime did not fully uncover.

How the JetBlue incident exposed the vulnerability

Investigations of the JetBlue event converged on this chain:

The aircraft, an A321 with ELAC B at L104, was in cruise with the autopilot engaged.
An intense solar radiation event – likely associated with the rising solar cycle leading to the predicted 2025 maximum – exposed the aircraft to an elevated particle flux.
A radiation‑induced SEE in ELAC B corrupted internal data used by the L104 envelope protection functions.
Under a particular combination of failure flags and corrupted state, the L104 logic generated elevator commands not consistent with pilot input or autopilot intent, resulting in a rapid nose‑down pitch and significant vertical acceleration.
Redundancy and pilot action prevented a catastrophic outcome, but the event demonstrated that, in worst‑case conditions, the combination of ELAC B hardware and L104 software could violate structural load limits.

Airbus’s subsequent analysis, summarized in AOT A27N022‑25 and echoed in the EAD, concluded that the safest immediate action was to remove all L104‑standard ELAC B units from service on affected aircraft and revert to L103+.

This is a classic example of the aviation system reacting decisively to a rare but credible failure path.

DO‑178C: why control software is engineered to be “almost perfect.”

Unlike consumer or even most automotive software, airborne flight‑control software is developed to DO‑178C/ED‑12C, the de facto global standard for software in certificated aviation systems.

Key aspects relevant here:

DO‑178C is not a regulation in itself. It is recognized by FAA AC 20‑115D and EASA AMC 20‑115D as an acceptable means of compliance with the software requirements of regulations such as 14 CFR Part 25.1309 and the corresponding EASA CS‑25 requirements.
Software is assigned a Development Assurance Level (DAL) based on the severity of failure effects: Level A for catastrophic, B for hazardous, C for major, D for minor, and E for no safety effect. ELAC control laws are clearly Level A: a software failure can directly cause loss of the aircraft.
For Level A software, DO‑178C requires:
- Exhaustive traceability from high‑level requirements to low‑level requirements to source code to tests.
- Structural code coverage to Modified Condition / Decision Coverage (MC/DC) for all safety‑relevant logic.
- Independent verification, configuration management, and quality assurance activities, with dozens of formally satisfied objectives.

This process does not mathematically prove correctness, but it drives defect rates to levels compatible with “extremely remote” failure probabilities on the order of 10⁻⁹ per flight hour at the system level, once combined with architectural redundancy.

What it does not inherently guarantee is that every conceivable hardware‑induced corruption mode has been adequately modelled and mitigated at the system level. DO‑178C focuses on software correctness under its specified assumptions; standards like DO‑254 and IEC 62396, and system‑safety processes under ARP4754A/ ARP4761 provide companion coverage for hardware and integrated system behavior.

The ELAC L104 case lives exactly at that interface between a highly controlled software process and a partly evolving understanding of atmospheric radiation risk.

Why are there no over‑the‑air updates for flight‑control software?

Modern narrow bodies are not technologically incapable of receiving data over wireless links. Airbus has invested in remote data‑loading infrastructure, and many aircraft already receive nav‑database and some system updates via connectivity solutions such as FOMAX or ground‑based Remote Data Loading (RDL) gateways.

Yet Level A flight‑control software is not updated the way smartphones or connected cars are.

Several structural reasons explain this:

Architecture and standards
Core avionics LRUs, such as ELACs, speak legacy deterministically‑timed buses, such as ARINC 429, and use ARINC 615A/ARINC 665 data‑loading protocols. These assume a tightly controlled maintenance context, not opportunistic wireless pushes. Portable data loaders and dedicated ground gateways implement these protocols with strict configuration and integrity checks.
Configuration control and legal accountability
Every software load on a safety‑critical LRU becomes part of the aircraft’s type design configuration under Part 21 and Part 25. Changing it is a design change that must be controlled, traceable by serial number, and demonstrably compliant with all applicable certification basis and ADs. The operator’s Part 121 maintenance program and any Part 145 repair station performing the work have explicit obligations to record and control that configuration.
Operational risk tolerance
Automotive OTA recalls have shown that remote fixes can and do introduce new defects, sometimes disabling critical systems such as drive power or driver‑assistance features, requiring rollbacks or further recalls. Smartphones routinely receive updates that degrade battery life, break applications, or even brick devices, sometimes requiring hardware repair or replacement. For phones, this is irritating. For cars, it is a serious but still primarily individual risk that regulators are only beginning to address. For a transport‑category aircraft, an erroneous update to Level A control software can compromise hundreds of lives in a single event. The tolerance for “we will patch it later” is essentially zero.
Cybersecurity and safety interaction
Introducing fully remote write access into safety‑critical LRUs creates an additional attack surface that must itself be secured and certified. DO‑326A and related aerospace cybersecurity guidance are still being operationalized across fleets; adding OTA for core flight controls would multiply that complexity.

As a result, flight‑control software updates remain ground‑based, deliberate, and heavily supervised, even where the underlying transport is digital or partly wireless.

Why specialized data‑loading equipment is still required

Even in 2025, updates to avionics, such as ELACs, typically require specialized, qualified data‑loading equipment that implements ARINC standards and is integrated with maintenance and configuration‑control systems. Examples include portable maintenance terminals and dedicated avionics data loaders used by airlines and Part 145 repair stations.

These devices are:

Built using hardware and operating systems that have themselves been assessed and qualified for use as part of the airworthiness data chain.
Integrated with ground systems that track aircraft registration, LRU serial numbers, software part numbers, and modification status.
Designed to validate the authenticity, integrity, and completeness of loadable software packages, often using ARINC 665 file structures and cryptographic or checksum mechanisms.

Off‑the‑shelf consumer tablets or laptops cannot simply be plugged into an ELAC to push flight‑control code, because that would break the traceable chain of controlled tools and data on which certification and continuing airworthiness depend.

This is the sense in which this update requires more than “just a USB stick”, without needing to spell out any particular cost adjectives.

When software updates are and are not possible on in‑service aircraft

Software updates in civil transport aircraft fall broadly into three categories:

Operational data updates
This includes navigation databases, terrain data for EGPWS, and performance databases. These are often field‑loadable with relatively light process overhead, sometimes using semi‑automated RDL mechanisms, provided integrity is assured and the changes are within the envelope approved in the original type design.
Field‑loadable function changes within an existing certification envelope.
Some systems are designed from the outset to accept Field Loadable Software (FLS) under controlled procedures. Changes in this bucket might be addressed by service bulletins and, where safety‑related, ADs, but do not necessarily require a full re‑certification of the equipment. Many avionics platforms implement this kind of “partitioned” architecture, allowing, for example, airlines to make options or minor improvements without touching Level A core functions.
Core Level A flight‑control software changes
ELAC B L104 falls here. These changes are part of the type design, usually approved under Part 21 at the TC or STC holder level, and require extensive regression testing, safety analysis updates, and, in some cases, simulator and flight testing. Distribution and installation must be carefully controlled, often using OEM‑defined procedures embedded in AOTs and more formal Service Bulletins.

The EAD and AOT for ELAC L104 essentially convert a Level A change into a fleet‑wide reconfiguration campaign. Operators either revert ELACs to L103+ or install an alternative configuration approved by Airbus in later revisions of the AOT.

Updates are possible, but within the constraints of:

The certification basis is defined in Parts 21 and 25.
Each operator’s approved maintenance program under Part 121.
The privileges and limitations of the maintenance organization under Part 145.

Regulations, industry standards, and OEM rules

It is helpful to distinguish three layers:

Regulations (14 CFR / EU law)
- Part 21 defines how designs and changes become approved type designs and how products and articles are produced and certificated.
- Part 25 sets the airworthiness standards for transport category airplanes, including system design and failure probability objectives.
- Part 121 governs the operations of large air carriers, including maintenance programs, SMS requirements, and AD compliance responsibilities.
- Part 145 governs repair stations, including facilities, personnel, and procedural requirements for maintenance and alterations.
Industry standards and guidance
- DO‑178C for software, DO‑254 for airborne electronic hardware, IEC 62396 for atmospheric radiation effects, ARP4754A / ARP4761 for system development and safety assessment, DO‑160 for environmental qualification, DO‑326A and companions for cybersecurity. DO‑178C for software, DO‑254 for airborne electronic hardware, IEC 62396 for atmospheric radiation effects, ARP4754A / ARP4761 for system development and safety assessment, DO‑160 for environmental qualification, DO‑326A and companions for cybersecurity.
  These are not law, but they are referenced as acceptable means of compliance by advisory circulars (FAA) and acceptable means of compliance (EASA).
OEM standards and documents
- Airbus AOTs, Service Bulletins, Component Maintenance Manuals, and configuration control rules.
- Supplier standards for ELAC hardware and embedded software, including internal coding, testing, and safety‑case methodologies.
  These documents sit below the regulatory level but are binding on operators through purchase contracts, approved maintenance programs, and, once referenced, ADs.
In the ELAC case:
1. EASA and other authorities used their Part 21 / Part 25 authority to mandate action via an EAD.
2. Airbus, as a type certificate holder for the A320 family, defined the technical means of compliance via AOT A27N022‑25.
3. Operators under Part 121‑equivalent regimes are obligated to comply and record that compliance.
4. Part 145 and in‑house maintenance organizations execute the actual removals, installations, and data loads, using qualified equipment and procedures.

Who actually builds the hardware and software

The supply chain for a system like ELAC is multi‑layered:

Airbus owns the overall A320 type design, system architecture, control‑law specification, and the integrated safety case.
Thales is the supplier for the ELAC hardware platforms on the A320 family. Public statements by Thales and Airbus have clarified that the specific L104 “safety beyond standard” protection function at issue is implemented in software that is not under Thales’s design responsibility.
The flight‑control software itself is developed under DO‑178C processes, but the precise corporate entity responsible has not been publicly named. It is typical in this domain for the OEM either to develop control‑law code internally or to contract a specialist software house while retaining design authority and certification responsibility.
Actuation systems for elevators, ailerons, and spoilers are supplied by other vendors, with their own DO‑254 and DO‑178C obligations, and interact with ELAC/SEC/FAC computers over certified data buses.

For comparison:

Boeing uses a different architectural and philosophical approach, particularly on the 737 family, where primary flight controls retain more conventional mechanical linkages supplemented by digital augmentation. More recent Boeing types, like the 777 and 787, implement fly‑by‑wire with envelope protections that pilots can override with sufficient force, reflecting a design philosophy that preserves greater direct pilot authority.
Embraer’s E‑Jet E2 family features a complete digital closed‑loop fly‑by‑wire system with full envelope protection in all flight phases, supplied by Moog for primary flight control and Honeywell for avionics.

In all cases, a complex ecosystem of semiconductor manufacturers, board‑level hardware vendors, software tool suppliers, test houses, and MROs participates in delivering and sustaining the certified configuration over decades.

Lifecycle implications: configuration, records, and asset value

An A320‑family aircraft is typically expected to remain in commercial service for 20 to 30 years. Over that lifetime, it will experience:

Multiple major and minor software updates across avionics, engines, and cabin systems.
Hardware modifications, upgrades, and occasional wholesale replacement of major LRUs.
Transitions between operators and owners, including sales, leases, and repossessions.

Every ELAC replacement or software change driven by the EAD becomes part of the aircraft’s configuration and maintenance history. Under Part 121 and Part 145, operators and repair stations must maintain records that:

Show that the aircraft conforms to its approved type design as modified by ADs and approved changes.
Document which serial numbers ELACs are installed on which tails, and at what software standard.
Demonstrate that the required tests and function checks were accomplished in accordance with the AOT and EAD.

From a transaction and asset‑value perspective, lessors and buyers will scrutinize those records. An aircraft with incomplete or inconsistent documentation of a major safety‑critical retrofit can face:

Delays and costs at redelivery or sale,
Additional inspections or rework to re‑establish traceability, and
Potential impairment of value.

The level of rigor that sometimes appears bureaucratic in day‑to‑day operations is precisely what enables confidence that an A321 built in 2015, modified in 2025, and sold in 2030 is in a well‑understood and safe configuration.

Controls software versus OTA updates in cars and phones

The contrast with consumer and automotive software is stark.

Commercial aviation achieves fatality rates on the order of 0.003 deaths per billion passenger‑kilometres, compared with roughly 2.5 deaths per billion passenger‑kilometres for cars, according to UK CAA data summarized by Allianz.

Expressed differently, the risk of a fatal accident per passenger flight on a modern airline is on the order of one in several million flights or better.

Some popular simplifications compress this into soundbites like “less than one death per light‑year of passenger travel”. Current data suggest the actual figure is likely tens of fatalities per passenger‑light‑year, depending on the data set and inclusion criteria, but the underlying point stands: fatal events per unit of passenger distance are extraordinarily rare in commercial aviation, significantly rarer than for road transport.

In contrast:

Automotive manufacturers increasingly rely on OTA updates for both convenience and safety recalls. While these can improve recall completion rates, there are documented cases where OTA updates themselves introduce new defects that affect braking, drivability, or driver‑assistance functions, prompting further recalls or rollbacks.
Smartphone OS and firmware updates routinely introduce regressions, including battery drain, application incompatibilities, and, in some cases, complete device “bricking”, as seen in multiple recent Samsung SmartThings and Galaxy update incidents.

These ecosystems are evolving toward stricter regulation, particularly for autonomous features. However, they still accept a level of in‑service experimentation with end users that would be unthinkable in Part 25 / Part 121 operations.

The DO‑178C worldview assumes that safety‑critical software must be as defect‑free as practicable before release, and that residual risk is controlled by redundancy and carefully analysed failure modes, not “rapid patching in the field”.

That philosophy, combined with highly structured update processes and configuration control, is a central contributor to the aviation safety record.

Why complexity is a feature, not a bug

From a distance, the ELAC L104 situation might look like a case of “complexity gone wrong”:

A sophisticated control‑law enhancement interacts with a rare radiation event,
The fleet requires a large‑scale rollback to an older software standard, and
operations are disrupted globally.

Seen in context, it is evidence that the system is doing what Part 21 and Part 25 intend:

A rare event reveals a non‑conforming failure path.
The type certificate holder diagnoses the issue, defines a technically sound mitigation in an AOT, and coordinates with regulators.
Authorities issue an EAD, and operators act within tightly defined compliance windows.
Every change is recorded and traceable across the aircraft lifecycle.

The technical disciplines involved – radiation physics, control‑law design, DO‑178C processes, DO‑254 and IEC 62396 hardware considerations, airline maintenance, Part 145 practices, and configuration management – are intricate and sometimes frustrating. Still, they are key reasons that commercial aviation achieves such a low risk per passenger‑kilometre.

If there is a lesson from ELAC L104, it is less about the existence of residual risk and more about the need to keep tightening the coupling between software engineering assumptions and evolving physical realities, such as increasingly well‑characterised atmospheric radiation environments and more aggressive use of deep submicron electronics.

Integrating SEE‑aware design and verification more deeply into the DO‑178C ecosystem and ensuring that tools, standards, and regulatory expectations keep pace are the natural next steps. The fact that a single radiation‑linked event on one flight could trigger a globally coordinated, technically disciplined response across thousands of aircraft is, in itself, a quiet demonstration of how mature that ecosystem already is.

Yves Remmler

Discussion about this post

Ready for more?