The Baker's Dirty Dozen

Thirteen Trust Failures That Changed Cybersecurity Forever

Cybersecurity has spent decades strengthening cryptographic mathematics.

At the same time, the discipline of understanding, measuring, governing, and assuring trust systems has received far less attention than its importance warrants.

The result is visible throughout the history of cybersecurity.

Many of the industry's largest and most expensive failures were not failures of cryptography.

They were failures of implementation.

Failures of governance.

Failures of visibility.

Failures of supply chains.

Failures of operational discipline.

Failures of trust.

The mathematics often survived.

The trust systems surrounding it did not.

The Baker's Dirty Dozen is a collection of thirteen lessons in how trust actually fails.

Twelve are historical.

The thirteenth is contemporary.

Together they represent billions of dollars in losses, remediation costs, programme failures, operational disruption, and strategic damage.

More importantly, they reveal a pattern.

Trust rarely fails where people expect it to fail.

Article content

For those who don't know the origins of The Bakers Dozen

1. Sony PlayStation 3

Year: 2010

Failure Type: Cryptographic Implementation Failure

Estimated Impact: Hundreds of millions of dollars

A cryptographic nonce that should have been unique for every digital signature was reused within Sony's implementation of ECDSA.

The mathematics was never broken.

The implementation was.

Once the repeated nonce was identified, Sony's private signing key could be recovered.

The platform's trust model collapsed and software authenticity could no longer be guaranteed.

Lesson: Strong algorithms cannot compensate for weak implementation.

2. Debian OpenSSL

Year: 2008

Failure Type: Randomness Failure

Estimated Impact: Tens of millions of dollars

A modification to OpenSSL intended to remove development warnings accidentally removed critical entropy sources used during random number generation.

The resulting cryptographic keys became predictable.

Millions of keys required replacement across affected systems.

The algorithms remained secure.

The randomness did not.

Lesson: Cryptography is only as strong as its randomness.

3. DigiNotar

Year: 2011

Failure Type: Trust Infrastructure Failure

Estimated Impact: Corporate collapse

Attackers compromised a trusted certificate authority and issued fraudulent certificates for major online services.

Browsers trusted those certificates because the trust infrastructure instructed them to do so.

The compromise destroyed confidence in the organisation.

The company ultimately failed.

Lesson: Trust anchors become single points of failure.

4. Heartbleed

Year: 2014

Failure Type: Software Assurance Failure

Reference: CVE-2014-0160

Estimated Impact: Billions of dollars globally

A flaw in the OpenSSL Heartbeat extension allowed attackers to retrieve sensitive information directly from memory.

Private keys.

Credentials.

Authentication tokens.

Sensitive data.

The cryptography worked exactly as designed.

The software surrounding it did not.

Lesson: Secure cryptography running inside insecure software remains insecure.

Article content

5. ROCA

Year: 2017

Failure Type: Hardware Assurance Failure

Reference: CVE-2017-15361 / Infineon Library

Estimated Impact: Hundreds of millions of dollars

Millions of cryptographic keys generated by certified hardware products contained weaknesses that made them vulnerable to attack.

The products were trusted.

The keys were flawed.

Governments, enterprises, and infrastructure providers were forced into large-scale replacement programmes.

Lesson: Certification is not proof of security.

6. Symantec Certificate Authority Distrust

Year: 2017

Failure Type: Governance Failure

Estimated Impact: Hundreds of millions of dollars

Major browser vendors lost confidence in Symantec's certificate issuance practices.

The algorithms had not failed.

Governance had.

Trust was removed and large-scale certificate replacement programmes followed.

Lesson: Trust can be revoked faster than it can be established.

7. Equifax

Year: 2017

Failure Type: Operational Security Failure

Reference: Apache Struts CVE-2017-5638

Estimated Impact: More than $1.4 billion

Attackers exploited a known vulnerability within Apache Struts that had not been remediated.

The vulnerability was public.

The patch existed.

The issue remained exposed.

Approximately 147 million individuals were affected.

Lesson: Security controls that are not maintained become liabilities.

8. SolarWinds

Year: 2020

Failure Type: Software Supply Chain Failure

Reference: SUNBURST / Orion Platform

Estimated Impact: Several billions of dollars

Attackers infiltrated the Orion software build environment and inserted SUNBURST malware before software updates were digitally signed and distributed.

Customers received authentic software.

The signatures were valid.

The software was compromised.

Government agencies, critical infrastructure providers, and major enterprises were affected.

Lesson: Authenticity does not guarantee integrity.

Article content

9. Log4Shell

Year: 2021

Failure Type: Dependency Visibility Failure

Reference: Apache Log4j2 CVE-2021-44228

Estimated Impact: Several billions of dollars

A vulnerability in Apache Log4j2 exposed systems across the world.

The challenge was not merely patching.

The challenge was finding.

Many organisations could not immediately determine where the dependency existed within their own environments.

One of the largest remediation efforts in Internet history followed.

