Shadow Cryptography: The Estate Nobody Signed For

Brian Couzens

1 hour ago

14 min read

Shadow cryptography as an estate blueprint: a teal beam lights one wing of keys and certificates; red ones lie in the dark rooms.

Shadow cryptography: what discovery tools cannot see, why that is a governance failure before it is a technical one, and how to remediate it before a post-quantum cryptography migration is scoped on an incomplete record.

On 6 December 2018, a certificate inside Ericsson core network software expired. From about 04:45, O2's mobile data service in the United Kingdom was down. The network carried around 32 million users at the time, including customers of virtual operators such as Tesco Mobile, Sky Mobile and giffgaff. 4G service was not fully restored until after 03:00 the following morning. SoftBank in Japan lost service to the same fault on the same day.

Ericsson's statement identified the cause as an expired certificate in the software versions installed with the affected customers. The certificate was not one O2 had issued. It sat inside a supplier's software, performing a function that the operator depended on and did not administer.

That is shadow cryptography in its plainest form: cryptography an organisation depends on, that carries operational and security consequence, and that sits outside the knowledge and control of the people accountable for the organisation's risk.

This article sets out what the term means, why discovery tools miss it, why it decides the outcome of a post-quantum cryptography (PQC) migration, and what a credible remediation approach looks like.

What shadow cryptography means

The name borrows from shadow IT, the long-standing label for technology bought or built by business units without the knowledge of the central IT function. The borrowed word carries a specific meaning. Shadow does not mean hostile, and it does not mean concealed on purpose. It means outside the line of sight of governance.

Shadow cryptography is any key, certificate, algorithm, protocol or cryptographic library that an organisation relies on but cannot account for through its inventory, its ownership model or its control process. It takes three forms.

Unrecorded: in use, and absent from the organisation's record of its cryptographic estate.
Unowned: present in the record, with no named owner answerable for it.
Uncontrolled: dependent on a supplier, cloud account, application or environment outside the organisation's effective control.

The O2 certificate is an example of the third form. Its supplier knew it existed, and that knowledge gave O2 no control over it. A developer who generated a self-signed certificate to meet a deadline creates shadow cryptography. So does the procurement team that buys an appliance without asking what cryptography it contains, and the platform team whose build pipeline issues signing keys that no register records.

Two points follow from the definition. The first is that shadow cryptography is created by ordinary work, at the speed of ordinary work. It is a by-product of delivery, so it will keep being produced unless the conditions that produce it change. The second is that it is defined relative to the record. Cryptography is in shadow because the inventory does not hold it, nobody answers for it, or the organisation cannot control it. That makes it a failure of governance and evidence before it is a failure of technology.

Four limits on what a discovery tool can see

Automated discovery tools are necessary. A large estate cannot be surveyed by hand. The error is to treat the output of a tool as the estate. A tool reports what it was able to observe, and four limits govern that.

The first limit is reach. A network scanner sees a handshake and a certificate. It does not see the key hard-coded in the application behind the listener, or the library bundled inside a container image. A source code scanner sees the code it was pointed at. It does not see the compiled binary supplied by a third party. Each technique has a field of view, and no single technique covers all of them. The preliminary practice guide on cryptographic discovery from the US National Institute of Standards and Technology (NIST) reflects this. It treats discovery across three separate areas: the code development pipeline, operational systems and applications, and transport protocols and network services. Its worked scenario concludes that multiple products may be necessary.

The second limit is permission. A tool inspects only what it has been authorised to inspect. A cloud account opened outside the corporate tenancy, a business unit that declined the agent, a supplier-operated appliance and a software-as-a-service platform all sit beyond its credentials. The organisation depends on the cryptography in each of them without any right to examine its configuration.

The third limit is time. A scheduled scan describes the moment it ran. A container that lived for ninety seconds, a serverless function, a short-lived certificate and a key generated at runtime can all be created and destroyed between two scans. In an estate built on automation, transience is designed in.

The fourth limit is meaning, and it is the one that additional coverage cannot close. A tool can report that a 2048-bit RSA key exists on a host. It cannot report what data that key protects, how long that data must remain confidential, who owns the system, or whether the business could tolerate its replacement. Without those facts the finding cannot be prioritised, and an unprioritised finding does not change a migration plan.

Where shadow cryptography sits

Shadow cryptography collects in three places.

The first is inside artefacts: cryptography embedded in things that are built, bought or configured.

