People Are Not the Weakest Link
For thirty years the security industry has called people the weakest link. We argue the opposite — people are not the weakest link, they are the perimeter. What changes when teams build around that.
Key Takeaways
- → Saying people are the weakest link confuses involvement with root cause. Humans are often in the loop, but that does not make them the failure.
- → Behavior depends on ability, motivation, and opportunity. If one of those is missing, training alone will not change what people do.
- → Bad password policy can create bad behavior. Forced rotation and unusable rules push people toward sticky notes, reuse, and workarounds.
- → Shadow IT is feedback. When people use unsanctioned tools, the first question should be what the approved tool failed to provide.
- → Security is not a plug-in or a one-time training. It is a system of design, defaults, process, and trust.
What this episode is about
The security industry has repeated one line for decades: people are the weakest link.
Simon and André argue the opposite. People are not the weakest link. People are the perimeter. They are where many attacks arrive, where mistakes can happen, and also where attacks can be stopped.
This episode starts with a point from cybersecurity psychologist Inge Wetzer, presented at the SANS Security Awareness Summit in 2025: the weakness is not in people. The weakness is often in how the industry understands people. From there, Simon and André talk through password rules, bad training, shadow IT, personal devices, security culture, and why breach statistics can be true while still being misread.
Why the phrase matters
“People are the weakest link” sounds practical, but it makes the wrong thing too easy. If a user clicks, the user gets blamed. If someone writes down a password, the person gets blamed. If an employee uses an unsanctioned tool, the employee gets blamed.
The better question is usually one step earlier.
Why was the link convincing? Why was the password impossible to remember? Why did the approved tool make the job harder? Why was the employee expected to protect a company system from a personal laptop?
That does not remove responsibility from people. It puts responsibility back into the full system: design, policy, tools, incentives, training, and support.
Password policy as a design failure
Simon gives the example of strict password rotation. A rule that forces people to change long passwords every few months may look secure on paper. In practice, it can create sticky notes, predictable password changes, and frustration.
André has seen the same pattern in financial organizations. Employees were expected to create long, complex, frequently changed passwords while being blocked from using password managers. Some wrote passwords down and hid them under keyboards. The policy created the behavior it was supposed to prevent.
The episode looks at better options: password managers, passkeys, hardware security keys, smart cards, and physical access cards. None of them are magic. They still require rollout, support, budget, and clear use. But they are examples of designing around people instead of blaming them after the policy fails.
Training is not behavior
André brings in a behavior model from the research: behavior depends on ability, motivation, and opportunity. If any one of those is zero, the behavior does not happen.
That matters for security awareness training. If people do not know what to do, they cannot do it. If they know what to do but the system makes it inconvenient or impossible, they still will not do it. If training is boring, repetitive, or easy to click through without thinking, it can reduce motivation instead of improving security.
Training can help. Bad training becomes theater.
Shadow IT is feedback
Simon raises another common pattern: employees using tools that the company has not approved. The default security response is often to ban the tool.
The better first question is: what did that tool do better?
Maybe it was faster. Maybe it was simpler. Maybe it solved a real workflow problem the approved system ignored. If security teams listen to that signal, the sanctioned tool can improve. If they only ban the workaround, people learn to hide the workaround next time.
Correlation is not root cause
The Verizon Data Breach Investigations Report often shows a large human element in breaches. Simon and André do not dispute that.
Their point is narrower: a human element is not the same as human blame.
If an attacker sends a malicious file and an employee opens it, the employee is part of the incident chain. But the root cause may include poor email filtering, weak isolation, unclear reporting channels, pressure, bad defaults, or a culture where people are afraid to admit mistakes.
Humans are often in the loop because humans are where work happens. That makes them part of the perimeter, not an excuse to stop thinking.
The insurance laptop
Simon tells a story from an insurance agency. The agent was using one personal laptop for everything: personal browsing, business work, and access to insurance systems.
After the appointment, Simon sent a follow-up link to a page he controlled. The agent clicked it. The page explained what could have happened if the link had been malicious: cookies, browser data, and insurance logins could have been exposed.
The agent was not angry. He was grateful. Simon helped him set up a password manager, separate networks, and better protections.
The useful question is not “was the agent stupid?” He was not. The useful question is why a person handling sensitive customer data was left to solve that risk alone.
Security is not a plug-in
Simon uses the line often with web developers: security is not a plug-in. Security is a concept.
That applies beyond websites. It applies to personal devices used for business. It applies to mandatory training. It applies to password rules. It applies to whether people can report a mistake without being punished for speaking up.
Security happens in layers. When one layer depends on a person making the perfect choice under pressure, that layer needs help.
Check your exposure
This is the “What’s Your Move” for the episode: check your main email addresses in Have I Been Pwned.
The point is not to panic. The point is to know whether an address appears in known breach data, then fix the accounts that need attention. If a password was reused anywhere, change it. If a service supports passkeys, use them. If it does not, use a password manager and turn on breach alerts.
One search is enough to turn a vague security worry into a concrete next step.
Frequently asked questions
-
Why do Simon and André reject the phrase people are the weakest link?
Because the phrase treats human involvement as proof of human failure. The episode argues that many incidents happen because systems, policies, tools, and incentives push people into risky behavior. People are often the point where an attack lands, but that does not make them the root cause. -
What does the episode say about security awareness training?
Training helps only when people have the ability, motivation, and opportunity to act on it. Click-through training that people can finish without thinking becomes compliance theater. It checks a box, but it does not reliably change behavior. -
Why can password rotation make security worse?
Forced password rotation can push people toward predictable changes, reuse, or writing passwords down. The episode argues for safer defaults such as password managers, passkeys, hardware security keys, or smart-card-style access where they fit the environment. -
What is the point of the Have I Been Pwned exercise?
It gives listeners one concrete action after the episode. Checking an email address shows whether it appeared in known breaches, which accounts need attention, and where reused passwords should be changed.