Find the crypto you cannot afford to discover too late

A post-quantum cryptography audit turns scattered TLS settings, certificates, signed updates, libraries, appliances and supplier claims into a defensible migration plan. Start with the data and trust chains whose confidentiality or authenticity must outlive today's public-key algorithms.

See the transition status Scope a crypto inventory

The standards are ready. Your estate probably is not.

NIST finalised FIPS 203, FIPS 204 and FIPS 205 in August 2024: ML-KEM for key establishment, ML-DSA for general digital signatures and SLH-DSA as a signature alternative. That does not make every protocol, certificate authority, hardware security module, embedded device or partner integration ready to use them.

Signal	What it means on 4 September 2026	Practical response
NIST PQC standards	Final technical standards, not an EU legal obligation	Use them as a selection baseline; validate the exact implementation and protocol profile in your environment.
Commission Recommendation (EU) 2024/1101	Non-binding recommendation for coordinated Member State action	Treat it as a strategic signal, not a universal private-company deadline.
June 2025 EU roadmap	High-level roadmap aimed at Member States; start transitioning by end-2026 and protect high-risk use cases by end-2030	Map its milestones to your sector, national plan, contracts and long-lived-data risk.
Store-now, decrypt-later exposure	A present risk where intercepted data must remain confidential beyond the arrival of a cryptographically relevant quantum computer	Prioritise archives, sensitive traffic, keys and records with a long confidentiality lifetime.
Supplier capability	Often unknown until it blocks a protocol, PKI, appliance, firmware or SaaS change	Collect version-specific roadmaps, supported modes, dependencies, test evidence and target dates.

The Commission's PQC policy page describes the roadmap as a high-level paper for Member States. It is useful context for EU operators, especially those serving public utilities, but it is not a substitute for a sectoral or national legal assessment. The audit method on this page is Yarify's implementation recommendation.

Inventory public-key use, not just cipher names

The joint CISA, NSA and NIST guidance recommends a cryptographic inventory across IT and OT, including network protocols, end-user and server assets, applications, libraries, firmware and the delivery pipeline. Discovery tooling is a useful input; it cannot see every embedded or managed implementation.

Traffic and service edges

TLS termination, mutual TLS, VPNs, email transport, API gateways, service meshes, remote administration and partner connections.

Trust and identity

Public-key infrastructure, certificate authorities, certificate lifecycles, OCSP, identity providers, token signing, SSH and code-signing keys.

Products and updates

Firmware signing, secure boot, device provisioning, mobile applications, embedded libraries, field gateways and long-lived deployed devices.

Data and records

Encrypted archives, backups, regulated documents, medical or financial data, legal records and secrets with long confidentiality requirements.

Platforms and dependencies

Cloud load balancers, CDNs, WAFs, HSMs, operating systems, language runtimes, open-source libraries, SaaS products and managed PKI.

Delivery and recovery

CI/CD signing, artifact repositories, image signatures, configuration management, disaster recovery, key backup and break-glass procedures.

Inventory field	Capture	Why it changes the plan
Cryptographic function	Key establishment, encryption, signature, authentication, certificate validation, secure boot or key transport	Different functions require different PQC mechanisms, trust-chain changes and tests.
Implementation	Protocol, algorithm, parameter set, library, module version, appliance or managed-service feature	A protocol name is not proof that the deployed implementation can negotiate, validate or operate safely.
Asset and owner	Service, device family, environment, business owner, technical owner and vendor	Someone must make a risk decision, fund a change and accept the operational impact.
Protected value	Data class, integrity objective, confidentiality lifetime, critical process and regulatory or contractual dependency	This supplies the reasoned order for migration rather than an arbitrary technology-first queue.
Dependency chain	Certificate issuer, peer systems, SDKs, HSMs, gateways, clients, devices and external suppliers	A change that a counterparty cannot negotiate is downtime, not resilience.
Change evidence	Supported release, vendor statement, test matrix, rollback path, operational owner and target date	It turns a spreadsheet into an executable and auditable migration backlog.

Rank by exposure and irreversibility, not by the loudest product

A data set can be copied today and attacked later. A signature chain can remain a trust anchor long after a service is retired. The result should be a reviewed risk decision for each use, not a single date applied to every RSA or elliptic-curve key.

Move first

Long-lived confidential data, high-value trust anchors, widely exposed internet services, critical infrastructure functions, deployed devices with slow upgrade cycles and systems whose recovery window is long.

Plan and test

Important services with manageable upgrade paths, bounded data lifetime, documented counterparties and a vendor release that can be exercised in a non-production environment.

Discover before committing

Opaque appliances, legacy products, unmanaged endpoints, proprietary protocols, external SaaS, supplier-hosted PKI and products with uncertain support or contractual control.

Confidentiality horizon

How long intercepted data, backups or archives must remain secret, versus the expected time to deploy a cryptographically relevant quantum computer.

Authenticity horizon

How long a signature, update or certificate must remain trustworthy and whether a historical record needs verifiable provenance.

Migration lead time

The time needed to update protocol peers, libraries, hardware, fleet devices, contracts, operations and recovery material.

Blast radius

The consequence of a failed negotiation, invalid signature, certificate rejection, capacity change, latency increase or unplanned rollback.

Design a reversible migration, one trust boundary at a time

ENISA's integration studydistinguishes selecting algorithms from integrating them into existing protocols and points to use-case trade-offs and hybrid approaches. Hybrid does not mean “enable two things and call it done”: define the peer behaviour, downgrade resistance, certificate and key lifecycle, capacity impact and exit path.

