The surety bond problem: why cyber risk transfer inherited the wrong model
8th October 2026Here's why that matters more than you think.
Ask a risk manager whether their vendor's cyber insurance would fully protect their organization in a real incident, and most will pause before answering. That pause is the tell. The insurance exists. Whether it was ever built to work the way the risk manager assumes is a different question, and one the market has mostly avoided asking.
I've been making the same comparison in conversations with brokers and risk managers for months. Hold a vendor's cyber policy up against a construction surety bond, and the contrast exposes something the cyber market has normalized that no other similarly situated risk transfer market would tolerate.
An instrument built for exactly this problem
A surety bond is written against one contract, for one owner. If a contractor is bonded on a hospital renovation, that bond protects the hospital's project. It is not diluted by a failure on an unrelated job site, for an unrelated owner, that the same contractor also happens to be working on. Each bond is ring-fenced by design.
That separation is not a feature of the instrument. It is the reason the instrument works as risk transfer at all. A project owner never has to ask how many other projects are drawing on their bond, because the answer is always zero. The protection follows the relationship.
Why the certificate works for other lines
Enterprises require vendors to carry insurance all the time, and for most lines the certificate is worth relying on. Hire a corporate law firm for intellectual property work and you might require $10M, even $100M, of Lawyers Professional Liability cover. When that certificate arrives you can take comfort in it for three reasons. The policy covers third party liability only, so the firm cannot erode the limit with its own losses. Two simultaneous, limit-sized errors against two different clients are vanishingly unlikely. And LPL is a mature, standardized line with a tested claims history, so what you expect to be covered will be.
Why it does not work for cyber
Run the same test on a vendor's cyber certificate and all three reasons fall away. The vendor's own response, recovery and business interruption costs draw down the limit first, before any client sees a dollar. A serious cyber event is engineered to do maximum harm, and it reaches every client the vendor serves in the same event, so the claims arrive together rather than one at a time. And cyber wordings still vary widely, with far less settled claims history behind them, so what the certificate covers is less certain than it looks.
Yet the structure underneath is the same one that works for LPL: one policy, one aggregate limit, every client relationship the vendor holds standing behind it. The structure was never what made the LPL certificate reliable. The three conditions around it were, and in cyber all three are gone. What is left is a single shared limit carrying every client the vendor serves, and a certificate that confirms the number without telling you how much of it is already spoken for, or where you stand in the line.
The asymmetry nobody questions
A project owner would reject a construction bond that was simultaneously backing unrelated projects for unrelated owners; the idea would be dismissed immediately as inadequate. Yet a risk manager will routinely accept a vendor's cyber certificate without asking the equivalent question: how many other companies are already relying on that aggregate limit?
Surety is not the only market that settled this long ago. Private mortgage insurance works the same way. The borrower pays the premium, the lender is the protected party, and the protection attaches to that one loan rather than to a pool across every mortgage the insurer has written. Neither instrument would be credible risk transfer if the protection were shared across unrelated parties.
Cyber has not settled it.
The question that matters
Nobody would sign off on a surety bond structured this way. We sign off on the cyber equivalent every time we accept a certificate of insurance at face value.
The argument is not that vendor risk should go uninsured. It should be insured, and enterprises are right to require it. The real question is narrower, and it is the one most TPRM programs are not built to ask: does a limit shared across every client a vendor serves actually transfer risk to any one of them, or does it only look like it does, right up until a real incident tests it?
Until the market answers that honestly, every certificate of insurance on file deserves a second look.
Disclaimer
This content is intended for general informational purposes only and does not constitute legal, regulatory, financial, or insurance advice. It should not be relied upon as a substitute for professional counsel. While efforts have been made to ensure the accuracy of the information presented, no representation or warranty is made as to its completeness or applicability to any specific situation. Readers should consult their own advisors regarding their particular circumstances.