Crash Course
& Glossary

Encryption changes readable information into a protected form that should be unreadable without the right key.

It protects information while moving across a network and while stored. Encryption does not automatically prove who sent a message, whether software is genuine or whether a file changed; those jobs may involve signatures, certificates, authentication and integrity checks.

Public-key cryptography uses a public key that can be shared and a private key that must remain secret.

It helps systems establish secure connections and prove identity without first sharing one secret in person. RSA and elliptic-curve cryptography are widely used examples in certificates, web connections, VPNs, software signing and device identity.

RSA is a widely deployed public-key algorithm used for encryption, key transport and digital signatures.

Its security relies on the difficulty of factoring large integers. A sufficiently capable fault-tolerant quantum computer running Shor's algorithm would undermine that assumption, so RSA dependencies need an owned migration route.

Elliptic-curve cryptography is a family of public-key techniques based on the mathematics of elliptic curves.

It supports key agreement and digital signatures in many protocols, certificates, devices and products. Like RSA, its security is threatened by Shor's algorithm on a sufficiently capable quantum computer.

Diffie–Hellman is a method that lets parties establish shared secret material over a public channel.

Classical finite-field and elliptic-curve forms are public-key dependencies affected by the quantum transition. They often sit inside protocols and supplier products rather than appearing as a visible business application.

Symmetric cryptography uses the same secret key, or closely related secret material, to protect and recover information.

It is fast and commonly protects large amounts of data after two systems establish a shared secret. AES is a well-known example. Quantum computing does not affect it in the same way as RSA and elliptic-curve systems; stronger key sizes can preserve a useful security margin.

AES is a widely used symmetric encryption standard for protecting data with a shared secret key.

Quantum computing affects AES differently from RSA and elliptic-curve cryptography. Appropriate key sizes can preserve a useful security margin, so organisations should not treat every cryptographic dependency as requiring the same response.

A cryptographic hash function maps data to a fixed-size digest used to help detect change and support other security constructions.

Hashes are not encryption. Their quantum risk and parameter choices differ from public-key systems, and their use should be assessed in the protocol or product where they appear.

A digital signature helps prove that data came from the expected signer and was not changed after signing.

Signatures protect authenticity and integrity in software updates, firmware, certificates, documents and machine-to-machine trust. If a vulnerable signature method could be forged, an attacker might impersonate a trusted publisher, device, service or person.

A digital certificate links a public key to an identity. Public key infrastructure is the wider system that issues, trusts, renews and revokes certificates.

PKI includes certificate authorities, trust stores, policies, renewal, revocation, key protection and operational ownership. Certificates can identify websites, people, services, machines or software.

TLS is a protocol that protects many network connections, including web traffic and APIs.

A TLS connection combines certificates, signatures, key establishment and symmetric encryption. Migration therefore depends on protocol versions, libraries, certificates, endpoints, performance and interoperability—not only an algorithm name.

A trust anchor is a root of trust that a system accepts when validating certificates, software, firmware or identities.

Long-lived or hard-coded trust anchors can make migration difficult because every dependent device or service must recognise a replacement route without accepting an unsafe fallback.

These terms describe security methods expected to remain effective against a sufficiently capable quantum computer.

Quantum-safe is useful plain language, not an absolute guarantee. Security still depends on the algorithm, implementation, key management, protocol, configuration, surrounding software and operating process.

A cryptographically relevant quantum computer is a quantum computer capable of attacking cryptography used in real systems.

Today's quantum computers cannot break internet-scale public-key cryptography in practice. The concern is a future machine with enough scale, quality and error correction. No universally accepted arrival date exists, so planning should use information lifetime, system lifetime and change lead time rather than one predicted year.

Q-Day is an informal name for the point at which quantum computing becomes a practical threat to widely used cryptography.

It is not an official deadline and may not be one public event. Different adversaries, systems and key sizes may face risk at different times. The useful question is whether important information or systems could outlive today's protection and whether migration can finish before that becomes unacceptable.

Organisations start before the threat is operational because discovery, supplier coordination, testing and migration can take many years.

Cryptography is often buried inside products. Some systems cannot change through a normal update, suppliers may lack a supported route, and certificates, devices and products can remain in service for a decade or longer. Encrypted information can also be copied today for later decryption.

Shor's algorithm is a quantum algorithm that could solve the mathematical problems behind widely used public-key cryptography much faster than conventional methods.

On a sufficiently capable fault-tolerant quantum computer it threatens integer factorisation and discrete logarithms, which support RSA, Diffie–Hellman and many elliptic-curve systems. It is not practical at real-world scale today; it explains why replacements are being standardised now.

