A security standard that offers unlimited choices without strong defaults can unintentionally build weaker systems than one that offers fewer, better-recommended ones. That sounds counterintuitive — more options should mean more ways to get it right — but it consistently doesn't work out that way in practice, and there's good reason both from security engineering and from decision-making research to explain why.
Security guidance often reads like a menu: API keys, shared secrets, mTLS, Private Key JWT, DPoP — pick whichever fits your situation. Technically, that's flexibility. Practically, most organizations will gravitate toward whichever option is easiest to implement, cheapest to operate, most familiar to their developers, and simplest to explain internally — not necessarily whichever option provides the strongest guarantees. That's not a criticism of the engineers making the call. It's what happens by default when a standard describes what's possible without also being clear about what's recommended.
Engineering teams operate under real constraints — deadlines, budgets, existing systems, and limited in-house security expertise, on top of ordinary pressure to ship features. When a standard presents five valid approaches side by side, the path with the least friction usually wins, even when a harder path offers meaningfully better guarantees. A configuration change beats standing up certificate lifecycle management, which beats building out cryptographic key infrastructure from scratch — not because teams are careless, but because humans reliably optimize for reducing complexity when a decision doesn't come with a clear default telling them not to.
This isn't a uniquely engineering phenomenon. Psychologist Barry Schwartz's research on the paradox of choice found that beyond a certain point, more options don't produce better decisions — they produce more cognitive effort, more decision fatigue, and a stronger pull toward whichever option requires the least deliberation to select. Security standards that present a long list of equally "supported" mechanisms are asking every implementing team to do the comparative risk analysis the standard itself could have done once, centrally, and didn't.
This is exactly why "secure by default" has become a load-bearing principle in modern security engineering rather than a nice-to-have. The UK's National Cyber Security Centre frames it directly: technology that's secure by default has the best security it can offer without the user needing to know it's there or having to turn it on — security shouldn't require extensive configuration to work, and it shouldn't depend on every implementer independently discovering and applying the same recommendation. Good defaults look like secure cookie settings enabled out of the box, modern TLS preferred automatically, strong password hashing as the unconfigured baseline, and least privilege as the starting assumption rather than something bolted on later. Poor defaults look like insecure options left enabled, deprecated algorithms still accepted, and meaningful controls requiring someone to remember to switch them on. A system shouldn't depend on every developer independently remembering every best practice — that's not a security architecture, that's a hope.
The cost compounds once multiple organizations are implementing against the same standard independently. Tell a set of financial institutions "you may use shared secrets, mTLS, Private Key JWT, or DPoP" without a strong recommendation, and the predictable result is that different banks land on different answers — not because one chose wrong and the others chose right, but because the standard never told any of them which choice it actually preferred. Every integration between those institutions now carries different security assumptions, and the ecosystem's overall strength gets pulled down toward whichever choice was easiest, not up toward whichever choice was strongest. Complexity that could have been resolved once, in the standard itself, gets pushed out into every individual implementation instead.
One of the more dangerous phrases in security documentation is simply "this is supported." Supported doesn't mean equally secure, equally appropriate for new systems, or equally likely to hold up under audit. A legacy mechanism can remain supported for compatibility reasons for years after it's stopped being the right default for anything new — and a standard that doesn't clearly separate "still works for existing integrations" from "what you should build today" leaves that judgment call to whoever's implementing it, at exactly the moment they have the least context to make it well.
A technically pristine design nobody implements correctly isn't effective security — it's a specification. The useful question for anyone writing a security standard isn't just "what does this make possible," it's "what will most organizations actually deploy, given real constraints," because the weakest widely-adopted implementation quietly becomes the real security boundary the whole ecosystem is operating under, regardless of what the strongest possible implementation could have achieved.
This is a large part of why FAPI didn't just add more options to OAuth — it narrowed them. The industry had already learned that bearer tokens can be stolen, shared secrets leak, and authentication alone doesn't prove enough about a given request. The response wasn't a longer menu. It was a smaller, stronger one: sender-constrained tokens, cryptographic client authentication, transaction binding, and stronger authorization flows, presented as what a compliant implementation should actually do rather than one item on a long list of acceptable options. The goal was never more choice. It was less ambiguity about what actually protects a high-value transaction.
In most of software engineering, flexibility is a virtue. In security, unmanaged flexibility is closer to a liability, because the cost of a bad default doesn't show up as a minor inconvenience — it shows up as a breach. A strong security recommendation states its default plainly — use this approach, because it provides these specific guarantees — and then explains where alternatives exist and for which real constraints they're actually justified. It doesn't hand over ten equally-weighted options and leave the risk analysis as an exercise for the reader.
Security isn't improved by adding more choices to a standard — sometimes it's actively weakened by it, because more options mean more opportunities to select convenience over protection, and every one of those individual choices is invisible until something goes wrong. The strongest systems are built when the secure option is clearly recommended, well documented, reasonably easy to implement, and secure without anyone having to opt in. Flexibility still has its place — real constraints are real, and no single mechanism fits every situation. But when the thing being protected is financial data, identity, or a system the rest of an ecosystem depends on, a clear default beats an open menu every time.
Clean Architecture or Not? Why the Real Question Is Autonomy and Pragmatism
Popularized by Robert C. Martin, Clean Architecture divides opinion for good reason. On the Big Ball of Mud, Vertical Slice Architecture, and why the real question is autonomy paired with pragmatism.
You Are Hired to Build Software, Not to Become a Merchant of Dependencies
Adding a package doesn't just add functionality — it adds another maintainer, another release cycle, another transitive tree nobody fully mapped. left-pad and xz-utils are what that cost looks like when it finally comes due.