The Encryption Migration Nobody Can Do Overnight: Post-Quantum Inventory, Crypto Agility and the Data Worth Protecting

An evidence-led analysis of what institutions should ask for before declaring their systems ready for a post-quantum future. Reporting checked October 29, 2026. The municipal example and proposed management tools below are explicitly hypothetical, not accounts of an actual organization.

1. A new roadmap is not a magic switch

On October 27, 2026, the US National Institute of Standards and Technology announced its final report on transitioning to post-quantum cryptography. Its publication record identifies NIST IR 8547 as final, and the downloadable report is dated October 2026. This is not the preliminary version circulated in November 2024. The distinction matters: a plan built around an old draft can be wrong even when its footnotes look impressively official. NIST announcement, final publication record.

The practical question is no longer whether an organization can put the words “post-quantum” in a strategy document. It is whether someone can demonstrate which information is protected, which systems remain exposed, who can authorize changes, and what will happen when an upgrade encounters an incompatible dependency. That is an accountability problem as much as a cryptographic one.

For the public, this distinction is unusually important. A person submitting a sensitive document to an institution generally cannot select that institution's cryptographic libraries, inspect its backup arrangements, or negotiate its supplier contracts. The institution makes those choices on the person's behalf. An impressive claim about one visible website therefore deserves a less glamorous follow-up question: what happened to the document after it arrived?

This article argues for evaluating migration through evidence of completed work rather than the drama of a predicted quantum breakthrough. Its proposed tools are an editorial framework, not an official checklist or a substitute for specialist engineering. The framework starts with the information people need protected, follows it through real operational boundaries, and demands a separate receipt for each meaningful improvement.

That approach also leaves room for uncertainty. A program can make measurable progress without claiming that every component is permanently secure. Conversely, a presentation can use all the right algorithm names while leaving the actual service unchanged. The challenge is to distinguish those two situations before public money, private records, and institutional trust are committed to the wrong one.

2. The three clocks that create urgency

The joint CISA, NSA and NIST quantum-readiness factsheet explains the concern often called harvest now, decrypt later: an adversary could retain encrypted information for possible decryption when relevant quantum capabilities become available. Its August 2023 guidance urged organizations to begin roadmaps, inventories, risk assessments and supplier discussions rather than wait for the standards process to finish. This is a planning rationale, not evidence that every encrypted conversation is being collected or that a capable quantum computer already exists. Joint quantum-readiness factsheet.

An accessible way to examine the problem is to separate three clocks. The first is how long information should remain confidential. The second is how long the institution needs to change the systems protecting it. The third is the uncertain arrival of an attacker capable of defeating the relevant existing public-key protection. This three-clock framing is analytical: it helps expose assumptions without pretending to calculate an exact day of failure.

Consider a hypothetical confidential application containing a person's location and family circumstances. Its confidentiality might matter well after the administrative decision is made. A migration project focused only on the application's processing time could therefore underestimate the protection period. The right discussion would include the people responsible for the record and its consequences, not just the team operating the server.

Now suppose the system supporting that application cannot be upgraded until a replacement contract is awarded. Even if nobody can supply a credible date for the third clock, the second clock is already running. Each procurement delay consumes time that would otherwise be available for integration, testing and correction. Uncertainty about quantum capability does not eliminate a known institutional lead time.

There is an equally important limit to this argument. It does not justify treating every dataset as equally urgent or every security purchase as necessary. A useful decision record should state the assumed confidentiality period, the reason for that assumption, the plausible consequences of disclosure, and the evidence behind the estimated migration effort. Where those answers are unknown, the honest output is a research task with an owner, not a manufactured numerical risk score.

3. Three standards, different jobs

NIST's three August 2024 standards do not describe interchangeable products. FIPS 203 specifies ML-KEM, a mechanism for establishing a shared secret over a public channel. That secret can then support symmetric cryptography used to protect communications. The standard offers three parameter sets, but choosing among them belongs within a reviewed system design rather than a competition to pick the largest number. FIPS 203.

FIPS 204 specifies ML-DSA for digital signatures. A signature addresses authenticity and unauthorized modification; it does not conceal the signed contents. FIPS 205 specifies another signature family, SLH-DSA, using a stateless hash-based construction. These are different cryptographic tools with different operational roles, not three names for an upgraded version of ordinary file encryption. FIPS 204, FIPS 205.

NIST subsequently published SP 800-227 in September 2025 to address the properties, applications and secure use of key-encapsulation mechanisms. Its existence is a useful reminder that an algorithm specification and guidance for putting an algorithm into a secure system answer different questions. An implementation still needs a surrounding protocol and carefully defined conditions of use. NIST SP 800-227.

