Most organisations cannot answer a simple question: Where do we use cryptography?
That is not because they are careless. It is because cryptography is designed to disappear into the background.
When it works, nobody thinks about it.
- A customer logs into a portal.
- A payment system connects to a bank.
- A staff member opens a VPN.
- A supplier accesses an API.
- A software update is verified.
- A document is signed.
- A website shows a padlock.
- A cloud service encrypts data in transit.
Everyday business continues, and cryptography quietly supports trust underneath it.
But post-quantum transition changes the equation.
Future quantum computers may weaken or break some of today’s widely used public-key cryptography. NIST finalised its first three post-quantum cryptography standards in August 2024: FIPS 203 for ML-KEM key establishment, FIPS 204 for ML-DSA digital signatures, and FIPS 205 for SLH-DSA digital signatures. These standards address key establishment and digital signatures, which sit behind many ordinary digital trust functions.
For Australian organisations, the planning issue is already concrete. The Australian Signals Directorate recommends ceasing use of traditional asymmetric cryptography by the end of 2030, including RSA, DH, ECDH and ECDSA primitives.
The problem is this: You cannot transition what you cannot find.
That is why a cryptographic inventory is the first step most organisations have not taken.
What is a Cryptographic Inventory?
A cryptographic inventory is a structured record of where and how an organisation uses cryptography.
In plain English, it helps answer:
- What systems use encryption, certificates, signatures or secure key exchange?
- Which algorithms and protocols are in use?
- Which systems protect sensitive or long-life data?
- Which vendors control cryptographic functions?
- Which applications, APIs and integrations depend on certificates or public-key cryptography?
- Which systems will be easy to update, and which may be difficult?
- Which dependencies are unknown?
It is not only a list of certificates.
It is not only a list of encryption products.
It is a visibility tool for digital trust.
A good inventory helps leadership understand where cryptography supports confidentiality, identity, access, signatures, secure connections, software integrity and business continuity.
Why most organisations don't have one:
Most organisations have asset registers, software lists, vendor lists, cloud inventories, risk registers and security policies.
Those are useful. But they are not the same as a cryptographic inventory.
An IT asset register may say: “Customer portal.”
A cryptographic inventory asks: “Which certificates, protocols, identity flows, key-exchange mechanisms, APIs, libraries, vendors and signed tokens does the customer portal rely on?”
A vendor register may say: “Payment provider.”
A cryptographic inventory asks: “Which cryptographic functions does the payment provider control, what is their PQC roadmap, and what customer-side changes may be required?”
A system diagram may show: “Application connects to database.”
A cryptographic inventory asks: “Is the connection encrypted? Which protocol is used? Who manages the keys or certificates? Does the application use outdated libraries? Is there certificate pinning? Would a cryptographic change break the connection?”
That is why the inventory is often missing. Existing records describe business systems. They rarely describe the cryptographic trust mechanisms inside and between them.
Why this matters for PQC readiness
Post-quantum cryptography is not a single product upgrade.
It is a transition across systems, vendors, protocols, certificates, identity platforms, signed records, software updates, applications and infrastructure.
CISA, NIST and NSA have urged organisations to begin early planning for migration to PQC standards, including preparing a cryptographic inventory, engaging technology vendors and assessing supply-chain reliance on quantum-vulnerable cryptography.
That recommendation is practical.
Without an inventory, an organisation cannot reliably answer:
- Which systems rely on RSA, DH, ECDH, ECDSA or related traditional asymmetric cryptography?
- Which systems use digital signatures that must remain trustworthy?
- Which systems protect data that must stay confidential for years?
- Which APIs, certificates or VPNs will require changes?
- Which vendors are transition blockers?
- Which systems should migrate first?
- Which changes may create outage or interoperability risk?
The first step is not to panic.
The first step is visibility.
What should be included in a cryptographic inventory?
The exact scope depends on the organisation, but a practical inventory should cover the major places where cryptographic trust appears.
1. TLS, certificates and secure websites
Most organisations use HTTPS across websites, portals, intranets, APIs, dashboards and SaaS integrations.
The inventory should identify:
- domains and endpoints;
- certificate authorities;
- certificate owners;
- renewal processes;
- algorithms used;
- TLS versions and configurations;
- certificate pinning;
- internal and external endpoints;
- systems likely to break if certificate requirements change.
This matters because certificates are both security controls and operational dependencies. Poorly understood certificate changes can create outages.
2. APIs and system-to-system communication
APIs often carry the organisation’s most important operational data.
They may support payments, bookings, customer records, memberships, identity checks, supplier workflows, reporting, claims, approvals or document exchange.
The inventory should identify:
- internal APIs;
- external APIs;
- vendor APIs;
- authentication methods;
- signed requests;
- tokens;
- API keys;
- mutual TLS;
- service accounts;
- data sensitivity;
- systems dependent on each connection.
This is especially important where APIs connect customer-facing systems to back-office platforms or third-party providers.
3. Identity and access-control systems
Access control is where cryptography meets business authority.
The inventory should identify:
- identity providers;
- single sign-on systems;
- multi-factor authentication infrastructure;
- signed tokens or assertions;
- privileged-access systems;
- administrator access pathways;
- certificate-based authentication;
- service accounts;
- vendor access mechanisms;
- systems where access logs are business-critical.
PQC transition is not only about secrecy. It is about whether the organisation can continue to prove who accessed, approved, signed, changed or administered something.
4. VPNs, remote access and secure administration
Remote access systems often rely on public-key cryptography for authentication, secure key exchange and protected communication.
The inventory should identify:
- VPNs;
- SD-WAN tunnels;
- remote desktop gateways;
- privileged administration tools;
- third-party support channels;
- SSH usage;
- keys and certificates;
- vendor-managed access;
- legacy or unsupported configurations.
These systems deserve priority because they often provide access to sensitive environments.
5. Digital signatures and document workflows
Digital signatures are used to prove authenticity and integrity.
They may appear in:
- contracts;
- approvals;
- board papers;
- audit evidence;
- legal records;
- procurement documents;
- financial authorisations;
- software releases;
- identity checks;
- compliance records.
The inventory should identify which signatures must remain trustworthy long-term.
NIST notes that digital signature schemes are used to detect unauthorised modifications to data and authenticate the identity of the signatory.
That makes digital signatures a trust issue, not merely a technical detail.
6. Software updates and code-signing
Software updates depend on trust.
Organisations need confidence that code, packages, firmware, mobile apps, container images or deployment artefacts have not been tampered with.
The inventory should identify:
- code-signing certificates;
- signing keys;
- build pipelines;
- software update mechanisms;
- firmware update processes;
- third-party libraries;
- mobile application signing;
- container signing;
- deployment tools;
- systems relying on signed updates.
For software providers and organisations with bespoke systems, this is a high-priority area.
7. Data-at-rest encryption, backups and archives
Not all post-quantum risk is about live traffic.
Some of the most damaging exposure may involve data captured now and decrypted later.
The inventory should identify:
- encrypted databases;
- file stores;
- backups;
- archives;
- document repositories;
- long-term records;
- key-management systems;
- retention periods;
- data that must remain confidential for years.
This is where the “harvest now, decrypt later” risk becomes practical. The organisation needs to know whether the confidentiality life of data exceeds the expected safe life of the cryptography protecting it.
8. Cloud, SaaS and vendor-controlled systems
Many cryptographic functions are controlled by vendors.
The inventory should identify:
- cloud providers;
- SaaS platforms;
- identity providers;
- payment providers;
- managed service providers;
- certificate authorities;
- cybersecurity tools;
- payroll and HR systems;
- CRM and document platforms;
- vendor roadmaps;
- customer-side configuration responsibilities;
- evidence gaps.
Vendor dependency is not a reason to wait. It is a reason to ask better questions.
9. Bespoke and legacy applications
Bespoke and legacy systems are often the hardest to assess and transition.
The inventory should identify:
- old cryptographic libraries;
- hard-coded algorithms;
- certificate pinning;
- outdated protocols;
- custom authentication logic;
- undocumented key handling;
- fragile integrations;
- unsupported platforms;
- systems where access-control logic is embedded in application code;
- systems that may require redevelopment rather than configuration changes.
These systems can become transition blockers if left until late.
What a useful inventory should tell leadership
A cryptographic inventory should not be a technical spreadsheet that only one person understands.
For leadership, it should answer five business questions.
1. What have we found?
Which systems, vendors, certificates, APIs, identity flows, signatures and data stores are known to rely on cryptography?
2. What matters most?
Which dependencies protect long-life sensitive data, customer-facing services, business-critical workflows, privileged access or trusted records?
3. What is still unknown?
Which systems, vendors or legacy applications require deeper review?
4. Who controls the dependency?
Is the cryptographic function controlled by the organisation, a vendor, a cloud provider, a SaaS platform, a managed service provider or a legacy product?
5. What should happen next?
Which systems require analysis, vendor engagement, remediation planning, migration sequencing or implementation support?
This is where the inventory becomes a management tool.
What might a PQC readiness evidence pack contain?
Organisations do not need a hundred-page document filled with cryptographic terminology.
They need a defensible body of evidence.
A useful starting pack might contain:
- Cryptographic inventory
A current view of where relevant cryptography is used across applications, infrastructure, protocols, certificates, identities, hardware, third-party services and embedded systems.
- Quantum-risk assessment
An assessment of which systems and information are materially exposed, including information with long confidentiality requirements.
- Dependency map
Identification of vendors, platforms and hardware whose PQC capabilities affect your own migration.
- Prioritisation model
Clear criteria explaining why some systems need action sooner than others.
- Transition roadmap
What will be upgraded, replaced, retired, redesigned or monitored — and approximately when.
- Cryptographic-agility strategy
Evidence that systems are being designed or modernised so cryptographic algorithms can be changed without another major architectural intervention.
- Governance
Named ownership, reporting arrangements and decision-making responsibilities.
- Standards position
The recognised standards and authoritative guidance against which your programme is being developed.
- Testing and implementation evidence
As migrations begin, records demonstrating that new implementations have been properly tested rather than simply enabled.
- Customer assurance statement
A concise, carefully worded explanation of your organisation’s PQC position that customer-facing teams can use consistently.
Notice what this does.
It converts:
“We are looking at quantum risk.”
into:
“We understand our exposure, we know our dependencies, we have prioritised the work, and here is the evidence supporting our position.”
That is a much stronger trust proposition.
Common mistakes to avoid:
Mistake 1: Treating the inventory as a one-off spreadsheet
A cryptographic inventory should become a living record. Systems change. Certificates renew. Vendors update platforms. New integrations appear. Legacy systems persist longer than expected.
Mistake 2: Looking only at encryption
PQC affects more than encrypted data. It also affects identity, signatures, certificates, secure connections, software integrity, APIs and trusted workflows.
Mistake 3: Waiting for perfect technical detail
The first inventory does not need to be perfect. It needs to be useful enough to prioritise risk and identify gaps.
Mistake 4: Ignoring vendors
Many dependencies are outside direct control. Vendor roadmaps, product support, customer configuration and assurance evidence must be tracked.
Mistake 5: Failing to link cryptography to business impact
A list of algorithms is not enough. The organisation must know what business process, data category or trust function depends on them.
Why leaders should not wait
There are three reasons to start before migration pressure arrives.
First, discovery takes longer than expected
Cryptography is embedded across systems. Some dependencies are easy to find. Others sit inside applications, vendor platforms, legacy systems or old integrations.
Second, vendors move at different speeds
Some vendors will publish clear PQC roadmaps. Others will not. Some will require customer action. Some products may not transition cleanly.
Third, transition can create operational risk
Changing certificates, protocols, libraries or trust mechanisms can affect availability, interoperability, performance, access control and customer experience.
A good inventory reduces the chance of rushed decisions later.
The Ariadne View
Ariadne’s view is simple:
PQC readiness starts with finding the cryptography your organisation already relies on.
This means creating enough visibility to make disciplined decisions, not entirely replacing everything.
Ariadne helps organisations with:
- PQC readiness snapshots;
- governance and discovery;
- cryptographic inventory development;
- sensitive-data and confidentiality-life mapping;
- vendor dependency review;
- access-control and identity workflow review;
- PQC exposure analysis;
- strategy and transition planning;
- secure software modernisation for complex systems;
- private AI knowledge systems to organise assessment evidence and transition documentation.
Our goal is to help leadership move from uncertainty to practical readiness.
The Practical Conclusion
A cryptographic inventory is not just an IT exercise. It is the foundation for post-quantum readiness, business continuity, vendor assurance, board reporting and customer trust.
Without it, organisations are left relying on assumptions:
- “We think our vendors will handle it.”
- “We think our systems are standard.”
- “We think our data is protected.”
- “We think nothing critical depends on old cryptography.”
Those assumptions may be wrong.
The better position is evidence:
- “We know where cryptography is used.”
- “We know which systems matter most.”
- “We know which vendors control key dependencies.”
- “We know what remains unknown.”
- “We know what to do next.”
That is where PQC readiness begins.
Ariadne Thread Solutions helps organisations start with a PQC Readiness Snapshot: a structured first-stage review covering governance, discovery, sensitive data categories, vendor dependencies and likely cryptographic touchpoints.
Not sure where PQC touches your access-control systems?
Start with visibility.
Ariadne’s PQC Readiness Snapshot helps leadership identify sensitive data, critical systems, vendor dependencies and cryptographic touchpoints before transition decisions become urgent.
