Why do security tools have such terrible UX?

You open your favorite food delivery app. Ten seconds, a few taps, pad thai on its way. The interface is intuitive and practically reads your mind.

Now open your company's enterprise security platform, a very, very expensive software suite designed to keep out sophisticated attackers. You get a wall of unfilterable logs, a dashboard that looks like a 1998 Excel spreadsheet mixed with an 80s plane cockpit, and 47 flashing red alerts. None of them tell you what's actually broken.

Welcome to cybersecurity, where the UX is made up and the user experience doesn't matter.

For decades, the security industry has operated on an unspoken myth: Security is for smart people, and smart people don't need pretty buttons. We treat bad UX as a rite of passage. If you can't parse a 400-line JSON log file with your bare eyes at 3 AM, are you even a real engineer?

This is more than an annoyance. Bad design in security tools directly causes data breaches and misconfigurations that wouldn't survive contact with a half decent interface. Not in some abstract, theoretical way. In the way where 200 million records end up on a paste site because the person configuring the firewall couldn't tell which rule was active and which was a draft.

The "built by engineers, for machines" problem

If you want to understand why a tool looks the way it does, look at who built it. Security tools were historically built by backend engineers and cryptographers whose primary concern was correctness and feature completeness.

When your core objective is "detect anomalous packet payloads using heuristic behavioral analysis," you're probably not spending sprint planning debating the padding around the "Mute Alert" button. The interface is an afterthought, a thin wrapper thrown over a massive database so the sales team has something to demo.

And it shows. Most SIEM dashboards aren't designed around analyst workflows. They're designed around the underlying data model. You get tabs for log sources, tabs for correlation rules, tabs for saved queries. What you don't get is a tab for "something is wrong and here's what you should do about it." The navigation mirrors the schema, not the job.

This is backwards. Nobody walks into a hospital and navigates by database table. "Excuse me, I'd like to visit the Radiology_Results tab, then cross-reference with Pharmacy_Orders." You navigate by what you're trying to accomplish: I'm here for a broken wrist, tell me where to go.

There's also the "Power User" fallacy. Security vendors assume their users are caffeinated Elliot Aldersons who want granular control over every variable in the system. The actual user is a stressed out DevOps engineer who just got paged during their kid's soccer game and needs to know if the database is being exfiltrated to a server on another continent or if this is yet another false alarm.

It could also be a junior analyst, six months into their first SOC role, staring at a correlation rule editor that looks like someone fed a regex through a particle accelerator. They don't need 47 options. They need the right three.

Design solely for machines and "experts" and cognitive load goes through the roof. That's when mistakes happen.

Your brain on bad security UX

This isn't just an opinion about aesthetics. Cognitive science has a lot to say about why bad interfaces cause security failures, and the research is not subtle.

Working memory is finite. Depending on which study you cite, humans can juggle somewhere between four and seven discrete pieces of information at once. A well designed interface respects that limit. It shows you what you need, hides what you don't, and doesn't force you to mentally reassemble context from twelve different screens.

Most security tools do the opposite. They either dump everything on you at once and say "good luck," or compartmentalize every aspect of a control into 25 different pages or tabs. An analyst responding to a potential intrusion might need to check the alert details in one pane, the affected asset inventory in another, the user's recent authentication history in a third, the relevant policy in a fourth, and the network topology in a fifth. Five tabs, five mental context switches, five opportunities for the brain to drop something important. There's actually a reason I have so many monitors on my desk!

This is what psychologists call cognitive tunneling. Under high stress and high information load, humans don't just get slower. They get selectively blind. They fixate on one data source and lose awareness of the others. In aviation, cognitive tunneling is what happens when a pilot locks onto one instrument and flies into a mountain. In security, it's what happens when an analyst fixates on one log source and misses the lateral movement happening in a completely different segment.

Then there's the decision fatigue problem. Every unnecessary choice a tool forces you to make depletes the same mental reservoir you need for the important calls. When your SIEM makes you click through three confirmation dialogs, select a severity from a dropdown that has nine options with no clear guidance on when to use which, and then manually tag the ticket before you can even start investigating, you've burned cognitive energy on bureaucracy. By the time you get to the actual analysis, you're operating on fumes.