For a non-specialist purchasing committee, the operational translation is simple. Ask what security function a promised feature performs. Does it change the way a connection establishes secrets? Does it change the signatures checked before accepting a software update? Does it affect a document's long-term verification? Or is the supplier describing a capability present in a library but not enabled in the purchased service?

Those questions prevent a common category error: allowing success in one workstream to certify another. If a pilot improves the confidentiality of a particular network connection, that is valuable. It is not, by itself, evidence about a separate signing service or a disconnected archive. A migration dashboard should preserve those distinctions instead of collapsing every technical achievement into a single green light.

The most useful language is deliberately narrow: this version, this configuration, this connection, this security purpose, this observed test. Precision can sound less exciting than an all-purpose assurance. For the people relying on the service, however, an assurance with a clearly described boundary is more meaningful than a grand promise whose boundary cannot be found.

4. A filled inventory record exposes the missing connection

Consider an entirely fictional municipal service called Harbor Records. Residents submit sensitive applications through a web portal. An edge service receives each upload and forwards it to a case-management application. A separate contractor reviews selected documents. Everything about this architecture, its releases, its records and its test results is invented for the worked example. It is not an audit of any actual municipality or product.

Instead of writing “portal: encrypted” in a spreadsheet, the fictional team creates a record for one connection. The following is a filled example, not a recommended production configuration:

The twenty-year assumption is intentionally conspicuous. A system inventory cannot legitimately invent a confidentiality period merely because a technical owner needs a number. If the records owner later determines that different document classes need different treatment, the row should be divided or its scope revised. The example's number is not a legal retention recommendation.

The row also separates transport from signatures. It is possible to ask a precise question about one connection without asserting that every cryptographic function in the service has changed. A future reviewer can see what this record measures and what it explicitly leaves outside its boundary.

Three other fictional rows prevent RS-02 from standing in for the whole service: RS-01 covers the resident-to-edge connection, RS-03 covers delivery to the reviewer, and RS-04 covers the archive's preservation requirements. If only RS-01 passes its tests, the result is one improved boundary. The team cannot turn that result into a claim about the document's entire journey.

Finally, the “unknown” field changes the next action. The platform engineer does not need another presentation about quantum threats. The engineer needs the contractor's release mapping and permission to run the agreed test. The inventory has converted a broad concern into a specific dependency that can be resolved, costed or escalated.

5. Use that record to choose the next experiment

Harbor Records has three options in this fictional exercise. It could update its public-facing connection, investigate the edge-to-API boundary, or commission a replacement for the contracted review process. The right order cannot be inferred from which option produces the most impressive demonstration. The team needs to identify which experiment will change its understanding of the service.

Suppose the public-facing update is already supported in the lab, while the API contractor has supplied a software package without the production configuration. The review contractor has not yet answered any migration questions. These are invented conditions, not allegations about real suppliers. They produce three different tasks rather than three equally meaningful red boxes.

For RS-01, the task is an interoperability test against the actual supported client set. For RS-02, the task is evidence reconciliation: does the proposed lab package correspond to a configuration the contractor will support in production? For RS-03, the task is to establish what exists before estimating the work of changing it. Paying for a replacement before obtaining that answer might be premature; treating silence as proof of readiness would be equally unsound.

The team writes a small decision table. RS-01 may proceed to a bounded pilot if its client tests pass. RS-02 remains on hold until the configuration mapping arrives. RS-03 gets a contractual information request with a named response owner. RS-04 goes to the records and signing specialists because a connection upgrade cannot settle archive-preservation requirements. These are proposed decisions for the example, not official migration stages.

Now change one assumption. Imagine that the API contractor confirms the production configuration cannot support the proposed change without replacing a shared component. RS-02 no longer represents a small setting adjustment. Its dependency may affect other applications, require a different maintenance window, or change the purchase decision. The inventory row should record the new evidence and reopen the estimate rather than preserve an obsolete green forecast.

This is the value of a bounded experiment: it can disprove the team's initial plan before that plan becomes an expensive commitment. The example does not require a numerical probability of a quantum breakthrough. It requires observable answers about current systems, together with an explicit account of the data that justified examining those systems first.

The office should preserve the rejected option as well as the chosen one. “No replacement authorized because supportability remains unknown” explains a decision. “Waiting on vendor” merely names a delay. When the answer arrives, the former tells the next operator exactly which decision must be revisited.