Widely used RSA and elliptic-curve methods for establishing secure connections are vulnerable to a sufficiently capable quantum computer.

Public-key methods often agree a shared secret at the start of a connection. Symmetric encryption then protects the larger transfer. If key establishment fails, the connection's confidentiality may fail even when bulk encryption remains strong.

Long-lived confidentiality means information must remain unreadable to unauthorised people for many years.

The relevant period is when disclosure could still harm people, customers, national interests, intellectual property, litigation, negotiations or safety—not only a formal retention period. Useful assessments separate short- and long-lived information instead of applying one blanket label.

Long-lived trust means a system, signature, certificate or identity must remain believable and usable for many years.

A product may need to verify updates throughout a long service life, a signed document may need verification after a certificate expires, or a device may contain a hard-to-replace trust anchor. This concerns proving what is genuine rather than keeping information secret.

Grover's algorithm could speed up brute-force searching, reducing the security margin of symmetric keys and some hash-based operations.

This differs from Shor's algorithm breaking RSA or elliptic-curve cryptography. The expected advantage is smaller and stronger key sizes can compensate.

PQC Ready uses this term for systems that depend on vulnerable cryptography but cannot change it through an ordinary update.

Cryptography may be hard-coded, resources limited, certificates fixed, support ended, recertification required or equipment difficult to reach. A cryptographic change can become a redesign, field programme, replacement or explicit end-of-life risk decision.

Embedded, operational technology and connected devices often have longer lifetimes and tighter change constraints than normal office software.

They may have limited memory, processing, bandwidth or storage. Updates may require physical access, narrow maintenance windows, safety approval or supplier support. Migration should separate these systems from cloud and standard business IT.

A hybrid approach uses a current cryptographic method and a post-quantum method together during the transition.

Hybrid designs can preserve compatibility or reduce dependence on one new method while ecosystems mature. They also add complexity, larger messages, processing and failure modes. The combination, protocol, implementation and fallback behaviour must be tested.

Quantum key distribution uses specialised quantum-physics technology to distribute key material. It is different from post-quantum cryptography.

PQC normally runs on conventional computers and networks using new algorithms. QKD generally requires special-purpose physical infrastructure. Most organisations beginning transition are planning around standardised PQC and migration of existing digital systems.

Exposure describes what could be harmed. Maturity describes the organisation's ability to understand and manage the transition.

A highly exposed organisation can have a strong programme, while a less exposed one can have weak visibility and ownership. PQC Ready therefore keeps exposure themes separate from the formal maturity result.

A plus shows meaningful, evidenced progress towards the next PQCEMM gate without claiming that the gate has been achieved.

A result shown as 2+ means Level 2 is the achieved canonical level and there is progress towards Level 3. It is not a fractional score and it never promotes the result to Level 3. The deterministic scoring model controls when the plus is displayed.

Confidence describes how complete and dependable the evidence is. It is separate from maturity.

Low confidence means important uncertainty, not automatically low maturity. High confidence can clearly show a strength or a gap. Phase 1 is primarily self-reported; later phases can inspect systems, records and technical evidence in greater depth.

The Quick Scan's deterministic exposure output: Minimal, Early-stage, Material, High or Critical.

It indicates transition priority from seven exposure signals. It is not a PQCEMM maturity level and does not claim technical verification.

Quantum risk is not yet represented as an organised enterprise transition concern. The organisation may have little visibility of affected systems, no clear ownership and no structured route from concern to action.

Level 1 does not mean the organisation has no cybersecurity. It means current cybersecurity has not yet been translated into a controlled post-quantum transition capability.

The organisation recognises the issue and has begun to identify relevant data, systems, people or suppliers. Early evidence exists, but important foundations remain incomplete.

Typical next needs include clear ownership, a reliable inventory, defined priority scope and a practical plan for the first decisions.

Core governance, discovery and planning capabilities are established and repeatable. The organisation can explain what it is assessing, who is responsible, which dependencies matter and how work will be sequenced.

Level 3 is still preparation. It does not automatically prove that migration has been tested or deployed successfully.

Migration is being managed through controlled execution, business continuity, measurement and enterprise integration. The organisation has evidence from real implementation, testing or operational change and can manage exceptions and dependencies.

Progress is no longer mainly a planning claim; it is supported by retained delivery and assurance evidence.

Quantum-safe transition capability is embedded, evidenced and continuously assured. The organisation can adapt as standards, suppliers, systems and threats change.