Hard-coded private keys, secret keys and certificates in source code and configuration files, and the access credentials stored beside them
Cryptographic libraries bundled into applications and container images, including those pulled in by dependencies nobody selected
Application-specific and home-built encryption
Firmware in devices and appliances
Proprietary protocols
Scripts and automation that call cryptographic functions directly

Toyota's disclosure of October 2022 shows the consequence. A website development contractor had uploaded part of the source code for the T-Connect service to a public GitHub repository in December 2017. The code contained an access key to a data server. The key stayed exposed until 15 September 2022, and Toyota reported that email addresses and customer control numbers for 296,019 customers were potentially accessible for that period. A network scan of Toyota's estate would not have found that key. It was in an artefact held by a third party. The key was an access credential rather than an algorithm. The lesson concerns where it sat, and it is the reason secrets scanning belongs in a cryptographic discovery programme.

The second is outside managed boundaries: cryptography the organisation relies on but does not administer.

Software-as-a-service platforms
Cloud accounts opened outside central control
Supplier-operated appliances and managed services
Partner integrations
Mobile and client-side applications
Isolated operational technology and air-gapped environments
Systems owned by a department instead of the central function

The O2 outage belongs here.

The third is transient environments: cryptography that exists briefly.

Short-lived containers and serverless functions
Temporary and automatically issued certificates
Keys generated at runtime
Test and development environments created on demand

The window is narrowing for publicly trusted certificates. The CA/Browser Forum, the body that sets the rules for publicly trusted certificates, has adopted a schedule that cuts the maximum validity of a public Transport Layer Security (TLS) certificate from 398 days to 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. A publicly trusted certificate that nobody tracks now expires sooner, and the renewals that keep it in service come round more often. The schedule does not govern private certificate authorities.

Why shadow cryptography decides a PQC migration

A PQC migration replaces the public-key algorithms that a sufficiently capable quantum computer could break, principally RSA and elliptic curve schemes, with the post-quantum algorithms NIST standardised in August 2024. Replacement requires a list of where the vulnerable algorithms are. Shadow cryptography is, by definition, what the list omits.

The consequences are specific.

Scope is understated, so budget and duration are understated with it.
Systems are reported as migrated while vulnerable cryptography continues to run inside them or beside them.
Dependencies surface during cutover, when a migrated system fails to interoperate with something nobody knew it spoke to.
Supplier constraints appear late: a product with embedded cryptography and no upgrade path, found after the contract has renewed.
Risk assessments rest on an incomplete denominator.
Evidence presented to auditors and supervisors describes the known estate and is offered as a description of the whole.

The timing problem compounds this. Michele Mosca's formulation is the standard reference. If the time data must remain confidential, added to the time needed to migrate, exceeds the time until a cryptographically relevant quantum computer exists, the data is already exposed, because encrypted traffic can be collected today and decrypted later. The attack is known as harvest now, decrypt later. Undiscovered cryptography lengthens migration time without appearing in the plan. It also hides the long-lived data that sets the confidentiality requirement in the first place.

What regulators and standard setters now expect

Precision matters here, because the instruments differ in force.

In the United Kingdom, the National Cyber Security Centre published migration timelines on 20 March 2025. They are guidance, not law. The first milestone asks organisations to carry out a full discovery exercise and build an initial migration plan by 2028, with the highest-priority migration activity by 2031 and completion by 2035.

In the United States, Executive Order 14412 of 22 June 2026 binds federal agencies, not private firms. It requires agencies to move their high value assets and high impact systems to PQC for key establishment by 31 December 2030 and for digital signatures by 31 December 2031. It directs the Cybersecurity and Infrastructure Security Agency, working with NIST, to publish guidance within 270 days on the minimum elements of a Cryptographic Bill of Materials (CBOM). It also directs a proposed procurement rule that would require covered federal contractors to comply by 31 December 2030 with NIST's Federal Information Processing Standards, including those that specify post-quantum algorithms. Suppliers to the US government should read that as notice.

In the European Union, the Digital Operational Resilience Act (DORA), the resilience law for financial entities, has applied since 17 January 2025. DORA's technical standard on information and communications technology (ICT) risk management requires a policy on encryption and cryptographic controls that provides for changing cryptographic technology in response to developments in cryptanalysis. It also requires a register of all certificates and certificate-storing devices for at least the ICT assets that support critical or important functions, kept up to date.

In payment card environments, version 4.0.1 of the Payment Card Industry Data Security Standard (PCI DSS) requires an up-to-date inventory of the cryptographic cipher suites and protocols in use, reviewed at least once every twelve months, with a documented strategy for responding to anticipated changes in cryptographic vulnerabilities. That requirement became mandatory on 31 March 2025.

