Why Are Hyundai and Kia Vehicles So Easy to Steal?

Over the past several months, it has become quite obvious that something is very wrong with anti-theft systems that are standard equipment on many Hyundai and Kia vehicles sold in the US. This has been driven by online videos that show how easy it is to defeat the existing systems on these vehicles—there’s even a TikTok challenge to steal these cars.

It’s gotten so bad that State Farm has stopped insuring many different models that come from these two closely related brands. (Hyundai and Kia have shared ownership in Korea and use engineering and design information and hardware interchangeably in many areas of their vehicles.)

While there are scores of questions that can be raised about this situation, one that should be asked is “How did this escape the design verification process when these vehicles were being developed?”

I have no direct knowledge of how this may have occurred, and it’s likely impossible to ever find out the real answers unless these automakers bare their souls publicly—which is not going to happen unless they are forced to via lawsuits or regulatory action by the US (or some other) government.

Nevertheless, this is important, and, frankly, the answers that can be guessed are neither simple nor satisfying. They may appear to be straightforward, but that is highly unlikely to be the case.

How Can You Know What You Don’t Know?

To explore this, I want to start with an excerpt from the start of Chapter Two of my recent book on Design Failure Modes and Effects Analysis (DFMEA), “The Power of Deduction” (the 2nd edition).

When I was employed at Lennox International and working on heating and air conditioning systems and products, I was charged with reducing the cost of warranty for the Lennox residential business unit. After learning a great deal about where and how warranty claims arose, it became clear that it wouldn’t be the best use of our resources and time to fix problems with existing products that were already in the field.

It would be faster and more effective to improve each new product that we introduced to eliminate some of the weak points that led to field failure and subsequent warranty claims (or at least reduce the frequency of occurrence of these issues). At the same time, we were trying to develop and release designs with a great deal of new technology and simultaneously reduce product costs, which meant we would potentially be creating even more issues that might lead to warranty claims and associated expenses.

The role I lobbied for—and was later assigned to—was to lead an overhaul of our product development processes to drive this initiative forward.

At that point, John Whinery, who was running the product management team for the Residential business unit, said to me (referring to the new technologies we were introducing), “We know about existing problems. But how can we know what we don’t know?”

In any product development process, “knowing what you don’t know” is a serious and major concern. Missing something that later causes major customer problems, warranty costs, or even safety recalls is never trivial. Moreover, it doesn’t have to occur with every product sold. Something that shows up in even 2% of the products sold can be disastrous, and that’s a high bar for most consumer goods.

Two percent of all of the Hyundais and Kias sold over a multi-year period is a big number.

A very big and very ugly number.

I don’t think Kia or Hyundai lacked the means to know in this case. A common vehicle security feature, called an immobilizer, relies on a transponder in the key fob for the car. This sends a signal to the ignition system. If the system recognizes the coded signal, the car can be started. Current versions of this even use two signals. The second signal is newly-encoded back into the fob when the ignition is turned off—and then both signals must be confirmed for the car to start the next time. It’s a different way to get “two factor authentication” which almost everyone who uses the internet knows about.

Immobilizer systems have been in common use for about a quarter century, and they’ve had a major impact on reducing vehicle theft.

However, they must not have known something to make such a serious blunder in the design of their vehicles.

What Might Hyundai/Kia Have Done Differently?

There are two ways that you can find an issue like this in the product development process. One is inductive and one is what I might term “semi-deductive.”

The first opportunity—the inductive element—is when the product managers, market planners or strategic planners first decide that a new vehicle design is needed. This is an involved process and it includes understanding what competitive products are already available, either from their own brands or from competitive brands. Formal benchmarking is often part of the process, too.

It also includes feedback about your own brands from internal systems (such as warranty, service feedback surveys, and similar tools). It may also include classical market research, such as focus group studies, feedback from commercial market research companies (such as J.D. Power) and any other tool that helps shape the next generation of a product.

The goal, of course, is to describe, specify and develop a product that will have a powerful competitive advantage in some way, an advantage that will lead to financial success for the company producing the product.

This part of the development process is far more inductive than deductive. It’s based almost entirely on judgments, judgments that are informed by data but less-than-analytical decisions, nonetheless.

Why is this so? There are many reasons, but the most common cause is that a substantial number of product features that lead to marketplace success don’t emerge easily from market research. A focus group participant is unlikely to bring up a need for an immobilizer (or to say something about an anti-theft device). This is what the Kano Model characterizes as a “basic” need, a need that is unspoken yet critical to product performance.

And so it is possible that this issue was overlooked when the initial conceptualization for these vehicles was generated, due to the inductive nature of this stage of product development.

At the same time, it’s a bit more difficult to understand how this was overlooked during the more deductive activities of technical product design and, ultimately, verification of that design information.

In the DFMEA process, which should be a cornerstone of new product development, there is a more analytical approach that should have identified the functional requirements for an anti-theft feature in the ignition system. This won’t happen automatically, but it is more likely to be “found” during design activities if a more deductive approach to DFMEA is employed.

