Perfect security does not exist: every protection measure has a cost, financial, in complexity, usability or performance. This lesson is for teams that must decide how much security to apply to a system, and why. It explains the dimensions of the trade-off (usability, performance, agility, cost), the principle of proportionality, then shows how Zero Trust and passkeys now reduce this trade-off instead of enduring it.
It extends the lesson why security fails in practice, which describes the dynamics leading to bad trade-offs, and prepares the one on shared responsibility, which says who decides these trade-offs.
What you will learn
- Understand why no security is ever absolute.
- Identify the four dimensions of the trade-off: usability, performance, agility, cost.
- Apply the principle of proportionality to avoid over- and under-investment.
- Structure a security trade-off in four repeatable steps.
- Place Zero Trust and modern authentication (passkeys) as answers to the classic trade-off.
Why is absolute security impossible?
A perfectly secure system would be unusable. To be fully protected, a server would have to be switched off, disconnected from the network and deprived of users. As soon as you turn it on and connect users, you introduce risks.
Every useful feature creates an attack surface. An open network port allows communication, and intrusions. An interface allows interaction, and human error. An API allows integration, and abuse. An admin account allows management, and compromise.
Security is therefore about finding the balance between protection and usefulness. It is not giving up: zero risk cannot be reached, only approached at the best cost-benefit ratio. What remains after the chosen protections is called residual risk, and someone must know and accept it.
What are the dimensions of the security trade-off?
Every security measure is paid for on at least one of four axes: usability, performance, agility or cost. The tabs detail each one, with the typical side effect of an excess of protection on that axis.
The more secure a system, the more restrictive it is to use. It is the most visible trade-off day to day, and the one that creates the most friction with users.
A 20-character password is hard to remember and encourages the sticky note on the screen. Mandatory MFA (multi-factor authentication) adds a step to every login. A forced password change every 30 days produces predictable patterns (Password1, Password2...). Manually approving each access creates delays that block work.
Excess security causes workarounds. When measures are too restrictive, users find ways around them, which reduces real security. It is also the mechanism that MFA fatigue attacks exploit: a user harassed by notifications ends up approving one out of weariness.
Security controls consume resources and add latency. In high-performance systems, this cost can be prohibitive.
Encryption adds latency and CPU load. Traffic inspection introduces a bottleneck. Exhaustive logging consumes storage and bandwidth. Vulnerability scans slow down deployments.
In some contexts (high-frequency trading, industrial real time), these costs are unacceptable. You must then choose which controls to apply and which to drop, accepting the residual risk.
A highly secured organisation tends to be slow: every change needs a validation, environments are siloed, access restricted, exceptions slow to obtain.
A startup applying a bank's controls does not survive commercially; a bank deploying like a startup exposes itself to major incidents. The right level depends on the business context and the organisation's maturity, a topic developed in the DevSecOps lesson.
Security has a direct cost (tools, staff, infrastructure) and an indirect cost (time, complexity, missed opportunities).
Three questions frame the decision: what would an incident on this system cost? What does the envisaged protection cost? Is the cost-benefit ratio defensible? Protecting an internal test system like a payment system makes no economic sense: the investment must be proportional to the value protected.
What is the principle of proportionality?
Security must be proportional to the value of what you protect and to real threats. This principle avoids both over-investment and under-investment, and it is often where beginner organisations go wrong first.
Assessing what you protect
Not all assets have the same value. Critical assets (customer data, payment systems, secrets) justify the defensible maximum. Important assets (source code, configurations, business logs) deserve a high level. Standard assets (internal documentation, development tools) need moderate protection, and low-value assets (public data, isolated test environments) a minimal level.
Assessing real threats
Not all organisations face the same threats. A local SME is not targeted by nation-states, a brochure site does not carry the risks of a trading platform, an isolated system does not have the exposure of a public API. The threats, risks and vulnerabilities lesson details how to qualify these threats before arbitrating.
Two concrete scenarios
These two scenarios contrast a disproportionate reaction and an assumed trade-off. The second shows the gradation by environment, summed up in the diagram.
A company suffers a minor security incident. In reaction, management imposes drastic measures: mandatory MFA on every application, even internal non-sensitive ones; security approval of every deployment, even in development; Internet access limited to an allowlist; password rotation every 15 days.
Six months on, productivity drops: developers spend a significant share of their time managing access and approvals. Shadow IT explodes, teams bypass restrictions with personal devices. Several engineers resign. And real security has not moved: the real risks, unpatched dependencies and secrets in clear text in the code, were not addressed.
The lesson: a disproportionate reaction can make things worse, by creating workarounds and diverting attention from the real problems.
A scale-up must set the security level of three environments. Rather than applying the same rules everywhere, it adopts an explicit gradation:
- Production (real customer data): end-to-end encryption, mandatory MFA, audit of every access, deployments approved by two people.
- Staging (anonymised data): encryption in transit, simple authentication, logs kept 7 days, automatic deployments with tests.
- Development (fictitious data): isolated network, wide freedom to experiment.
Teams work efficiently while protecting what matters. The residual risk in development is consciously accepted, because a compromise there would have a negligible impact.
How do you arbitrate in practice?
A security trade-off is not an isolated technical decision: it is a structured process involving business, engineering and management. Four steps make it repeatable.
-
Identify what has value
Before securing, know what to protect. Which data would be catastrophic if leaked? Which systems would be critical if they went down? Which access would allow compromising everything?
-
Assess credible threats
No paranoia, realism. Who could attack, with what means? Which vectors are realistic in your context? Which incidents hit comparable organisations?
-
Define the acceptable level
Residual risk will always exist. What level can the organisation absorb? Which incidents would be tolerable, which intolerable?
-
Document the choices
Each trade-off is explicit and traced: why this protection level, which risks are accepted and by whom, when the decision will be reassessed. It is the same discipline as the security debt register.
How does Zero Trust reduce the trade-off?
The Zero Trust approach seeks to reduce the trade-off rather than endure it: instead of choosing between strong but painful security and risky usability, it applies contextual and adaptive security. The reference model is CISA's Zero Trust Maturity Model 2.0, the US cybersecurity agency: five pillars (identity, devices, networks, applications and workloads, data), each progressing through maturity stages from "traditional" to "optimal". The Zero Trust page (in French) goes deeper into the model.
The principle "never trust, always verify"
Unlike the perimeter model, where anything inside the network is trusted, Zero Trust verifies every request. Who is asking (identity)? From which device (device posture)? From where? To access what? Is the behaviour usual (behavioural analysis)?
Adaptive rather than static security
The traditional approach imposes MFA on every login; Zero Trust applies adaptive MFA, required when risk is high. The traditional approach imposes a VPN for everything; Zero Trust offers secure direct access per application (ZTNA, Zero Trust Network Access). The traditional approach forces password rotation; Zero Trust triggers it on detected compromise. Rules become differentiated by sensitivity, and authorisation dynamic according to context.
Passkeys: security and comfort improve together
For a long time, strengthening authentication meant adding friction. Passkeys, cryptographic credentials bound to the device and based on the FIDO2 and WebAuthn standards, break this pattern: they resist phishing better than passwords and are faster to use, a biometric check replacing typing.
Adoption has passed a milestone: in May 2026, the FIDO Alliance estimated about five billion passkeys in use worldwide, and 68 % of the organisations surveyed had deployed or were deploying passkeys for their employees. MFA fatigue attacks remain active though: Microsoft counted more than 382,000 of them over twelve months in its 2023 Digital Defense report. This is exactly what phishing-resistant authentication neutralises, unlike classic push notifications.
Security across the whole lifecycle
Zero Trust also goes beyond the opposition between shift-left and shift-right. Upstream, verification of identities and permissions starts at development. At runtime, every request is verified, not just the login. Downstream, behavioural detection and automated response complete the chain.
Enterprise browsers: security made transparent
Enterprise browsers, such as Island or Palo Alto Networks' Prisma Access Browser (from the Talon acquisition), illustrate another way to make security transparent. They embed data loss prevention controls (DLP: copy-paste, download), isolate risky web sessions and stay close to a regular browser.
The market is however moving toward a browser-agnostic approach: rather than imposing a replacement browser, offers such as Chrome Enterprise Premium or Edge for Business add controls through extensions or policies to the browser already installed. Users keep their habits, and controls apply automatically: the friction of changing tools disappears.
Key points
- No perfect security: any useful system has an attack surface, to reduce to an acceptable level, not eliminate.
- Every measure has a cost, in usability, performance, agility or budget; ignoring these costs leads to failure.
- Excess is counter-productive: overly restrictive measures cause workarounds that reduce real security.
- Proportionality: adapt the security level to the value of assets and to real threats, for example per environment.
- Explicit trade-offs: document each decision, the accepted risk and who accepts it, to own it and reassess it.
- Zero Trust and passkeys reduce the trade-off: context-adaptive security and frictionless authentication rather than static controls.
Knowledge check
Check that you have the essentials of this guide. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Threat, risk, vulnerability, attack: understanding the differences
A new full quiz with random questions
Work again only on the questions you missed
FAQ: frequently asked questions
The questions below cover the most frequent doubts about the security trade-off: its dimensions, how to arbitrate, Zero Trust and passkeys.