Policy & leadership

When Security Gets in the Way: Users, Friction and Mission Assurance

Why defensive controls frustrate users, how to distinguish necessary constraints from poor design, and how to build shared responsibility through practical exercises.

Published: 9 October 2026

A control succeeds only if the mission can use it

The user who says that a work computer is slower and more complicated than the one at home may be describing a real operational defect. A security team should investigate that statement before turning it into an awareness problem. Some constraints are essential: a restricted network cannot accept every external device or transfer every document freely. Other obstacles result from ageing hardware, inconsistent configuration, duplicate tooling or a service nobody has designed around the actual task. Our central proposition is that mission assurance includes both preventing unauthorised activity and enabling authorised work at the required quality and speed.

Why the home-computer comparison feels convincing

At home, one person often chooses the software, accepts interruptions and decides which services to trust. A corporate or defence environment must consider shared systems, other users, sensitive information, accountability and the consequences of one compromised account. Explaining that difference can make controls understandable. It does not justify every delay. Our recommended response is to connect a particular restriction to a particular consequence: preventing an unapproved application from changing operational data, for example. Avoid vague claims that everything is slower because security is important. Users need to know which limitation is deliberate and which problem the organisation intends to fix.

The evidence on fatigue should be used carefully

NIST’s 2016 Security Fatigue study used interviews with 40 participants and identified experiences such as resignation and avoidance of security decisions. [1] It is a useful qualitative account, not a representative estimate of military personnel or proof that a frustrated user will become malicious. NCSC’s usability guidance explicitly connects difficult or unpredictable products with pressure to find alternative ways of working. [2] Our inference is that repeated friction deserves investigation as a system risk. The response should combine better design, practical support and relevant learning rather than label ordinary frustration as evidence of an insider threat.

Distinguish necessary friction from accidental friction

We propose reviewing each obstacle against four questions: what threat or obligation does it address, what evidence shows that it works, what operational cost does it create, and is there a safer usable alternative? Necessary friction might be a release decision before information crosses a classification boundary. Accidental friction might be asking three teams to approve the same low-risk software update because responsibility is unclear. Some controls contain both. Keep the required authorisation while simplifying duplicate steps. The objective is not to minimise clicks indiscriminately, but to remove effort that does not contribute to the intended security outcome.

Defence networks have several kinds of risk at once

In our hypothetical defence setting, a communications outage, incorrect maintenance instruction or delayed logistics decision may harm the mission alongside a confidentiality breach. The right balance therefore depends on the task, information sensitivity, threat and operating conditions. Some obligations are non-negotiable; a local manager cannot waive a classification rule simply because a meeting is urgent. Other choices, such as scheduling background work or improving a transfer queue, are engineering decisions. Make that distinction visible. Security, operations and the relevant authorising authority should agree the acceptable operating envelope before an emergency, including what must pause when it cannot be maintained.

Example one: the workstation that takes too long

Imagine a planning team waiting several minutes each morning for documents to open. This is an invented scenario, not a measured incident. The tempting responses are to blame endpoint protection or dismiss the complaint. Our proposed diagnosis measures startup, CPU and memory pressure, storage latency, network delays and the timing of management tasks. Compare representative configurations in an authorised test environment. Check whether two agents repeatedly process the same files or whether the equipment is undersized. Do not create broad scanning exclusions or disable protection in production as an unexamined performance fix. Any tuning needs scoped justification, security validation and a rollback plan.

Explain the result in the user’s language

A useful response to that team might be: the delay is real; the review found overlapping scheduled tasks; the service owner will stagger them and measure the result. If a remaining delay is necessary, explain what it protects and what the user can do during it. If hardware capacity is the limiting factor, report a capacity problem. Calling every performance defect a security requirement erodes confidence in legitimate requirements. Our recommendation is to give the requester a reference, owner and next update date, then report whether the change actually improved the task rather than merely closed the ticket.

Example two: repeated authentication during a busy shift

