top of page

The Case for Cryptographic Modernisation

Writer: Brian Couzens
Brian Couzens
2 minutes ago
10 min read
Locks showing broken crypto with the SITG logo

Cryptographic modernisation is the case for treating cryptography as a managed asset class, with an owner, a budget and a lifecycle, rather than as a technical detail that surfaces only when it fails. This article sets out the evidence for boards, Chief Financial Officers (CFOs) and Chief Risk Officers (CROs): what unmanaged cryptography has already cost, why the next forced change is already scheduled, why cyber insurance may not cover the gap, and what modernisation buys that a series of one-off fixes does not.

Cryptographic modernisation starts with a category error

Cryptography sits in every system that authenticates a user, signs a transaction, connects to a supplier or stores customer data. It is in applications, network devices, cloud services, payment flows and the products the organisation buys. Almost none of it appears on a balance sheet, an asset register or a budget line.

That is the category error. Cryptography is treated as a property of other systems, so it is owned by nobody in particular. It is chosen by developers, inherited from suppliers, configured by default and left in place until something forces a change. When the force arrives, the organisation discovers how much it depends on cryptography it never listed.

The evidence below is not about quantum computers. It is about what happens to organisations that run cryptography without managing it.


The bill is already arriving

Expired certificates blind controls and stop services

The 2017 Equifax breach is commonly remembered for an unpatched web application. The US Government Accountability Office (GAO) found a second failure. A device that inspected network traffic for malicious activity had been misconfigured because of an expired digital certificate, one that had expired about ten months before the breach began. Encrypted traffic passed through uninspected. Attackers extracted data for about 76 days, and the intrusion was noticed only after an administrator replaced the certificate and inspection resumed. The breach exposed personal information of at least 145.5 million people. Equifax later agreed a settlement with US federal regulators and states of up to $700 million.

The certificate did not cause the breach. It removed the control that should have caught it. That is the board-level lesson: an unmanaged cryptographic asset can silently disable a security investment the organisation believes it owns.

The pattern repeats in operations. In April 2023 Starlink suffered a multi-hour outage that SpaceX attributed to an expired certificate at a ground station. The company said it was checking its systems for other single points of failure. A certificate is a dated object. Any organisation that cannot list its certificates and their expiry dates is carrying outages it has not yet scheduled.


Trust can be withdrawn by someone else

In June 2024 Google announced that Chrome would stop trusting new TLS certificates issued by Entrust, a long-established certificate authority, with the change taking effect from November 2024. Google cited a pattern of compliance failures. Mozilla took similar action. Organisations using those certificates had to replace them on a timetable set by a browser maker, not by their own change calendar.

This is cryptographic risk that no internal control prevents. The decision sat with a third party. The operational defence is the ability to identify every affected certificate quickly and replace it without a project. Organisations that had that capability absorbed the change as routine. Organisations that did not met it as an incident.

Root certificates expire too. When a widely used root certificate for Let's Encrypt, DST Root CA X3, expired on 30 September 2021, older devices and software that did not trust the newer root began failing connections. Smart devices, API clients and systems on outdated libraries were affected. Nobody had made a decision. A date had passed.


Library dependencies become emergencies

In April 2014 the Heartbleed flaw in OpenSSL, a cryptographic library embedded across the internet, exposed memory on affected servers, including private keys. Netcraft estimated that 17.5 per cent of SSL sites, around half a million widely trusted websites, had the vulnerable heartbeat extension enabled. Fixing the code was not enough. Keys and certificates that might have been exposed had to be revoked and reissued.

The cost of Heartbleed to any one organisation was set by a single question: did it know where OpenSSL sat in its estate, and which keys depended on it? The bulk of the effort went on finding out.


Acquisitions inherit cryptography, and regulators do not discount it

Marriott acquired Starwood in 2016. Starwood's guest reservation system had been compromised in 2014, and the breach was found in 2018, after the acquisition. About 339 million guest records were affected worldwide. In October 2020 the UK Information Commissioner's Office (ICO) fined Marriott £18.4 million. The ICO was particularly concerned that not all passport numbers were encrypted, rejected the argument that more encryption was impractical, and stated that due diligence is not a one-off requirement that ends at completion.

