# Trusting a Remotely Operated Nuclear Reactor Safely

> Remote operation splits the operator from the core. Learn the two trust gaps this opens, verified commands and verified state, and how each is being addressed.

[Resources](https://rankshieldenergy.com/resources) / Autonomy & Part 57 Autonomy & Part 57

# Trusting a Remotely Operated Reactor: The Command and State Problem
Published July 23, 2026 · Updated July 24, 2026 · By [Jamie Kloncz](https://rankshieldenergy.com/authors/jamie-kloncz), Founder, RankShield Energy

HELIX microreactor, concept render. RankShield Energy is at the pre-application stage; this depicts a design under development, not an operating facility. Remote operation splits the operator from the core: the people running the reactor are no longer standing next to it. That separation opens two distinct trust gaps. The command gap is whether the instruction the reactor carried out is the one the operator actually sent. The state gap is whether the condition the reactor reports back is its real condition. Verified commands and verified state are the two things an outside party has to be able to check, and neither is solved by trusting the network link. Safety-significant actions keep a human in the loop, and no facility today is licensed to operate unattended.
When a reactor is operated from outside the site boundary, the physics of the core do not change, but the path between the operator's intent and the reactor's behavior gets longer, and every link in that path is something a regulator, insurer, or grid operator now has to be able to trust. In July 2026, Idaho National Laboratory and university partners demonstrated remote, real-time autonomous power control of a research reactor, with the reactor's safety systems retaining control throughout the test [[1]](#src-1). That result shows the operating model is becoming real. It also sharpens the two questions that follow it: was the right instruction received, and is the reported condition true?
RankShield Energy is a pre-applicant with the NRC, engaged in early regulatory interaction and holding no license or approval. This article is educational. It defines remote operation as command and control from outside the site boundary, distinct from monitoring, then takes apart the command gap and the state gap in turn, compares them, reads the July 2026 demonstration honestly, and sets out where the regulation stands, against a current rule that assumes an operator at the controls and a proposed Part 57 that is not yet final [[8]](#src-8). The reactor's own safety systems and the human in the loop are one layer; independent confirmation of commands and state is a separate layer, and it is the one this post is about.
Key takeaways

- Remote operation is command and control from outside the site boundary, which is distinct from monitoring and opens two trust gaps.
- The command gap is proving the reactor carried out the instruction the operator actually sent, unaltered and in order.
- The state gap is proving the condition the reactor reports back is its real condition, not a stale or spoofed reading.
- Both gaps are verification problems: they are closed by evidence an outside party can check, not by trusting the link.
- Current rules require an operator at the controls; proposed Part 57 contemplates reduced staffing but is not final, and no facility is licensed to operate unattended.

## What does remote operation actually change?
Remote operation means issuing command and control from outside the site boundary, over a communications link, rather than from a control room on the plant. That is a narrower thing than it sounds, and the first useful move is to separate it from monitoring. A regulator can watch data leave a site without anyone off site being able to change what the reactor does. Human factors researchers working with the NRC draw exactly this line, treating offsite monitoring and remote operation as distinct activities with different demands on the people involved [[6]](#src-6). Monitoring observes; remote operation acts.
On-site operation keeps intent and action in one room. An operator moves a control, watches the instrument respond, and confirms both firsthand. Remote operation breaks that loop into pieces joined by a network: the instruction travels to the reactor, and the reactor's response travels back, and neither leg is something the operator witnesses directly. Oak Ridge described the shape of this well before it became topical, noting that remote and centralized control rooms change where operators sit relative to the plant they run [[2]](#src-2).
The engineered safety systems still act locally, and safety-significant actions keep a human in the loop; no facility today is licensed to operate unattended. Current rules assume presence, requiring a licensed operator to be at the controls [[7]](#src-7). What changes under remote operation is the basis for trusting the day-to-day operating picture. More of the operating case now rests on two flows of messages, the commands going out and the state coming back. For a consequential system, trusting those messages is not the same as verifying them, and it helps to keep remote operation distinct from the neighboring ideas of automation and autonomy, which a companion piece on [what those terms actually mean](https://rankshieldenergy.com/resources/automation-remote-autonomous-reactor-terms) takes up. The next two sections take the outbound and inbound flows in turn.

## The command gap: how do you prove the reactor got the instruction the operator sent?
The command gap is the risk that the instruction the reactor acts on is not the instruction the operator meant to send. Closing it means making each command something the reactor can confirm as genuine before acting, and something an outside party can check afterward. In practice that has three parts. First, the command carries proof of who issued it, so the reactor can reject anything not from an authorized operator. Second, it is protected against alteration in transit, so a message changed on the way is detected rather than obeyed. Third, each command is recorded in order, so a replayed or reordered instruction cannot pass as fresh.
This is not a new class of problem. Computer security settled its shape years ago in the internet's attestation architecture, published as IETF RFC 9334, which formalizes the idea that a relying party should act on evidence it can appraise rather than on an unverified assertion [[9]](#src-9). Applied to a reactor, the operator proposes an action, but the reactor and any independent verifier act on a command whose origin and integrity can be confirmed.
Oak Ridge, studying the licensing implications of autonomous control, found that the reach of these questions goes well past staffing: it extends into manipulation of controls, licensed-operator provisions, technical specifications, cybersecurity, and required notifications, with the control room possibly not co-located with the plant [[3]](#src-3). Each of those touches the command path. In our own attestation engineering at RankShield, the recurring lesson is that the hard part is not signing a command but making the record of what was commanded checkable by someone who is not the operator, which is the same separation described in [self-attestation versus independent verification](https://rankshieldenergy.com/resources/self-attestation-vs-independent-verification-reactors). All of this is design intent, subject to analysis, testing, and NRC review; nothing here has been demonstrated to or accepted by the NRC.

## The state gap: how do you prove the reactor's reported condition is real?
The state gap is the mirror image of the command gap. Once a command has been carried out, the operator needs the reactor's actual condition, and outside the control room that condition arrives as reported data rather than direct observation. Verified state is the continuous, checkable confirmation that the condition the reactor reports is its real condition, and not a stale reading, a dropped update, or a value altered in transit.
The mechanics parallel verified commands. The reported state carries proof of where it came from, it is protected against alteration on the way back, and it is recorded so a regulator, insurer, or lender can inspect it later. The same attestation logic applies, in which a relying party appraises evidence about a system rather than taking the system's word for its own status [[9]](#src-9). There is a mature precedent for placing this kind of check outside the reporting party. International safeguards exist so an outside body can independently verify a facility's declarations through its own technical measures, rather than relying on an operator's assertion [[12]](#src-12). Safeguards address non-proliferation, not operational safety, so the analogy is structural rather than exact, but the structural point holds: for a claim that matters, the party confirming it sits outside the party making it.
The engineering preconditions are real. Turning a raw sensor stream into a record an outside party can trust involves instrumentation that survives long unattended operation and a defensible chain from sensor to signed statement, which is the sequence walked through in [turning reactor state into an attestation record](https://rankshieldenergy.com/resources/reactor-state-sensors-attestation-record). The point is durability of trust. A live dashboard shows what the operator's software chooses to show right now. Verified, recorded state tells an outside party, later, what the reactor actually reported, in a form that does not depend on the operator vouching for itself.

## How do the two gaps compare?
The two gaps are symmetric in structure and opposite in direction. One protects instructions traveling to the reactor; the other protects condition data traveling back. Laying them side by side makes the shared remedy visible: in both cases the fix is not trusting the link but producing a record an outside party can check. The appraise-the-evidence model of RFC 9334 is the common thread [[9]](#src-9).

The command gap and the state gap, compared across what each is, what can go wrong, and how it is addressed

Aspect
Command gap
State gap

What it is
Proving the reactor carried out the instruction the operator actually sent
Proving the condition the reactor reports back is its real condition

Direction of flow
Outbound: operator to reactor
Inbound: reactor to operator and outside parties

What could go wrong
An unauthorized, altered, replayed, or reordered instruction is obeyed as if genuine
A stale, dropped, spoofed, or altered reading is trusted as current truth

How it is addressed
Origin proof, tamper-evidence in transit, and ordered recording an outsider can check
Origin proof, tamper-evidence on the return path, and recording an outsider can inspect later

Who needs to check it
Regulator, insurer, lender, grid operator
Regulator, insurer, lender, grid operator

Reading the table across rather than down is the useful exercise. The failure modes differ, but the remedy is one idea applied twice: replace an act of trust with a piece of evidence. That is why command and state verification are usually built as one system rather than two, and why the honest measure of a remote-operation claim is not how good the dashboard looks but what an outside party can reconstruct without the operator's help. The proposed regulatory framework for this class of reactor contemplates exactly the reduced-presence models that make this evidence matter, which the next sections take up [[8]](#src-8).

## What did the July 2026 INL demonstration show, and what did it not?
Remote reactor control has moved from concept to demonstration. In July 2026, Idaho National Laboratory and university partners achieved remote, real-time autonomous power control of a research reactor, with the reactor's safety systems retaining control throughout the test [[1]](#src-1). That is a national-laboratory demonstration of the operating model, run on a research reactor under laboratory conditions. It is not a demonstration of any commercial reactor's safety, and it is not RankShield Energy's result.
It helps to be precise about what a result like this establishes. It shows that operating a reactor across a network is feasible while local safety systems keep control, and it was performed by a national lab whose broader microreactor program, including the MARVEL test reactor, is aimed at exactly this kind of experiment [[14]](#src-14). What it does not establish is that the command and state flows have been independently verified in a form a buyer, regulator, or insurer could check for themselves. The demonstration proved the operating capability. It did not, and did not claim to, prove independent verification of the record.
That second piece is the open frontier, and the honest framing for every serious developer, including us, is design intent subject to testing and regulatory review. The digital-twin approaches that make autonomous control possible on the operations side are further along than the independent-verification approaches that would let an outsider confirm the result, an asymmetry examined in [digital-twin verification of remote operations](https://rankshieldenergy.com/resources/digital-twin-verification-remote-reactor-operations). Reading the demonstration as proof of a trustworthy remote reactor would overstate it; reading it as proof that the operating model is reachable is exactly right.

## Where does the regulation actually stand?
The regulatory picture is best stated as a gap between what the rules require today and what a proposed rule would allow. Today, a licensed operator must be present at the controls; the conditions of an operating license assume on-site, at-the-controls presence [[7]](#src-7). That baseline is backed by an oversight system built on human presence. The NRC stations resident inspectors at operating plants, at least two per site, whose stated role is to independently verify that requirements are being met [[10]](#src-10), inside a Reactor Oversight Process that combines inspection findings with performance indicators [[11]](#src-11).
Against that baseline, the NRC published a proposed rule in May 2026, a new 10 CFR Part 57, that would set licensing requirements for microreactors and reactors with comparable risk profiles, and that contemplates remote operation and reduced on-site staffing with human responsibility retained for safety-significant actions [[8]](#src-8). The agency's microreactor regulatory-activities pages place this rulemaking within a broader modernization effort for the reactor class [[13]](#src-13). The single most important fact about Part 57 is its status: it is proposed, its comment period has run, and no developer is licensed under it. A neutral reading of what it does and does not say is set out in [our explainer on proposed Part 57](https://rankshieldenergy.com/resources/nrc-part-57-autonomous-operation-explained).
The direction of travel is clear, and so is the distance still to cover. Reduced presence is contemplated, not authorized. The oversight model that presence supports, independent verification by inspectors on site, does not vanish when staffing thins; it has to be reconstituted in another form. That is the regulatory reason command and state verification matters, rather than a purely technical one: as human presence is proposed to decrease, the mechanism that presence provided has to be replaced by something an outside party can still check.

## Isn't this a problem the reactor's own safety systems already solve?
A fair objection runs like this: the reactor's engineered safety systems act locally and independently of the network, so if a bad command arrives or a reading is wrong, the plant's own protection should hold regardless. Why layer verification on top of that?
The response is that the two do different jobs. Engineered safety systems keep the reactor inside safe physical limits; they are the reason a corrupted command should not be able to cause harm. Command and state verification is about trust in the operating record, which is a separate question the safety systems do not answer. An insurer underwriting the plant, a lender financing it, and a regulator overseeing it all need to know what was commanded and what the reactor reported, in a form they can check without taking the operator's word. Safety systems protect the reactor; verification protects the account of what happened. Both are needed, and neither substitutes for the other. Human factors work for the NRC on facilities without traditional main control rooms frames the core question precisely, as confirming that important human actions can be accurately and reliably performed under these new arrangements [[5]](#src-5).
The honest limitation is this. Independent verification of remote operation is, across the industry, less mature than the operating capability it is meant to check. Sandia, working for the NRC, has mapped the human-factors demands of automating microreactors, including models where one control room supervises several units, and that body of work describes requirements more than it describes finished solutions [[4]](#src-4). RankShield is no exception. We can describe the architecture, and we can point to the attestation engineering behind it, but describing an architecture is not the same as having demonstrated it under regulatory review, and we would rather say that plainly than blur it.

## Where does this leave RankShield Energy?
RankShield Energy is a pre-applicant with the NRC. We hold no license, permit, or design approval, and nothing about our design has been demonstrated to or accepted by the NRC. Verifier-operator separation, applied to both the command flow and the state flow, is the architecture we are building toward and the reason this site exists. It is not a certified capability, and we do not present it as one.
Stated as a position that can be argued with: a vendor cannot be its own independent verifier, and that stays true of us. It is why we treat the separation as structural rather than as a feature to be bolted on later. The tradeoff is real and worth naming. A separate verifier costs more to stand up, adds a party to coordinate with, and creates a body that can publicly contradict the operator. We think that last property is the point rather than a defect, because a verifier that can never disagree with you is not verifying anything. That is a design decision we have made and are willing to defend, including what it gives up.
Two things keep this honest. Remote and autonomous operation are demonstrated capabilities at the national-lab level, not settled commercial reality, and no facility today is licensed to operate unattended; safety-significant actions keep a human in the loop. And the independent-verification layer we care about is a direction of work, not a finished product. If you are evaluating developers on any of this, the questions worth asking, and worth turning back on us just as hard, are collected in [how to verify an autonomous microreactor](https://rankshieldenergy.com/resources/verify-autonomous-microreactor-operating-safely). The distinction between what has been demonstrated and what has been claimed is the whole of the argument, and it should be applied to us without sentiment.

## Frequently asked questions

### What are the two trust gaps in remote reactor operation?
They are the command gap and the state gap. The command gap is the risk that the instruction the reactor acts on is not the one the operator sent, whether through alteration, replay, or an unauthorized source. The state gap is the risk that the condition the reactor reports back is not its real condition, whether through a stale reading, a dropped update, or a value changed in transit. Both are verification problems rather than only engineering problems, because closing them means giving an outside party something it can check [[9]](#src-9). The reactor's own engineered safety systems and the human in the loop for safety-significant actions are a separate and additional layer.

### How is the command gap actually closed?
By making each command confirmable rather than merely trusted. The command carries proof of who issued it, so the reactor can reject anything not from an authorized operator; it is protected against alteration in transit; and it is recorded in order, so a replayed or reordered instruction cannot pass as fresh. This mirrors the internet's attestation architecture, in which a relying party acts on evidence it can appraise rather than on an unverified assertion [[9]](#src-9). The aim is a record of what was commanded that a party other than the operator can check afterward.

### Is a remotely operated reactor unmanned?
No. Remote operation moves some operators away from the site; it does not remove people from the safety picture. Safety-significant actions keep a human in the loop, and no facility today is licensed to operate unattended. Current rules require a licensed operator at the controls [[7]](#src-7), and the proposed Part 57 framework contemplates remote and reduced-staffing models with human oversight retained, a rule that is proposed rather than final [[8]](#src-8). RankShield Energy does not describe its work as unmanned or fully autonomous, and neither term should be read as a settled reality or as this company's claim.

### Has remote reactor operation actually been demonstrated?
Yes, at national-lab scale. In July 2026, Idaho National Laboratory and university partners demonstrated remote, real-time autonomous power control of a research reactor, with safety systems retaining control throughout [[1]](#src-1). That demonstrates the operating model on a research reactor under laboratory conditions. It is not a demonstration of a commercial reactor's safety, and it is not RankShield Energy's result. Independent verification of the command and state flows, in a form an outside party can check, remains an open area of work across the industry.

### Does RankShield Energy verify commands and state today?
No, not as a deployed or certified capability. We are a pre-applicant with the NRC holding no license, permit, or design approval, and nothing about our design has been demonstrated to or accepted by the NRC. Verifier-operator separation across the command and state flows is the architecture we build toward and our reason for existing, but describing an architecture is not the same as having demonstrated it under regulatory review. The proposed framework this sits inside is itself still proposed and subject to change [[8]](#src-8), and we would rather say all of that plainly than let the distinction blur.

## Sources

- [Idaho National Laboratory. Researchers achieve remote, autonomous power control of a research reactor in real time. July 2026](https://inl.gov/news-release/researchers-achieve-remote-autonomous-power-control-of-a-research-reactor-in-real-time/)
- [Oak Ridge National Laboratory. Nuclear: Remote-controlled reactors. April 2019](https://www.ornl.gov/news/nuclear-remote-controlled-reactors)
- [Oak Ridge National Laboratory. Licensing Challenges Associated with Autonomous Control (ORNL/SPR-2018/1071). December 2018](https://www.osti.gov/biblio/1492160)
- [Sandia National Laboratories. Human Factors Considerations for Automating Microreactors (SAND-2020-5635). June 2020](https://www.osti.gov/biblio/1763526)
- [Brookhaven National Laboratory for the U.S. NRC. Review of Reactor Facilities without Main Control Rooms (BNL-227637-2025-INRE). February 2025](https://www.osti.gov/biblio/2529385)
- [U.S. NRC and Idaho National Laboratory. Characterizing the Human Factors of Offsite Monitoring and Remote Operation for the Nuclear Domain. NPIC&HMIT, June 2025](https://inl.elsevierpure.com/en/publications/characterizing-the-human-factors-of-offsite-monitoring-and-remote/)
- [U.S. Government Publishing Office. 10 CFR 50.54(m), Conditions of licenses. 2024 CFR edition](https://www.govinfo.gov/content/pkg/CFR-2024-title10-vol1/xml/CFR-2024-title10-vol1-sec50-54.xml)
- [U.S. Nuclear Regulatory Commission. Licensing Requirements for Microreactors (proposed 10 CFR Part 57). Federal Register, May 1, 2026 (91 FR 23628)](https://www.federalregister.gov/documents/2026/05/01/2026-08550/licensing-requirements-for-microreactors-and-other-reactors-with-comparable-risk-profiles)
- [Internet Engineering Task Force. RFC 9334: Remote ATtestation procedureS (RATS) Architecture. January 2023](https://www.rfc-editor.org/info/rfc9334/)
- [U.S. Nuclear Regulatory Commission. Backgrounder on NRC Resident Inspectors Program. Accessed July 2026](https://www.nrc.gov/reading-rm/doc-collections/fact-sheets/resident-inspectors-bg)
- [U.S. Nuclear Regulatory Commission. Reactor Oversight Process Framework. Accessed July 2026](https://www.nrc.gov/reactors/operating/oversight/rop-description)
- [International Atomic Energy Agency. Basics of IAEA Safeguards. Accessed July 2026](https://www.iaea.org/topics/basics-of-iaea-safeguards)
- [U.S. Nuclear Regulatory Commission. Microreactors: Regulatory Activities. Updated May 2026](https://www.nrc.gov/reactors/new-reactors/advanced/modernizing/microreactors/reg-activities)
- [Idaho National Laboratory. MARVEL Project. Accessed July 2026](https://inl.gov/marvel/)

## Related

- [Automation, remote operation, and autonomy explained →](https://rankshieldenergy.com/resources/automation-remote-autonomous-reactor-terms)
- [Self-attestation versus independent verification →](https://rankshieldenergy.com/resources/self-attestation-vs-independent-verification-reactors)
- [How to verify an autonomous microreactor →](https://rankshieldenergy.com/resources/verify-autonomous-microreactor-operating-safely)

Written by
Jamie Kloncz
Founder, RankShield Energy
Jamie leads the HELIX microreactor pre-application program and RankShield Energy's verification-first approach to advanced-reactor operations. [More about the author](https://rankshieldenergy.com/authors/jamie-kloncz)

*This guide reflects the state of remote reactor operation and NRC rulemaking as of July 2026. Proposed rules for this class of reactor are not final and may change. This area is evolving rapidly; check back if the rule is finalized or if the NRC issues new guidance.*
**About this article.** RankShield Energy is a pre-applicant engaged in early regulatory interaction with the U.S. Nuclear Regulatory Commission (NRC). Nothing here should be read as a representation that any RankShield Energy design, product, or facility is NRC-approved, licensed, or certified, or that any safety, performance, or operational characteristic has been demonstrated or accepted by the NRC. Descriptions of reactor and system behavior reflect design intent and are subject to analysis, testing, and regulatory review. This article is for general educational purposes and is not engineering, legal, regulatory, or investment advice.

A note on how we write about our own reactor
HELIX is in pre-application development. Where this article touches our design, every figure is a design target and every physics result is unqualified screening, labeled as such. We cite authoritative sources (NRC, DOE, IAEA, national laboratories) and never invent statistics.
RankShield Energy · HELIX · pre-application