For the ignition system, this starts with a realization that the ignition system has a large number of parts and components. If this system operates well, there will be many different interactions between these internal system elements. Each interaction leads to one or more quantifiable functions that the system must successfully execute for the nominal, projected life of the product.

However, the ignition system does not exist in a vacuum; it is interactive with other vehicle systems. Again, as is true for the internal functions of the ignition system, each interaction gives rise to quantifiable functions that can be assessed, characterized, and then analyzed for potential failure, including cause, effect, risk, and the related tests and evaluations that will form the basis for verification of the design information that will be used to fabricate and assemble the vehicle.

But there’s yet another set of issues that must be addressed. These are the issues of user factors and environmental factors that exist outside of the vehicle itself—and outside of the direct control of the design engineering team. Each of these external factors may interact with the ignition system in many ways, and, once again, each interaction leads to one or more quantifiable functional requirements and a similar sequence of events leading to design verification.

These two categories of external elements, though, are a bit more murky than the direct interactions within the ignition system or between the ignition system and the rest of the vehicle. These interactions also lead into the less-than-clearcut realm of robustness.

The first error that may have occurred is to fail to identify “unauthorized user” as a potential external interaction source. That’s an error that is hard to accept, given the current nature of hacking that occurs on modern, web-connected vehicles.

If “unauthorized user” was identified as an external factor in the ignition system using a parameter diagram (or “P-diagram”), the next step is to link the ignition system to the unauthorized user with an active verb—inhibits—which leads to a constructive statement of function.

This explicit function could be stated as “Ignition system inhibits vehicle usage by unauthorized user.”

Now, this function may have several potential disruptions, or failure modes, including:

• Doesn’t inhibit
• Partially inhibits
• Excessively inhibits (makes it too hard for authorized users to start the vehicle)
• Loses inhibition over time (the function isn’t reliable)

Each of these modes has associated effects, probable causes, prevention controls that explore the causes and detection controls that evaluate the design with respect to the effects. The execution of these controls is then the basis for design verification.

There’s an intermediate step that’s often overlooked, however. And that is the quantification of the original function. In other words, how well must the system inhibit unauthorized usage? This is really what “robustness” is about—the degree of functionality that’s suitable for the product and the target markets. At a certain point, excessive robustness leads to wasted cost, but at another point, lesser robustness can lead to problems that degrade a product.

Of course, even an immobilizer can be defeated. An immobilizer will not stop a thief from rolling up a flat bed truck and winching the targeted vehicle onto the bed and stealing it that way. But it will significantly inhibit a lower level of thievery, and that is a reasonable level of robustness in this case.

This is where I suspect that Hyundai/Kia went astray. They may have understated the need for?resistance to unauthorized usage during the design process and decided that an immobilizer was more than necessary.

All of that would be a technical design error, and DFMEA would—if done rigorously and deductively—at least expose the issue. Without the quantification of the function, though, this may have been overlooked.

There’s Yet One More Thing To Consider

Finally, beyond the inductive tools of product management and the deductive tools of technical design, there’s yet one more possibility. This is another reality that occurs from time to time. Both product managers and design engineers may have recognized that an immobilizer was needed, having used the tools, both inductive and deductive, at their disposal to determine that requirement.

That’s not the final word, though. In some cases (and I’ve seen this far too often) senior management then decides, for some reason, often to increase margins by reducing cost, that something identified as important during the product development process really isn’t necessary.

Proper use of inductive and deductive tools only informs management; they do not, in the final analysis, constrain management. Executives can (and sometimes do) make decisions that are foolish, violate existing governmental regulations, or are even criminal.

Volkswagen’s “Dieselgate” disaster is just such a case.

If we continue to ask “why” in such circumstances, it often comes down to a fundamental issue. The importance of quality in products is often relegated to a second tier of significance behind more easily quantified (and often incentivized for executives) financial outcomes. There are few organizations with Chief Quality Officers, and those that have such roles usually make the CQO a powerless figurehead who only advises and is often ignored.

Another way to say this is that quality rarely has a seat at the main table in large corporations. Quality should not be the reigning monarch, of course, but subjugating quality to other executive goals is all too common.

This occurs in spite of the fact that the relegation of quality to secondary status can, and too often does, lead to financial calamities just as we are seeing play out for Hyundai/Kia and has already befallen Volkswagen.

While the term “foolproof” has deservedly fallen out of favor as a somewhat pejorative term, it’s still true that “any damn fool can break something if they try hard enough.”

Which of these failures—or perhaps a combination of these failures—was at play in this case? We don’t know and won’t be able to learn from this unless more details are made public.

Nevertheless, any organization can learn the essential disciplines of product development methods and processes and apply those principles in new product introduction activities.

But, beware, knowledge alone is not enough; the principles must be applied and that must be done rigorously and with full documentation and review to avoid major failures. And that’s because there are always things that are not known when new products are developed.

Incomplete, inadequate, or improper use of the tools described above are often the reason that unknown or unrecognized issues, issues that lead to financial and marketplace tragedies, occasionally slip through the cracks.