The instruments differ in scope, but each assumes that the record it depends on is current and fit for its purpose. A register that omits shadow certificates does not satisfy a requirement to register all certificates. An inventory that covers only what one tool could see is not an inventory of what is in use.

The governance failure underneath

Discovery, inventory and CBOM are used interchangeably in a good deal of current commentary. They are different things, and the difference matters to this problem. The distinction is set out in more detail in Discovery Is Table Stakes for PQC. A CBOM Is Not Discovery.

Discovery is the activity that establishes the as-is state of the cryptographic estate. An inventory is the maintained record of that state. A CBOM is a structured format in which the record, or part of it, can be expressed and exchanged. A CBOM generated from the output of a single tool inherits each blind spot of that tool and presents the result in a format that looks complete. The format adds no assurance. The assurance comes from knowing how the record was assembled and what it does not cover.

That leads to ownership. Shadow cryptography persists where nobody is accountable for the completeness of the record. A security team can operate scanners. It cannot compel a business unit to declare its cloud accounts, require procurement to change contract terms, or decide how much residual unknown the enterprise will accept. Those are enterprise risk decisions. PQC transformation is an enterprise risk programme, and its accountable owner should be the Chief Risk Officer, with security, technology, procurement and the business lines as contributors. Assigning it to the Chief Information Security Officer alone places an enterprise-wide accountability on a function that controls only part of the estate.

Three questions test whether ownership exists.

Who signs the statement that the cryptographic inventory is complete enough to scope the migration?
What does that statement say about the parts of the estate that were not examined?
When an unknown cryptographic asset is found, who becomes its owner, and within how many days?

Where those questions have no answer, the organisation has a tooling output and no inventory.

Remediation, part one: bringing shadow cryptography into the record

Remediation has two parts. The first brings shadow cryptography into the record. The second treats what has been found. The first part answers the four limits in turn.

The reach gap closes by using more than one method for each part of the estate, and by choosing methods whose blind spots differ.

Static analysis of source code, for cryptographic calls, hard-coded keys and home-built implementations
Software composition analysis, for libraries introduced through dependencies
Binary and container image analysis, for software where the source is unavailable
Secrets scanning across repositories, including their history, and across configuration stores
Passive observation of network traffic, for the protocols and cipher suites that are negotiated in practice
Enumeration of certificate stores, key management services and hardware security modules across each account and region
Firmware review for devices and appliances, carried out with the supplier where the organisation cannot do it alone

The sources are then reconciled against each other. Certificates observed on the network that are absent from the issuing authority's records are shadow certificates. Hosts present in network observation and absent from the asset register are shadow systems. Publicly trusted certificates issued for the organisation's domains can be checked against Certificate Transparency logs, the public record of issuance, to find those nobody requested through the sanctioned route. The discrepancies between sources are the finding.

The permission gap closes through contract and mandate, because the tool cannot go there.

Require suppliers to disclose the cryptography in their products and services, in a structured format, as a condition of purchase and renewal. Buying without that disclosure is buying cryptographic debt.
Require a dated PQC roadmap from each supplier of a product with embedded cryptography, and record the absence of one as a risk.
Secure notification rights for cryptographic changes and for certificate expiry inside supplied products. The O2 outage is the argument for that clause.
Bring cloud accounts under organisation-level control, so that an account cannot exist outside the policy that governs key management and logging.
For operational technology and air-gapped environments, plan a manual survey with the engineers who run them, and budget for it as fieldwork.
Give the programme a mandate, issued at executive level, that removes the option to decline participation.

The time gap closes by governing the point of creation. A periodic scan cannot inventory assets that live for minutes.

Issue short-lived certificates only from managed certificate authorities, with issuance logged. The record is then the issuance log, and each individual certificate does not need to be found.
Apply policy where infrastructure is defined and admitted: infrastructure-as-code checks and container admission controls that reject non-compliant algorithms and key sizes before a workload starts.
Add cryptographic checks to the build pipeline, so that a deprecated algorithm or an embedded key stops the build.
Use runtime observation on critical hosts to record which cryptographic libraries are loaded and called.
Move from scheduled scanning towards event-driven recording, in which the creation of a key or certificate writes to the inventory at the moment it happens.

The meaning gap closes only through people. This part cannot be automated.

