Security Economics Guide: Incentives and Liability

Many security failures are not technical mysteries but predictable outcomes of who pays, who decides and who suffers, and programmes that ignore those incentives keep buying controls that do not change outcomes. Security economics applies microeconomics to information security: externalities, asymmetric information, moral hazard, network effects and liability. Ross Anderson's 2001 paper "Why Information Security is Hard: An Economic Perspective" argued that insecurity stems at least as much from perverse incentives as from technical shortcomings, and that view now underpins regulation such as secure by design initiatives, product liability reform and the EU Cyber Resilience Act. This guide explains the core concepts, shows how they play out in product buying, vendor risk, open source, insurance and regulation, and turns them into decisions a CISO or risk team can make. It is written for security leaders, risk managers and policy teams. For putting numbers on risk, see the Cyber Risk Quantification Guide; this page explains why the numbers fall where they do.

Key takeaways

Misaligned incentives cause failure. Anderson and Moore put it plainly: systems fail when the person guarding them is not the person who suffers when they fail.
Buyers cannot see security, so markets underprovide it. This is Akerlof's "market for lemons": without credible signals, vendors gain little by investing in security buyers cannot measure.
Insecurity is often an externality. The owner of a vulnerable device or library rarely bears the full cost of its compromise, as with botnets and widely used open source components.
Liability is moving to producers. Secure by design, EU product liability reform and the 2023 US National Cybersecurity Strategy all aim to put costs where risk can best be managed.
Use economics to design controls. Ask who has the information, who has the power to fix the problem and who bears the loss; then change contracts, metrics or defaults so those align.

Core concepts

Concept	Meaning	Security example	Typical remedy
Misaligned incentives	The party able to protect a system is not the party harmed by its failure	Anderson's ATM example: banks that could blame customers for disputed withdrawals grew careless, while US banks that bore the burden of proof invested more effectively	Allocate liability to the party best placed to manage the risk
Negative externality	A cost imposed on others who are not part of the decision	Insecure machines used in denial-of-service attacks harm third parties, not their owners	Regulation, default security, network-level controls
Asymmetric information (lemons)	Sellers know quality, buyers do not, so price and quality fall	Security products and software whose real security buyers cannot assess	Credible signals: independent testing, transparency, warranties
Adverse selection	The least trustworthy parties are most attracted to a scheme	Anderson and Moore cite research that about 8 per cent of websites certified by one large trust-seal vendor were malicious, against about 3 per cent of websites overall	Certifications with real testing and sanctions
Moral hazard	Being protected from loss reduces care	Insured or indemnified parties relaxing controls	Deductibles, control requirements, monitoring
Network effects and lock-in	Products become more valuable as more people use them; switching is costly	Anderson's "ship it Tuesday, get it right by version 3": speed to market beats security in winner-take-all markets	Regulation of baseline security; procurement pressure
Public goods and free riding	Everyone benefits whether or not they contribute	Widely used open source maintained by a few volunteers	Funding, shared maintenance, foundation support

Varian's three ways that effort adds up

Hal Varian's model, summarised by Anderson and Moore, explains why some systems improve with more people and others get worse.

Model	System security depends on	Practical implication
Total effort	The sum of everyone's effort; in Varian's analysis the party with the highest benefit-cost ratio does most of the work and others free-ride	More testers and reviewers help
Weakest link	The least careful participant	More participants make it worse; Anderson and Moore suggest fewer, better programmers for code where one bug is enough
Best shot	A single champion's effort	Fund and protect the one team or person who carries it

Most identity estates are weakest-link systems: one unrotated service account key or one admin without MFA can undo the rest. That is why baseline enforcement beats training-only approaches for credentials.

The market for security products

Anderson applied Akerlof's lemons model to security products in 2001: when buyers cannot tell good from bad, the good cannot command a premium. Practitioners can respond on the buying side.

Demand evidence, not claims: ask for independent test results, published security findings, vulnerability disclosure history and secure development attestations. See the CISA Secure Software Attestation Form Guide.
Be wary of who pays the evaluator: Anderson noted that Common Criteria evaluations are paid for by vendors, unlike the earlier Orange Book scheme, creating an incentive to seek the easiest evaluation. Read the scope and assurance level, not only the certificate.
Write security into contracts: service levels for patches, notification duties and secure defaults move the cost of insecurity back to the vendor.
Value defaults: CISA's secure by default concept asks for products secure out of the box, with features such as MFA, logging and access control at no additional cost. Paying extra for basic security features is a sign the incentive is upside down.