You cannot hire your way out of this. You can hire brilliant people and burn them out with bad tooling in six months. The tool is either working with the human brain or against it.

Alert fatigue is a design failure

Every event is a critical alert in a poorly designed system. Successful login from a new IP? Alert. Failed login? Alert. A scheduled backup ran successfully? Believe it or not, alert.

When a dashboard flashes red 500 times a day, the brain adapts by doing what it does best: ignoring it. If everything is an emergency, nothing is.

In the 2013 Target breach, the security tools caught the malware. They fired the alerts. Those alerts were buried under so many false positives that the security team, trained by years of noise, just ignored them. The tools worked in the technical sense. They detected the threat. But in the design sense, they failed completely, because detection means nothing if the human on the other end can't distinguish signal from noise.

Target is by no means an outlier. It might even be the norm. SOC analysts routinely ignore or deprioritize a huge chunk of the alerts they receive, not because they're negligent, but because the tools have trained them to. When your system cries wolf hundreds of times a day, the rational response is to stop listening.

The medical field figured this out decades ago. Hospital monitors used to alarm constantly, a phenomenon called "alarm fatigue" that was directly linked to patient deaths. The response wasn't to lecture nurses about paying more attention. It was to redesign the alarm systems. Smarter thresholds, tiered severity, suppression of clinically insignificant events. The same intervention is desperately needed in security, and it's barely happening.

Good UX curates. It prioritizes. A well designed security tool follows one rule: don't ask for the user's attention unless you have a specific, actionable task for them to perform.

The configuration minefield (or: why S3 buckets keep leaking)

If you've been in tech for more than five minutes, you've read a headline about a massive data leak from an "unsecured Amazon S3 bucket."

For years, the industry blamed the user. "Stupid developers," the security team would grumble. "They should have read the (1,200-page) IAM documentation before deploying!"

AWS IAM has historically had a user interface that feels actively hostile. If it takes a PhD in cloud architecture to figure out whether a folder is public or private, the system is broken, not the user.

Yes, I'm being a little hyperbolic. But only a little. And I haven't even mentioned Azure, whose portal is what happens when you give a team of product managers infinite nested blades and zero information architecture. You can spend ten minutes clicking through menus in the Azure IAM console and still not be sure whether you just granted someone read access or made them a subscription owner. I'm getting sweaty just thinking about it.

This is where "secure by default" meets UX design. The path of least resistance in cloud configuration used to be the insecure path. You wanted to make the app work, so you opened it to the world. Securing it meant navigating a labyrinth of JSON policies and confusing toggles.

And it wasn't just S3. The Capital One breach in 2019 exploited a misconfigured WAF. The Elasticsearch exposures that plagued 2019 and 2020 were almost entirely configuration failures. The pattern repeats: a powerful tool with a confusing interface, a human under time pressure making a reasonable-seeming choice, and millions of records ending up where they shouldn't be.

When the interface makes the right choice hard and the wrong choice easy, people choose wrong. This isn't a training problem. It's a design problem. You can run all the security awareness campaigns you want, but if the "make it work" button and the "expose everything to the internet" button are the same button, you're going to have a bad time.

Cloud providers are finally catching on. AWS now makes S3 buckets private by default, and if you want to make something public, you have to click through two confirmation dialogs that get progressively scarier. That one design decision is probably preventing more breaches than a hundred security training seminars ever did. Azure started surfacing Secure Score prominently. GCP improved its IAM recommendations. These are small moves, but they demonstrate the principle: when the secure path is also the easy path, people take it.

The compliance UX catastrophe

I spend a significant amount of my professional life in the compliance world, and I want to be clear about something upfront: the frameworks themselves are works of art. NIST 800-53, for example, is a brilliant collection of knowledge and guidance. Its control language is the product of decades of refinement by people who deeply understand risk, and that comprehensiveness is a feature, not a bug. A single control can reference six other controls, three supplemental guidance sections, and an overlay, and that interconnectedness reflects the actual complexity of securing an organization.