Interview system owners, developers, operations staff and suppliers to confirm what each cryptographic asset protects and what depends on it.
Attach to each asset a named owner, the classification of the data it protects and the period for which that data must stay confidential.
Offer a declaration window in which teams can report unsanctioned cryptography without penalty. A team that expects a penalty for disclosure will not disclose.
Record the cause of each shadow asset found. If self-signed certificates appear because the sanctioned issuance process takes three weeks, the remedy is a faster process.

Remediation, part two: treating what is found

Once an asset is in the record, it needs a disposition. Six are available, and each should be a recorded decision with an owner and a date.

Migrate: replace the vulnerable algorithm with a standardised post-quantum algorithm, or with a hybrid of classical and post-quantum algorithms where the relevant national guidance calls for one. Key establishment protecting long-lived confidential data comes first, because that data is exposed to collection now.
Retire: some shadow cryptography protects things that should no longer exist, such as abandoned test environments, superseded interfaces and decommissioned services with live certificates. Removal costs less than migration and reduces the estate permanently.
Rotate and relocate: a hard-coded or exposed key should be treated as compromised. Replace it, and place its successor in a key management service or hardware security module where it has an owner, an access record and a rotation schedule.
Replace: home-built encryption and unsupported libraries should give way to vetted, maintained libraries called through a common interface, so that the next algorithm change is a configuration change. That is the practical meaning of cryptographic agility.
Isolate: where a system cannot be upgraded, as is common in operational technology and supplier-controlled appliances, contain it. Segment the network, terminate vulnerable protocols at a controlled gateway that uses post-quantum algorithms on the exposed side, and limit the data that crosses it. Record the trust boundary this creates. Traffic behind the gateway remains classical, and the gateway becomes a point of concentration that needs its own protection.
Accept, with an expiry: some assets will remain vulnerable for a period. That is a legitimate decision when it is made by the risk owner, recorded in an exception register, tied to compensating measures and given an end date. It is not legitimate when it is made by omission.

Keeping it from coming back

Discovery that is run once describes a single day. The conditions that created the shadow estate will recreate it unless they change.

Procurement language that makes cryptographic disclosure and a PQC roadmap standard terms
A sanctioned route for obtaining certificates and keys that is faster than the unsanctioned one
Pipeline and admission controls that prevent new non-compliant cryptography from reaching production
A rule that no cryptographic asset enters production without a named owner
A coverage statement, maintained with the inventory, that records for each part of the estate which methods were applied, when, and what was not examined
Reporting to the risk committee on a small set of measures: the proportion of the inventory with a named owner, the number of previously unknown assets found in the period, the time taken to assign an owner to each, and the number and age of open exceptions
Periodic independent challenge of the inventory by a party that did not compile it, such as a thematic review that tests how cryptographic risk behaves across the whole estate

The coverage statement deserves emphasis. An inventory that states its own gaps can be relied upon within those limits. An inventory that claims completeness gives its reader no means of testing the claim.

Questions for the board

A board or risk committee does not need to understand lattice mathematics to test this. Its concern is whether management can defend the completeness of the evidence used to approve investment, accept residual risk and report migration progress. Seven questions test that.

Which executive is accountable for the completeness of the cryptographic inventory?
Which methods were used to compile it, and which parts of the estate did each method not reach?
How much of the inventory has a named owner and a data confidentiality period attached?
Which suppliers have disclosed the cryptography in their products, and which have declined?
How are cryptographic assets that exist for minutes recorded?
How many previously unknown cryptographic assets were found in the last quarter, and what does the trend say about what remains?
What is in the exception register, who approved each entry, and when does each expire?

An organisation that can answer these has a basis for scoping a migration. An organisation that cannot is planning against a record it has no grounds to trust. The evidence that should sit behind those answers is set out in What Evidence Actually Proves a PQC Migration Is Good.

The position

A discovery tool that cannot see a cryptographic asset has not reduced the risk attached to it. The asset still protects data, still depends on an algorithm with a finite life, and can still fail when its certificate expires. What the tool's silence changes is the organisation's knowledge, and a migration scoped on that knowledge may be reported as complete while vulnerable cryptography remains in the estate, the supply chain or a transient workload.

A better scanner will not supply what is missing. The remedy is an owned record: assembled by several methods, explicit about its gaps, extended by contract into the supply chain, and maintained by controls at the points where cryptography is created. That is governance work, and it sits with the executive who owns enterprise risk.

About the author

Brian Couzens is CEO of SITG-Consulting, an independent consulting and advisory firm working on post-quantum cryptography governance and transformation, cryptographic risk and quantum risk management. The PQC Discovery Sprint is SITG-Consulting's structured engagement for establishing cryptographic visibility across an estate.

SITG-CONSULTING