Lesson: You cannot secure what you cannot see.

10. MOVEit

Year: 2023

Failure Type: Third-Party Ecosystem Failure

Estimated Impact: Billions of dollars

A vulnerability in MOVEit Transfer became an entry point into thousands of organisations.

One software platform.

Thousands of victims.

The incident demonstrated how concentrated dependency risk can propagate across entire ecosystems.

Lesson: Third-party risk frequently becomes first-party damage.

11. XZ Backdoor Attempt

Year: 2024

Failure Type: Open Source Trust Failure

Reference: liblzma

Estimated Impact: Potentially incalculable

A sophisticated attempt was made to introduce a backdoor into liblzma, a widely used open-source component.

The attack did not begin with code.

It began with trust.

Influence was established gradually over a prolonged period before malicious functionality was introduced.

The attack was detected before widespread deployment.

Lesson: Supply chain attacks begin long before malicious code appears.

Article content

12. RSA SecurID

Year: 2011

Failure Type: Identity Trust Failure

Estimated Impact: Hundreds of millions of dollars

RSA disclosed that attackers had compromised information relating to its SecurID authentication platform.

The incident undermined confidence in one of the world's most widely trusted authentication systems.

The consequences extended far beyond RSA itself.

Organisations dependent upon SecurID were forced to reassess their trust assumptions and remediation strategies.

Lesson: When trust providers lose trust, the impact propagates far beyond a single organisation.

13. Post-Quantum Migration Failure

Year: 2026

Failure Type: Trust-State Discovery Failure

Estimated Impact: Six-week programme stall, significant vendor burn rates, executive escalation, and approximately USD $680,000 in direct programme costs

A large enterprise contacted our team after an in-flight Post-Quantum Cryptography migration programme stalled.

The programme was deploying hybrid ML-KEM across a complex enterprise estate.

The request came directly from the Chief Risk Officer and the lead delivery vendor.

By the time we arrived, the migration had been frozen for six weeks.

Multiple vendors had investigated.

Multiple partners had conducted reviews.

Internal engineering teams had exhausted their own analysis.

Despite significant effort, nobody could identify the root cause.

The working assumption was straightforward: "The problem must be in the PQC."

Reasonable.

Incorrect.

The theories were familiar:

Hybrid KEM interoperability.

Certificate size increases.

TLS negotiation failures.

Application incompatibilities.

Network performance impacts.

Every explanation appeared plausible.

None matched the evidence.

Every review shared the same flaw: they were searching for a cryptographic failure.

The failure was not cryptographic.

Instead, trust relationships were reconstructed across the estate and certificate replacement was simulated at scale.

The result appeared almost immediately.

A previously undocumented trust hierarchy surfaced.

Buried inside legacy middleware.

Absent from programme documentation.

Absent from governance records.

Absent from the cryptographic inventory.

Unknown to the migration team.

Unknown to risk management.

Unknown to programme leadership.

Yet it represented a critical trust dependency.

The migration had not stalled because of ML-KEM.

The migration had stalled because a significant portion of the trust estate had never been discovered.

The organisation eventually discovered something important: its trust estate was materially larger than its documented cryptographic estate.

Lesson: You cannot migrate what you have not discovered.

Cryptographic inventories describe known assets.

Trust relationships frequently extend far beyond them:

Undocumented certificate hierarchies.

Legacy trust anchors.

Embedded middleware dependencies.

Supplier-controlled trust paths.

Operational workarounds that became permanent infrastructure.

PQC was not the risk.

The undocumented trust infrastructure already operating inside the organisation was the risk.

PQC did not create the exposure.

PQC exposed it.

SITG-Consulting Conclusion

The Baker's Dirty Dozen spans nearly two decades of cybersecurity history.

Implementation failures.

Governance failures.

Identity failures.

Supply chain failures.

Visibility failures.

Operational failures.

Trust-state failures.

The common thread is remarkably consistent.

Sony lost a platform because of one repeated number.

DigiNotar lost a business because of one compromised trust anchor.

SolarWinds compromised thousands of organisations through one software pipeline.

A modern PQC migration stalled because of one undocumented trust hierarchy.

The lesson has remained unchanged for almost twenty years: Trust rarely fails where people expect it to fail.

The organisations that succeed in the quantum transition will not be those that deploy new algorithms first.

They will be the organisations that finally understand the trust systems they already have.

The algorithms usually survived.

Trust did not.

That is the real lesson of The Baker's Dirty Dozen.

Article content

Copyright Notice

© 2026 SITG-Consulting and Brian Couzens. All rights reserved.

This publication may be shared, referenced and quoted in part provided full attribution is given to SITG-Consulting, Brian Couzens and the original publication source. No part of this publication may be reproduced, republished, modified, distributed, incorporated into derivative works or commercially exploited without prior written permission from the copyright holders.

Disclaimer

This publication is provided for informational and educational purposes only and does not constitute legal, regulatory, financial, investment or professional advice.