Humans Are Not the Weakest Link: UX in Cybersecurity Is Finally Federal Policy
Last week I sat on a panel at the GovExperience Summit, held at Carahsoft in Reston, on the Emerging Technology Track, with Vicky Pillitteri of NIST, moderated by Shea Connelly of GovExec. The topic was the UX in cybersecurity. It is a subject I have lived inside for most of my career, but the panel format pushed me to sharpen my thinking, and in the course of preparing I ended up writing what amounted to a primer on the field. Sitting with the material afterward, it felt like a waste to leave it as a one-time prep document. This is that primer, restructured as an argument rather than a panel walkthrough.
The compressed thesis is this: cybersecurity has spent most of its history treating the human being as the problem. The evidence from twenty-five years of human-centered research is that this framing has been almost exactly wrong. Most of what gets called “human error” in security incidents is the predictable result of systems designed without regard for how people actually think, work, and behave under pressure. The fix is not more training or stricter policies. It is to redesign the underlying systems so the secure behavior is the easy behavior, and to shift the burden of security upstream, away from end users and small operators and onto the vendors, platforms, and standards bodies that are best positioned to bear it.
That argument has finally moved from research papers into operative federal policy. The remaining work is implementation, which is to say, the work that actually matters.
Why this topic suddenly matters
For most of cybersecurity’s history, the field has treated the human being as either an obstacle or an afterthought. The dominant industry slogan, repeated across keynotes and vendor booths for two decades, has been some version of “humans are the weakest link.” That framing produced a predictable response: stricter policies, more annual training videos, more mandatory password rotations, more blame when something went wrong. It also produced, predictably, more breaches.
The thesis of human-centered cybersecurity is that the framing has been almost exactly wrong. When you build a control that demands the impossible, people will not become superhuman. They will cope, work around, or give up. The security failure is a design failure first.
That idea is not new. It dates to the late 1990s in academic computer science. What is new in 2026 is that the idea has finally migrated from research papers into federal policy. The 2023 National Cybersecurity Strategy, CISA’s Secure by Design campaign, the OMB phishing-resistant MFA mandate, and the just-finalized NIST authentication guidance are, at their core, the same idea expressed in different vocabularies. Each one says some version of: stop expecting end users and downstream operators to be the security experts. Build security in upstream, at the system, the product, and the standard. Let the humans focus on the mission.
For federal agencies, this shift is not abstract. It changes how Authorities to Operate are written, how Zero Trust is rolled out, how identity is managed, and how AI systems will be governed as they take on more of the decision-making humans used to do. It also changes who counts as the “user” in usable security. The traditional answer was the consumer or the end user clicking a phishing email. The new answer includes the developer fighting a CI/CD pipeline, the Information System Security Officer drowning in evidence collection, the analyst staring at a wall of alerts, and the mission owner whose people will shadow-IT around any control that slows them down.
What human-centered cybersecurity actually means
The National Institute of Standards and Technology runs a program officially called Human-Centered Cybersecurity (HCC). It lives in the Visualization and Usability Group, and it has existed in some form since 2008. Until 2023 it was called the Usable Cybersecurity program. NIST renamed it to fight the misconception that “usable security” only meant making interfaces prettier for end users. The actual scope is much wider: practitioners, IT professionals, policymakers, and standards developers are all users whose understanding of security shapes how systems get built.
The program’s stated mission is to “champion the human in cybersecurity.” Its working definition is that human-centered cybersecurity involves the social, organizational, and technological influences on people’s understanding of and interactions with cybersecurity, and that taking a human-centered approach improves both the human experience and the security outcomes. The two are not in conflict. The point of the work is to show, with evidence, that they reinforce each other.
Usability has a specific technical meaning here. The NIST definition is that usability is how well people can use a system to accomplish a goal with effectiveness, efficiency, and satisfaction in a specific context of use. The phrase “in a specific context of use” is crucial. A control that is usable for a casual home user is not necessarily usable for a field operator with intermittent connectivity. A control that is usable for a senior developer at a large vendor is not necessarily usable for a contracting officer at a small agency. Context determines whether a design is human-centered, which is why generic security solutions tend to fail in specific deployments.
A practical implication: human-centered cybersecurity is not the same as cybersecurity awareness training. Awareness is one tactic, and on its own a weak one. The richer answer is to redesign the underlying system so the secure behavior is the easy behavior, and to reserve training for residual cases where human judgment genuinely matters. If you find yourself training your way out of a usability problem, you have probably misdiagnosed the problem.
The intellectual foundations
Two 1999 papers established the field, and a working familiarity with both is enough to sound credible in any room where this conversation is happening.
The first is “Users Are Not the Enemy,” by Anne Adams and M. Angela Sasse. Sasse is the godmother of the field. The paper studied password practices in a real organization and found that users who appeared to be making careless security choices, writing passwords on sticky notes, reusing them across systems, choosing weak ones, were not careless. They were coping with a system that was demanding the impossible. They were trying to do their jobs while being asked to remember dozens of unique, complex, frequently rotated passwords across systems that did not share an identity provider. The “human error” was the rational response of a person trying to function inside a broken design. The fix was not more training. The fix was a design that did not demand the impossible.
The second is “Why Johnny Can’t Encrypt,” by Alma Whitten and J.D. Tygar, presented at USENIX Security in 1999. The authors gave twelve participants with reasonable computer literacy basic tasks in PGP 5.0, the leading encryption software of the time. Most could not figure out how to encrypt a message correctly even after ninety minutes. Some encrypted with the wrong key, which silently produces a message the intended recipient cannot read while feeling secure to the sender. The paper proved, in an experimental setting, that even motivated, technical users could not reliably operate a security tool whose design was hostile to human cognition.
You can measure the longevity of these papers by the fact that CISA published guidance in early 2026 titled “Barriers to Secure OT Communication: Why Johnny Can’t Authenticate,” a deliberate homage. The federal cybersecurity establishment is still publishing documents named after a 1999 academic paper because we have not solved the problem. The technology has changed completely. Networks, threats, and tools have all evolved. But the underlying human-factors gap has stayed open for twenty-seven years.
In 2016, NIST researchers Brian Stanton, Mary Theofanos, and colleagues published the paper that named the most cited concept in the field: “security fatigue.” They had set out to do open-ended interviews about computer security behavior with forty users. They did not start with a hypothesis about fatigue. The fatigue emerged from the data uninvited. Participants felt bombarded, resigned, and out of control. Many rationalized risky behavior with the belief that they had nothing worth stealing. They described avoiding decisions, choosing the easiest option among alternatives, behaving impulsively, and failing to follow rules they technically understood. The researchers connected this to decision fatigue, the well-established cognitive phenomenon where the quality of human choices degrades as the number of choices in a day accumulates. The same person who would refuse a phishing email at nine in the morning will click it at four in the afternoon, not because they care less but because their cognitive resources are depleted.
The study’s three prescriptions have aged extremely well, and they generalize beyond end users. Limit the number of security decisions a user has to make. Make it as simple as possible to make the right choice when a decision is unavoidable. Design for consistent decision-making across contexts. They apply to SOC analysts triaging hundreds of alerts a day, to ISSOs producing thousands of pieces of compliance evidence per ATO cycle, and to developers interpreting noisy static analysis output. Decision fatigue is the connective tissue between consumer usability problems and federal practitioner burden problems. They are the same phenomenon at different scales.
The big debates: weakest link, false tradeoff, and the burden shift
Three contested ideas dominate the current conversation, and they are worth unpacking because the surface form of each one hides a more useful reframe underneath.
The weakest link reframe. For two decades the industry has quoted some version of the statistic that the majority of breaches involve human error. The dominant interpretation has been that humans are therefore the weakest link, and the best return on security spend is to harden the humans through more training, stricter policies, and punitive consequences for failure. The challenger view, drawing on safety science from aviation, healthcare, and nuclear operations, is that punishing individual operators for errors makes systems less safe because it drives reporting underground. People stop surfacing near-misses and mistakes, which removes the data the organization needs to improve. The high-reliability response is a just culture, which distinguishes carefully between honest mistakes, violations with systemic root causes, and intentional misconduct. Most cybersecurity organizations have not made this transition. They still publicly shame employees who fail phishing simulations, which produces silence and disengagement, exactly the opposite of what they want. A more useful reframe: humans are not the weakest link, they are the last line of defense when technical controls fail, and our job is to support them, not blame them.
The false tradeoff. The intuitive belief is that more security means more friction. The contemporary HCC position is that this is a false binary at the design stage. It is true that any specific security control, considered in isolation, often does introduce friction. But the choice is not between secure-and-annoying and insecure-and-easy. The best modern controls are simultaneously more secure and more usable than what they replaced. The flagship example is authentication, which gets its own section below. The general claim is that the question is not “usable or secure”; the question is “where does the friction live, and who pays for it.”
The burden shift. That question, taken seriously, leads to the third idea. The 2023 National Cybersecurity Strategy stated the position explicitly. The United States, the strategy argued, has allowed a system where the cybersecurity burden sits disproportionately on consumers, small businesses, local governments, and infrastructure operators, all of whom are poorly equipped to bear it. The right model is to shift that burden onto the parties best positioned to reduce risk for everyone: technology vendors and platform owners whose products everyone else depends on. CISA operationalized this through the Secure by Design campaign and the Secure by Design Pledge, which grew from sixty-eight initial signatories in May 2024 to more than two hundred and fifty within a year. The honest assessment is more sobering than the pledge numbers suggest; one industry report estimated only around four percent of developers globally apply Secure by Design principles in practice, and CISA’s own program managers describe the campaign as “locking the front door,” a first step that does not by itself remove risk. The direction of travel is largely the same regardless of the political cycle. Stop expecting the end user to be the security expert. Move the security upstream to the parties who can actually do it.
This burden-shift idea is the macro-policy version of everything human-centered cybersecurity has been arguing for twenty-five years. The 1999 papers said the same thing at the scale of a single login dialog. The 2023 strategy said it at the scale of the national economy.
Federal policy in 2026: the operative mandates
A working knowledge of the field requires fluency in roughly half a dozen policy artifacts. They all point in the same direction.
OMB Memorandum M-22-09, the Federal Zero Trust Strategy, was issued in January 2022. It requires federal civilian agencies to deploy phishing-resistant multi-factor authentication for all employees, contractors, and partners, and actively pursue passwordless approaches as they modernize. The memo’s framing is that the foundation of Zero Trust is very strong authentication, which requires cryptographic proof of identity rather than shared secrets.
NIST Special Publication 800-63-4, the Digital Identity Guidelines, was finalized in 2025. It makes phishing-resistant authentication mandatory at Authenticator Assurance Level 3, requiring hardware-bound, non-exportable cryptographic keys. PIV cards, Common Access Cards, and FIDO2 hardware authenticators are now the only fully compliant options at AAL3. Anything relying on a shared secret, including SMS codes, time-based one-time passwords, and push notifications, is no longer sufficient at the highest assurance level.
NIST SP 800-53 Revision 5 remains the catalog of security and privacy controls used as the basis for FedRAMP and most other federal authorization frameworks. The catalog’s organization-defined parameters and the tailoring and overlay mechanisms are themselves human-centered in spirit; they allow controls to be fitted to the specific mission context rather than applied generically. The forthcoming AI control overlays from Pillitteri’s group will extend this approach to predictive, generative, and agentic AI systems.
CISA’s Secure by Design and Secure by Demand campaigns operate alongside these NIST and OMB artifacts. Secure by Design targets vendors; Secure by Demand targets buyers, encouraging operational technology and other critical infrastructure operators to demand specific security properties from their suppliers. Both campaigns are explicit applications of the burden-shift idea.
Beneath these top-level artifacts sit several supporting initiatives. The Secure Software Development Framework in NIST SP 800-218 and the OSCAL machine-readable control format are the most important for this conversation. OSCAL is, fundamentally, a human-centered design move for the compliance workforce. The vision is that authorization packages, control implementations, assessments, and Plans of Action and Milestones should be expressed in machine-readable form so that humans stop doing what machines should do. FedRAMP’s modernization track, sometimes called FedRAMP 20x, is the most visible federal application of this approach in 2026.
Phishing-resistant MFA: the case study that breaks the false tradeoff
If you retain one concrete example from this piece, retain this one. Traditional multi-factor authentication asks the user to provide a password and then a second factor, typically a six-digit code by SMS, an authenticator app code, or a push notification. This was a meaningful improvement over passwords alone when it was introduced, but it has aged poorly for two reasons.
The first is that it remains phishable. Modern adversary-in-the-middle phishing kits proxy the entire authentication flow in real time. The user thinks they are logging into the legitimate service. The phishing site relays the credentials and the second-factor code to the real service, captures the resulting session cookie, and the attacker walks away with valid access. Microsoft reported more than ten thousand of these attacks in 2024 and a roughly forty-six percent increase in 2025. The user did nothing visibly wrong. The control failed because it relied on a secret the user could be tricked into revealing.
The second reason is push fatigue. Push-based MFA is convenient when it works as intended. It also created a new attack surface. Attackers who have a password can generate repeated push prompts at three in the morning until the tired user taps approve to make the alerts stop. This is called MFA bombing or push fatigue, and it has been the entry vector for several high-profile breaches. The control became the vulnerability because it ignored a basic fact of human behavior: exhausted people will silence alerts.
Phishing-resistant MFA solves both problems. FIDO2 and WebAuthn, the standards underlying passkeys and hardware security keys, and PIV and CAC, the federal smart cards, bind authentication to a specific cryptographic key on a specific piece of hardware, and to a specific origin. An attacker who proxies the login flow cannot replay the authentication because the cryptographic challenge is bound to the legitimate origin. There is no code for the user to type. There is no push to approve. There is no secret to phish.
The human-centered punchline is that the result is also a substantially better user experience. Users do not type codes. They do not context-switch to a phone. They tap a key, or touch a fingerprint sensor, or look at a camera. The most secure authentication available in 2026 is also, by a wide margin, the most convenient. This is not an accident. It is what happens when designers stop treating usability and security as opposed and start treating them as the same problem.
The practitioner as user: the conversation everyone misses
Most human-centered cybersecurity work has historically focused on end users. That focus made sense in the era when end-user behavior was the dominant attack surface. It does not match the federal landscape in 2026, where the most overworked and under-designed-for users in the security ecosystem are not end users at all. They are the security and compliance practitioners themselves.
Consider the workflow of a federal ISSO during an authorization cycle. They are responsible for producing or coordinating a System Security Plan that runs hundreds of pages and references hundreds of controls. They must gather evidence for each control, in many cases manually, by taking screenshots, exporting logs, copying configuration files, and pasting them into a document or evidence portal. They must coordinate with engineers, system owners, third-party assessment organizations, and authorizing officials. They must maintain a Plan of Action and Milestones for open gaps and update everything for continuous monitoring. Most of this work is done in tools that were not designed for the workflow, on timelines set by the audit calendar rather than by the security risk, with handoffs that lose context at every step.
This is a human-centered design failure of dramatic proportions. The cognitive load is enormous. The signal-to-noise ratio of compliance evidence is poor. The result is what GAO has documented across the federal estate for years: systems that pass the audit and fail in practice. A substantial portion of that paper-vs-practice gap is downstream of bad compliance UX.
The same dynamic plays out for SOC analysts who face alert fatigue at industrial scale, for developers who experience security tooling as friction in the pipeline and route around it whenever they can, for procurement professionals who must interpret security requirements they did not write, and for engineers who must implement controls they often do not understand the intent behind.
The human-centered response is the same across all of these. Reduce the cognitive load. Make the secure path the easy path. Automate the toil so humans can focus on judgment. Surface signal, suppress noise. Treat workarounds as diagnostic data, not deviance. Build feedback loops so practitioners can tell you what is and is not working. Eliminate evidence collection by humans where machine collection is feasible. Standardize on machine-readable formats so the same data can flow across tools without retyping. Provide secure defaults so developers do not have to choose between shipping fast and shipping safely.
Continuous Authorizations to Operate (cATO), the model in which an authorization is maintained continuously through automated evidence collection and ongoing monitoring rather than reauthorized periodically through manual paper exercises, is fundamentally a human-centered design intervention for the compliance workforce. Reducing audit cycle time by half and automating significant portions of evidence collection is not just an efficiency gain. It removes the toil that drives shortcuts, burnout, and turnover in a workforce that is already understaffed. I led a cATO program at USPTO that cut cycle time roughly in half and automated more than thirty percent of evidence collection, and the most important second-order effect was not the efficiency gain. It was that engineering teams stopped seeing the security team as the people who slow them down to collect screenshots and started seeing them as partners who care about the same things they care about: shipping reliably, not breaking production, not getting paged at 3am.
Artificial intelligence and the next generation of human-factors problems
The current frontier of human-centered cybersecurity is the question of what happens to human judgment when AI systems take on increasing portions of the security workflow.
On the optimistic side, AI is positioned to reduce the very burdens human-centered research has been documenting for years. Copilots can summarize alerts, draft control narratives, triage tickets, generate evidence, and answer practitioner questions in natural language. A well-designed AI assistant can do for an ISSO what spell-check did for the writer: remove toil so the human can focus on judgment. NIST’s forthcoming AI control overlays will provide tailored baselines for predictive, generative, and agentic AI systems, giving the compliance world a structured way to incorporate AI into authorization packages.
On the cautious side, AI introduces a new set of human-factors problems that are not yet well understood. The most pressing is the question of meaningful human oversight. As AI systems take more autonomous actions, particularly agentic systems that chain tool calls and make decisions across sessions, the human role is no longer to make the decision but to oversee a system that is making decisions on the human’s behalf. The cognitive task changes from active decision-making to vigilant supervision, and vigilance is the cognitive mode humans are worst at sustaining. The aviation literature on automation surprise, where pilots fail to detect that an autopilot has done something unexpected, is directly applicable. A human reviewing every output of an AI agent will quickly lapse into rubber-stamping, which is a known failure mode in safety-critical systems.
The same alert-fatigue dynamic that produced security fatigue in 2016 will reappear in AI-augmented security operations if it is not designed against. An AI system that surfaces a hundred suggested actions per day, ninety-five of which are routine, creates the exact conditions in which a human operator will miss the five that matter. Building AI tools that respect human cognitive limits, that escalate the right things, that explain themselves, and that preserve auditability is a serious design challenge.
The third axis is adversarial. AI-generated phishing and social engineering are already eroding the assumption that suspicious-looking communication is detectable by an attentive user. As large language models produce flawless writing in any target language, register, or persona, the human cannot be the filter. This pushes even more weight onto technical controls and reinforces the burden-shift argument: if humans cannot reliably detect attacks anymore, the system must.
What I told the panel I had learned
I came up as an Air Force Cyber Systems Operator. When I started, the prevailing assumption was that security was a discipline humans served, not the other way around. If a control did not fit the operational reality, the answer was to train people harder, write a sterner policy, or eventually punish someone. In environments I watched that approach fail consistently, because mission tempo always won. When a control got in the way of the mission, people found a way around it. Not because they were cavalier, but because the mission was the actual reason they were there.
Moving into the federal civilian compliance world as an ISSO and later in advisory roles, I saw the same dynamic at a much larger scale. Programs producing thousands of pages of authorization documentation. People spending nights and weekends collecting screenshots for evidence. Most of that work had limited bearing on the actual security posture of the system. It was performance for the audit, not protection of the mission. The compliance experience itself had become a usability disaster, and the practitioners executing it were burning out.
The arc through my career has been watching the field slowly internalize what the academic researchers were saying in 1999, which is that humans are not the problem, the systems are. The shift to continuous monitoring, the move toward machine-readable compliance through OSCAL, the FedRAMP 20x modernization track, and now the Zero Trust and Secure by Design movements are all expressions of the same idea. Stop asking humans to do what machines should do, and stop asking end users to be the last line of defense for systems that should be defending themselves.
If I had to compress the operational lessons into three moves an agency can make right now, in order of leverage, they would be these.
Modernize authentication. Phishing-resistant MFA is the highest-leverage usable-security investment any agency can make. It reduces friction for users, eliminates the most common credential-theft attack vector, and satisfies M-22-09 and the new SP 800-63-4 assurance levels at the same time. There is no excuse to be running on SMS codes and push approvals in 2026.
Automate compliance evidence collection. The ATO process is largely a paperwork exercise built on top of systems that could be reporting their compliance state directly. OSCAL exists. Continuous monitoring tooling exists. cATO models exist. The work to wire these together is significant, but the payoff is enormous. A workforce that spends its time thinking about risk instead of collecting screenshots is a workforce that catches actual problems.
Inherit security where you can instead of rebuilding it. Every agency that builds its own hardened baseline from scratch is doing work that has been done many times before. Shared services, common platforms, inheritance of controls from accredited boundaries, are all human-centered design at the ecosystem level. They shift the burden from the program manager to the platform. This is, not incidentally, the model Knox Systems operates: a FedRAMP shared boundary across the three major hyperscalers that independent software vendors deploy into, inheriting the bulk of the control set rather than rebuilding it. I see, every week, what it does to the people on the customer side when they get to focus on their product instead of becoming reluctant FedRAMP experts.
Underneath all three is a cultural move. Stop treating friction as evidence of seriousness. Friction is a tax, and the agency pays it in burnout, turnover, and shortcuts. Reducing friction is not laxness. It is strategy.
Closing synthesis
Cybersecurity has spent most of its history treating the human as the problem. The evidence from twenty-five years of human-centered research is that this framing is wrong. Most “human error” in security incidents is the predictable result of systems designed without regard for human cognition, organizational context, or operational reality. The fix is not more training or stricter policies. The fix is to redesign the underlying systems so the secure behavior is the easy behavior, and to shift the burden of security upstream, away from end users and small operators and onto the vendors, platforms, and standards bodies that are best positioned to bear it.
In 2026, this argument has finally moved from research papers into operative federal policy. The Zero Trust mandate, the phishing-resistant MFA requirement, the new identity assurance levels, the Secure by Design campaign, the AI control overlays in development, and the broader machine-readable compliance modernization are all expressions of the same underlying idea. The framework is being rewritten. The implementation is uneven. The direction is set.
The user in human-centered cybersecurity is no longer just the consumer or the employee at the endpoint. It is also the developer, the analyst, the ISSO, the contracting officer, the mission owner. Every role in the security workflow is a user whose experience has been underdesigned, and every one of them is a leverage point. The discipline is finally mature enough to ask all of these questions at once. The policy environment is finally aligned enough to support agencies that take the answers seriously. The remaining work is implementation, which is to say, the work that actually matters.
Every time I have seen a security program produce mission outcomes worse than the controls alone would predict, the root cause has been treating security as a separate workflow from the mission. Every time I have seen a security program produce outcomes better than the controls alone would predict, the root cause has been treating security as part of the mission workflow. Design accordingly.
Mario Lunato is the Field CISO at Knox Systems. He writes about FedRAMP, GRC engineering, and general cybersecurity at OneUpSec.tech. Thanks to Vicky Pillitteri (NIST) and Shea Connelly (GovExec) for the panel conversation that prompted this piece.