The Agentic Post-Quantum Conversion Problem Definition

Why cryptographic conversion is failing, why it cannot be fixed by scaling current methods, and why a new discipline is required.

• Document: APQC-PROBLEM-002 — Problem Definition
• Status: Draft 0.1
• Version: 0.1
• Date: 2026-07-02
• Editor / Authoring body: H33.ai, Inc.

This is the why of the discipline. It is deliberately vendor-neutral and implementation-free: it describes the problem any organization faces, in terms any vendor, analyst, auditor, or regulator can adopt. It names no products.

RFC 2119 keywords apply where used.

0. Front Matter

0.1 Normative References

• APQC-CORE-001 — The APQC Constitution.

0.2 Informative References

• NIST SP 1800-38 — Migration to Post-Quantum Cryptography.
• U.S. CNSA 2.0; NSM-10; OMB M-23-02; CISA PQC guidance; NIST IR 8547 (transition).

0.3 Related Specifications

• APQC-MODEL-003 (Conceptual Model) formalizes the response to the problem stated here.

0.4 Conformance Dependencies

• Depends on: APQC-CORE-001.
• Referenced by: APQC-MODEL-003, APQC-MATURITY-008.

1. Abstract

Every organization that uses public-key cryptography must migrate it to post-quantum standards, on a regulated timeline, across an estate few can fully see. The methods available today — manual discovery, static inventories, cryptographic bills of materials, discovery scanners, crypto-agility programs, and consulting engagements — cannot complete this work at enterprise scale, and, more importantly, cannot prove it was completed. This document establishes that the failure is structural, not effort-related: it will not be solved by more people or more urgency. It analyzes each failure mode by its mechanism, illustrates each with a neutral hypothetical, quantifies the stakes, and compares the existing approaches against what the problem demands. It then derives — as a logical consequence of the failures, not as a design preference — why the response must be performed by governed agents and why authority and proof must be intrinsic invariants of the operating model rather than features bolted onto it.

2. Context: the mandate and the clock

Post-quantum migration is not a research question. The algorithms are finalized (NIST FIPS 203/204/205) and the deadlines are set (CNSA 2.0 and related directives require migration on defined horizons). The intellectual work of choosing a quantum-resistant algorithm is done; what remains is the operational work of applying it — everywhere, correctly, and provably. That remaining work is where organizations are failing, and where this document is directed.

Two facts make the clock real. Both are developed rigorously in Section 4.

• Harvest-now-decrypt-later. Adversaries can capture encrypted data today and decrypt it once a cryptographically-relevant quantum computer exists. Any data whose confidentiality must outlive that event is already at risk. For long-retention data, the deadline for confidentiality protection has effectively already passed.
• Scale. Public-key cryptography is not in one place. It is in application code, X.509 certificates, TLS and IKE endpoints, protocol handshakes, cryptographic libraries, firmware, hardware security modules, key stores, code-signing pipelines, and third-party and transitive dependencies — across every system an enterprise runs. The migration surface is the entire estate.

The mandate is settled; the method is not. That gap is the problem this document defines.

3. Why post-quantum migration fails today

The failure of current practice is not one failure but five, each with a distinct mechanism. What unites them is examined in Sections 6 and 7: each is a symptom of applying human-rate, snapshot-based, assertion-based methods to a machine-scale, continuously-changing, evidence-demanding problem.

3.1 Discovery is the hard part, and it is manual

Mechanism. The difficulty of migration is not choosing the algorithm — NIST chose it. The difficulty is finding every place cryptography is used and understanding what depends on it. A single business function may terminate TLS at a load balancer, re-encrypt to a service mesh, sign requests with one key hierarchy, encrypt data at rest with another, and depend on a payment library that itself negotiates key exchange three layers down. Cryptography is not a component an organization owns; it is a property distributed through code paths, configuration, runtime negotiation, and vendored dependencies. Discovery — the continuous sensing function that observes an estate and reports assets — is today performed by humans reading source, configuration, and certificates by hand, or by point tools whose output a human must still interpret and stitch together. It is slow, incomplete, and stale the moment it finishes because the estate does not stop moving while it is being read.

