Ask most security teams what their biggest vulnerability is and you’ll hear about phishing, unpatched systems, or credential theft. Ask them privately and off the record, and a different answer comes up almost as often: their own employees quietly working around the security tools meant to protect them, because those tools are simply too painful to use correctly. It’s a theme that’s been surfacing repeatedly in enterprise IT circles this year, echoed by CIOs at major institutions describing the same core problem in different words — poor user experience is undermining security policy from the inside.
The Friction Tax Nobody Budgets For
Every additional click, every extra authentication step, every confusing password rule extracts what’s effectively a tax on employee time and patience. Security teams have historically treated that tax as an acceptable cost of doing business — friction is the price of safety, and employees should simply pay it. The problem with that model is that friction doesn’t just slow people down. Past a certain threshold, it changes their behavior in ways that make the organization less secure, not more.
An employee blocked by an overly restrictive file-sharing policy doesn’t stop sharing the file. They find another way — a personal email account, a consumer cloud storage app, a messaging tool the IT department has never heard of. A password policy that’s technically compliant but practically unmemorable doesn’t produce stronger passwords. It produces sticky notes, reused passwords across systems, or password managers configured so loosely they defeat the purpose. In each case, the policy exists, was correctly designed on paper, and still fails — not because of an attacker, but because of an employee trying to get their actual job done.
The Shadow IT Feedback Loop
This dynamic feeds directly into shadow IT, and it’s a self-reinforcing loop rather than a one-time failure. Once an employee finds a workaround that lets them bypass a friction-heavy official tool, that workaround tends to spread informally through a team — a colleague sees it working and adopts it too, without ever raising it through official channels, because raising it would mean admitting they’d been avoiding the sanctioned tool in the first place. Security teams often only discover how widespread a given workaround has become after an incident forces an audit, by which point the unsanctioned tool may have been quietly holding sensitive data for months.
The uncomfortable conclusion CIOs are increasingly willing to say out loud is that this isn’t primarily an employee training problem. Awareness campaigns and mandatory security training modules keep getting deployed, and shadow IT keeps growing anyway, because the underlying incentive structure hasn’t changed: the sanctioned path is still slower and more annoying than the unsanctioned one. No amount of training fixes a tool that’s simply harder to use than the alternative it’s competing against.
Designing Security Like a Product, Not a Policy
The emerging response among more sophisticated security organizations is to treat internal security tooling with the same product-design rigor normally reserved for customer-facing software — user research, usability testing, and iteration based on how people actually behave, not just how a policy document says they should behave. That’s a genuine cultural shift for security teams that have historically operated from a compliance-first mindset, where the measure of success was whether a control existed and was documented, not whether people actually used it correctly day to day.
In practice, this looks like:
- Reducing authentication friction where risk is genuinely low, reserving heavier verification steps for actions that actually carry elevated risk, rather than applying uniform friction everywhere regardless of context.
- Building sanctioned tools that are actually more convenient than the shadow alternatives they’re competing with — matching consumer-grade usability rather than assuming employees will tolerate worse UX because it’s “official.”
- Involving frontline employees in policy design before rollout, rather than writing rules top-down and discovering the friction points only after adoption stalls.
- Measuring workaround behavior directly — tracking where employees are quietly avoiding sanctioned tools — rather than relying solely on self-reported compliance surveys that tend to understate the problem.
Where AI Agents Complicate the Picture Further
This UX-versus-security tension is getting more complicated, not less, as AI agents take on a bigger role inside enterprise workflows. An agent acting on an employee’s behalf inherits whatever access and permissions that employee has — which means a security policy with usability gaps doesn’t just get worked around by a frustrated human anymore. It can get worked around systematically and at scale by an agent optimizing purely for task completion, with none of the hesitation a human might feel about cutting a corner.
That’s part of why evaluation frameworks specifically built for high-stakes, AI-involved incident response have become a live topic in security engineering circles this year. If an autonomous system is going to be trusted with any part of incident response — triage, containment, even partial remediation — it needs to be evaluated against adversarial and edge-case scenarios with the same seriousness a human analyst’s judgment would be evaluated under, rather than assumed competent by default because it performed well in a demo.
The Business Case for Better Security UX
For executives who still see usability investment in security tooling as a “nice to have” competing against harder infrastructure priorities, the more persuasive argument isn’t about employee happiness — it’s about actual risk reduction. A security control that gets bypassed provides none of its intended protection while still showing up as “implemented” on a compliance checklist, which is arguably worse than having no control at all, because it creates false confidence in the organization’s actual risk posture.
Reframed that way, usability isn’t in tension with security. It’s a precondition for it. A control nobody actually uses correctly isn’t a security control — it’s paperwork. And as AI agents start inheriting the same access, the same incentives, and increasingly the same workaround behaviors as the humans they’re assisting, the cost of getting that balance wrong is only going to compound.
Learning From Consumer Product Design
It’s worth noting how much of the current push toward better security UX is explicitly borrowing playbooks from consumer product teams rather than from traditional security engineering. Consumer software has spent two decades ruthlessly optimizing for the fewest possible steps between a user’s intent and a completed action, because every extra step in a checkout flow or a signup form measurably costs a company revenue. Enterprise security tooling almost never faced that same commercial pressure — a frustrated employee couldn’t simply switch to a competitor’s product the way a frustrated shopper could abandon a cart, so friction accumulated for years with comparatively little pushback from the people actually forced to live with it.
That asymmetry is finally correcting itself, driven less by internal reform than by external competition: the moment a slicker, unsanctioned consumer tool becomes one download away, employees start behaving exactly like the price-sensitive, patience-limited consumers that product teams have spent years designing for. Security leaders who understand that dynamic are increasingly recruiting product designers directly onto security teams, rather than treating usability as something the security engineers pick up as a side skill, and early results from organizations that have made that hire suggest measurably lower rates of policy circumvention within the first year.
A Practical Starting Point for Security Leaders
For organizations trying to figure out where to start, the most useful first move usually isn’t a redesign of every security tool at once — that’s an expensive, slow project that rarely survives budget scrutiny intact. It’s a targeted audit of where employees are already quietly working around official tools, because that shadow-IT map is effectively a prioritized list of the organization’s worst UX-versus-security mismatches, discovered for free by the people living with the friction every day.
From there, the highest-leverage fixes tend to be the ones that touch the most frequently used workflows rather than the highest-severity ones on paper — a login flow used fifty times a day by every employee is usually worth fixing before a rarely used admin control, simply because of how much cumulative friction it removes across the organization. That’s a different prioritization logic than security teams are traditionally trained to use, which tends to rank fixes by theoretical severity rather than by how often real people actually collide with the friction. Both matter. But the frequency-weighted view is the one more likely to actually move the needle on whether people stop working around the rules altogether.
The Long-Term Case for Rethinking Security Investment
Zoom out far enough and this entire conversation is really about where security budgets have historically been allocated versus where the actual failure points are turning out to live. A large share of enterprise security spend still goes toward perimeter defense and threat detection — tools aimed at keeping attackers out and catching them once they’re in. Comparatively little has historically gone toward the usability of the internal tools employees are required to use every day, even though a growing body of internal incident post-mortems keeps pointing back to exactly that gap as a root cause.
Rebalancing that allocation doesn’t mean abandoning perimeter defense — external threats remain real and well-resourced. It means recognizing that a security program with excellent threat detection and poor internal tool usability is still leaving its biggest door open, just from the inside rather than the outside. The organizations making that adjustment fastest tend to be the ones that have already lived through an incident traceable back to a workaround, which is an expensive way to learn the lesson. The ones reading about it now still have the option of learning it the cheaper way, before their own version of that story becomes the case study.
Leave a Reply