6. Read the deadlines with their jurisdiction attached

The final NIST report sets out deprecation of quantum-vulnerable public-key cryptography after 2030 and disallowance under NIST standards and guidelines after 2035. It also describes earlier federal requirements for high-value, high-impact and other priority systems, including key establishment by December 31, 2030, and signatures by December 31, 2031. Those distinctions should not be flattened into a claim that every organization everywhere has one identical deadline. They should also not be used to tell sensitive federal systems that they can simply wait until 2035. NIST IR 8547, section 4.

The UK's National Cyber Security Centre provides a separate planning framework: discovery, goals and an initial plan by 2028; early priority migrations and a refined roadmap by 2031; completion across systems, services and products by 2035. Its guidance is principally aimed at large organizations, critical infrastructure and bespoke IT. It acknowledges particularly difficult technologies. These are migration milestones, not a scientific prediction that a quantum attacker will appear on a particular calendar date. NCSC migration timelines.

The analytical lesson is to attach a jurisdiction, audience and status to every date in a project plan. Is the date a binding requirement applicable to this institution, an official recommendation, a supplier commitment, or an internal target? A timeline assembled without those labels can look orderly while mixing fundamentally different obligations.

Consider a multinational supplier selling a shared platform to several kinds of customers. It might publish one product roadmap, while customers face different assurance needs and procurement processes. A customer should not infer that the roadmap automatically satisfies its own obligations. Equally, a supplier should not present the most permissive deadline in one context as permission to ignore more demanding requirements elsewhere.

For public oversight, the useful question is therefore not simply “Will you finish by 2035?” It is “Which milestones apply to which systems, what must precede them, and what evidence shows that the preceding work is on schedule?” This moves the discussion from a distant finish line to the decisions that could already make that finish line unattainable. Compliance specialists should confirm applicability; a general article cannot determine an individual institution's legal duties.

7. Crypto agility is controlled change, not unlimited choice

NIST's crypto-agility white paper, updated June 29, 2026, describes the ability to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and operations. That definition includes continuity. It is not satisfied merely because a configuration file contains a long list of algorithms. NIST CSWP 39 update 1.

A proposed acceptance test for agility would ask the institution to demonstrate a controlled change in a representative environment. Who approves the policy? How is the allowed configuration distributed? How does the organization discover systems that failed to adopt it? What stops an emergency compatibility exception from becoming the undocumented permanent default? These are management questions with technical evidence behind them.

The hypothetical office could rehearse a small change without pretending that it has migrated the whole service. The rehearsal would produce a before-and-after configuration record, observed connection results, an exception list, and a recovery procedure. Its value would lie in learning where control breaks down. Finding a forgotten integration during a rehearsal is cheaper institutionally than discovering it during a hurried emergency, even when no responsible estimate of the monetary saving is available.

Agility also requires restraint. Allowing every application owner to improvise a cryptographic construction would not constitute a healthy change process. The editorial recommendation here is to make approved paths easy to adopt and departures visible to qualified reviewers. The institution needs a way to change its choices without making every employee responsible for designing those choices.

There is a staffing implication as well. If only one person knows how to modify a critical configuration, a successful test performed by that person is incomplete evidence of organizational capability. The office should test the instructions, not just the expert. Another authorized operator should be able to understand the documented procedure, identify when to stop, and find the person empowered to resolve an unexpected condition.

This is why agility is better understood as a repeatable capability than as a purchase. A product may contribute necessary mechanisms. The organization must still supply ownership, documentation, review and practice. The meaningful outcome is not that change is theoretically possible, but that the next justified change can be made without reconstructing the entire institution's memory from scratch.

8. A hybrid claim needs a protocol, not a slogan

The IETF's informational RFC 9794 defines post-quantum/traditional hybrid schemes as constructions combining both kinds of algorithms. The intended security property is that defeating the construction requires defeating its components, subject to how it is designed. The document also cautions that the label post-quantum describes intended properties, not a guarantee that an algorithm can never be compromised. RFC 9794.

There is now a concrete standards-track example for TLS 1.3. Published in August 2026, RFC 10024 specifies three hybrid key-agreement mechanisms combining ML-KEM with an ephemeral elliptic-curve exchange: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. A defined protocol mechanism is more specific than a vendor's statement that its portfolio contains both classical and post-quantum technology. RFC 10024.

The purchasing implication is to ask which mechanism the actual connection uses, not merely which mechanisms are available somewhere in the stack. A system may contain a feature without negotiating it on the connection under examination. That distinction should be settled with appropriate test evidence from an authorized environment, rather than a screenshot of a product's general capabilities page.