Level 5 is not a promise that risk has disappeared. It means the organisation has a mature, repeatable capability to keep its cryptographic position current.

Phase 1 uses the organisation's answers to create a structured readiness picture. It is not independent technical verification.

Quinn records what the respondent reports, including uncertainty, current capability, future plans and explicit gaps. The maturity engine evaluates that evidence against the methodology. Later phases can validate inventories, configurations, supplier evidence, test results and operating controls.

The Quick Scan is PQC Ready's anonymous, deterministic, seven-question exposure snapshot.

It asks about information lifetime, system lifetime, business impact, technology type, supplier control, past change delays and current preparation. It produces a Transition Priority Band—Minimal, Early-stage, Material, High or Critical—not a PQCEMM maturity assessment.

The Deep Scan is the registered Phase 1 assessment: twenty canonical questions, with questions 3 to 20 each able to carry up to two adaptive follow-ups.

The application selects questions, applies the follow-up policy and scores every answer. Quinn explains unfamiliar ideas and interprets open-text answers. Quick Scan context can guide the conversation when the user chooses, but only answers confirmed in the Deep Scan become formal evidence.

Quinn is PQC Ready's Senior Assessment Consultant persona (they/them): an AI assessment consultant for explanation, evidence elicitation and narrative drafting.

Quinn asks policy-approved follow-ups and interprets open answers against evidence rubrics. Quinn does not select the canonical question path, compute scores or maturity, independently verify technical claims, make legal determinations or replace accountable human decisions.

A Cryptographic Bill of Materials is a structured way to describe cryptographic components and dependencies in software, systems or products.

Usage differs across tools and organisations. The useful principle is to retain enough provenance and dependency information to understand where a vulnerable method is present and what changing it would affect. A CBOM can support a wider inventory, but the terms are not always identical.

A business impact analysis identifies which products and services matter most, how disruption affects the organisation and how quickly recovery is needed.

For PQC it translates a technical failure—such as an untrusted certificate or software-signing method—into customer, operational, safety, financial and legal consequences.

A tabletop exercise is a structured discussion of a realistic disruption scenario.

Participants work through decisions, responsibilities, communications, suppliers, technical options and recovery without causing a production incident. A useful exercise records gaps, owners and actions, then checks whether improvements were completed.

Phase 3 sub-module M1B evaluates likelihood and impact to produce an owned PQC risk register, grounded in ISO 31000.

The Phase 3 gate at which a PQC Ready consultant reviews the Module 1 package and the client executive endorses it before later sub-modules begin.

The package comprises the business impact analysis, risk assessment, continuity strategy and policy. The gate preserves professional review and client accountability.

Harvest Shield is Phase 3 sub-module 2B, connecting verified asset evidence to the organisation's data-retention landscape and HNDL exposure.

It produces a ranked Harvest Shield Risk Register and strategic Transition Roadmap across immediate, medium- and long-term action.

Q-Day Ready is Phase 3 sub-module 2C: scenario design, inject cards and a facilitated tabletop exercise for a sudden loss of cryptographic trust.

It tests decision roles, communications, fallback, supplier escalation and urgent-change routes, then retains owned remediation.

A migration wave is a controlled group of systems or products moved through a similar transition route.

Waves may be organised by business priority, technical pattern, supplier, architecture, product family or risk. Each should have entry criteria, test evidence, rollback, acceptance and ownership.

Rollback is the controlled ability to return to a known safe state when a change fails or creates unacceptable impact.

A migration test is incomplete if it proves only that a new configuration can be enabled. It should also show what happens when deployment, interoperability or performance does not behave as expected.

A Phase 6 mechanism that repeats a bounded part of an earlier phase when a material change invalidates prior evidence or assumptions.

It avoids restarting the entire journey while ensuring that affected decisions, inventory, plans or assurance are refreshed.

ML-KEM is a post-quantum key-encapsulation mechanism standardised in FIPS 203.

In practical terms, it helps two parties establish shared secret material over a public connection. That secret can then support symmetric protection of the data exchange. It is not a direct drop-in answer for every protocol or product; protocol standards, certificates, libraries, hardware and suppliers still matter.

Primary source: NIST final PQC standards announcement ↗

ML-DSA is a post-quantum digital signature algorithm standardised in FIPS 204.

It can help prove origin and integrity in use cases such as software, documents, certificates and machine identities, depending on the protocol and implementation.

Primary source: NIST final PQC standards announcement ↗

