Internal security tools rarely get the UX they deserve

Building internal tools is hard. Not necessarily technically hard, but it’s hard to build tools that people actually want to use. Security teams are good at creating access request portals, compliance dashboards, and exception workflows that technically work, but that are painful for our users — and then we wonder why these controls and processes get circumvented. When we build internal security tools, we consistently underestimate the time, investment, and ongoing maintenance needed to build something that people actually want to use.

We’re thinking about this constantly as we build access management tools at Oblique. We've experienced firsthand how challenging it is to create security tools that people actually embrace rather than reluctantly tolerate. An employee isn't necessarily thinking of the security implications when they share superadmin creds with a teammate who urgently needs to debug an issue, or when they download a sensitive financial report to a USB key to get printed at FedEx — they're just trying to get their work done when the approved path is too slow or unclear. And yes, I’ve done both of these things.

Whether you’re building because there isn’t a good enough solution on the market or because your environment is unique (or because you think it’s unique), the challenge remains the same. Before you commit to building — or deploying — a new security tool, step back and consider the full cost: you're committing to UX work, user support, integrations with every tool in your environment, and maintenance that will outlast the engineer who built it.

Security engineers aren’t the best product engineers

I’ll say the quiet part out loud: security engineers aren’t the best product engineers. (But that’s okay, because that’s not why you hired them!) Security teams now hire engineers who can build secure systems, not just analysts who review them. But engineering secure systems and designing intuitive interfaces are different skills — and most security engineers were hired for the former, not the latter.

Most security teams have limited engineering resources that need to support many teams: analysts, compliance, and IT. These engineers often focus on building core infrastructure and backend systems — with less experience in frontend and user experience. (This isn’t to say full stack snowflakes don’t exist, they’re just rare.)

When security teams do build tools, just like with any other development, the timeline estimation is completely off. We estimate the time required based on the core functionality we need, but forget about everything else: monitoring and logging, integrations with the IdP and SIEM, and testing. We struggle just to ensure coverage across internal systems — there's no time left for polish. UX improvements, documentation, and internal training all get cut.

Internal teams also don't generally get the full support you need to build a product: they don’t get product managers, designers, or docs writers. And if you do get allocated this help, you’re lucky to get a passionate volunteer. PMs working on internal tools tend to be evaluated against the same criteria as those shipping customer-facing products, putting them at a disadvantage for promotions and limiting career growth.

Usability matters for security

OK, everyone builds terrible internal tools — so why pick on security? Because usability actually matters in how effective your security program is. When our tools are too painful to use, people develop workarounds. An access request workflow that requires justifications that are never read and time-consuming approvals from multiple people teaches engineers to just share credentials instead.

A solution that's ‘good enough’ with unnecessary or unclear steps isn't actually good enough. It becomes an ongoing support burden: constant tickets for help because users can't figure out basic workflows, and requests for new functionality or integrations with new systems. This gets worse when the person who originally built the tool has moved on, and no one else understands how the black box works or how to modify it.

Security teams also deal with high-risk, high-stress workflows — do you really want someone to cause an outage, miss a critical piece of information, or accidentally send an alert because the UX wasn’t clear?

Choosing where to invest

When you do decide to build, invest properly from the start: think about UX, documentation, training or education, and exceptions. Explicitly hire for frontend and UX experience on the security team, and look for engineers with a product mindset or experience building for end users. Plan for integration work, ongoing maintenance, and support. Actually test your tool with your users and gather feedback. Track adoption, retention, and support tickets. If you're getting more support tickets than usage after launch, the tool isn't working. (Basically, act like it’s a real product — because to your users, it is!) If you don’t make that investment, it’ll all be a waste of engineering time.

And if you’re not willing or able to make that investment, realize you’re creating debt that you’ll still have to address later. Your engineering time is too valuable to waste on tools that people actively avoid using.