Signalling and screening

Economists describe two ways out of a lemons market. Sellers can signal quality with something that is costly to fake: a warranty, a published record of fixed vulnerabilities, a long support commitment or open review of their code. Buyers can screen by designing a test that only good sellers pass: a proof of concept on your own environment, a contractual right to audit or a requirement for independent penetration test reports. A signal that costs a weak vendor nothing, such as a self-assessed questionnaire or a logo, carries little information. When you evaluate suppliers, score evidence by how expensive it would be for a weak vendor to produce, and give questionnaire answers the least weight.

Liability and the policy shift

Recent policy applies the economics directly: put responsibility on those best placed to bear it.

Instrument	Economic mechanism	Status note
US National Cybersecurity Strategy (1 March 2023)	Two shifts: "rebalance the responsibility to defend cyberspace" towards the most capable actors and "realign incentives to favor long-term investments"; Strategic Objective 3.3 Shift Liability for Insecure Software Products and Services, with an adaptable safe harbour for companies that develop and maintain software securely, drawing on the NIST SSDF; Objective 3.6 explores a federal cyber insurance backstop	Published by the previous administration; check current federal policy before relying on it
CISA Secure by Design	Says the burden is placed disproportionately on consumers and small organisations and asks manufacturers to claim ownership of customers' security outcomes	Guidance, not law
EU Product Liability Directive (EU) 2024/2853	Strict liability for defective products, modernised for software and digital products; repeals Directive 85/374/EEC	Adopted 23 October 2024; see the EU Product Liability Directive 2024 Guide for application dates
EU Cyber Resilience Act	Mandatory essential requirements and vulnerability handling for products with digital elements, so security is no longer optional for market access	See the EU Cyber Resilience Act Guide

Safe harbours matter economically: liability without a defined standard of care creates uncertainty, while a safe harbour tied to recognised practice rewards the investment the policy wants. See the Software Liability and Secure by Design Policy Guide.

Shared responsibility, vendors and open source

Shared responsibility models: cloud and SaaS contracts divide duties, but the party choosing defaults shapes outcomes. In the Snowflake breach, infostealer credentials without MFA unlocked about 165 customer environments; Snowflake said its platform was not breached, and in December 2024 it announced a phased block on single-factor password sign-ins. The default changed once the cost of the old default became visible.
Open source as a public good: the XZ Utils backdoor targeted a library largely maintained by one volunteer, who was pressured to hand over release rights. Everyone downstream benefited from the code; almost nobody paid for its maintenance or review.
Vendor concentration: network effects create a few dominant suppliers, so a single failure becomes a correlated loss across thousands of customers.

Practical responses: fund or contribute to critical dependencies, require MFA and secure defaults contractually, and treat concentration as a risk to be recorded and tested. See the Open Source Security Guide.

Insurance, correlated loss and moral hazard

Anderson and Moore observed in 2006 that cyber insurance was underdeveloped because worms and viruses create correlated, system-wide losses that are hard to pool. The market has grown since, but the same economics explain its features.

Underwriting questionnaires: insurers reduce information asymmetry by asking about MFA, backups and privileged access before quoting. See the Identity Controls for Cyber Insurance Questionnaires Guide.
Exclusions and sub-limits: responses to correlated, catastrophic risk.
Moral hazard controls: deductibles, co-insurance and warranties that cover can be void if declared controls were not in place.
Federal backstop proposals: the 2023 US strategy committed to explore one for catastrophic events, a classic response when private markets cannot pool correlated risk.

See the Cyber Insurance Guide.

Attacker economics

Asymmetry favours attack: Anderson argued, using a statistical model of bug discovery, that attackers need to find only one flaw while defenders must fix many, so attackers can find flaws faster than defenders can remove them.
Raise cost, lower return: controls that add work to every attempt (phishing-resistant MFA, short-lived credentials) change attacker economics more than controls that only add detection after the fact.
Vulnerability markets: Anderson and Moore discuss markets and bounties as ways to reveal the cost of finding flaws, which can serve as a proxy for security. See the Bug Bounty and Vulnerability Disclosure Guide.
Crime as a business: specialisation and services lower entry costs for criminals. See the Cybercrime Ecosystem Guide.

