False Sense Of Either Or Choice

Expanded Definition

A false sense of either or choice is a decision-making error, not a technical control. It appears when security is framed as inherently incompatible with usability, speed, or adoption, even though the real design question is usually how to reduce friction while preserving assurance. In practice, the term covers policy, process, and architecture debates where teams treat inconvenience as evidence that control must be weakened.

The boundary matters. A genuine tradeoff exists when a control really does add cost, latency, or operational burden. The false sense of either or choice arises when that burden is assumed to be unavoidable rather than challenged through design, automation, or better identity and access patterns. In digital identity work, the most effective approaches hide complexity from users while strengthening assurance. The NIST SP 800-63 Digital Identity Guidelines are useful here because they show how assurance, authenticator choice, and user experience can be balanced without collapsing the discussion into a false binary.

Industry guidance is consistent on the principle that strong security need not be synonymous with poor usability, but organisations often misapply that principle by treating every friction point as proof that the control is wrong. The more accurate question is whether the control can be redesigned so that users experience less visible effort while the organisation retains stronger governance.

Examples and Use Cases

This pattern shows up in design reviews, security exceptions, and product debates when teams overstate the cost of control. The practical value of the term is that it helps decision-makers distinguish between a real constraint and a solvable implementation problem.

• A login team removes phishing-resistant authentication because users complain about extra steps, even though a better authenticator flow could preserve both convenience and assurance.
• A business unit argues that stronger approval workflows will kill adoption, despite evidence that automation can reduce manual effort while improving accountability.
• A platform team claims that least-privilege access will slow delivery, but the actual bottleneck is poor role design and missing self-service provisioning.
• A governance group treats security review as a blocker rather than redesigning the workflow so reviews happen earlier and with less rework.
• A SaaS rollout frames access control and end-user experience as opposing goals, when the real challenge is aligning defaults, policy, and exception handling.

The tradeoff is that not every security requirement can be made invisible. Some controls do add real friction, and mature teams acknowledge that. The mistake is to accept the first inconvenient design as the only design.

Security Implications

When this mindset takes hold, organisations often weaken controls prematurely. The result is not just lower assurance, but weaker governance because exceptions become normalised, policy is bypassed, and the team starts optimising for short-term convenience rather than durable risk reduction. Over time, this can produce fragile access patterns, inconsistent enforcement, and unclear ownership for security decisions.

A common failure mode is that the organisation confuses user resistance with technical impossibility. That leads to control dilution, where protections are simplified until they no longer materially reduce exposure. Another consequence is shadow process creation: staff work around cumbersome controls, creating opaque approval paths or informal access grants that are harder to audit and revoke. The practical symptom is often visible in repeated exception requests, inconsistent implementation across teams, and a widening gap between policy intent and real behaviour.

For NHIMG, the broader lesson is that identity-centric controls only deliver value when they are designed to be usable enough to survive real workflows. If they are not, users and administrators will route around them, and the control will exist on paper more than in practice.

Domain and Governance Relevance

This term matters most in governance because it changes how leaders evaluate control decisions. The question is not whether security and productivity are always in tension, but whether the organisation has designed the system so that assurance is embedded in normal work rather than added as an afterthought. That framing affects policy, procurement, user experience, and accountability.

In identity and access programmes, the relevance is especially clear. If access controls, authenticator choices, approval steps, or entitlement reviews are too cumbersome, teams will seek exceptions or delay adoption. If they are streamlined well, the organisation can raise assurance without turning security into a separate, adversarial process. The practical governance task is to measure whether a control actually improves outcomes or merely shifts burden to users in ways that invite circumvention.

This also shapes how security leaders communicate with business owners. Mature governance avoids slogans like "security versus usability" and instead asks what design change would make the secure path the easy path. That is the standard that separates genuine constraint from a false either or choice.

Related resources from NHI Mgmt Group

• When does static testing create a false sense of security?
• When do IAST and RASP create a false sense of coverage for NHIs?
• Why do one-time codes create a false sense of security?
• When does zero standing privilege create a false sense of security?