The problem has never been the frameworks. The problem is that the GRC tools built around them inherit all of that complexity and do absolutely nothing to make it navigable.

Take a typical GRC (Governance, Risk, and Compliance) platform. You need to map controls across multiple frameworks, maybe SOC 2, NIST 800-53, CMMC, and a state specific framework like TX-RAMP. Each framework has its own language, its own structure, its own granularity. The tool gives you a spreadsheet-style grid with hundreds of rows and asks you to fill it in. There's no intelligent crosswalking, no progressive disclosure of what matters versus what's informational, no prioritization of which gaps actually create risk versus which are paperwork deficiencies. The frameworks provide the structure to do this well. The tools just don't bother.

The result is that compliance becomes a checkbox exercise, not because the people doing it don't care, and not because the frameworks are poorly designed, but because the GRC platforms make it nearly impossible to do anything else. When the interface presents 900 controls as a flat, undifferentiated list, the human brain does the only rational thing: it processes them mechanically. Check, check, check. The nuance that the framework authors carefully built in disappears. The actual security value disappears. What remains is documentation that satisfies an auditor but doesn't make the organization meaningfully safer.

Evidence collection is another disaster. Most GRC tools treat evidence as a file upload problem. Take a screenshot, upload it, tag it to a control, move on. There's no continuous validation. There's no intelligence about whether the evidence actually demonstrates what the control requires. Six months from now, that screenshot is stale and nobody remembers if the configuration it captured is still accurate. The tool doesn't care. The box is checked.

To be fair, there's a newer generation of GRC platforms that recognize this problem and actively try to solve it. Tools like Vanta, Drata, Secureframe, and others have made real strides in automating evidence collection, integrating directly with cloud providers and SaaS platforms, and presenting compliance status in dashboards that don't look like they were designed during the Clinton administration. They deserve credit for pushing the space forward.

But they still don't quite hit the mark, and the reasons are instructive.

First, most of these platforms optimize for the frameworks that are easiest to productize. SOC 2 and ISO 27001 are well-supported because they're common, relatively standardized, and the market for them is large. But the moment you step into something more complex — NIST 800-171 rev 3, CMMC Level 2, FedRAMP, StateRAMP, or sector-specific frameworks like HITRUST or TX-RAMP — the automation thins out dramatically. The crosswalks get shaky. The control mappings feel like they were done by someone who read the framework once and called it a day. You end up back in spreadsheet territory, except now you're paying five figures a year for the privilege.

Second, there's a depth problem. These tools are excellent at answering "is MFA enabled on this AWS account?" They are far less capable of answering "does this organization's access control implementation actually satisfy the intent of AC-2 across all of its environments, including the ones that aren't cloud-native?" The easy controls get automated. The hard ones, the ones that require judgment, context, and organizational knowledge, still get dumped on a human with no meaningful support from the tool. Sadly, those hard controls are usually the ones that matter most.

Third, continuous monitoring in practice often means continuous screenshot-taking. Yes, the tool pulls a configuration state from an API. But it's checking a point-in-time value against a binary condition. It's not assessing whether your actual security posture has drifted in ways that the control framework cares about. There's a difference between "this S3 bucket is not public right now" and "your data storage practices consistently satisfy SC-28 across your entire data lifecycle." The tools measure the former and let you pretend it's the latter.

Fourth, and this is the structural issue that's hardest to fix: these platforms still treat compliance as the destination rather than a byproduct of good security practice. The workflow is still "pick a framework, map your controls, collect your evidence, pass your audit." It's a more pleasant version of the old workflow, but it's the same workflow. The frameworks themselves envision something more integrated — a continuous risk management process where compliance status is an emergent property of how you actually operate. No GRC tool on the market truly delivers that experience, because doing so would require rethinking the entire product model, not just putting a better UI on the old one.

The gap between "compliance as paperwork" and "compliance as actual security assurance" is enormous, and it's a gap the frameworks were designed to close. The GRC tools are the ones keeping it open.

The vendor incentive problem

