MCAS, the 737 MAX flight control law, acted on input from a single angle of attack sensor at a time, so one faulty sensor could trigger repeated nose down trim. Two MAX crashes, Lion Air 610 and Ethiopian Airlines 302, killed all 346 people aboard. The lessons concern redundancy, assumptions and certification.
What MCAS was
The MAX's larger, forward mounted engines made the aircraft tend to pitch up at high angle of attack. MCAS was meant to make it handle like the earlier 737 NG, which reduced pilot retraining. When active it trims the horizontal stabiliser nose down.
The single point of failure
The MAX has two angle of attack sensors, but MCAS used one at a time and had no basis to reject bad data. Boeing acknowledged on 4 April 2019 that MCAS played a role in both crashes. Lion Air 610 crashed into the Java Sea on 29 October 2018 after repeated MCAS nose down input from false high angle of attack data. Investigators found the same pattern on the Ethiopian flight in 2019.
What investigations found
The NTSB said in September 2019 that Boeing's safety assessment assumed pilot responses that did not account for multiple alerts and indications, and questioned testing that used highly trained test pilots instead of a representative range. A Joint Authorities Technical Review found the FAA had not properly reviewed MCAS and that Boeing did not give adequate, updated technical information or thoroughly stress test the system.
Other reported findings: MCAS could move the stabiliser about four times farther than the initial analysis stated; manual trim was very hard to turn under load; and an angle of attack disagree alert was disabled by default and was a paid option most airlines had not bought. MCAS was also left out of the flight manual and training, so pilots did not know it existed.
What changed
The November 2020 airworthiness directive requires input from both sensors and disables the speed trim system if they differ by more than 5.5 degrees. MCAS activates only once per high angle of attack event with limited movement, and the flight control computers monitor each other. EASA had preferred triple redundant sensors, which the upgrade did not include.
Lessons for software safety work
Count your single points of failure. If a safety function reads one sensor, one bad reading is the whole story.
Cross check inputs. Disagreement between redundant sensors is information, so use it.
Test your assumptions about people. A response time assumed in a paper analysis needs testing with realistic users and distraction.
Re-run the analysis when scope grows. The function was expanded without a fresh safety review.
Tell users the system exists. Hidden automation is a hazard.
Do not sell safety as an option. A key alert that was a paid extra undermines the safety case.
These are the same questions functional safety standards put at the start of the lifecycle: see what functional safety is.
Quick check
Did MCAS use both sensors?
Originally it used one at a time. The 2020 directive changed that to require both.
Was it only a software bug?
The source describes design, assumption, certification and training failures as well as the sensor dependency.
Sources
A secondary summary of the first part of a long page; see NTSB and JATR reports for primary findings.
Last reviewed: 19 October 2026.