Illustrative scenario (hypothetical). A regulated financial institution commissions a cryptographic discovery exercise. Over four months, analysts catalogue TLS endpoints, certificate stores, and the cryptographic calls in the twelve applications management considers "the crown jewels." The report is delivered. It does not include a batch-processing service that reaches a legacy partner over a hardcoded RSA channel, because that service was owned by a team that reorganized during the exercise and no one pointed the analysts at it. It does not include a firmware-level signing key in an appliance fleet, because firmware was out of the analysts' declared scope. Neither omission is negligence; each is a boundary that a human-scoped exercise had to draw somewhere. The institution now holds a document it will reasonably treat as its map of exposure — a map with holes it cannot see.

Stakes. The cost of migration is dominated by discovery, not conversion; industry guidance (NIST SP 1800-38) treats inventory as the foundational and most laborious phase precisely because everything downstream depends on it. An inventory that is 90% complete is not 90% of a migration — the missing 10% is exactly the set of unconverted, unknown assets that a quantum adversary, or a regulator asking "prove you found everything," will find. Incompleteness in discovery is not a quality metric; it is a residual, unbounded liability.

3.2 Inventories are snapshots, not operating models

Mechanism. A cryptographic inventory is a photograph of a moving target. An estate is a live, changing population, never a fixed list: certificates rotate on schedules measured in days to months, deployments ship continuously, infrastructure autoscales, changes roll back, and shadow systems appear without central knowledge. An inventory answers "what did we have?" at a past instant. It does not answer "what do we have now?", it does not track the delta between then and now, and — critically — it does not convert anything. It is a noun where the problem demands a verb.

Illustrative scenario (hypothetical). An enterprise completes a cryptographic bill of materials and reports it to its board as a milestone. Six months later, a routine audit samples fifty production services against the inventory. Eleven have changed cryptographic posture since the snapshot: seven rotated to new certificates (still classical), two were redeployed on a base image with a different TLS library, and two are services that did not exist when the inventory was taken. The inventory is not wrong about the past; it is simply no longer a description of the present. The organization's "we have visibility" claim was true for one instant and decayed continuously thereafter, and nobody could say by how much.

Stakes. Any migration governed by a snapshot is migrating against a target that has already moved. The gap between the inventory and reality is unbounded and grows monotonically until the next inventory — which restarts the same decay. Organizations that treat inventory as the deliverable discover, months later, that the estate moved out from under it, and that the effort must be repeated rather than extended. A snapshot cannot support a continuous mandate; drift (the reappearance of pre-transformation state) is not an edge case but the steady-state behavior of every real estate.

3.3 Crypto agility is a property, not a plan

Mechanism. Crypto agility — the architectural ability to swap primitives without re-architecting the system around them — is necessary and good; the corpus treats it as a target property, not a strawman. But agility is a capability, not an execution. Being able to change cryptography does not tell you where to change it, in what order, under what authority, or whether the change succeeded and stayed succeeded. Agility answers "can this be changed cheaply?"; the migration problem asks "which of my hundreds of thousands of cryptographic uses must change, by when, safely, and how do I prove each one did." Those are disjoint questions. An estate can be perfectly agile and entirely unmigrated.

Illustrative scenario (hypothetical). A platform team invests two years making its services crypto-agile: primitives are abstracted behind a provider interface, algorithm identifiers are configuration rather than code, and a new algorithm can be enabled by a flag. The work is genuinely excellent. Then the migration mandate arrives with a deadline, and the team discovers that agility told them nothing about which of 40,000 configured endpoints across dozens of teams still point at classical primitives, which of those carry long-lived confidential data and must go first, who is authorized to flip each flag in production, or how to demonstrate to an auditor that a given flag was flipped, by an authorized party, and has not been flipped back. The car is superb; there is still no driver, no route, and no logbook.