Consider an analyst repeatedly interrupted while moving among approved applications. Strong authentication matters, but disconnected session designs can create unnecessary repetition. NIST SP 800-63B-4 provides authentication and session guidance, including usability considerations; it does not justify a single arbitrary timeout for every mission. [5] Our recommended design uses appropriately assured authentication, approved federation where suitable and additional checks for consequential actions. Test idle and maximum session limits against the required assurance and physical setting. Do not solve fatigue by sharing accounts or removing authentication. Recovery, lost authenticators and shift handover need equally usable procedures.

Example three: the blocked USB drive

A technician receives an urgent maintenance document on external media, but the workstation refuses it. The restriction may prevent malware introduction or unauthorised transfer; the correct next step depends on the approved environment. Our proposed service supplies a documented intake route, file validation and an accountable release decision, with an escalation path for operational urgency. A generic refusal without an alternative encourages staff to seek uncontrolled conversions or forwarding. The explanation should state the permitted route and expected handling time. If no approved route can meet the mission need, the responsible authority must resolve that conflict; the technician should not be left to invent one.

Example four: a cross-domain transfer changes the output

A hypothetical image analyst receives a transformed file whose detail no longer supports the task. NCSC’s cross-domain guidance explicitly considers the accuracy, completeness and accessibility of outputs, including the effects of security transformations. [3] Our recommendation is to specify quality acceptance criteria with the operational user before selecting the transfer process. Test representative authorised material, not only whether a file arrives. A transfer can be technically successful and operationally useless. If the transformation removes essential information, the team needs an approved alternative or a revised task, not an instruction to accept lower-quality evidence without assessing the consequence.

Example five: a collaboration tool is blocked

A project lead wants to use a convenient public file-sharing service because the approved one is slow. Our proposed response first identifies the actual requirement: external partner access, file size, version history or time-critical review. Then provide an approved route that supports it and explain the information-handling boundary. A block page should offer a service request rather than just an error. Where the existing platform cannot meet the need, record the gap and assign an owner. Banning a named tool may reduce one risk while leaving the underlying work requirement unresolved; the work will still need to happen somewhere.

Example six: patching meets an operational deadline

In this invented scenario, a reboot is required shortly before a scheduled mission activity. The choice is not adequately described as patch now or ignore security. Our recommended process assesses vulnerability exposure, exploitation evidence, operational timing and available redundancy. Use an authorised maintenance window or alternate capacity where feasible. A temporary deferral needs an owner, expiry and compensating measures appropriate to the threat. A critical exposed vulnerability may justify urgent disruption; a different situation may allow a controlled delay. The user should receive a clear window and escalation route rather than an unpredictable countdown that repeatedly appears during essential work.

Example seven: a data-loss rule blocks a legitimate report

A report is stopped because a detection rule interprets its contents as restricted. Our proposed workflow gives the author enough explanation to request a review without exposing information they are not authorised to see. The reviewer checks the actual data, recipient and handling requirements. If the rule is wrong, improve its scope and test both permitted and prohibited examples. Avoid blanket allowlisting of an entire team because one report was blocked. A useful measure is the time to resolve a justified block and the rate of recurring false positives, alongside the detection of real policy violations.

Do not confuse a workaround with a malicious insider

An intentional bypass can be serious and still arise from a person trying to complete an assigned task. An accidental mistake, negligent action, compromised account and malicious insider require different assessments. Our recommendation is to investigate the behaviour, access and consequences before inferring motive. Did supervisors demand an impossible deadline? Was the approved service unavailable? Had the team repeatedly reported the same obstacle? Understanding these factors does not excuse deliberate harm. It identifies whether the organisation is repeatedly creating the conditions for unsafe work and whether correcting those conditions will prevent the next incident.

Build understanding through a two-way agreement

We recommend a concise explanation for each high-impact control: the mission consequence it prevents, the behaviour required, the approved way to complete the task and the route to help when that route fails. Invite users to describe where the procedure breaks under real conditions. The security team should commit to responding, explaining decisions and fixing avoidable friction. Users should commit to using the approved route, reporting problems and avoiding unauthorised alternatives. Shared understanding grows through visible follow-through. Asking people to care about the mission while ignoring their evidence that a system obstructs it is unlikely to be persuasive.

Teach decisions in context rather than rules in isolation

