TABLE OF CONTENTS
Key Takeaways
- Product recalls remain widespread and costly, with more than 29 million vehicles recalled in both 2024 and 2025 alone.
- Fragmented product data makes it harder to identify root causes, determine which configurations are affected, and execute corrective actions accurately.
- PLM reduces recall risk by connecting requirements, BOMs, supplier parts, revisions, approvals, and engineering changes within a controlled product record.
- Effective recall management requires a closed loop between field issues and engineering— including proof that corrective actions reached every affected product.
- PLM cannot eliminate every failure or replace a quality management system, but it can help teams catch problems earlier, limit their impact, and prevent them from recurring.
Here’s how to make a hardware team quiver: “product recall.”
Not only can these two words cost your business money, but jobs as well. And unfortunately, product recalls aren’t infrequent. In the automotive industry alone, more than 29.3 million vehicles were recalled in 2024 across 1,073 vehicle and equipment safety recalls. In 2025, another 29 million+ vehicles were recalled through 997 safety recalls.
Product recalls are sometimes treated as isolated failures: a bad batch of batteries, a faulty automotive component, or a design that did not behave as expected in the field. But the reality is that hardware products are becoming more complex, supply chains are becoming more distributed, and software, electronics, and mechanical systems are increasingly intertwined. More complexity means more opportunities for requirements to be misunderstood, specifications to drift, supplier defects to escape detection, and engineering changes to be implemented incorrectly.
Many of these recent recalls reveal the kinds of product-data, traceability, and change-control problems that product lifecycle management (PLM) systems are designed to help hardware companies manage. Let’s dive into how PLM can mitigate product recalls across hardware.
Recent Hardware Recalls Show the Scale of the Problem
In 2024, Samsung recalled approximately 1.12 million electric ranges because their front-mounted knobs could be activated accidentally by people or pets. The ranges were reportedly involved in approximately 250 fires, 40 injuries, and seven fires involving pet deaths.
That same year, Hatch Baby recalled approximately 919,400 power adapters included with its first-generation-generation Rest sound machines. The plastic housing could detach while the adapter was being unplugged, leaving energized prongs exposed. Hatch received 19 reports of the housing coming off, including two reports of minor electrical shocks.
The pattern continued in 2025.
Anker recalled approximately 1.16 million PowerCore power banks because their lithium-ion batteries could overheat. The company received 19 reports of fires or explosions, including two minor burn injuries and 11 reports of property damage totaling more than $60,700.
Perhaps the most serious recent example came from the medical-device industry. Abbott initiated a correction involving approximately three million FreeStyle Libre 3 and Libre 3 Plus glucose sensors produced on one manufacturing line. Certain sensors could report glucose levels lower than they actually were, potentially leading patients to make incorrect treatment decisions.
The FDA later classified the action as its most serious type of recall. As of January 7, 2026, Abbott had reported 860 serious injuries and seven deaths associated with the issue.
These recalls involved different products, industries, and failure modes. But they all required the affected companies to answer a similar set of questions:
- What exactly failed?
- Which requirement, component, process, supplier, or software version contributed to the failure?
- When was that configuration introduced?
- Which products contain the affected component or revision?
- Who approved the design or process change?
- What evidence shows that the corrective action solves the underlying problem?
- Which shipped units need to be repaired or replaced?
When product information is fragmented across CAD files, spreadsheets, emails, supplier portals, and disconnected business systems, answering those questions can become an enormous undertaking; and is often the cause of these failures in the first place.
What Happens When a Recall Does Not Address the Root Cause?
Ford’s recent fuel-injector recalls offer an especially revealing example.
The underlying problem involved fuel injectors that could crack and leak fuel near hot engine components, creating the risk of an under-hood fire. Ford initially addressed the issue through recalls in 2022 and 2024, and the remedies used software to detect a cracked injector and included a tube intended to direct leaking fuel away from potential ignition sources.
But NHTSA questioned whether those remedies addressed the actual root cause: the defective injectors themselves.
The situation became more complicated in 2025, when Ford recalled 33,576 vehicles because they had not received the correct software remedy even though records indicated that the repair had been completed. The new corrective process required technicians to validate the installed software before closing the recall action.
Ford subsequently expanded the recall to 694,271 Bronco Sport and Escape vehicles. The final remedy called for replacing the high-pressure fuel rail and injectors with components of a different design, along with updating the vehicle software.
By that point, Ford had identified cracked injectors in eight vehicles that experienced under-hood fires. The company estimated that the field action would cost approximately $570 million.
This entire debacle shows why effective change management involves more than releasing a corrective action. Your company has to make sure the action addresses the root cause, reaches every affected configuration, is installed correctly, and is validated before the work is recorded as complete.
Without that closed loop, a recall can become just another source of product inconsistency.
Kia encountered a similar challenge. In 2026, the automaker recalled 462,869 Telluride vehicles that had already been recalled in 2024 for a power-seat motor fire risk. An improper repair under the earlier recall could still allow the motor to overheat. Kia reported seven seat fires and 11 melted motors, leading to a new remedy involving an electronic fuse assembly.
Corrective action is only valuable if the organization can prove that it was effective.
The Cost of a Recall Goes Well Beyond Replacement Parts
A hardware company may also need to absorb the cost of engineering investigations, destructive testing, supplier analysis, replacement inventory, expedited freight, dealer or technician labor, customer support, regulatory reporting, legal work, the list goes on and on… and so do the costs.
Additionally, all this means that internally, the engineers who would otherwise be developing the next product will instead be spending months reconstructing decisions and investigating old configurations all in the name of damage control. Future products are delayed, which means lower revenue across the board.
Then we get to the fines. In 2024, NHTSA imposed a civil penalty of up to $165 million on Ford for acting too slowly and providing incomplete information in connection with defective rearview cameras. As part of the resulting consent order, Ford was also required to improve its safety-data analytics, cross-functional information sharing, recall decision processes, document infrastructure, and component traceability at the vehicle-identification-number level. (Ahem, that’s a wordy way to say “you need better PLM.”)
Recalls are also difficult to complete once products are in customers’ hands. The Consumer Product Safety Commission reported an average 44.55% response rate for consumer-product recalls in fiscal year 2025. In other words, even after a company identifies a dangerous product and launches a corrective action, reaching every customer and removing every defective unit can be extremely difficult.
So what have we learned? The best time to address a quality problem is before the product ships. Enter PLM.
How PLM Helps Reduce Recall Risk
PLM can’t guarantee that a product will never fail. But what it can do is give engineers and other stakeholders much better and tighter control over the information used to design, approve, source, manufacture, and maintain that product.
Connect Requirements to Product Decisions
Many hardware recalls happen because the product was not designed for a real-world condition that should have been considered earlier. For example, the risk of accidental activation, exposure to heat and moisture, repeated mechanical stress, drainage, corrosion, and foreseeable misuse can all begin as product requirements. Those requirements then need to remain connected to design decisions, validation tests, approvals, and later changes.
When requirements and product records are disconnected, engineers may not realize that a seemingly “minor” component change compromises a safety assumption made earlier in development. Connecting requirements management with PLM makes it easier to see what a part or assembly must do, and whether a proposed change affects those obligations.
Maintain Control of Revisions and Engineering Changes
Hardware teams make thousands of decisions throughout a product’s life. Materials change. Suppliers change. Firmware gets updated. Manufacturing processes evolve. Components become unavailable and are replaced.
PLM creates a structured process for proposing, reviewing, approving, and documenting those changes. It establishes which revision is current, when it became effective, which products use it, and why the change was made.
That history is vital during a quality investigation. Instead of searching through inboxes and old file directories, engineers can reconstruct the evolution of a product and determine when a potentially defective configuration entered production.
Trace Supplier Parts Through the BOM
The Abbott sensor issue was connected to one production line. GM’s 2025 recall of 597,630 vehicles was tied to supplier manufacturing and quality problems affecting connecting rods and crankshafts.
These examples demonstrate the importance of knowing more than a component’s basic part number. Hardware companies need relationships between supplier parts, manufacturer part numbers, approved alternatives, revisions, BOMs, and finished products.
A structured product record in your PLM helps a company determine where an affected component is used and which products could contain it. That can make the difference between a targeted recall and an unnecessarily broad one.
Create a Closed Loop Between Field Quality and Engineering
Warranty claims, customer complaints, nonconformances, service records, and returned-product analyses contain valuable engineering information. But that information often remains isolated in service, support, or quality systems. Siloed data is always problematic in hardware, especially when the products are complex.
A closed-loop quality process connects those events back to the product definition. Engineers can look for patterns across part revisions, suppliers, lots, configurations, and operating conditions. If a design change is needed, that change can be managed in PLM while the associated investigation and corrective action remain linked in the QMS.
This prevents the organization from treating each failure as an isolated incident. It also preserves the lesson so the same problem does not reappear in a future product generation.
Verify That Corrective Actions Were Implemented
The Ford fuel-injector case demonstrates the danger of recording a corrective action as complete without verifying the product’s actual configuration.
An effective process should be able to confirm that the correct part, firmware, software, instruction, or process revision reached the affected product. It should also preserve the validation evidence and approval history behind that correction.
PLM contributes the product definition and change history, while connected ERP, MES, QMS, and service systems provide manufacturing and implementation records. Together, these systems can establish what was supposed to change, what actually changed, and which units still require action.
PLM Is the Product-Data Backbone, Not the Entire Quality System
PLM alone does not replace risk analysis, design verification, supplier audits, manufacturing controls, a QMS, or experienced engineers. But its role is to connect these disciplines around a controlled product definition. When data is everywhere, your PLM acts as your single source of truth.
When those systems share accurate product information, companies can create a continuous feedback loop from design through manufacturing and back from the field.
Duro’s PLM gives hardware teams a centralized system for part data, BOMs, revisions, impact analysis, approvals, and engineering changes. Its integrations and API-first architecture also allow product information to connect with requirements, CAD, QMS, ERP, MES, and other systems across the hardware development stack.
The goal is not simply to improve documentation. It is to ensure that everyone designing, approving, sourcing, building, and correcting a product is working from the right information.
Better Recall Management Starts Before the Recall
Recalls will unfortunately remain a part of the hardware industry. Products are complex, operating conditions are unpredictable, and no development process can eliminate every possible failure.
But hardware companies can control how much uncertainty exists in their product data to help mitigate these recalls, and catch many more issues before they even make it out of the development phase by leveraging a robust PLM. It can give engineers the information needed to catch problems while they are still digital, long before they become thousands or millions of physical products in the field.
That is where a modern PLM proves its value, by helping prevent avoidable failures, limit the blast radius when something goes wrong, and turn every quality issue into knowledge that improves the next product.
