Rethinking “The Human Firewall”: Build security that works when people can’t
By: Kathleen Moriarty & Ashish Laravee
Even seasoned security pros get duped by phishing. The Verizon 2024 DBIR found the “human element” present in 68% of breaches, and the median time from opening a phishing email to clicking is just 21 seconds—another 28 seconds to enter data. That’s not a training problem; it’s physics and cognition under pressure.
Yet our playbook still treats people as the final, flawless IDS. We expect employees to parse URLs at forensic speed, validate every attachment, and second-guess messages from their own colleagues. Meanwhile adversaries industrialize social engineering across email, apps, fake sites, SMS, and voice. Even when awareness helps, evidence suggests its impact is limited on its own. Verizon+1
Artificial intelligence (AI) complicates this paradigm further in that deception and triggers on human emotion, used by attackers has improved making it more practical to target individuals. Relying on the user as the last line of defense will not prevent attacks.
People aren’t static security devices
In my years of teaching at Georgetown, 3 separate students mid-semester experienced either a traumatic brain injury (TBI) or a concussion. These were all young and otherwise healthy students with a minor setback that required time to heal where screen time could impact their recovery. Bright, capable adults suddenly struggled with screen fatigue, slower processing, and decision-making—the exact faculties we lean on to spot sophisticated lures. That’s not an edge case. CDC data show hundreds of thousands of TBI-related hospitalizations annually in the U.S., and research links concussions with deficits in processing speed, memory, executive function, and reaction time. Decision fatigue and time pressure also increase phishing susceptibility. CDC+2journaloei.scholasticahq.com+2
When we architect systems that depend on perfect human judgment, we don’t just set people up to fail—we create inequitable defenses that punish anyone who is tired, stressed, medicated, aging, or recovering.
Flip the model: secure-by-design, not secure-by-blame
“Secure by Design” is not marketing. It’s a shift in responsibility—from end users to the manufacturers and operators of software and systems. CISA and allied agencies explicitly call for vendors to take ownership of security outcomes by building protections in and turning them on by default.
Memory safety removes entire vulnerability classes
A huge share of high-severity bugs in large C/C++ codebases are memory-safety issues. Microsoft and Google each report ~70% of their security bugs fall into this category; NSA and CISA now advise adopting memory-safe languages where feasible because language-level guarantees prevent many of these errors outright. That doesn’t fix every bug, but it meaningfully eliminates prolific classes like buffer overflows and use-after-free.
Put automated controls in front of people
Email and URL protections. Providers already block the vast majority of malicious mail automatically; Google reports Gmail defenses stop >99.9% of spam, phishing, and malware and block ~15B unwanted emails daily. Lean on those layers and supplement with integrated cloud email security (post-delivery) where warranted.
Protective DNS. DNS-level filtering prevents connections to known-bad destinations before a browser tab even opens. U.S. CISA/NSA guidance describes Protective DNS as a security service that analyzes queries and blocks, redirects, or sinkholes matches to threat intel. Services are available both free and paid to meet the needs of different organizations and individuals.
Isolation and sandboxing. Major browsers now have built-in capabilities to isolate between browser tabs through the use of containers and is enabled by default. Consider how users’ email platform and systems view attachments to prevent an exploit from impacting the system or environment by using these capabilities. Remote Browser Isolation (RBI) goes a step further offering execution of the content on a remote platform with the display only back to the users end system.
Zero Trust defaults. Move from implicit trust to continuous verification (users, devices, and workloads) per NIST SP 800-207. The less any one human click can grant broad access, the safer everyone is.
The goal isn’t to remove humans from the loop—it’s to ensure threats are filtered, contained, or blocked long before a tired person has to make a split-second call.
Change how we buy technology
Security shouldn’t be an add-on upsell or a checkbox questionnaire. Procurement can demand secure-by-design and secure-by-default characteristics, evaluating vendors on the protections they shoulder so users don’t have to. CISA’s “Secure by Demand” guidance offers practical questions and criteria teams can embed in RFPs and renewals.
Bridging the gap: what SecurityBias does
Most orgs lack the bandwidth to deeply assess every SaaS app. Many vendors want to “do the right thing” but need help implementing enterprise-grade controls. SecurityBias works directly with SaaS providers to embed defenses—memory-safe choices where feasible, protective DNS integrations, modern email/URL analysis, isolation options, and Zero Trust-aligned patterns—then publishes standardized, comparable assessments so buyers can see which burdens are shifted off users. This creates a marketplace where security is transparent and comparable, not a black box.