Where identity fits

Non-human identities are a clear case of misaligned incentives. The developer who creates an API key or service account gains speed; the cost of a leaked, over-privileged or orphaned credential falls later on the security team or on customers. Because one exposed secret can be enough, identity estates behave like weakest-link systems. Economic fixes include assigning a named owner to every credential, making the secure path (short-lived workload identity, a secrets manager) the cheapest and fastest path, and charging the cost of exceptions to the team that requests them. See the NHI Ownership Attestation Campaigns Guide.

Using security economics in your programme

Map incentives for top risks: for each, record who decides, who has the information, who bears the loss and who pays for the control.
Find mismatches: where the decider does not bear the loss, change something: ownership, budget, metrics or contract.
Prefer defaults to persuasion: secure defaults and guardrails beat training where effort adds up as a weakest link.
Size investment to expected loss: use quantification to compare control cost with reduction in expected loss. The Gordon-Loeb model suggests investment in protecting an information set should not normally exceed about 37 per cent (1/e) of the expected loss.
Use procurement as leverage: demand evidence, secure defaults and liability terms.
Review annually: regulation and insurance terms change the cost of risk; revisit the map when they do.

Decision guidance

Question	If yes	If no
Can the buyer verify the security claim?	Compete on price and features	Require independent evidence or contractual commitments
Does the decision maker bear the loss?	Advise and let them decide	Move ownership or budget, or impose a baseline
Is the system weakest-link?	Enforce minimum controls centrally	Encourage contributions and accept variation
Is the loss correlated across many parties?	Plan for concentration risk and check insurance exclusions	Standard risk transfer is available

Small organisations have little leverage over vendors, so they benefit most from regulation and secure defaults and should favour vendors that publish evidence. Large organisations can shape markets through procurement terms and should use that power.

Detection and measurement

Ownership coverage: percentage of top risks and of non-human identities with a named owner who bears the cost of failure.
Evidence-based procurement: percentage of new critical suppliers assessed on independent evidence rather than questionnaires alone.
Secure-by-default share: percentage of critical products where MFA, logging and least privilege are on by default without extra licence cost.
Exception cost: number of security exceptions, with the requesting team recorded as risk owner.
Concentration: share of critical services depending on any single supplier.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0 Govern	GV.RM-01, GV.RM-02, GV.RM-06	Risk objectives, appetite and a standard method for prioritising risk
NIST CSF 2.0 Govern	GV.RR-03 Adequate resources; GV.OV-02 strategy reviewed and adjusted	Funding proportional to risk; revisiting incentives
NIST CSF 2.0 Govern	GV.SC-01, GV.SC-05	Supply chain programme and security requirements in contracts
NIST CSF 2.0 Identify	ID.RA-04, ID.RA-05	Impact, likelihood and inherent risk for investment decisions

Common failure patterns

Buying on claims: selecting products on marketing and questionnaires in a market where quality cannot be observed.
Security as someone else's budget: teams that create risk do not pay for controls or incidents, so risk grows.
Trusting certificates without reading scope: treating any certification as proof of security, ignoring who paid and what was tested.
Free riding on open source: depending on critical projects with no funding, review or contingency, as the XZ Utils case showed.
Accepting insecure defaults: paying extra for MFA or logs, or leaving vendor defaults that put the cost of failure on you.
Ignoring correlated loss: assuming insurance or diversification will absorb a failure that hits every customer of the same supplier at once.

Practitioner checklist

Map decider, information holder, loss bearer and payer for each top risk.
Assign owners to risks and non-human identities, and charge exceptions to the requester.
Require independent evidence and secure defaults in procurement.
Put patch, notification and liability terms in supplier contracts.
Identify critical open source dependencies and support their maintenance.
Record supplier concentration and check insurance exclusions for correlated events.
Use quantification to size investment against expected loss.
Track the status of liability and product security regulation that applies to you.

Security Economics Guide: Incentives, Externalities and Liability Explained for Practitioners