Failure Modes: Types, Examples, and Identification

A failure mode is the way an item fails to perform as specified, such as a valve that stays open past its stop point or a pump whose outlet pressure drops below a stated value. Failure modes are particularly risky when teams don’t document them in product requirements, because nobody writes a test for a mode the team never wrote down.

A Failure Mode and Effects Analysis (FMEA) rates and ranks failure modes, so you have to find and write down the modes before you start filling out the FMEA worksheet. Read on for six types of failure modes, four ways to identify them, and why each one should become a traced requirement.

What Are Failure Modes?

Formally, a failure mode is the manner in which a failure occurs, as the IEC vocabulary defines it in IEC 60050-192. Each of the entry’s examples names a lost or disturbed function and says nothing about why, as with a valve that “does not open,” an engine that “does not start” and timeout logic that “times out earlier than required.” A requirement that the valve open within a stated time of command can therefore be written, designed against and tested. “Corrosion” alone cannot support the same requirement, because it names the process behind a failure and no function a test could check.

The standards disagree on where the mode ends and the mechanism begins, so you should state your team’s convention. Military Standard 1629A (MIL-STD-1629A), a procedure for Failure Mode, Effects and Criticality Analysis (FMECA), defines the mode as “the manner by which a failure is observed.” It dates from 1980 and was canceled in 1998. Take a transistor whose cracked die produces an open circuit between collector and emitter. The open circuit is the mode, and the cracked die is the mechanism.

Each neighboring term belongs in a different column of the analysis and a different part of the requirements set. The table lines each one up against the failure mode, with definitions drawn from Military Handbook 338B (MIL-HDBK-338B), MIL-STD-1629A and NASA Guidebook 8719.13.

Term	Meaning	How it relates to the failure mode
Failure	The event or inoperable state in which an item does not perform as specified	The parent event. The mode is the manner in which it occurs
Failure mechanism	The physical, chemical, electrical, thermal or other process that results in failure	Produces the mode. The cracked die, not the open circuit
Failure cause	Design defects, quality defects, part misapplication or other processes that are the basic reason for failure or that start the mechanism	Upstream of the mechanism. Something causes the die to crack
Failure effect	The consequence of a failure mode on the operation, function or status of the system, rated at local, next-higher and end levels	Downstream of the mode, at each level of the design hierarchy
Fault	An anomalous change in an item’s state, such as an out-of-limits sensor value or an incorrect step in a program, that may warrant corrective action	A preliminary indication that a failure may have occurred, so it precedes the mode
Hazard	A condition or changing set of circumstances that presents a potential for adverse or harmful consequences	A failure mode may or may not lead to one. None of the standards cited here equates the two

An indenture level is one level of the design hierarchy. One level’s failure effect may become the next level’s failure cause, so the open circuit that is a mode at the transistor is a cause at the board. Each level needs its own requirement and verification.

The Types of Failure Modes Teams Have to Specify

The six types below group failure modes by where each type’s requirement comes from. No single standard groups them this way, but you can use the grouping to check whether the analysis covers functions, interfaces, operating environments, human actions, software behavior and degradation over time.

Functional Failure Modes

A functional failure mode describes a function and the way it departs from intent, with no reference to the hardware or software behind it. The generic list in MIL-STD-1629A is a common starting point:

• Premature operation: A stage separation command is issued early.
• Failure to operate at a prescribed time: The function does not start when commanded.
• Intermittent operation: Output appears on some demands and not others.
• Failure to cease operation at a prescribed time: A valve stays open past its stop point.
• Loss of output or failure during operation: Delivery stops partway through a demand.
• Degraded output or operational capability: Performance runs below its specified value.

Each entry needs a named function and a measurable threshold before it can become a requirement. Inadequate outlet pressure below a stated value is a mode a test can detect. An entry that says only that a pump “fails” gives no threshold, and copied into a requirement it becomes one of the ambiguous requirements no test can verify.

Interface Failure Modes

According to NASA’s definition of interface FMECA in Goddard Space Flight Center handbook GSFC-HDBK-8004, interface failure modes cover lost, degraded or excessive exchanges of data, material or energy between elements. Teams usually write the resulting requirements into the interface control document (ICD), so an FMEA that skips the ICD misses those modes.

