Stop Blaming the User: Design Security for Human Failure

Security Awareness Training can reduce the likelihood of a successful attack.

Security Architecture determines whether that attack becomes a minor incident or a business-impacting breach.

The wrong question after a phishing incident is:

"Why did the employee click?"

The better question is:

"Why was a single click enough?"

For years, incident reviews have stopped at a familiar conclusion:

The user clicked the link.

Technically, that may be accurate.

Architecturally, it explains very little.

People are part of the security system. Security Awareness Training, phishing simulations, and reporting processes all have value. But none of them should be treated as a security boundary.

A resilient security model assumes that, sooner or later, someone will make a mistake.

The real measure of resilience is what happens next.

Human Error Should Be a Failure Mode, Not a Catastrophe

Modern cybersecurity already assumes that many controls will eventually fail.

We accept that:

• Software will contain vulnerabilities.

• Endpoints may be compromised.

• Credentials may be exposed.

• Third parties may be breached.

• Detection controls will occasionally miss malicious activity.

This is the foundation of defense in depth and Zero Trust.

Human behavior should be treated no differently.

Any security model that depends on every employee correctly identifying every phishing email, fake login page, fraudulent phone call, and social-engineering attempt contains a dangerous dependency:

perfect human behavior.

Attackers only need that assumption to fail once.

A successful phishing interaction should therefore be viewed as the start of an architectural stress test, not the end of the investigation.

The Wrong Question: "Who Clicked?"

Focusing on the initial mistake often distracts from the factors that actually determined the outcome.

Consider an Adversary-in-the-Middle (AiTM) phishing attack.

The victim receives a convincing phishing page, enters credentials, and may even complete Multi-Factor Authentication (MFA).

At that point, asking why the user failed to recognize the attack provides limited insight into organizational resilience.

The more important questions are:

• Why could the attacker authenticate?

• Why could the session be reused?

• Why did the compromised identity have access to those resources?

• Why was privilege escalation possible?

• Why was lateral movement allowed?

• Why did detection and containment fail to interrupt the attack chain?

These are architectural questions.

And architectural questions determine business impact.

Human Failure Does Not Have to Become Business Failure

The 2022 SMS-phishing campaign targeting technology companies provides a useful example.

Employees at both Twilio and Cloudflare received highly convincing phishing messages and were directed to fake authentication pages.

In both organizations, users entered credentials.

The difference was not user behavior.

The difference was architecture.

Cloudflare's use of phishing-resistant FIDO2 authentication prevented stolen credentials from being used successfully. Human failure occurred, but the attack was contained.

The lesson is simple:

Security outcomes are determined less by whether a mistake occurs and more by what the environment allows an attacker to do afterward.

Awareness Reduces Likelihood. Architecture Reduces Impact.

A common mistake in security strategy is treating awareness as a primary security control.

It is not.

Awareness serves one purpose:

Reduce the likelihood of compromise.

Architecture serves another:

Reduce the impact when compromise occurs.

Both are necessary. Neither replaces the other.

Problems arise when organizations implicitly assume that everything behind the authentication boundary remains secure as long as users continue making perfect decisions.

That is not a resilient assumption.

And it is becoming increasingly unrealistic.

Attackers continue to evolve their techniques, using phishing, social engineering, token theft, device-code phishing, malicious OAuth consent, and compromised workload identities to obtain initial access.

The lesson is not that users are the weakest link.

The lesson is that initial access will continue to happen.

Security Architecture must therefore be built to absorb failure.

Design the Attack Chain to Break

Resilience comes from creating multiple independent opportunities to stop an attacker.

A mature architecture should focus on five objectives:

1. Prevent Initial Compromise

Use controls such as:

• Phishing-resistant authentication

• Passkeys and FIDO2

• Secure email controls

• Browser protection

• Device trust enforcement

• Legacy authentication removal

• Strong identity-verification processes

The objective is simple:

Make unauthorized access difficult.

But never assume prevention is perfect.

2. Protect the Authenticated Session

Authentication is not the end of the problem.

The authenticated session itself becomes a target.

Organizations should focus on:

• Device-bound sessions

• Continuous risk evaluation

• Risk-based reauthentication

• Appropriate session lifetimes

• Rapid session revocation

• Token and application-consent protections

The key question becomes:

If authentication is compromised, can the resulting trust be reused elsewhere?

3. Limit Privilege

Assume an attacker gains control of a standard user account.

What can they actually reach?

Least privilege should be an architectural property, not a policy statement.

Key controls include:

• Just-in-Time (JIT) privileged access

• Separate administrative identities

• Access reviews

• Approval workflows

• Restricted application permissions

• Workload identity governance

A compromised identity is a risk.

A compromised identity with excessive privilege is an amplifier.

4. Contain Lateral Movement

Attackers rarely stop at the first account.

They pursue what that account can lead to.

Architectures should therefore enforce:

• Administrative tiering

• Environment segmentation

• Separate privileged identities

• Protected administration pathways

• Hardened workload identities

• Clear trust boundaries

The goal is not merely to secure systems individually.

The goal is to stop compromise from becoming transitive.

5. Detect, Respond, and Recover

Eventually, preventative controls will fail.

Organizations must be able to:

• Detect suspicious authentication quickly

• Identify abnormal privilege use

• Revoke sessions immediately

• Isolate compromised devices

• Restrict affected identities

• Identify downstream compromise

• Securely recover accounts

A weak recovery process can undermine even the strongest authentication controls.

Recovery is part of the security architecture.

The Metric That Matters

Phishing simulation results may be useful, but they reveal only part of the picture.

A more meaningful question is:

What is the maximum credible impact of a single compromised user?

The answer exposes architectural weaknesses immediately.

Can the attacker:

• Reach privileged systems?

• Access sensitive data?

• Discover credentials?

• Establish persistence?

• Move laterally?

• Use administrative tools?

Most importantly:

How quickly would the organization know?

These answers provide a far better measure of resilience than click rates alone.

Design for Failure

Zero Trust is not fundamentally about products or technologies.

It is about assumptions.

Do not assume:

• Successful authentication means trustworthy activity.

• A compliant device remains trustworthy indefinitely.

• Awareness training guarantees correct future decisions.

• The first control will always work.

Every meaningful control should force an attacker to cross another boundary.

That is defense in depth.

That is containment.

That is resilience.

After an incident, the investigation should not end with:

The employee fell for phishing.

That describes the trigger.

It does not explain the breach.

The questions that matter are:

• Why was that mistake sufficient?

• Which control should have stopped the attack next?

• Why did that control fail?

• How far could a compromised identity travel before being contained?

The goal is not to eliminate human error.

The goal is to ensure that inevitable human error becomes a contained security event rather than an enterprise compromise.