Your team is struggling with cybersecurity, and it's likely not their fault. The password policy is so complex that people store credentials in spreadsheets. The VPN drops every third connection, so field staff bypass it. The phishing simulation feels more like a trap than a lesson. Meanwhile, your SOC analysts are overwhelmed with alert fatigue, juggling multiple dashboards that don't integrate, and making critical decisions at 2 a.m. when they're least alert.
NIST has released a concept paper on human-centered cybersecurity, seeking feedback through September 30, 2026. This is significant because the agency highlights a key gap: existing cybersecurity frameworks focus on training employees but rarely address why security processes fail. This leads to a cycle where we blame "the human element" for breaches while ignoring that our tools and processes set people up to fail.
Why These Mistakes Keep Happening
Organizations often default to technology-centric security because it seems measurable and controllable. You can track patch rates, count blocked phishing emails, and audit MFA adoption. What you can't easily quantify is whether your security processes fit into actual workflows, respect cognitive limits, or account for the different needs of your finance and engineering teams.
Another issue is misplaced blame. When breaches occur due to someone clicking a malicious link or misconfiguring a setting, the instinct is to add more training or restrictions. However, research on security fatigue and burnout among cybersecurity professionals shows that the problem isn't knowledge, it's that security processes often conflict with how people actually work, creating friction that leads to workarounds, mistakes, and exhaustion.
Mistake 1: Treating Training as a Complete Solution
Your organization runs quarterly phishing simulations and mandatory security awareness modules. Employees complete them, maybe even pass the quiz, but breaches still happen.
Why it happens: Training assumes that once people know the "right" behavior, they'll execute it consistently. But knowledge doesn't translate to action when the secure path is slower, more complicated, or disrupts urgent work. A sales rep on a client call won't stop to verify a link if the process takes three minutes and six clicks.
The consequence: You create resentment without reducing risk. Employees feel blamed for failures that stem from poor system design. Security teams grow cynical about user behavior. The gap between policy and practice widens.
The fix: Audit your security processes for friction points. Where do people resort to workarounds? What tasks require cognitive effort that could be automated or simplified? Build security into existing workflows rather than adding extra steps. If your secure file-sharing tool requires four authentication steps while the insecure alternative takes one click, you've designed a compliance failure.
Mistake 2: Ignoring Cognitive Load in Alert Design
Your SOC team receives hundreds of alerts daily, all flagged as high or critical priority. They're supposed to investigate each one, but in practice, they triage based on gut feeling because there's no time for thorough analysis.
Why it happens: Security tools are designed by engineers optimizing for detection sensitivity, not for the analyst who has to make sense of the output. Alert fatigue is a known problem, but organizations keep adding tools without integrating them or tuning thresholds to reduce noise.
The consequence: Real threats get missed in the flood. Analysts burn out and leave. Research on burnout in the cybersecurity profession identifies overwhelming workloads and lack of organizational support as key drivers. When your best people quit, you're left with inexperienced staff making judgment calls on sophisticated threats.
The fix: Implement alert aggregation and correlation before adding new detection tools. Establish clear severity definitions tied to required response times. Build in decision support, when an alert fires, the interface should surface relevant context (asset criticality, recent changes, related events) without requiring the analyst to query multiple systems. Schedule regular reviews where analysts can flag alerts that consistently turn out to be false positives, then tune the rules.
Mistake 3: Designing Password Policies That Guarantee Insecure Behavior
Your password policy requires 14 characters, uppercase, lowercase, numbers, symbols, no dictionary words, and rotation every 60 days. Employees respond by using Password123! and incrementing the number each cycle, or storing passwords in unencrypted notes files.
Why it happens: The policy is based on outdated guidance that assumed attackers were brute-forcing passwords character by character. Modern attacks use credential stuffing and phishing, which complexity requirements don't prevent. But the policy stays in place because it feels rigorous and checks a compliance box.
The consequence: You've made the insecure path easier than the secure one. People can't remember 14-character random strings that change quarterly, so they write them down or use predictable patterns. Your actual security posture is weaker than if you'd required longer but simpler passphrases that don't expire.
The fix: Adopt NIST's current password guidance: require length (12+ characters), check against breach databases, allow passphrases, and eliminate forced rotation unless there's evidence of compromise. Deploy a password manager and make it the default, not an optional tool. If you're requiring MFA (you should be), you can relax password complexity because the second factor is doing most of the security work.
Mistake 4: Building Processes That Assume Unlimited Time and Attention
Your incident response playbook has 47 steps, requires input from five teams, and assumes everyone is available immediately. When a real incident hits, the plan falls apart because people are in meetings, on vacation, or handling other urgent issues.
Why it happens: Playbooks are written during calm periods by people who aren't considering the chaos and time pressure of an actual incident. They're optimized for thoroughness, not for execution under stress.
The consequence: During a real incident, responders improvise because following the playbook would take too long or require unavailable resources. The documentation becomes a post-incident checkbox exercise rather than a useful guide. You lose the benefit of having a plan.
The fix: Test your playbooks with tabletop exercises that include time pressure and missing personnel. Identify the critical path, the minimum set of actions needed to contain damage, and make that a separate quick-start guide. Build in decision trees for common branches ("If legal counsel isn't available within 30 minutes, proceed with..."). Assign backup roles. Your plan should assume Murphy's Law, not ideal conditions.
Mistake 5: Isolating Security Decisions from Operational Context
Your security team makes architecture decisions without consulting the people who'll use the systems. The result is technically sound security controls that conflict with business processes, leading to shadow IT and workarounds.
Why it happens: Security teams are measured on risk reduction, not on user productivity. They're incentivized to say "no" or to implement the most restrictive option. Operational teams aren't invited into security design discussions until after decisions are made.
The consequence: Security becomes the team that blocks progress rather than enables it. Business units route around security by using unapproved tools or services. You lose visibility into actual risk because people hide their workarounds. The organization treats security as an obstacle, not a partner.
The fix: Embed security input into project planning from the start, but also embed operational input into security design. When evaluating a new security control, include representatives from the teams who'll use it. Ask: "What workflow does this disrupt? What's the workaround if this fails? What's the cost in time and attention?" Make tradeoff discussions explicit. Sometimes the most secure option isn't viable, and you need to find the most secure feasible option.
Prevention Checklist
Before implementing any security control or process:
- Workflow mapping: Document how the affected users currently complete the task. Where does your control add friction?
- Cognitive load assessment: How much attention and decision-making does this require? Can it be reduced through automation or better interface design?
- Failure mode analysis: What happens when this control breaks or is unavailable? What workaround will people use?
- Pilot testing: Run the control with a small group and solicit honest feedback before full deployment.
- Operational input: Include representatives from affected teams in the design phase, not just the rollout.
- Alert tuning: For any new detection capability, establish thresholds and aggregation rules before going live.
- Documentation review: Can someone execute your incident response plan at 3 a.m. under stress? If not, simplify.
NIST's concept paper on human-centered cybersecurity is open for feedback through September 30, 2026. The guidelines they're developing aim to fill the gap between "train your users" and "design security that fits how people actually work." You can shape that guidance by reviewing the concept paper and emailing feedback to [email protected].
The shift isn't about lowering security standards. It's about recognizing that security controls are only as effective as their implementation, and implementation depends on people who have competing priorities, cognitive limits, and workflows that predate your security requirements. Design with that reality in mind, or watch your carefully crafted defenses get routed around by people who are just trying to do their jobs.
