Approval Does Not Migrate
Relocating 693 public systems is also a question of what happens to the authority their actions carry
South Korea is preparing to redesign part of its national public-sector information infrastructure. As reported in July 2026, KT has been selected as the preferred bidder for a strategic planning project covering the 693 information systems operated at the Daejeon headquarters of the National Information Resources Service. The work is expected to define relocation criteria and phased migration plans, public data-center operating alternatives, private-cloud usage standards, disaster-recovery arrangements, and the future role of the institution itself — with system importance and the National Network Security Framework (N2SF) shaping which environment is appropriate for each system.
This is important work, and the framing is sound: classify each system, place it in an environment whose security posture matches its sensitivity, and plan the moves in phases. The questions being asked are the right infrastructure questions. Where may this system operate? Which network may it join? What classification applies? How is continuity maintained?
But a migration of this scale also surfaces a question that infrastructure architecture is not built to answer, and it is worth naming before the moves begin rather than after: what happens to the authority carried by actions while the systems that execute them are in motion?
The approval rides in the luggage
Public systems do not necessarily arrive in a new environment as empty installations. They may carry live operational state: pending requests, scheduled jobs, standing data-transfer arrangements, delegated service permissions, and queued actions approved days or weeks earlier. Where those objects are preserved or reconstructed during migration, the approval records attached to them may be carried forward as well.
Here is the structural problem. An approval is issued inside a specific world: a particular hosting environment, a particular network path, a particular service identity, a particular data classification, particular operating restrictions. Migration changes that world. The receiving environment may be a private cloud where the source was a public data center; the network zone changes; the service account executing the action is re-provisioned; a disaster-recovery site may be active; the classification of the underlying data may have been revised as part of the very relocation criteria this project will define.
The approval record can survive all of this untouched. It moves with the workload the way a document moves in a packed box — intact, legible, and referring to a house that no longer exists.
Nothing in the migration process necessarily falsifies the approval. That is precisely the danger. The record remains formally authentic while everything it implicitly assumed may have been replaced. An action executed after the move can present a perfectly genuine approval issued for a world that is gone.
Where the earlier failures converge
This series has examined the components of this problem separately. The operating environment can change after approval, leaving the consent anchored to conditions that no longer hold. Passage through a legitimate channel does not make an action admissible — inside is not the same as authorized. And an action whose scope or identity has shifted is no longer the action that was approved, however continuous the session around it looks.
A mass migration is the place where all of these fire at once, and at scale. Six hundred ninety-three systems can mean thousands of standing approvals, delegations, and scheduled actions crossing environment boundaries through a phased relocation program. Each crossing is a moment where the environment changes, where a compliant new channel may be mistaken for admissibility, and where the executable action may quietly stop being the action that was approved — because a transfer whose destination has moved to a different cloud, under a different service identity, with different data-handling conditions, is a different action wearing the same request.
The migration does not merely move software. It can change the identity of the executable action while leaving its paperwork unchanged.
Re-bind or expire
What should happen at that crossing is not complicated to state. When an action approved in the old world attempts to execute in the new one, something at the execution point has to compare the two.
If the authority basis, the target, the risk class, the conditions, and the operating environment still materially hold, the action can be re-bound to the present and allowed to open.
If they do not, the prior approval should not simply travel with the workload. It should expire. A new action requires a new approval basis — not because the original request was wrong, but because the world that consented to it no longer exists in the relevant respects.
The uncomfortable part is the default. In most operational reality, the default is silent portability: the approval is present, the checks that would question it are not, and the action opens. Expiry has to be designed; portability happens on its own. That asymmetry is why this question belongs in the planning phase of a migration, not in its incident reviews.
What classification cannot decide
None of this is a criticism of N2SF or of the relocation architecture. Frameworks of that kind are essential: they define the security conditions under which systems, networks, and data may operate, and a migration of this scale would be reckless without them.
But a security classification governs the operating space, not the moment of consequence. A compliant cloud does not make every data transfer admissible. A correctly classified network does not make every inherited privilege current. A protected environment cannot certify that the specific action waiting inside it is still the action that was approved, under authority that is still valid, in conditions that still hold. Those are different controls.
One establishes where a system is permitted to run. The other establishes whether an action is permitted to open. The second cannot be derived from the first.
The more public systems adopt AI-assisted and automated operations, the wider this gap becomes. Actions will increasingly be proposed at one time, approved under one environment, queued, and executed after the underlying system has moved. Each of those actions may arrive at execution carrying an approval issued somewhere else.
The question to settle before the boxes are packed
The redesign of 693 public information systems is, on its surface, a question of where each system should go. Underneath, it is also a question of what each system’s pending authority is worth after the move: which approvals survive a change of cloud environment, a network-zone change, a disaster-recovery activation, a service-identity change, or a reclassification — and which ones should be treated as expired the moment the world they referred to was left behind.
Approval does not migrate with the workload.
The record may migrate. The authority it once evidenced does not transfer automatically.
Whether that authority still exists is a question only the execution boundary — checking current authority, current state, current conditions, and the current operating environment at the moment the action opens — can answer.
A secure environment can establish where a system is permitted to operate. It cannot, by itself, establish that the action waiting inside it is still permitted to execute.
Source: reporting on the National Information Resources Service innovation ISP project (KT selected as preferred bidder), Edaily, July 14, 2026. Project details are cited as reported and describe planning-stage arrangements.