In the hypothetical office, the engineer would document the client, server, intermediaries and relevant versions used in each test. The resulting record would describe what was observed and under which conditions. A successful modern-client test would not be silently generalized to every older device. An unsuccessful test would not automatically condemn the algorithm; it would initiate investigation of the actual path.

Hybrid design also should not become an invitation to invent a homemade combiner. Buying two locks is not the same as designing a secure door, and combining cryptographic outputs is not made safe by the intuition that more ingredients must be better. The office's requirement should be support for a reviewed, applicable construction with maintained implementations, not a marketing demonstration assembled to satisfy a fashionable keyword.

Finally, the report should separate confidentiality improvements from other security functions. Demonstrating a selected hybrid key agreement on a connection answers a bounded question. It does not independently establish the status of every certificate, signature or application-level authorization decision surrounding that connection. The responsible claim is narrower than “the entire website is quantum-proof,” and much more useful.

9. What real protocol documentation teaches about boundaries

Signal's published PQXDH specification offers a useful example of careful scope. The revision last updated January 23, 2024 describes post-quantum forward secrecy while explicitly retaining a discrete-logarithm assumption for mutual authentication in that revision. The document is evidence about the specified protocol version, not a current audit of every Signal deployment or a claim about the application's complete security in October 2026. Signal PQXDH specification.

Apple's February 2024 technical account of PQ3 describes a different messaging design that includes post-quantum key establishment and continuing rekeying. Its explanation discusses the additional communication overhead associated with the post-quantum ratchet and the design choices made around it. These are Apple's documented design claims, not independent certification by this article or a ranking of messaging products. Apple's PQ3 technical account.

The useful comparison is not a contest over which brand wins. It is that a serious specification names the property being protected and the conditions under which the claim holds. That level of specificity should influence institutional procurement. A buyer should be able to ask whether a claim concerns initial session establishment, subsequent updates to secrets, authentication, recovery after compromise, or something else entirely.

This matters even when the institution is not building a messaging application. A label can move too easily from a precise technical discussion into a broad procurement slide. By the time it reaches a budget committee, the caveats may have disappeared while the confidence has increased. The committee should ask for the underlying document and have an appropriate specialist explain its boundaries in ordinary language.

One practical editorial recommendation is to require a short “not covered” paragraph beside each major security claim. A supplier describing a connection upgrade could identify the interfaces, configurations or security functions outside that upgrade's scope. The buyer could then decide whether those exclusions are acceptable or require additional work. This is not an allegation that a particular supplier is hiding anything; it is a method of making honest claims easier to compare.

The hypothetical office would preserve that paragraph through testing and reporting. If the product changes, the scope statement would change with it. Over time, this creates a record of actual capability rather than a collection of promotional phrases that remain in circulation long after their original technical context has been forgotten.

10. Test the service people use

The IETF's June 2026 informational RFC 9958 explains that the shift to post-quantum algorithms can affect protocols and infrastructure, potentially requiring redesign rather than a simple replacement of one mathematical primitive. Its engineering perspective is a reason to test the complete service, not to assume that an isolated algorithm benchmark answers every operational question. RFC 9958.

For the hypothetical office, a proposed test matrix has four dimensions: the supported client, the connection path, the service operation and the failure condition. A client might be an approved browser or an integrated application. A path might include an institutional intermediary. An operation might be submitting a document or retrieving a decision. A failure condition might involve an unavailable dependency or an interrupted session. Exact cases would be selected by the service's engineers, not copied blindly from this example.

Each test needs a result that can fail. “The demonstration looked good” is not an acceptance criterion. The office could instead require that a defined transaction succeeds, the expected security configuration is observed, relevant errors are recorded, and the user receives a comprehensible result. Where performance matters, the team should agree on service-specific thresholds before running the test, not invent a favorable threshold after seeing the results.

Capacity deserves its own evidence. A quiet demonstration does not establish behavior during the service's busiest legitimate workload. Nor does testing on a powerful development machine establish behavior on every supported endpoint. The office should measure the conditions it actually intends to support, document the limits of the measurement, and avoid presenting a laboratory result as an institution-wide guarantee.

Recovery should be tested with equal care. If the change causes an outage, who can stop the rollout, what configuration is restored, and how will any security tradeoff be recorded? A recovery path that silently abandons the intended protection creates a different risk from a recovery path whose temporary limitations are visible and approved. The test report should make that distinction explicit.