Stakes. Investment in agility is frequently mistaken for progress on migration, which delays the actual work until the deadline is closer and the estate is larger. Agility reduces the unit cost of a single conversion; it does nothing about the two costs that dominate — knowing the full set of conversions required (§3.1, §3.2) and proving the set was completed (§3.5). A plan-less agility program can consume the entire budget and timeline and still leave the organization unable to answer "are we migrated?"

3.4 Consultants do not scale and do not stay

Mechanism. Cryptographers and migration specialists are among the scarcest and most expensive experts in security. A consulting engagement applies this scarce labor to one organization's estate for a bounded period. It works — for years, at a cost of millions, for one migration that is partially obsolete by the next re-architecture. The engagement produces documents and human judgment; when it ends, the judgment leaves with the people, and the documents begin to decay exactly as inventories do (§3.2). The model has no mechanism to keep pace with an estate that changes after the consultants depart, and it produces no durable, machine-verifiable record that a later party could re-check without re-hiring.

Illustrative scenario (hypothetical). A global manufacturer engages a top-tier firm for an eighteen-month migration program. The firm assembles a rare team, delivers real conversions across priority systems, and hands over a comprehensive final report. Two years later a regulator asks the manufacturer to demonstrate — not describe — which systems were converted, when, and under whose authorization. The consultants are gone; the engineers who executed the changes have moved on; the report describes what was intended and reported, not independently-verifiable evidence of what occurred. The manufacturer must reconstruct its own history from editable logs and human memory, and cannot close the regulator's request without commissioning a fresh, equally-expensive assessment.

Stakes. This is not a criticism of consultants; it is arithmetic (developed in Section 5). There are not enough specialists in the world to migrate every mandated enterprise on the mandated timeline, the specialist supply cannot be scaled on the timeline of the deadline, and the model structurally externalizes the two things the mandate actually requires: continuous coverage and portable proof. Consulting converts money into a one-time result and a report; the problem requires converting a continuously-changing estate into a continuously-maintained, independently-verifiable record.

3.5 "Migration complete" is unprovable today

Mechanism. This is the deepest failure, and the least discussed. When an organization declares its migration complete, it typically cannot produce independent evidence of what was converted, when, by whom, and under whose authority — evidence a regulator, auditor, insurer, or successor team could verify without trusting the organization's own dashboards. What exists instead is a log: a chronological record emitted by systems for operational purposes, editable by whoever holds the system, bound to the vendor and system that wrote it, and mortal with them. A log is an assertion of the issuer; the mandate needs a proof independent of the issuer. "We migrated" is, today, a claim, not proof — and a claim is not proof until it is attested and independently verifiable.

Illustrative scenario (hypothetical). An organization attests to its regulator that its externally-facing systems have completed post-quantum conversion. The attestation is made in good faith. Eighteen months later, a subset of those systems is found still negotiating classical key exchange after an infrastructure change silently reintroduced a legacy library. The organization cannot show, from portable evidence, the state each system was actually in at the moment of attestation, nor who authorized the changes that were made, nor prove that the reintroduction was a later drift rather than a gap that always existed. Its own logs — where they survive at all — are the only record, and they are exactly the records an auditor cannot accept at face value because the audited party controls them.

Stakes. A mandate that cannot be evidenced cannot be enforced, defended in an audit, priced by an insurer, or trusted by a counterparty. Unprovability converts a completed technical migration into an open compliance and liability exposure that persists for the entire retention horizon of the data — years to decades. It also poisons continuity: a successor team inherits assertions, not verifiable state, and must in practice redo the discovery to trust anything. Of the five failures, this is the one that no amount of additional human effort can fix, because the defect is not in how much work was done but in the nature of the record the work leaves behind.