SLH-DSA is a stateless hash-based digital signature algorithm standardised in FIPS 205.

It uses a different mathematical approach from ML-DSA and provides diversity, but has different size and performance characteristics. Selection should follow the use case and relevant guidance rather than a belief that one signature algorithm is always best.

Primary source: NIST final PQC standards announcement ↗

FN-DSA is the standardisation name for the FALCON post-quantum digital-signature family selected by NIST.

Its standard remains in development. Organisations should track the primary NIST source and current implementation guidance rather than treating an evolving candidate as interchangeable with a final FIPS standard.

Primary source: NIST post-quantum cryptography project ↗

HQC is a code-based key-encapsulation mechanism selected by NIST for future standardisation.

It is intended to add a mathematically different KEM option alongside ML-KEM. Its future standard and implementation guidance should be checked at the primary NIST source before operational use.

Primary source: NIST post-quantum cryptography project ↗

NIST describes crypto agility as the capability to replace and adapt cryptographic algorithms while preserving security and ongoing operations.

That capability spans protocols, applications, software, hardware, firmware and infrastructure. It matters because the next algorithm change should not require the same level of emergency redesign as the current transition.

Primary source: NIST post-quantum cryptography project ↗

EU Member States, supported by the European Commission, published a coordinated implementation roadmap in 2025.

It gives Member States a common direction for planning, awareness and prioritisation. Organisations should still check national implementation, sector guidance and regulator expectations.

Primary source: European Commission coordinated PQC roadmap ↗

DORA creates ICT risk and operational-resilience requirements for in-scope EU financial entities.

It covers ICT risk management, incident reporting, resilience testing and ICT third-party risk and has applied since 17 January 2025.

DORA is not a dedicated PQC standard. PQC becomes relevant where cryptographic dependency, legacy technology, supplier concentration or migration risk affects ICT risk and resilience. A PQC Ready assessment can support visibility and planning, but does not prove compliance.

Primary source: EUR-Lex Regulation (EU) 2022/2554 (DORA) ↗

NIS2 expands cybersecurity risk-management and incident-reporting duties across many critical and important sectors in the EU.

It is not PQC-specific. Organisations in scope may nevertheless need to manage cryptographic dependencies, supply-chain risk, vulnerability, continuity and long-term security within wider cybersecurity risk management.

National transposition and supervision matter; an EU summary does not replace country-specific legal advice.

Primary source: European Commission NIS2 overview ↗

ISO/IEC 27001 defines requirements for an information security management system.

It provides a useful home for risk ownership, asset management, policies, supplier management, change, evidence and continual improvement. It does not prescribe a complete PQC migration, and certification does not mean an organisation is quantum-ready.

PQC work should reuse an existing management system where possible instead of creating a disconnected parallel programme.

Primary source: ISO/IEC 27001:2022 ↗

ISO 22301 provides requirements for a business continuity management system.

It is relevant where cryptographic disruption could stop remote access, updates, transactions, identity, products or critical services. Existing impact analysis, crisis roles, recovery objectives and exercises can provide a foundation for transition resilience.

Primary source: ISO 22301:2019 ↗

ISO 31000 provides general guidance for managing risk across an organisation.

It can help integrate quantum-related cryptographic risk into normal governance and decision-making. It is not a certification standard and does not prescribe PQC algorithms.

Primary source: ISO 31000:2018 ↗

CNSA 2.0 sets future quantum-resistant algorithm direction for United States National Security Systems and relevant vendors.

It is not a universal commercial standard for every company. It is most relevant to National Security Systems and organisations supplying that environment. Others may learn from its direction but should not claim applicability without confirming customer, contract and system requirements.

Primary source: NSA post-quantum cybersecurity resources ↗

The UK reference point is the NCSC migration guidance and its 2028, 2031 and 2035 milestones.

Regulated organisations should also consider sector-specific requirements, contracts and customer expectations.

The EU has a coordinated PQC roadmap, while DORA, NIS2 and other rules create wider risk and resilience obligations.

Applicability varies by sector, entity and national implementation.

NIST provides the main technical PQC standards; CNSA 2.0 is a distinct policy direction for National Security Systems.

Federal, defence, regulated and commercial contexts should not be conflated.

Financial services depend on payments, identity, certificates, secure channels, third-party technology and records that can remain sensitive for years.

Transition must connect discovery to operational resilience, supplier risk, testing and regulated change. DORA can be relevant to the wider ICT-risk context, but is not a dedicated PQC rule.

Telecom networks combine high-scale services with infrastructure that can remain deployed for many years.