The point is not to demand impossible certainty before any improvement can occur. It is to make the experiment informative. A useful pilot narrows uncertainty, identifies the remaining work and leaves evidence another qualified person can examine. A polished demonstration that cannot be reproduced does none of those things.

11. Put assurance documents beside the configuration they cover

NIST's Cryptographic Module Validation Program FAQ distinguishes a validated module from a larger product that incorporates it. It says the larger product is not thereby validated and that correct use of the embedded module lies outside that validation's scope. CAVP and CMVP also do not test an industry protocol's compliance with the protocol standard. These are boundaries on assurance, not reasons to dismiss it. NIST CMVP FAQ, P-17 and SG-6.

Return to the fictional RS-02 row. Its supplier submits three items: a product brochure, a module-validation reference and a lab configuration export. No actual certificate number or vendor is invented here. The exercise concerns the relationship among the documents, not a claim that a fictional component holds a real validation.

The reviewer creates a crosswalk with four questions. Does the assurance document identify the component actually included in the offered release? Does its scope correspond to the security service being claimed? Does the configuration use that component for the relevant operation? Does the transaction test demonstrate the intended behavior on this boundary? Each question needs its own evidence; a favorable answer to the first does not automatically answer the remaining three.

Suppose, as an invented result, the release mapping agrees but the configuration export does not identify which provider handles the selected operation. The appropriate finding is not “validation failed.” It is “integration evidence incomplete.” That wording matters because it tells the supplier what to supply next without misrepresenting the assurance document itself.

Suppose instead that the mapping and configuration agree, but the test shows a different negotiated group from the one required by the pilot. The unresolved issue is now observed behavior. The reviewer should preserve the test inputs and result, investigate the mismatch and avoid approving the transaction merely because the paperwork was convincing.

A successful review would retain both kinds of evidence: what the component's assurance establishes and what the institution observed in its own configuration. Neither is a substitute for the other. This crosswalk gives a purchasing committee a concrete way to distinguish a missing document, a mismatched release and an unsuccessful integration—three problems that need different remedies.

12. Signatures and archives deserve their own workstream

Long-term evidence preservation is not a problem invented by the current migration. RFC 4998, published in August 2007, specifies Evidence Record Syntax for supporting evidence of data's existence and integrity over long periods. Its relevance here is the longstanding distinction between possessing a file and preserving the evidence needed to assess that file later. It is background, not a claim that the old RFC is a complete post-quantum migration recipe. RFC 4998.

In the hypothetical office, a decision document might need to be read and assessed years after it was created. The team should ask what a future reviewer will need: the document, its context, the relevant verification evidence, and an understandable account of any preservation actions. These are requirements to investigate with records and cryptographic specialists, not instructions to re-sign every old document indiscriminately.

A careless migration could confuse preservation with replacement. Suppose a new export process changes a document's representation and discards the original supporting material. The office may have produced a convenient new file while making the historical record harder to interpret. This invented scenario illustrates why a successful conversion test must examine meaning and evidence, not merely whether the output opens.

Software updates raise a different set of questions. The office should identify which systems decide whether an update is authorized, who controls the relevant signing process, and whether the receiving systems can change their verification capabilities through a supported procedure. These questions do not establish that any particular device is unupgradeable. They establish what the institution needs to learn before promising that a software update will solve every dependency.

The practical recommendation is to maintain separate milestones for connection protection, signing workflows and long-term records. They can share expertise and governance, but they should not share an ambiguous completion label. A network team should not accidentally become responsible for archival policy simply because both subjects involve cryptography.

This division also helps explain cost. Some work may be an ordinary platform update. Other work may require changes to workflows, contracts or preservation practices. A budget that treats all of these as identical installations will struggle to explain its own delays. Naming the distinct jobs early is a way to protect both the project and the people whose records depend on it.

13. Write the supplier's deliverable so it can fail

For the invented RS-02 purchase, “support post-quantum cryptography” is too vague to test. The fictional office instead asks for a release-specific evidence package. Qualified engineering and procurement staff would decide whether these example requirements are appropriate; this is not model contract language or legal advice.

The first deliverable is a component map linking the supplied API release to its cryptographic implementation and supported configuration. The second is a protocol statement identifying the mechanism used on the edge-to-API connection, with prerequisites and limitations. The third is a reproduction procedure that lets an authorized reviewer repeat the transaction and inspect the negotiated result without accessing residents' real documents.

