You've invested in awareness training, rolled out MFA, and sent phishing simulations. Yet, your help desk still fields password reset requests every hour, your analysts are overwhelmed with alerts, and someone in finance just clicked a credential-harvesting link while rushing to close the quarter.
The problem isn't that your people are careless. The problem is that most security programs are built as if people don't exist until they need to be trained or blamed.
NIST just released a concept paper on human-centered cybersecurity, seeking public input by September 30, 2026. The timing matters. Gartner identified human-centric security as a top trend, and research continues to document what security leaders already know: burnout among security professionals is widespread, employees work around security controls that disrupt their jobs, and the business pays in lost productivity and breach costs.
But here's what doesn't help: the myths we keep telling ourselves about why security fails. Let's address them directly.
Myth 1: "We just need better training"
Reality: Training alone has never solved a design problem.
Existing cybersecurity frameworks overwhelmingly treat the human element as a training gap. You see it in every compliance checklist: annual security awareness, phishing simulations, acceptable use policies. Check, check, check.
Awareness training creates an unrealistic expectation that employees will remember everything, understand complex concepts, and always make the right decision under pressure, without addressing why they're making mistakes. If your password policy is so complicated that people write passwords on Post-it notes, no amount of training will fix that. You've built a system that requires workarounds.
Research backs this up. Security fatigue is a documented phenomenon: when security controls are too demanding or frequent, people disengage. They click through warnings without reading them. They reuse passwords across systems. They find the path of least resistance, which is rarely the most secure path.
What works instead: Design security controls that fit how people actually work. If your VPN disconnects every 20 minutes, don't train people to reconnect more diligently, fix the timeout setting or implement zero-trust architecture that doesn't require constant re-authentication.
Myth 2: "People are the weakest link"
Reality: People are also your sensors, reporters, and problem-solvers.
This framing does real damage. When you position employees as vulnerabilities to be contained, you build defensive controls that treat every user action as suspect. You create friction. You erode trust.
Human-centered cybersecurity flips this: people aren't just attack surfaces. They're the ones who notice unusual vendor emails. They're the ones who report suspicious behavior. They're the ones who adapt when your carefully designed incident response plan meets reality at 2 a.m.
Security professionals themselves are burning out under systems that weren't designed for them. You've hired skilled analysts and then asked them to monitor six disconnected dashboards, triage alerts with no context, and make judgment calls while exhausted because the tools don't integrate and the runbooks assume perfect conditions.
What works instead: Build controls that empower rather than constrain. Make reporting easy. Make alerts actionable. If your SIEM generates 500 "urgent" alerts per shift, you don't have an alert problem, you have a design problem.
Myth 3: "Security and usability are always in tension"
Reality: Bad security is often unusable security.
You've heard the tradeoff argument a thousand times: we can make it secure or we can make it easy, pick one. It's a false choice.
When security controls are confusing or disruptive, people work around them. They share credentials. They disable protections. They use shadow IT. You haven't achieved security, you've achieved security theater while actual risk moves to places you can't see.
Consider MFA implementation. You can require six-digit codes that expire in 30 seconds and change the enrollment process every quarter, training people to hate security. Or you can implement push notifications with device trust, biometrics where appropriate, and clear communication about why it matters. Both are "secure" in the narrow technical sense. Only one is sustainable.
What works instead: Involve users in design decisions before you deploy. Pilot security controls with real workflows. Measure not just compliance rates but workaround rates. If 40% of your users are using personal email for file sharing because your approved tools are too slow, you need that signal.
Myth 4: "We can policy our way to compliance"
Reality: Policies don't change behavior when the environment makes compliance impossible.
Every organization has that policy: the one everyone knows exists, everyone has acknowledged in the LMS, and almost nobody follows. Often it's the clean desk policy, or the "no unapproved software" policy, or the "lock your screen every time you step away" policy.
The problem isn't that people are ignoring policy out of malice. It's that the policy was written without considering the actual work environment. If your developers need to install packages to do their jobs, and your approval process takes three days, they'll find another way. If your office layout makes clean desk impractical, people won't comply.
This shows up in regulatory compliance too. You can document beautiful processes for SOC 2 or ISO 27001, but if those processes don't reflect how work actually happens, you're creating compliance debt. Auditors see the documentation. Attackers see the reality.
What works instead: Write policies after you understand the workflow, not before. Use the NIST Cybersecurity Framework's risk-based approach: identify the actual risk, then design the control to address that risk in context. If the control creates more risk through workarounds than it mitigates, it's the wrong control.
Myth 5: "This is just about being nicer to users"
Reality: This is about reducing organizational risk.
Human-centered cybersecurity isn't a soft skills initiative. It's a risk management approach grounded in evidence.
Organizations lose money when employees make mistakes because security controls were confusing. They lose talent when security professionals burn out from unsustainable workloads and poorly designed tools. They lose productivity when every secure action requires five extra steps. And they lose the breach lottery when workarounds become standard practice.
The business impact is measurable: lost productivity, increased support costs, higher turnover, and breach consequences. Research documents the connection between security fatigue and both mistakes and noncompliance. You can't train your way out of a problem caused by design.
What works instead: Treat human factors as technical requirements. When you're evaluating a new security tool, ask: How many clicks does this add to common workflows? How many dashboards will analysts need to monitor? What happens when someone makes a mistake, do they know immediately, or do they find out during the post-incident review?
What to Do Instead
NIST's concept paper outlines an approach that complements existing frameworks by addressing what's been missing: practical guidance on designing security with people in mind. This isn't about lowering security standards. It's about building controls that people can actually follow.
Start here:
Map your workarounds. Where are people bypassing security controls? That's your priority list for redesign, not re-training.
Measure security friction. Track not just compliance but time-to-complete for security-required tasks. If MFA enrollment takes 20 minutes and three help desk calls, you've built failure into the system.
Design with your actual users. Before you deploy the next security control, test it with people who will use it daily. Adjust based on what breaks.
Fix your tools before you fix your people. If your security team is managing alerts in six different consoles, start there. Cognitive load is a security risk.
The comment period on NIST's concept paper runs through September 30, 2026. If you've ever wanted to influence how security guidance gets written, this is the opportunity. Because the alternative is another decade of "user error" root cause analyses for problems we designed into the system.
Your people aren't failing your security program. Your security program is failing your people. Fix the design.