An example of an interface failure mode is the Kansas City Hyatt Regency walkway collapse, where the walkways failed at a mechanical interface. A design change replaced a continuous hanger rod with interrupted rods, which roughly doubled the load on the fourth-floor box beam-hanger connections. From the day of construction, the connections “had only minimal capacity to resist their own weight and had virtually no capacity to resist additional loads imposed by people,” according to the National Bureau of Standards investigation. The walkways fell in 1981. The collapse killed 113 people and injured 186.

Environmental and Stress-Induced Failure Modes

An environmental failure mode is a function lost under a stress the item wasn’t specified to withstand, so the environmental envelope is itself a requirement. Temperature shock is associated with mechanical stress, structural collapse, weakening and seal damage, according to MIL-HDBK-338B, the Electronic Reliability Design Handbook. In Takata’s air bag inflators, long-term exposure to high temperature fluctuations and humidity breaks down the propellant until it burns too quickly and the inflator explodes, shooting shrapnel toward the occupants, according to the National Highway Traffic Safety Administration (NHTSA). The inflators have killed 28 people in the United States and allegedly injured at least 400 more, and about 67 million air bags are under recall, NHTSA reports. Because the propellant degrades along that path, the moisture and temperature envelope belongs in the inflator’s requirements.

Human-Induced Failure Modes

A human failure mode names the function lost through an action committed or omitted, according to the IEC vocabulary’s note on the term. In software-controlled systems, operator modes also include accidental unknown commands, proper commands issued at the wrong time and a failure to issue a command, according to NASA Guidebook 8719.13, the NASA Software Safety Guidebook.

The probable cause of the 2009 crash of Colgan Air Flight 3407 was “the captain’s inappropriate response to the activation of the stick shaker, which led to an aerodynamic stall from which the airplane did not recover,” according to the National Transportation Safety Board (NTSB). Listed only as “pilot error,” that mode produces no design change. Written as a failure to detect a decaying airspeed cue in time, it produces alerting, procedure and training requirements that can each be verified.

Software Failure Modes

Software doesn’t wear out, so its failure modes are design faults rather than degradation. To find them, software risk management enumerates modes by function, interface and data item. Five example modes come from NASA Guidebook 8719.13, and each points to something the software requirements have to state:

• Data value out of limits: A sensor reading or computed value leaves its valid range, and the requirement states that range and the software’s response outside it.
• Garbled data: Corrupted bytes arrive in a message, which calls for a requirement naming the integrity check and what happens when it fails.
• Overwritten memory: One routine writes over data another routine relies on, so memory protection or overwrite detection becomes the requirement.
• Missing input parameters: A function is called without a value it needs, and its requirement defines the default or the rejection.
• Unexpected path under previously unconsidered conditions: Execution takes a branch nobody analyzed, which a requirement can bound by limiting inputs and stating a safe response.

Four Cluster science satellites, the product of 10 years of work, were lost because a reused software routine met a flight profile nobody had written into its requirements. The first Ariane 5 veered off course at about 3,700 meters on 4 June 1996 and broke up. Inside its inertial reference system (SRI), the fault was an unprotected conversion of a 64-bit floating-point value to a 16-bit integer, in a routine reused from Ariane 4 for an alignment function Ariane 5 didn’t need. “There is no evidence that any trajectory data were used to analyse the behaviour of the unprotected variables, and … it was jointly agreed not to include the Ariane 5 trajectory data in the SRI requirements and specification,” according to the inquiry board’s report. The conversion fault was the kind of mode that never becomes a written requirement, so no test checked it.

In the Therac-25 radiation therapy machine, software permitted concurrent access to shared data, and the machine massively overdosed patients at least six times between 1985 and 1987. The manufacturer’s risk assessment “seems to consider only hardware failures,” the published investigation summary concluded. Software errors and poor software engineering practice were the primary cause of the overdoses, according to a 1993 IEEE Computer paper by Leveson and Turner.

Wear-Out and Degradation Failure Modes

A wear-out or degradation failure mode is a function that works at delivery and loses performance with time or use. MIL-STD-1629A calls this “degraded output.” “A low-cycle fatigue crack in the dovetail” of a CFM56-7B engine fan blade was the probable cause of Southwest Airlines Flight 1380 in 2018, the NTSB found.

After the crack released the blade, the blade struck the fan case, parts of the fan cowl separated and an inboard aft latch keeper hit the fuselage near a window. The window then departed, the cabin depressurized and one person was killed. To control this wear-out mode, a requirement has to catch the dovetail crack before it can release the blade.