Core networks, customer identity, roaming, lawful access, equipment and supplier dependencies may follow different timelines. Compatibility and service continuity are central.

Cloud and data-centre environments concentrate certificates, APIs, tenant boundaries, key management, identity and managed platforms at scale.

An organisation needs visibility of what it controls and what the provider controls. A supplier statement is not proof that the actual service configuration has migrated.

Public services may hold citizen, policy, identity and archival information for long periods while relying on large supplier ecosystems.

Prioritisation should consider information lifetime, critical services, national guidance, long-lived infrastructure and the public consequence of disruption.

Patient records, genomic information, clinical research, intellectual property and connected medical technology can have long confidentiality or trust lifetimes.

Planning should distinguish data protection, signed software, device lifecycles, safety, research platforms and supplier-controlled equipment.

Privileged advice, disputes, transactions, client files and corporate records may remain sensitive long after a matter closes.

The first challenge is often seeing dependencies on client platforms, document systems, identity services, cloud providers and third parties.

Manufacturers can have long-lived products, complex supplier chains, signed firmware, embedded controllers and safety or certification constraints.

Migration may involve product families, update infrastructure, supplier commitments, hardware limits, replacement decisions and end-of-life policy—not only central IT.

Technology providers can expose cryptographic choices to many customers through one product, API, library or cloud service.

They need to show which versions and configurations support PQC, how compatibility and fallback behave, what evidence customers can rely on and how long older products remain supported.

This role translates the quantum threat into existing risk, policy, exception and assurance processes.

It helps prevent PQC from becoming a disconnected technical experiment with no route into accountable decisions.

Architects and technical leaders identify where cryptography sits in systems, protocols, platforms and dependencies.

They help define target patterns and decision criteria informed by real inventory and testing rather than algorithm names alone.

Engineering and product teams understand implementation constraints, releases, firmware, performance, compatibility and product lifecycles.

They prove whether a migration route works in the environment where it will actually be used.

Procurement and supplier teams obtain product-specific roadmaps, commitments, support horizons, change notifications, test cooperation and exit options.

General marketing claims should not replace evidence about the exact product, version and service used.

These teams identify confidentiality periods, contractual commitments, legal applicability, customer promises and evidence expectations.

They should not be asked to make technical claims, but can clarify why protection and trust must last and what must be demonstrated.

These teams define what cannot be interrupted, who can authorise emergency action, how fallback and recovery work and what customer impact is acceptable.

Their involvement is especially important for long-lived products, operational technology and critical services.

PQC Ready brings together business risk, technology, programme, policy and operational perspectives to guide the transition.

The team's role is to turn a broad future threat into a staged, evidence-based programme—from first awareness to continuous assurance.

An NDA is a contract that sets confidentiality obligations for information shared between parties.

It does not make every technical system automatically secure. It establishes legal duties and should sit alongside appropriate access controls, data handling, retention and security measures.

The deterministic application component that evaluates evidence, applies stage gates and computes maturity, plus notation and confidence.

The Phase 1 engine evaluates 260 conditions across 800 atom states. Identical evidence yields the same calculation; Quinn never assigns the result.

A deterministic rule that evaluates one or more atom states and contributes to a criterion or dimension result.

Phase 1 uses 260 conditions designed by PQC Ready. They are application logic, not rules invented by a language model during an assessment.

The smallest unit of evaluable evidence state in PQC Ready's rule engine.

The Phase 1 engine defines 800 atom states. Conditions evaluate those states to produce traceable criteria, dimension results and the overall gate.

Self-reported evidence is provided by the respondent. Verified evidence has been independently inspected, tested or otherwise confirmed through an agreed process.

Phase 1 is mainly self-reported. That can support a useful baseline and roadmap, but the report must not present it as certification or technical assurance.

Data minimisation means collecting only the information needed for the purpose.

A useful assessment records a clear capability or gap without storing unnecessary secrets, credentials, personal data or detailed vulnerabilities.

AI can help structure evidence, explain concepts and draft narrative, but accountable people remain responsible for decisions.

People own scope, risk acceptance, investment, technical approval, suppliers and implementation. The application—not Quinn—owns scoring and gates. A mature process keeps every recommendation's basis visible enough to challenge and approve.

A PQC Ready assessment is not a certification and does not guarantee compliance with DORA, NIS2, ISO/IEC 27001, CNSA 2.0 or another framework.

It can identify evidence, gaps and actions relevant to those frameworks. Formal applicability and conformity require the appropriate legal, regulatory, technical or certification process.