The fourth deliverable is a failure-handling statement. It must identify whether an unsupported peer causes the transaction to stop or allows an approved alternative, and how the operator can tell which happened. The fifth is a recovery procedure with a specific configuration version, authorization path and statement of what protection would be lost during recovery. These are proposed requirements for Harbor Records, not a claim that one fallback policy fits every service.

The acceptance meeting can now ask concrete questions. A reproduction procedure that works only on an unidentified engineering build is incomplete. A compatibility claim that omits the intermediary on the purchased connection is outside the stated scope. A recovery procedure that restores service but fails to describe the resulting security configuration is missing decision-critical information.

Consider an invented supplier response: the requested behavior is available in the test build, but production support will begin in a later release. That answer is useful if recorded accurately. The office can change its schedule, narrow the pilot or evaluate another supported option. It should not rewrite “planned production support” as “production supported” because the demonstration succeeded.

The evidence package also makes competing bids more comparable. One supplier may include the mapping and test support while another expects the customer to reconstruct them. That difference belongs in the estimate of integration work. A lower license price does not settle the comparison, and neither does a higher price establish superior security.

When support eventually changes, the same five deliverables provide a bounded update request. The office can ask what changed in the implementation, protocol behavior, reproduction procedure, failure policy and recovery path. Procurement has produced a maintainable record rather than a one-time slogan.

14. A worked interoperability and recovery test

The following lab exercise is entirely fictional. Its architecture, thresholds and observations are invented to demonstrate how pass/fail evidence should be written. No software was deployed, no real system was tested, and these results establish nothing about any vendor's product. The example concerns only RS-02, not the other three Harbor Records rows.

The imagined setup contains an Edge client, an API server and one intermediary. Test build H is configured to support the selected hybrid group; test build L is deliberately configured not to offer it. These are capability definitions within the example, not claims about named browsers or operating systems. The payload is a synthetic application document containing no personal information.

Before testing, the fictional team agrees that this sensitive pilot connection must not silently fall back to traditional-only key agreement. If a peer cannot meet the pilot policy, submission must stop with a clear error. A different service might approve a different policy; this example's choice requires an availability plan for affected users.

T1 does not cancel T2. The normal path worked, but an unsupported peer bypassed the fictional policy. The team must correct the configuration or redesign the pilot before claiming that this boundary enforces its stated requirement. It also needs a usable alternative submission route; rejecting an incompatible client is not by itself a complete public-service solution.

T3 checks an application consequence rather than an algorithm property. A network-security improvement that duplicates submissions or sends false receipts can still harm the people using the service. Its pass is confined to one precisely described scenario, not evidence that every recovery case works.

T4 shows why recovery includes truthful status. Restoring availability may deliberately return the service to an earlier security posture. The operator needs to know that posture and obtain the required authorization. A stale green indicator would conceal the tradeoff from the person deciding whether to resume traffic.

The test packet would retain the configuration identifiers, synthetic input, negotiated-group evidence, observed response and reviewer decision for each case. After correcting T2 and T4, the team would repeat those tests and the relevant successful cases to check for regressions. The earlier failures would remain in the history, marked resolved only when new evidence supports that conclusion.

15. Report the result without inflating it

After the fictional first round, Harbor Records has four inventory boundaries and four executed test cases for one boundary. Two cases passed and two failed. It has not achieved fifty percent migration, and it has not established fifty percent security. Test cases are different questions, not interchangeable units of protection. A percentage calculated from their outcomes would conceal the importance of the failed policy and recovery checks.

An accurate public summary could say: the office mapped the pilot service, tested the edge-to-API connection in a lab, and identified two conditions requiring correction before that connection is accepted. It could separately state that contractor information and archive requirements remain unresolved. That communicates progress without publishing sensitive operational details or pretending that a lab exercise protected real records.

Once the failures are corrected, the next claim should remain bounded: the stated configuration passed the defined acceptance tests for RS-02. Production rollout, operational monitoring and the other service boundaries remain separate decisions. Readers should be able to see when each claim became justified and which evidence supports it.

The broader lesson is not that institutions need longer reports. They need reports whose nouns remain stable. A component is not a service. A supported capability is not an observed negotiation. A successful transaction is not proof that failure handling is correct. A completed connection upgrade is not completion of a signing or archival workstream.

Post-quantum standards make the technical destination more concrete, but they do not erase these distinctions. The useful response is a sequence of specific improvements: identify the boundary, state the requirement, test behavior, resolve failures and report the remaining limits. That is slower than attaching a quantum-ready label. It is also the kind of work that another person can examine, reproduce and improve when the next change arrives.