Even after a system stops, customers' rights, incident evidence, and the responsibilities of those in charge must remain verifiable. The editorial in KCBCA Signals Issue 2 examines cyber resilience from this perspective. Its first task is the transition to post-quantum cryptography (PQC, Post-Quantum Cryptography).
When quantum computers will break cryptography is uncertain, but transition preparations must come earlier.
In tokenization, the normal functioning of smart contracts alone is also insufficient to assess the safety of financial infrastructure. Even on 'the day after the operator disappears,' organizations must check whether assets in custody remain segregated, rights in insolvency are protected, and settlement finality across ledgers is assured.
The editorial introduces the shared challenges of 13 contributions. It does not set detailed criteria or numerical benchmarks. This article organizes those challenges and examines the review records to retain in practice.
Five challenges and the burdens of transition and response
The editorial addresses five challenges. They are the transition to post-quantum cryptography, the automation of attack and defense, responsibility for ciphertext harvesting attacks (HNDL, Harvest Now Decrypt Later), infrastructure conditions for tokenization, and governance that adapts to technological change. Their common point is that protection and responsibility must continue even when existing security assumptions fail.
The burdens of transition must first be examined. Moving to NIST-standard algorithms ML-KEM, ML-DSA, and SLH-DSA, or to Korea's KpqC, is more complex than a simple software update. Larger keys and signatures bring latency, packet fragmentation, and blockchain transaction fee burdens.
Endpoint compromise and breaking signature cryptography must also be distinguished as different attack paths.
The difference in speed between attacks and responses is another problem. Generative AI accelerates reconnaissance, impersonation, and social engineering, while AI-assisted testing finds weaknesses even in mature software. As the cost of finding vulnerabilities falls, development and operations teams have more work to handle.
More findings offer little benefit without the capacity to prioritize, fix, and verify them.
Reviewing long-retained information and tokenized assets
HNDL is the threat of collecting encrypted communications now and attempting to decrypt them later. Considering only how long the current system will be used is insufficient. Intellectual property, clinical records, and institutional information may need to remain confidential for longer.
The editorial proposes clarifying transition plans and responsibility for this information and reviewing actual insurance terms.
Mosca's relationship (X + Y > Z) is a planning model that examines protection gaps by comparing the sum of the information protection period and the cryptographic transition period with the time remaining until quantum capabilities arrive. It neither precisely predicts the arrival of quantum computers nor shows that records have already been decrypted.
For tokenization, an operational shutdown is considered. The exercise proposed by the editorial is 'the day after the operator disappears.' Before committing capital, organizations check the segregation of assets in custody, rights in insolvency under UNIDROIT principles, and settlement finality across ledgers.
Evidence and responsibility records to retain with every change
The final challenge is how governance should respond to technological change that outpaces regulation. The contributors propose the following. Core duties concerning customer asset protection, responsibility, and remedies belong in primary legislation, while technical standards belong in mechanisms that can be changed flexibly.
Rather than relying solely on periodic audits, organizations reassess when smart contracts are upgraded, new tokens are listed, or unusual cross-chain fund flows occur. Automated decisions require understandable explanations, verifiable evidence of fairness, and avenues for appeal.
Simply writing 'no issues' in review results leaves no supporting evidence. Organizations must record who checked what and when, and which event prompted reassessment. This allows the judgments and responsibilities at that time to be checked after the next incident.
Confirmed facts and assumptions must also be distinguished when recording incident causes. The original distinguishes a company's provisional announcement about an October 29 incident at a major exchange from an independent analysis by a security firm. The common issue is a weakness in withdrawal authority.
This is not evidence that blockchain cryptography was broken. The timing of quantum capabilities and the resources required also remain uncertain.
Sample cyber resilience review records — compiled by KCBCA
| Review item | Record to retain | Responsible party or verification channel | Review focus |
|---|---|---|---|
| Action after finding a vulnerability | Priority, remediation, and verification results for each finding | Security and development teams' remediation queue | Response capacity |
| Protection period for long-retained information | Protection period, transition plan, and insurance terms review results for each information type | Information security officer; reporting to the board | HNDL |
| Preparation for operational shutdown | Verification results for asset segregation, rights in insolvency, and settlement finality | 'The day after the operator disappears' exercise | Tokenization |
| Event-triggered reassessment | Reassessment triggers and results | Change management; supervisory reporting | Response to change |
| Automated decisions | Explanatory materials, fairness evidence, and appeal handling records | User appeals channel | Basis for decisions |
Distinctions to make in practice
Incident prevention and responsibility after an incident
The absence of an incident alone makes resilience difficult to judge. Even when a system changes or collapses, rights must remain verifiable, evidence must be preserved, and responsibility must be assessable. Resilience reviews also include protection and remedies after an incident.
Periodic reviews and reassessment following changes
Organizations must check whether the assumptions of a previous review remain valid. A smart contract upgrade or a new token listing should trigger reassessment. Applying an old judgment unchanged after a system has changed can leave new risks overlooked.
Basic verification procedures for individuals and practitioners
The editorial proposes verifying requests through a separate channel, simulating transactions before signing, and separating service accounts from personal accounts. Even a familiar voice and face on a video call must be considered potentially a real-time deepfake.
What to retain from reviews
- Rights, evidence, and responsibility that remain verifiable after an incident
- A cryptographic transition plan that considers information protection periods
- Conditions for handling assets and settlement during operational shutdown
- Review owners, supporting evidence, and reassessment triggers
Read the full issue free: https://signals.kcbca.ca/
Read the editorial: https://signals.kcbca.ca/signals/read/#page=5
References KCBCA Signals Vol.1 Issue 2 · JJ Park; editorial “Trust That Survives Failure”, p.5–8