For a CFO, the point is direct. Cryptographic weakness in an acquired estate becomes the acquirer's liability on completion. The issues that matter in mergers and acquisitions are not only whether data is encrypted, but whether anyone can show what protects it and who manages the keys.


Assurance status changes on a fixed date

In September 2026 NIST's Cryptographic Module Validation Program moved all remaining FIPS 140-2 validations to its historical list. The programme continues to support their purchase and use for existing systems, and US federal agencies decide when to require FIPS 140-3. Organisations whose products, contracts or customers require active validation must establish where the status change creates a compliance or procurement validation gap, on a standards body's calendar rather than their own.


Fixing incidents versus building capability

Each of these cases was handled as a one-off. An expired certificate is replaced. A distrusted authority is swapped out. A vulnerable library is patched and its keys reissued. Each fix is paid for from an operating budget, under time pressure, and rarely leaves behind a capability that makes the next change cheaper.

The changes are not slowing down. Certificate validity periods are being cut in stages. NIST has proposed deprecating RSA and elliptic curve algorithms after 2030 and disallowing them after 2035. Post-quantum migration is one more forced change on that list, and the largest. An organisation that meets it with the same incident-by-incident approach will pay for the same discovery work again, at greater scale and under externally imposed transition deadlines. The argument that PQC stands on its own without a quantum computer is set out in PQC Is Not About the Quantum Computer. The argument here is wider: every one of these changes draws on the same missing capability.

Cryptographic modernisation replaces the cycle with a capability. The organisation knows what cryptography it runs, who owns each part, how it is replaced and what evidence proves it was replaced. The next change becomes a scheduled activity. This is what cryptographic agility means in operational terms: the ability to change cryptography on the organisation's timetable rather than an external one.


The investment case for the board, the CFO and the CRO

The case does not rest on predicting a quantum computer. It rests on five costs the organisation already carries.

Incident cost: IBM's 2025 Cost of a Data Breach report put the global average cost of a breach at $4.44 million and the US average at $10.22 million. Cryptographic failures are rarely the whole cause, but as Equifax shows, they can remove the control that limits the damage.

Outage cost: certificate expiries stop revenue-bearing services. The cost is the value of the service multiplied by the time it takes to find the failed certificate, and that time depends on the quality of the inventory, how far renewal is automated and how quickly a replacement can be deployed.

Forced-change cost: every external decision, whether a browser distrusting an authority, a root expiring or a standard being withdrawn, triggers an unplanned project. Without an inventory, the first and largest part of each project is finding out what is affected.

Assurance cost: regulators, auditors and acquirers increasingly ask for evidence of cryptographic control. An organisation that cannot produce it pays in findings, delayed deals, higher remediation estimates and, as Marriott found, penalties.

Insurance cost: cyber insurers increasingly price and grant cover against specific security controls, and the application asks the organisation to state which controls are in place. An organisation that cannot evidence its cryptographic controls either pays for weaker terms or signs a declaration it cannot support.

Modernisation converts those recurring, unplanned costs into a planned programme with a defined scope. The CRO gains a risk that can be measured and reported. The CFO gains a cost that can be forecast across budget cycles. The board gains an answer to a question it will be asked: how quickly can this organisation change its cryptography when it is told to?


Insurance is not the backstop boards assume

Boards often treat cyber insurance as the answer to the residual risk. For failures of basic control, that assumption does not hold reliably.

Cover depends on the declarations made when the policy was bought. In 2022 Travelers asked a US federal court to rescind a $1 million cyber policy issued to International Control Services after a ransomware attack, alleging that the application had stated multi-factor authentication was in place across systems when it protected only the firewall. In August 2022 ICS agreed that the policy should be rescinded and treated as void from inception, and the court entered judgment on that basis on 30 August 2022. In an earlier case, Columbia Casualty sought to deny cover to Cottage Health after a breach of patient records, relying on an exclusion for failure to follow the minimum security practices set out in the application. Cottage Health had already paid $4.125 million to settle the resulting class action.