4. Why now: harvest-now-decrypt-later and the mandate clock

Two independent clocks make this problem urgent today rather than at some future "Q-Day." An organization that waits for a quantum computer to exist before acting has already lost on the first clock and is racing the second.

4.1 The retroactive clock: harvest-now-decrypt-later

The threat to confidentiality does not begin when a cryptographically-relevant quantum computer is built. It begins the moment an adversary captures ciphertext that it can store and decrypt later. Encrypted traffic and encrypted data at rest that an adversary records today can be retained and decrypted retroactively once the capability exists. This inverts the usual security timeline: the exposure is set not by when the attacker succeeds but by when the data was captured combined with how long that data must stay confidential.

The consequence is a simple, defensible inequality. For any dataset, let its required confidentiality lifetime be the number of years it must remain secret, and let the horizon to a capable quantum adversary be the years until such an adversary plausibly exists. If the confidentiality lifetime exceeds the horizon, the data is at risk today — because it can be captured now and decrypted before its secrecy requirement expires. For data that must remain confidential for a decade or more (health records, government secrets, financial and legal records, long-lived credentials, intellectual property), the required lifetime plausibly exceeds any reasonable estimate of the horizon, so the effective deadline for protecting that data has already passed. No future date can be waited for; the only remaining variables are how much such data an organization holds and how quickly it can find and convert the cryptography protecting it.

This is why prioritization is inseparable from discovery: the migration is not uniformly urgent, but the most urgent slice — long-lived confidential data — is precisely the slice that harvest-now-decrypt-later has already put on the clock, and it cannot be prioritized until it is found.

4.2 The forward clock: mandates and timelines