NIST SP 800-50 Rev. 1 recommends a lifecycle approach to cybersecurity and privacy learning, including behaviour change and evaluation. [4] Our proposed programme uses short role-specific scenarios instead of relying only on annual completion certificates. A maintainer practises media intake; a manager practises an exception decision; an administrator practises restoring access without creating permanent privilege. Give participants a chance to explain the operational pressure before reviewing the options. Training should clarify the available safe action, not merely ask whether someone remembers a prohibition. Revisit scenarios after service changes so that the advice remains usable.

Measure mission performance and security together

Our suggested dashboard pairs task completion time, failure rate and support demand with control effectiveness, unsafe exceptions and detection or containment outcomes. Examine the 95th percentile as well as the average so that severe delays affecting a minority are visible. Include accessibility, low-bandwidth conditions, night shifts and temporary staff. Do not publish individual frustration scores as a disciplinary ranking. Report by workflow where practical and minimise personal data. A drop in complaints may mean improvement, but it may also mean people have stopped reporting; combine tickets with observation, interviews and evidence that the authorised process is actually used.

A worked calculation without false precision

Suppose, purely for illustration, that 80 staff each encounter three avoidable two-minute delays per day. That is 480 staff-minutes, or eight staff-hours, daily. It is a capacity estimate, not proof of eight hours of recoverable cash savings, and it says nothing by itself about the security value of the control. Add the consequences of interrupted attention, missed handovers and pressure to bypass the process. Compare alternative designs against both operational performance and protection. Do not turn guessed incident probabilities into an apparently precise return-on-investment figure. Record uncertainty and use measured trials where possible.

Make exceptions temporary, visible and appropriately authorised

Our recommended exception record states the affected task, reason, information involved, scope, compensating controls, decision-maker, expiry and review trigger. The decision-maker must have authority for the risk in question; an ordinary business owner cannot waive every legal, contractual or classification obligation. If an exception is repeatedly renewed, treat that as a design problem requiring investment or a change to the operating model. NIST SP 800-53 provides a control catalogue covering areas such as access and configuration management, but a catalogue entry is not evidence that the local implementation works. [6]

Give administrators a safe way to administer

Administrators experience friction too. Our proposed operating model provides separate administrative identities, scoped elevation where supported, approved maintenance tools and a documented emergency process. A requirement for privileged access should not force routine work through a shared account because the approved route is too slow. Test emergency access before it is needed, log its use and review it afterwards. Monitor the service that grants access as a critical dependency. The aim is to reduce standing authority while preserving the ability to restore the mission, with clear accountability for exceptional actions.

Leadership should remove contradictory incentives

A supervisor who insists on instant completion while treating the authorised process as optional teaches a stronger lesson than a training module. Our recommendation is for leaders to use the same routes, allocate time for necessary controls and escalate service defects rather than quietly reward bypasses. Procurement should include usability and support requirements, not only a list of security features. CISA’s Secure by Design work emphasises manufacturers’ responsibility for security outcomes. [7] Applied as an organisational design principle, this means reducing unnecessary decisions imposed on users instead of expecting perfect judgement to compensate indefinitely for a difficult system.

A practical improvement cycle

Begin with one frequently obstructed mission task. Observe it with representative users, establish a baseline and identify the threat and obligation behind each restriction. Co-design an alternative with operations, security, support and accessibility input. Pilot it in an authorised scope, measuring task quality and protection together; keep a rollback option. Publish the result to the people who raised the problem and retain unresolved risks with named owners. Repeat on the next important workflow. Our conclusion is that user understanding and good engineering reinforce each other: explain the controls that must remain, fix the friction that adds no value and make the secure route a credible way to accomplish the mission.

References

1. NIST · Security Fatigue, qualitative study, 2016
2. NCSC · Technology assurance: usability of the product
3. NCSC · Cross-domain solutions: people and the CDS
4. NIST · SP 800-50 Rev. 1: Cybersecurity and privacy learning programmes
5. NIST · SP 800-63B-4: Authentication and authenticator management
6. NIST · SP 800-53 Rev. 5: Security and privacy controls
7. CISA · Applying Secure by Design thinking

Original editorial analysis and paraphrases. Recommendations are distinguished from documented facts; references do not imply institutional endorsement.

Francisco Javier Jurado Alonso