Exclusions are also widening. From 31 March 2023 Lloyd's required standalone cyber policies written in its market to include exclusions addressing war and certain state-backed cyber attacks, including attacks that significantly impair a state's functioning or security capabilities.

The pattern is consistent. A breach that follows from an expired certificate, an unmanaged key or a weak algorithm the organisation said it had controlled is precisely the kind of claim an insurer will test against the application. Whether a given policy pays depends on its wording and the facts. The cryptographic answers on an insurance application are representations, and they need the same independent evidence as any other.


Fiduciary exposure sits with the board

Directors cannot delegate oversight of a risk this central. In the UK, the Companies Act 2006 requires directors to exercise reasonable care, skill and diligence. In the US, the Securities and Exchange Commission's 2023 rules require listed companies to disclose material cyber incidents within four business days of determining materiality, and to describe each year how the board oversees cyber risk.

The Delaware Court of Chancery dismissed a shareholder claim against Marriott's directors in October 2021, but it described cyber risk as a consequential risk across business sectors that calls for board-level monitoring. The bar for personal liability remains high. Personal liability can arise where a board has no oversight system at all or ignores known red flags. A board that has never asked who owns the organisation's cryptography, or what its certificates and keys protect, will find that question hard to answer after an incident, in front of a regulator, an insurer or its own shareholders.


What cryptographic modernisation involves

Modernisation is a management programme with technical delivery, not a technology purchase. It has five parts.

  1. Ownership: one executive, preferably the CRO, accountable for cryptographic risk across the enterprise, with authority over technology, procurement and suppliers.

  2. Inventory: a maintained record of algorithms, keys, certificates, libraries and protocols, with owners, dependencies and the data each protects. The record states how it was compiled and what it does not cover.

  3. Policy: approved algorithms, key lengths, certificate lifetimes and retirement dates, written down and applied to new systems and new contracts.

  4. Lifecycle: automated issuance, renewal and replacement for certificates and keys, so that expiry and distrust events become routine rather than urgent.

  5. Evidence: continuous proof that the policy is applied, in a form an auditor, regulator or acquirer can test. Activity is not evidence, as argued in What Evidence Actually Proves a PQC Migration Is Good.

The Cryptographic Transformation and Modernisation methodology structures these five parts into governed levels, from executive mandate to continuous evidence, with gates that prevent progression without validated evidence. It is measured against the Quantum Cryptographic Assurance Standard (QCAS).


What the board should ask for

  1. The name of the executive accountable for cryptographic risk, and the authority they hold.

  2. The number of certificates the organisation depends on, how many expire in the next 90 days, and how they are renewed.

  3. How long it would take to replace every certificate from one certificate authority if a browser distrusted it tomorrow.

  4. Which systems depend on cryptographic modules whose validation status changed in September 2026.

  5. Whether cryptography is part of due diligence in every acquisition, and who signs off the finding.

  6. Whether every cryptographic control declared on the cyber insurance application is in place and evidenced.

  7. A costed modernisation plan across budget cycles, with the post-quantum migration shown as part of it rather than as a separate programme.

  8. The evidence, not the assurance, that each of the above is true.

A board that cannot get clear answers to the first three questions is running its cryptography by exception. The PQC Readiness Assessment tests those answers independently, and the common ways programmes go wrong are set out in The PQC Baker's Dozen.


The case in one line

Organisations already pay for unmanaged cryptography, in breaches it did not detect, outages it did not schedule and changes it did not choose. Cryptographic modernisation decides whether that cost keeps arriving as a series of surprises or is managed as a programme the board can see.


About the author

Brian Couzens is CEO of SITG-Consulting, an independent advisory firm working on post-quantum cryptography governance, cryptographic risk and board-level assurance across financial services, critical infrastructure and government. SITG-Consulting is vendor-independent and holds no product vendor partnerships.


Sources

Comments


bottom of page