Independently of the physics, the regulatory environment has fixed the second clock. National-security and civilian directives (CNSA 2.0; NSM-10; OMB M-23-02; and the transition guidance in NIST IR 8547 and CISA's PQC materials) require inventory, prioritization, and migration of public-key cryptography on defined horizons, with staged expectations rising toward full deprecation of classical primitives in covered systems. The specifics vary by jurisdiction and sector and will continue to evolve; what does not vary is the shape: inventory first, prioritize by risk and data lifetime, then convert, on a schedule that is externally imposed rather than internally chosen.

The forward clock does two things to the failures of Section 3. First, it removes the option of doing the work opportunistically — the deadline makes discovery incompleteness (§3.1) and inventory decay (§3.2) into compliance failures rather than merely operational debt. Second, it makes the unprovability failure (§3.5) acute: a mandate is enforced by demonstration, and an organization that cannot demonstrate completion is exposed regardless of whether its underlying technical work was in fact done.

4.3 Why the two clocks together are decisive

Either clock alone would be manageable by conventional means over a long enough horizon. Together they are not. The retroactive clock says the highest-value data is already exposed and must be found and converted first; the forward clock says the entire estate must be converted and proven on an externally-fixed schedule. The intersection is a demand that no snapshot-based, human-rate, assertion-based method can meet: find everything, continuously, prioritize by data lifetime, convert on a deadline, and prove each conversion in a form that survives audit for the data's full retention horizon. Section 5 shows why the labor arithmetic of the conventional methods cannot close this demand, and Sections 6–7 show what structure can.

5. Scale arithmetic: why human-rate labor cannot cover a machine-scale estate on a deadline

The failures of Section 3 are frequently read as execution problems — "we need more people, more budget, more urgency." This section shows, by construction, that the labor model itself cannot close the gap, independent of effort.

The population. A large enterprise's cryptographic estate is not counted in the dozens or hundreds. Each of thousands of services and hosts may present multiple TLS endpoints; certificate populations run to tens or hundreds of thousands; every application contains many distinct cryptographic call sites; libraries, firmware, HSM slots, key stores, code-signing steps, and third-party and transitive dependencies each multiply the count. A cryptographic asset — any single use of a primitive — is the unit of work, and the number of units in a large estate is realistically in the hundreds of thousands to millions.

The per-unit work. Each asset is not "changed once." Over its life it must be discovered, classified (what is it, what depends on it, how long must its data stay confidential), planned (in what order, with what fallback, under what authority), converted, validated (does it still function and interoperate), verified (did the intended change actually occur), and thereafter re-checked continuously for drift. That is a recurring, multi-step workflow per asset, not a one-time touch.

The rate mismatch. Human analysis proceeds at human rate: an expert can meaningfully examine, reason about, and document a small number of non-trivial cryptographic assets per day, and the supply of such experts is fixed and scarce on the timeline (§3.4). The estate, meanwhile, changes at machine rate — certificates rotate, deployments ship, and infrastructure scales continuously, so new and altered assets are created faster than a human team clears the old ones. This is the decisive arithmetic: when the rate at which the estate changes meets or exceeds the rate at which humans can process it, the backlog never closes. More people raise the processing rate linearly and expensively; they do not change the fact that the target is a moving population on a fixed deadline, nor do they change the fact that the work is recurring rather than one-time (§3.2, §6). A workforce sized to complete a snapshot is, by the time it finishes, facing a new snapshot.

The proof multiplier. Even granting — counterfactually — that enough labor could be found to touch every asset once, the model still fails on Section 3.5: human execution leaves behind logs and reports, not portable proof. Adding the requirement that every one of hundreds of thousands of changes carry independent, offline-verifiable evidence does not add a fixed overhead to a human process; it adds a per-asset artifact-production burden that no manual process produces as a byproduct, and that curated-after-the-fact documentation cannot satisfy because after-the-fact evidence can be shaped by the party producing it.

Conclusion of the arithmetic. The problem is defined by four multiplied quantities — a population in the hundreds of thousands to millions, a recurring multi-step workflow per unit, a continuous rate of change, and a per-unit proof requirement — against a fixed deadline and a fixed, scarce human supply. No value of "more effort" reconciles a linear, scarce, one-time labor rate with a super-linear, continuous, proof-carrying workload. The gap is structural. This is the formal statement of what Section 3 observed qualitatively: the work is human-rate and the estate is machine-scale.

6. Comparison of existing approaches

Each conventional approach does something real and does it well within its scope. The table states, for each, what it does, what it structurally cannot do, and therefore why it leaves the problem of Sections 3–5 unsolved. The point is not that these approaches are worthless — most are prerequisites — but that no combination of them closes the demand of Section 4.3.

Two patterns run through the table. First, every approach is a snapshot or a capability, and the mandate demands a continuous, proven operation; a snapshot cannot satisfy a continuous requirement, and a capability is not an execution. Second, none of the approaches produces independent, portable proof of what was done — the artifact each leaves behind is a document, a format, a report, or an architecture, all of which are assertions of their producer rather than evidence verifiable without trusting that producer. The two gaps that survive every approach are therefore continuous machine-scale coverage and intrinsic proof — which is exactly what Sections 7 and 8 require the response to provide.

7. Why authority and proof must be intrinsic invariants

Sections 3–6 establish two survivors: no conventional approach provides continuous machine-scale coverage, and none provides independent proof. The first survivor forces the response to be agentic; the second, combined with the safety consequences of the first, forces authority and proof to be intrinsic invariants of the operating model rather than features added to it. This section derives those conclusions as consequences of the failures, not as design preferences.

7.1 The response must be agentic

The scale arithmetic (§5) is decisive: a continuously-changing, machine-scale population subject to a recurring, multi-step-per-asset workflow on a fixed deadline cannot be covered by a scarce, linear, human-rate labor supply. The only labor whose rate can meet a machine-scale, continuously-changing target is machine-rate labor — autonomous agents performing discovery, understanding, planning, and re-verification continuously. This is not a claim that agents are better than humans at judgment; it is the narrow claim that the four tasks that dominate the workload (sense, classify, plan, re-check, forever, over the whole estate) are exactly the continuous, estate-wide, machine-scale tasks that only machine-rate execution can keep pace with. Humans remain necessary — to set intent and grant, scope, and revoke authority — but they cannot be the coverage.

7.2 Agency without intrinsic authority is a larger attack surface, not a smaller one

Introducing agents that can change production cryptography introduces a new failure that manual work did not have: an agent that can change cryptography can change the wrong cryptography, or exceed what it was asked to do. Autonomy multiplies both correct and incorrect action at machine rate. If authority is checked after an action — a review, a report, an audit of what the agent did — then the out-of-scope action has already occurred at scale before it is caught, and authority "checked after the fact is authority not enforced." The only design in which an agent cannot exceed its scope is one in which an out-of-scope action fails closed and produces nothing at all — where the bound on authority is a precondition of action rather than a judgment about action already taken. That property cannot be added as a wrapper, because a wrapper can be bypassed, misconfigured, or run after the fact; it must be a structural invariant of how the agent acts. Hence authority must be intrinsic: scoped, delegable, time-bounded, revocable, rooted in a verifiable anchor, and enforced as a fail-closed precondition of every action.

7.3 Agency without intrinsic proof reproduces §3.5 at higher speed

The unprovability failure (§3.5) is not cured by automation; it is worsened. "The agent migrated it" is the same unprovable assertion as "we migrated it," now issued faster and more often. If proof is produced after the work — a reporting exercise that reads back what the agents did — then the evidence is exactly the curatable, issuer-bound artifact that Section 3.5 rejected: evidence gathered after the fact is evidence that can be shaped by the party gathering it. The only proof that survives an adversary and an auditor is proof emitted as a byproduct of doing the work, at the moment of each material change, bound to the authority under which the change occurred, and independently verifiable offline without trusting the issuer for the full retention horizon. That, too, cannot be a later add-on, because anything produced later is separable from the act it purports to describe. Hence proof must be intrinsic: emitted per material change, at the time of the change, as an inseparable product of the transformation.

7.4 Why "add-on" fails as a category

The recurring error the corpus guards against is treating authority and proof as features — modules an organization can procure and attach to an otherwise-conventional automation. The derivations above show why that category is unsound. An add-on authority check is bypassable and after-the-fact, so it does not deliver fail-closed bounding; an add-on evidence layer is separable and after-the-fact, so it does not deliver uncuratable proof. A migration model that treats authority and proof as features rather than invariants therefore does not solve the problem — it reproduces the manual era's ungoverned and unprovable failures at machine speed, which is strictly worse than the manual era, because now the failures scale. The conclusion is forced: authority and proof are not properties the operating model has; they are properties the operating model is built from. An operating model that emits proof and enforces authority as invariants is the minimal structure that answers Sections 3–6; anything less is one of the approaches Section 6 already ruled out, running faster.

8. Problem statement

Post-quantum migration is mandated, estate-wide, and continuous; the methods available today are human-rate, snapshot-based, and unprovable. The problem is not effort but structure. What is required is an operating model in which cryptographic conversion is performed by agents operating at machine scale, bounded by intrinsic authority so they cannot exceed what they were permitted, and emitting intrinsic, independently-verifiable proof of every change — so that "migrated" becomes something an organization can demonstrate rather than merely assert.

The discipline that satisfies this problem statement is defined in APQC-CORE-001 and formalized in APQC-MODEL-003.

9. Not In Scope

This document does not specify how the problem is solved (that is APQC-MODEL-003 and APQC-LIFECYCLE-004), does not endorse any implementation (that is APQC-REFERENCE-010), and does not select cryptographic algorithms (that is NIST's role). It establishes only that the problem is real, structural, and unsolved by current methods, and that its structure forces the two invariants — intrinsic authority and intrinsic proof — that the rest of the corpus builds upon.