Get the Datasheet

How to Identify Failure Modes Before the FMEA Begins

Teams find failure modes with four methods, starting from functions and interfaces and then drawing on field data and fault trees. An FMEA rates and ranks the list of modes those methods produce, so the list is only as good as the methods that built it.

Functional Analysis and Decomposition

Functional analysis produces the list of functions whose loss, degradation or unintended operation becomes the first set of failure modes. The steps are translating top-level requirements into functions, decomposing and allocating them to lower levels, and identifying the functional and subsystem interfaces, according to the NASA Systems Engineering Handbook. Decomposition produces a hierarchy that lets the team state each mode at the level where a requirement and verification activity can control it. Teams can use each function’s allocation to a lower-level element to assign an owner to each mode before opening the FMEA worksheet.

Interface Analysis From the Control Documents

Interface analysis works from the ICDs, the block boundary diagram and the parameter diagram (P-diagram). A functional FMECA can progress to an interface FMECA and then to a detailed FMECA in one Goddard Space Flight Center methodology. For every hardware failure mode, ask whether the flight software detects it and, if not, whether the hardware provides information the software could use. Asked at each interface, the two questions expose failures that neither side owns explicitly.

Field Data, Test Results, and the FRACAS Loop

A Failure Reporting, Analysis and Corrective Action System (FRACAS) supports identification as well as corrective action, because it can validate or disprove an FMECA’s baselines with measured failure data. In medical device risk management, the loop is an obligation. ISO 14971:2019, the risk management standard for medical devices, requires the manufacturer to actively collect production and post-production information and review it for previously unrecognized hazards or hazardous situations. No risk assessment had been done for Complaint #47856 to decide whether the FMEA needed updating, FDA investigators found at Xoran Technologies.

The 2019 edition of ISO 14971 widened the post-production information a manufacturer must collect to include the state of the art and feedback from component, subsystem and third-party software suppliers. Field monitoring under ISO 26262 Part 7 of the automotive functional safety standard can reveal unanticipated failure modes in warranty and diagnostic data.

Fault Trees as the Top-Down Complement

Fault Tree Analysis (FTA) works down from an undesired system event. In the deductive approach, the analyst postulates that the system has failed in a certain way and looks for the component behavior that contributes, according to the NASA Fault Tree Handbook. The handbook builds on the Nuclear Regulatory Commission’s NUREG-0492. An FMEA works inductively, starting from a component condition and tracing its effect upward.

A tree’s minimal cut sets, the smallest combinations of basic events that produce the undesired event, also expose common causes that can negate a redundancy, such as one manufacturing defect shared by identical valves. “In general, both deductive and inductive approaches must be employed to get a complete set of accident sequences,” the handbook concludes. Teams usually let the FMEA populate the basic events and use the tree to find the combinations and common causes that a single-mode entry doesn’t show.

Learn About FMEA

Why Each Failure Mode Has to Become a Traced Requirement

Automotive and medical safety standards both require each hazard to be traced to the requirement that controls it, and each failure mode a team identifies is one route to those hazards, so it belongs in the trace chain. ISO 26262 traces safety goals through functional and technical safety requirements to hardware and software.

In medical devices, design inputs must include the applicable outputs of risk management under the FDA’s Quality Management System Regulation (QMSR), in effect since 2 February 2026. Title 21 of the Code of Federal Regulations (21 CFR) 820.10(c) incorporates Clause 7.3 of ISO 13485, the medical device quality management system standard. ISO 14971 requires the risk management file to trace each identified hazard through risk analysis, evaluation, implementation and verification of risk controls, and residual risk. An auditor checks compliance by inspecting that file.

ISO 14971 also asks for two verifications of each control, one confirming implementation in the final design and the other confirming that the control reduces the risk. A risk control written as a mitigation with no test behind it cannot pass the second verification. Envoy Medical’s risk management process did not ensure routine hazard-evaluation updates, failed to identify critical hazards and allowed inconsistent severity ratings for infection-related failure modes, according to the FDA’s November 2025 warning letter.