Security vendors often don't have strong incentives to improve UX, and the reason is structural.

Enterprise security is sold top down. The CISO or VP of Security evaluates tools based on feature matrices, compliance certifications, analyst quadrant placement, and integration capabilities. The actual end users, the SOC analysts, the DevOps engineers, the IT admins, are usually not in the room when the purchase decision gets made.

This creates a classic principal-agent problem. The buyer optimizes for checkbox coverage ("Does it support SAML? Does it integrate with ServiceNow? Is it FedRAMP authorized?"). The user optimizes for "can I do my job without wanting to throw my laptop out a window." These are not the same optimization function.

Vendors know this. They invest in features that show up on RFP responses and in sales demos. A slick 30-minute demo can hide years of UX debt. The buyer sees a polished overview. The analyst sees the real product at 2 AM on a Tuesday when something is actively on fire, and the interface they need to navigate might as well be written in ancient Sumerian.

There's also the switching cost moat. Once an organization has invested months deploying a SIEM, writing custom correlation rules, training staff, and integrating it with their ticketing system, they're not switching because the UX is bad. They're stuck. The vendor knows they're stuck. And so the UX stays bad because there's no competitive pressure to fix it.

This is starting to change, slowly. The developer tools market has demonstrated that bottoms-up adoption driven by individual user experience can unseat established players. Stripe didn't win payments by having more features than legacy processors. They won by having documentation that developers could actually read and an API that didn't make you want to cry. The same dynamic is beginning to appear in security, but it's early.

Error messages are a microcosm of everything wrong

Here is a real error message (lightly anonymized) from a major identity provider:

AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '00000003-0000-0000-c000-000000000000'.

Take a second to appreciate this. A human being, probably a university staff member or faculty member, sees this and has absolutely no idea what to do. What configuration change? Which administrator? What is that gibberish? Is "moved to a new location" literal? Did the office move? Did the server move? Did they connect to a different Wi-Fi network?

The correct interpretation is probably "your admin enabled a Conditional Access policy that requires MFA for Microsoft Graph API access from your current network." But the error message doesn't say that. It says a string of words that technically form a sentence but convey almost no usable information to the person who needs to act on it.

This matters because unclear error messages create two failure modes. First, the user gives up and finds a workaround, which is almost always less secure. Second, the user contacts support, which creates ticket volume, wastes analyst time, and still might not produce a clear resolution because the support team is often interpreting the same cryptic messages.

