Friction Is a Vulnerability
Your internal tools aren't just slow. They're building workarounds you don't know about.
Many years ago I needed to push a config change to a staging environment. Simple change. One line. I had to: file a ticket, wait for a reviewer who was out of the office, find the backup reviewer, get them to approve a JIRA subtask, get a second approval because the first approver wasn’t in the right group, then log in to a deploy console that required a separate MFA token I hadn’t enrolled yet. The enrollment flow redirected me to a page that no longer existed.
I made the change locally and moved on.
That’s the friction tax. And the last move, the unsafe workaround, was exactly what the process was designed to prevent.
Friction Isn’t Inconvenience. It’s a Design Vulnerability.
Here’s the thing about friction: it doesn’t stop people. It redirects them.
When friction in a system is low, people use the system. When it’s high enough, they find a way around it. The workaround usually exists somewhere on a spectrum from “inefficient but harmless” to “will be someone’s incident report in six months.”
The config change I made locally? Harmless that day. Except it didn’t go through the audit trail, wasn’t in the deployment log, and nobody could reproduce the state in prod had something broke two weeks later.
This is why friction is a vulnerability, not just an annoyance. The workaround is the security incident. It’s the compliance gap. It’s the debugging session where nobody can explain why prod is different from staging.
Friction shifts cost from the moment of resistance to a later, harder-to-trace moment. That’s the ledger entry we don’t see.
A Taxonomy That’s Actually Useful
Not all friction is the same. I’ve found it useful to split it into three types:
Resistance friction: The system makes the correct path slow. MFA with a broken enrollment flow. A deploy approval chain with no backup reviewer. A ticket queue nobody monitors on Fridays. You can see the right path. You just can’t get there quickly.
Confusion friction: The system makes the correct path unclear. Four different runbooks for the same task, last updated in different years. Permissions that vary by team, environment, and moon phase. A tool that does what you want but only if you know the non-obvious flag. People don’t skip the process here: they don’t know what the process is.
Punitive friction: The system makes the correct path feel like a punishment. Log access requires a ticket. The ticket requires a justification. The justification gets reviewed in 48 hours. You need the log in the next 20 minutes because there’s a customer on hold. So you Slack someone who has access and they share their credentials.
Resistance friction generates shadow activity. Confusion friction generates inconsistency. Punitive friction generates credential sharing, screen sharing, and all the things that make security teams lose sleep.
The point isn’t just that friction is bad. It’s that each type of friction generates a different category of risk.
The Friction Audit
You don’t have to instrument everything. You just have to ask the right questions.
For any internal tool or process, I use four:
1. What’s the fastest workaround? Not “what could go wrong,” but “what do people actually do when the official path fails?” If you don’t know, ask. The workaround exists. You’re just not looking at it.
2. Where does the path break under time pressure? The approval chain that works fine on a Tuesday at 2pm will fail at 10pm on a Friday. Map the failure modes, not the happy path.
3. What do new people do on their first week? They don’t know the hidden knowledge. They follow the documented path. If they end up stuck or frustrated, that’s a signal the documented path doesn’t work.
4. Which steps get skipped most often? Not never. Most often. Skipped steps aren’t laziness: they’re the system telling you something. Either the step isn’t worth doing, or the friction around it is too high for the value it provides.
These four questions will surface your unsafe workarounds faster than any audit tool I’ve found.
Prioritization: Start Where the Workaround Is Dangerous
Not all friction is worth fixing immediately. The backlog is real.
The prioritization heuristic I use: fix friction in order of workaround risk.
Friction that causes someone to add a hardcoded secret to an env file? Fix it before anything else. Friction that causes someone to skip a documentation step? That’s a Wednesday afternoon problem.
Map your friction to its actual workaround, then assess the blast radius of the workaround:
If the workaround is “I skip the log entry” → low blast radius, medium priority
If the workaround is “I give someone my credentials” → high blast radius, fix now
If the workaround is “I deploy without review” → depends entirely on what you’re deploying
The prioritization isn’t about what’s most annoying. It’s about which friction is actively generating the highest-risk behavior in your organization right now.
You probably already know which one that is. You just haven’t named it yet.
What This Costs
I want to be precise about this.
Friction costs are real costs. They just don’t show up on the sprint board. They show up as the incident that took four hours to debug because the audit trail had gaps. The credential rotation event that swept up three shared accounts nobody knew existed. The compliance finding that traced back to a process everyone admitted was “too annoying to follow.”
The cognitive budget article said that alert systems drain human attention invisibly. Friction is the same mechanism at the process level. It doesn’t eliminate the demand. It pushes the cost downstream, where it arrives as debt, risk, or failure.
The config change took me thirty seconds to make locally. The incident it contributed to two weeks later took the better part of a day.
Fix the friction that forces unsafe workarounds first. That’s not a productivity argument. It’s a reliability argument.
Next: Next week looks at what happens when friction and surveillance defaults converge, and why the people least able to pay the friction tax are also the least able to opt out of being watched.
Resources
NIST SP 800-63B: Digital Identity Guidelines - NIST’s authentication standards explicitly acknowledge that onerous security controls generate workarounds that compromise the controls themselves. The spec is written around this tradeoff.
Health Professionals’ Ethical, Security, and Patient Safety Concerns Using Digital Health Technologies - PMC study of 369 healthcare workers found roughly 80% expressed concerns about credential sharing, with researchers noting that authentication friction was a primary driver. Healthcare is an extreme case, but the pattern holds everywhere.
Shadow IT Is an Adoption Problem, Not Just a Security One - Shadow IT now accounts for 30–40% of enterprise IT spending, per Gartner. The root cause isn’t that employees want to break rules: it’s that approved tools are too slow, too limited, or too hard to access.