The failure mode, the requirement it produced and the verifying test are often kept in separate documents, so a change to one may not reach the others. A hazard rating changes in the FMEA spreadsheet while the requirement keeps its old threshold and the test keeps passing against a requirement that no longer matches the hazard rating. The practice behind product traceability in regulated industries is to hold the risk item, the affected requirement and the verifying test as connected records in a linked-item system. When the hazard rating changes, you have to use your change management process to reassess every requirement and test linked to that hazard before the next assessment. Audit preparation shrinks when an auditor can follow the links between hazard and test instead of asking the team to reconcile three documents.

How Jama Connect Supports Failure Modes

An assessor can’t follow a failure mode that has no linked requirement, or a requirement that has no linked test. Jama Connect®, a web-based requirements management and traceability platform, holds failure mode work in FMEA matrices and linked risk records, where a custom picklist field can record each mode’s type, from functional and interface through environmental, human, software and wear-out. Traceability Information Models (TIMs) specify the required relationships among risks, requirements and tests, so a mode or requirement missing either link shows up as missing coverage in Live Trace Explorer™. When an upstream item changes, suspect links flag the downstream records that need review, whether the team found the mode through functional analysis, interface analysis, fault trees or FRACAS data. Ambiguous mode statements also need a quality check before baselining. Jama Intelligence, an add-on for Jama Connect Cloud, scores requirements against a set of International Council on Systems Engineering (INCOSE) rules, so a phrase such as “opens quickly” can be flagged as vague.

For automotive work, the pre-built framework provides a TIM for hazard analysis and risk assessment (HARA) under ISO 26262 and templates for threat analysis and risk assessment (TARA) under ISO/SAE 21434. Medical device teams get a framework that aligns hazard identification, risk estimation, risk control and residual risk assessment to ISO 14971, and both frameworks ship with pre-built risk analysis reports. An ISO 26262 assessor follows the chain that links each hazard to the requirement that controls it and the test that proves it. Linking each identified failure mode into that chain gives the assessor a path that starts from the mode. Apex.AI, which builds Apex.OS, an Automotive Safety Integrity Level D (ASIL-D) safety-certified software framework for mobility systems, reports a 75% improvement in audit efficiency with Jama Connect.

Keep the Failure Modes List Open After Release

Production data, supplier feedback and field monitoring can reveal modes after release, so a failure modes list that stops being updated at design freeze can be out of date by the first field report. Each design change, supplier change and field finding should trigger a review of the list for the items it touches before the next release.

Jama Connect supports this workflow with baselines, point-in-time snapshots of the linked risk items, requirements and tests at each release, so a field finding can be compared against what shipped. If your team reconciles an FMEA spreadsheet against a requirements document before every assessment, start a free 30-day trial and link one failure mode to its requirement and test.

Frequently Asked Questions About Failure Modes

Is fatigue a failure mode or a failure mechanism?

Fatigue is a failure mechanism under the IEC 60050-192 definition. The failure mode is what it produces at the item boundary, such as a fractured shaft. Some FMEA conventions record fatigue itself as the mode, which moves the resulting requirement off the lost function and onto the process that causes it. Whichever convention your team picks belongs in the FMEA ground rules, and Jama Connect can hold it in custom risk-item fields or picklists.

How many failure modes should an analysis include?

An analysis should include every mode with a credible effect at the next indenture level, with the scoping rules written down. For example, a scoping rule might leave out connector failures only for connections verified by pre-launch testing and left mated. A recorded exclusion defines the analysis boundary, while an undocumented exclusion looks like an omission. You can record which relationship types are required and which are optional in a Traceability Information Model.

Is a failure mode the same thing as a hazard under ISO 14971?

A failure mode and a hazard are different things under the ISO 14971 risk management process, and a failure mode is one way a device can reach a hazardous situation. The risk file should record the failure mode, the hazardous situation it can lead to and the risk control as separate linked entries, each pointing to its verification evidence, so the distinction remains visible through evaluation and testing.

Do software failure modes belong in a hardware FMEA?

Software modes belong in the same analysis set, although complex integrated circuits and software are analyzed with the functional approach under European Cooperation for Space Standardization (ECSS) standard ECSS-Q-ST-30-02C. A separate hardware and software interaction analysis then handles the software’s reaction to hardware failures before system integration testing.

If I want to learn more about failure modes, what else should I read?

The guide to types of FMEA explains how the main analysis variants differ and when to use each. For the regulated-work view, the article on traceability in medical device development shows how risk, requirements and verification evidence connect.
This article was authored by Mario Maldari and published on October 31, 2026.