Writing good error messages is genuinely hard. You need to balance specificity with security (you don't want to leak system internals to an attacker), technical accuracy with human comprehension, and brevity with completeness. But the current state of the industry isn't "we tried hard and landed on a reasonable compromise." It's "we dumped the internal exception string to the UI and called it done."

If a policy fails because a user isn't in the right AD group, say "You don't have access to this resource. Contact your IT administrator to request membership in the Admin group." Don't say "AUTH_FAIL_ERR_CODE_77: Privilege Escalation Blocked." The first message tells a human what to do. The second makes them feel like they've committed a federal crime.

The documentation gap

Security tools have a documentation problem that compounds the UX problem.

Consumer software barely needs documentation because the interface is self-explanatory. A food delivery app doesn't ship with a user manual. The onboarding is the documentation. But security tools are complex by nature, they deal with real complexity that can't be designed away, and they absolutely need good documentation. What they tend to ship instead is either an auto-generated API reference with no conceptual overview, or a 400-page PDF that was last meaningfully updated two major versions ago.

The gap between "reference documentation" and "understanding documentation" is vast. I've talked about it before. A reference doc tells you that the --exclude-pattern flag accepts a regex. Understanding documentation tells you when you'd want to use it, why the default behavior might not be what you expect, and what happens if you get the regex wrong. Most security tools only provide the first kind, if that.

This matters because security misconfigurations don't happen in a vacuum. They happen when a competent person encounters an unfamiliar system, can't find clear guidance on the intended behavior, makes their best guess, and gets it wrong. Better documentation is cheaper than a breach and cheaper than a support ticket. The return on investment is absurd. Nobody does it anyway.

What good design actually looks like

Treat developers and security analysts with the same empathy you give consumers. That's the whole philosophy. Here's what it looks like in practice.

Alerts need to be actionable. A bad alert says: "Port 22 is open on Server Alpha." A good one says: "Port 22 is open on Server Alpha. This violates your hardening policy. Close it, or add a 2-hour exception." One click from detection to fix. Every alert should answer three questions: what happened, why does it matter, and what should I do about it. If your alert can't answer all three, it's not ready to fire.

Bring context to the user. Analysts spend half their day alt-tabbing between 15 browser windows to figure out what an IP belongs to. Show me the user's name, department, recent activity, and baseline behavior in one view. Don't make me assemble it.

Think about what an analyst actually does during triage. They see an alert. They need to know: who is this user, what do they normally do, what did they do differently, is the asset they touched sensitive, and is there corroborating evidence from other sources. A well designed tool answers all of that in a single view. A poorly designed tool makes them open five different screens, run three queries, and mentally correlate the results. Same data, vastly different cognitive load.

Progressive disclosure matters. Power users exist and need granular control. But you don't need to expose every knob to a junior engineer on day one. Hide complexity until someone asks for it. Show the executive summary by default. Let the curious click deeper. This isn't dumbing things down. It's respecting the user's current task.

Design for the 2 AM use case. Almost nobody does this. Your tool will be used by someone who is exhausted, stressed, and dealing with an active incident. That's the use case you should design for, not the Tuesday afternoon demo. High contrast text. Clear visual hierarchy. Large click targets. No ambiguous icons. The person using your tool during an incident has the cognitive capacity of someone who's been awake for 20 hours, because that's exactly who they are.

Make the secure path the default path. Every configuration screen should have a sane, secure default. If a user deploys your tool without changing a single setting, the result should be reasonably secure, not wide open. The user can relax security for specific use cases later. But the starting point should never be "everything is allowed."

Developer experience is a security surface

Developer experience is a security surface, and the industry is only starting to figure that out.

When a developer encounters a security tool that's painful to use, they don't just suffer through it. They route around it. They hardcode credentials because the secrets manager has a terrible CLI. They disable certificate validation because the PKI enrollment process is a 15-step nightmare. They push straight to production because the CI/CD security gate has a 40% false positive rate and they've learned to ignore it.

Every one of these workarounds is rational from the developer's perspective. They have a feature to ship, a deadline to meet, and a tool that's actively impeding them. The friction is the problem. Remove the friction and the workaround disappears.

Shadow IT is a UX failure. "Temporary" exceptions that become permanent are a UX failure. Developers running personal AWS accounts because the enterprise provisioning process takes three weeks and six approvals? Also a UX failure.

The security tools that actually work in practice are the ones developers voluntarily adopt. The tool is good enough that using it is easier than not using it. That's a high bar, and almost nobody in enterprise security clears it.

Where this is heading

Developers hold the keys now, and they won't put up with hostile tooling. They'll route around it. Workarounds, shadow IT, "temporary" exceptions that become permanent. All of it makes the organization less secure.

The security companies that win the next decade won't just have the best detection. They'll have actual design teams. They'll have figured out that security isn't a math problem. It's a behavior problem.

The raw ingredients for better security UX already exist. We have design systems and component libraries. We have decades of research on human factors and decision making under stress. We have consumer software that proves complex problems can be presented simply. None of this is a technology gap. It's a priorities gap: the security industry hasn't yet decided that the humans operating these tools deserve the same design attention as the threats the tools are meant to detect.

I'll go further. I think the compliance and security UX problem is so fundamental, and so underserved, that there's room for entirely new approaches. Rethinking the workflows from the ground up, not just reskinning existing architectures. What does a security tool look like when you start with the analyst's task instead of the data model? What does compliance look like when you start with the human trying to understand their risk posture instead of the framework committee's taxonomy?

I've been thinking about this a lot, and building. There's something in the works that I'm not ready to talk about in detail yet, but the short version is: I think we can do dramatically better, and I'm working on proving it.

More on that soon.