Security economics asks why systems fail even when the technology is known. Ross Anderson and Tyler Moore argue that misaligned incentives matter as much as bad design. Six ideas from their survey cover most of what an engineering leader needs: externalities, hidden information, hidden action, interdependence, lock-in and liability.
1. Externalities
An externality is a cost that lands on someone else. Anderson and Moore, building on Camp and Wolfram, compare an insecure machine on the internet to a coal fire: the owner does not pay the full cost. In your shop, a team that skips a patch may push the cost onto customers.
What to do: make the team that creates a risk feel part of its cost, for example by tracking security debt per team.
2. Hidden information
Sellers know quality, buyers do not. Akerlof's used car example shows how bad products can drive out good. See the lemons problem in security products.
What to do: ask for evidence you can test yourself.
3. Hidden action
One party cannot see what the other does. The classic case is insurance, where the insured may act carelessly out of sight. See moral hazard in cyber insurance.
What to do: build monitoring and contract terms that make actions visible.
4. Interdependence
Security often depends on the efforts of many people. Hirshleifer's island has flood defenses built by each family, so the laziest family sets the level. Varian split this into weakest link, best shot and sum of efforts. See weakest link, best shot and total effort.
What to do: find where your system is only as strong as its weakest part, and spend there first.
5. Lock-in and network effects
Software markets have high fixed costs, low marginal costs, network effects and lock-in, so winning the race matters most. The authors note that platform vendors may start with little security and add more later, sometimes in ways that raise switching costs.
What to do: price the exit before you commit to a platform.
6. Liability
The authors note that liability should fall on the party who can best manage the risk. Their banking example is memorable. In the US, banks generally had to refund disputed card transactions. UK banks could more easily claim their systems were secure and blame customers, yet they spent more on security and saw more fraud. The authors suggest moral hazard played a part.
What to do: ask who can actually prevent a loss, and check whether the contract puts the cost on them.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that the same finding looks different once you know whether it is exploitable in your setup, which is a hidden information problem in miniature.
Quick check
Which idea explains why the laziest party sets the security level?
Interdependence of the weakest link kind, where the outcome depends on the minimum effort.
Why did UK banks spend more and still see more fraud in the authors' example?
The authors suggest moral hazard: staff knew complaints would be dismissed, so they became careless. It is their interpretation, not a proven law.
Sources
Last reviewed: 19 October 2026.
