The Security Decision Nobody Can Make Correctly

In recent years, several high-profile intrusions have reportedly begun with a remarkably simple attack path: convincing a help desk employee to reset account credentials. What appears at first glance to be a failure of identity verification is often a much more interesting problem involving trust, uncertainty, and decision-making. The resulting breaches disrupted operations across organizations and became some of the most widely discussed examples of social engineering.

The incidents sparked a familiar conversation within the security community. How could someone be convinced to reset access for an attacker? What warning signs were missed? Why wasn't the attack detected?

These are reasonable questions. However, they may not be the most interesting ones.

A more useful question is this: What information did the help desk employee actually have available when the decision was made?

Imagine receiving a call from someone claiming to be an employee who has lost access to their account. They know the employee's name, department, manager, and perhaps details gathered from public sources or previous data breaches. They sound legitimate. They sound frustrated. They may sound exactly like a genuine employee who needs help regaining access to a critical system.

Your responsibility is to determine whether they are who they claim to be. The difficulty is that you cannot directly observe the answer. In many cases, the information available to the help desk is equally consistent with a legitimate employee and a sophisticated attacker. The challenge is not detecting obvious deception. The challenge is distinguishing between two plausible explanations when neither can be directly verified.

Approve the request. Deny the request. Escalate the request.

The challenge is not that help desk personnel are careless or insufficiently trained. The challenge is that trust decisions are often made under conditions of uncertainty. Researchers have studied this problem for decades in fields ranging from economics and organizational theory to psychology and systems engineering. One recurring finding is that people rarely make decisions with complete information. Instead, they make decisions within constraints.

Available information, time pressure, incentives, and operational objectives all shape behavior. Herbert Simon's work on bounded rationality observed that people facing incomplete information and limited time rarely identify the optimal solution. Instead, they select a solution that appears acceptable based on the information available to them. In other words, decision quality is often bounded by the environment in which the decision is made.

Support organizations operate within those constraints every day. Most help desk interactions are legitimate. Most callers genuinely need assistance. As a result, support operations are typically optimized for responsiveness, efficiency, and customer satisfaction. Those priorities are entirely reasonable. Employees need access to systems to perform their jobs, and organizations depend on support teams to restore that access quickly when problems occur.

Attackers understand this reality. Some groups are described as social engineers, but that description only tells part of the story. They are also students of organizational processes. They understand how identity recovery works. They understand the pressures support teams face. Most importantly, they understand that support personnel must often make decisions without perfect information.

The attacker does not need to defeat the process. They only need to appear consistent with what the process expects to see. This is why social engineering is often more than an attack against an individual. It is an attack against a decision environment.

The attacker understands that a frustrated employee may sound legitimate. An urgent request may sound legitimate. A senior executive demanding immediate assistance may sound legitimate. The signals used to identify legitimate users are often the same signals an attacker attempts to imitate. The result is an unavoidable challenge: distinguishing between legitimate and malicious behavior when both may appear similar.

Complex systems research provides another useful perspective. In his work on Normal Accident Theory, sociologist Charles Perrow argued that complex systems sometimes produce failures not because individuals are negligent, but because operators are required to make decisions with incomplete visibility into the larger environment. The lesson is not that failure is inevitable. Rather, it is that decision quality is constrained by the information available to the decision maker.

Help desk identity verification often shares these characteristics. The support representative is expected to make an important trust decision while possessing only a fraction of the information that might be useful. Recognizing this challenge changes how we think about solutions.

When social engineering incidents occur, the natural response is often additional awareness training. Training absolutely has value, and support personnel should be equipped to recognize common attack techniques. However, training alone cannot create information that does not exist.

A more durable approach is to examine whether certain trust decisions can be redesigned.

Consider self-service password reset and account recovery systems. Rather than requiring a support representative to determine whether a caller is legitimate, these systems rely on identity factors established before the recovery event occurs. The decision is based less on whether someone sounds convincing and more on whether they can satisfy pre-established identity verification requirements.

This does not mean self-service recovery is automatically secure. Poorly designed recovery workflows can still be abused through weak recovery factors, compromised email accounts, SIM swapping, or insecure fallback mechanisms. However, from an architectural perspective, strengthening a controlled identity recovery process is often preferable to requiring a support representative to act as the primary verifier of identity.

Of course, not every trust decision can be automated. Exceptional circumstances occur. Systems fail. Recovery factors are lost. Human judgment will always remain necessary in some situations. When that happens, the surrounding process should adapt to the risk of the decision.

One of the more interesting findings from organizational research is that people naturally optimize for the metrics by which they are evaluated. Agency theory and related research suggest that individuals align their behavior with organizational incentives. This is not a flaw. It is a predictable consequence of how performance systems work.

For routine support requests, metrics such as responsiveness, customer satisfaction, and resolution time make sense. These interactions are generally low risk and benefit from efficiency.

High-risk identity decisions are different. Resetting credentials for a privileged administrator account, modifying multifactor authentication settings, or restoring access to sensitive systems may have consequences far beyond a typical support interaction.

In these situations, the primary objective should not be speed. It should be correctness. The decision environment should reflect that distinction. Additional context should be available to the decision maker. Escalation paths should exist for higher-risk scenarios. Verification requirements should become more rigorous as potential impact increases. Most importantly, personnel should never feel pressure to prioritize speed when the consequences of an incorrect decision are significant.

Ultimately, social engineering is not simply a story about deception. It is a story about trust, uncertainty, and decision-making. Organizations face a difficult balancing act. They must provide users with timely access to the systems they need while also protecting those systems from increasingly sophisticated attackers. Support teams sit at the intersection of those competing objectives.

Rather than asking whether an individual should have made a better decision, it may be more useful to examine the design of the decision itself. Can identity recovery be based on pre-established factors rather than real-time human judgment? And when human judgment is unavoidable, can incentives, escalation paths, and available context be adapted to reflect the risk of the decision?

In many cases, the answer may involve stronger identity architectures, self-service recovery workflows, and risk-based escalation processes. The objective is not to eliminate human judgment. The objective is to ensure that when human judgment is required, people are supported by systems designed to help them succeed.