Choose a bounded pilot
Select one internet-facing or partner-facing service with a clear owner, known peers, representative traffic and a rollback route. Define the security objective: protect a long-lived secret, validate a signature chain, or both.
Confirm interoperable implementations
Test the actual operating system, crypto library, server, client, load balancer, HSM, certificate service and monitoring stack—not only their product roadmaps. Record versions, feature flags, supported modes and unsupported peers.
Model the trust and negotiation path
Document how keys are established, which certificate or signature checks occur, how hybrid negotiation is selected, what happens when a peer lacks support and how downgrade attempts are detected or rejected.
Exercise non-functional impact
Measure handshake size, CPU, memory, latency, connection reuse, MTU and fragmentation behaviour, hardware acceleration, log visibility, alerting and failure modes under realistic traffic.
Prove recovery and rollback
Rehearse certificate rotation, key revocation, feature disablement, client fallback policy, HSM recovery and incident communications. A rollback must not silently restore a weaker posture beyond the approved exception window.
Promote by evidence
Expand only after security, interoperability, performance, support and business owners approve the pilot evidence. Feed every exception and supplier gap back into the inventory and risk register.

Turn an audit into a programme the platform team can run

The deliverable is not a list of weak algorithms. It is a decision-ready inventory, a risk-ranked migration backlog and a small number of proven patterns that teams can repeat without rediscovering the whole trust chain on every release.

Discovery workshop

Set scope and evidence standards with security, platform, application, product, procurement, privacy and business owners. Identify the services and records that cannot wait for a blanket refresh cycle.

Evidence-led inventory

Combine configuration review, asset and certificate data, code and dependency analysis, architecture interviews and supplier questionnaires. Label unknowns explicitly rather than inferring capability.

Risk and owner review

Score confidentiality and authenticity horizons, exposure, criticality, migration lead time, dependencies and recovery constraints. Assign one accountable owner and target decision to every high-priority item.

Pilot architecture

Create a version-specific test plan for the selected service, including protocol peers, trust stores, HSM or key management, monitoring, capacity, rollback and support escalation.

Migration backlog

Sequence product releases, infrastructure changes, contract dependencies, certificate and key rotations, device update windows and decommissioning. Make exceptions time-bound and reviewable.

Operating model

Establish crypto policy ownership, change controls, supplier evidence refresh, continuous discovery signals and an executive view of coverage, open risk and blocked dependencies.

What a useful first phase proves

A programme is ready for its next scope only when it can show the decision, not merely the configuration. These are Yarify engineering acceptance criteria, tailored with the client's security and operational owners.

Traceable

Each priority cryptographic use links to an asset, owner, business purpose, protected value, implementation, dependency chain and evidence source.

Risk-ranked

The order of work explicitly considers confidentiality and authenticity lifetime, exposure, criticality, lead time and recovery consequences.

Supplier-tested

Managed services, products and embedded dependencies have version-specific capability evidence or a dated remediation and exception decision.

Interoperable

A pilot proves the intended peer, client, protocol, trust-chain and fallback behaviour under realistic traffic and failure conditions.

Recoverable

Key rotation, certificate handling, feature rollback, alerting, support handoff and incident communications are tested and owned.

Governed

Policy changes, exceptions, target dates, evidence and open dependencies are reviewable without relying on a one-off consultant spreadsheet.

Post-quantum cryptography audit FAQ

Is post-quantum cryptography mandatory for every EU business in 2026?

No EU-wide rule in the sources on this page imposes a universal private-sector PQC deadline. The Commission Recommendation and the June 2025 coordinated roadmap are non-binding policy instruments aimed principally at Member States and public-sector coordination. Sectoral, contractual, national-security and customer requirements may still create a concrete obligation for a particular organisation.

What should a PQC audit inventory contain?

It should identify each public-key use and its business context: protocol and cipher suite, algorithm and key size, certificate or signing chain, library and version, asset and owner, data sensitivity and confidentiality lifetime, external dependency, upgrade path, test evidence and retirement date. A scan alone is not enough: embedded firmware, managed services and vendor products need supplier confirmation.

Does quantum risk affect only encrypted traffic?

No. Key establishment for encryption is one concern, but public-key signatures also protect code signing, firmware updates, certificates, identity assertions, signed documents and time-stamped records. The inventory needs separate tracks for confidentiality and authenticity because their migration paths, trust chains and operational risks differ.

Should we replace RSA and ECC everywhere immediately?

Usually no. First establish exposure, data lifetime, dependency and upgrade feasibility. Then pilot a reversible, interoperable path for the highest-risk service. The exact protocol and hybrid design must be validated against the organisation's TLS, PKI, device, vendor and regulatory constraints; it should not be selected from a generic algorithm list.

What is cryptographic agility in this context?

It is the ability to discover, select, configure, test, rotate and retire cryptographic mechanisms without rebuilding an entire product or service. In practice that means explicit crypto ownership, versioned policies, separated protocol configuration, testable interoperability and an evidence trail for each change.

Primary sources and status

Reviewed 4 September 2026. NIST FIPS publications are final technical standards. Commission Recommendation (EU) 2024/1101 and the coordinated EU roadmap are non-binding policy instruments, not a universal private-sector PQC mandate. ENISA and CISA/NSA/NIST material provides authoritative guidance, not a substitute for applicable national, sectoral, contractual or product-specific obligations. Yarify's audit scope, ranking method, pilot design and acceptance criteria are implementation recommendations, not legal advice.