Microreactor Cybersecurity, Explained: Digital I&C and the New Threat Model

Reactor cybersecurity is a safety problem, not an ordinary IT problem

The short answer is that a compromise of the wrong system in a reactor can have physical, not just informational, consequences, and that changes everything about how the risk has to be treated. In ordinary enterprise IT, the worst outcome of an intrusion is usually loss of data, money, or availability. In a reactor, the systems being protected are the instrumentation and control that read plant state and move equipment, so the failure surface includes physical processes rather than only records.

This is why nuclear cyber guidance is written around consequence rather than around convenience. The NRC's Regulatory Guide 5.71 sets out a cyber security program for power reactors that centers on the systems whose compromise could affect safety, security, and emergency preparedness functions, and it builds defensive architecture and controls around exactly those functions ^[2]. The point is not to secure everything equally, but to identify the systems where a digital compromise becomes a physical problem and to protect those most strongly.

The regulator's own framing keeps cyber tied to the same protective mission as physical security, and its cyber security resources describe the objective as protecting digital systems and networks associated with safety and security functions ^[1]. That is a narrower and more demanding target than "keep the network safe." It means the threat model has to reason about how a manipulated sensor value or a spoofed command could propagate into the plant.

Advanced reactors sharpen this because they lean harder on digital instrumentation and control than the analog fleet did, and the NRC has published dedicated guidance for digital I&C in that context ^[7]. The more of the plant that is mediated by software, the more the safety case depends on the integrity of that software and the data moving through it. Treating that as a generic IT problem would miss the part that actually matters, which is why verifying that a microreactor is operating safely has a cyber dimension that a conventional security audit does not fully cover.

Why the old air gap no longer protects a microreactor

The honest answer is that the air gap was always partly an assumption, and modern microreactor concepts weaken the parts of it that were real. The traditional mental model was that safety-significant systems sat on isolated networks with no path to the outside world. Two forces erode that: the systems now update, phone home, and integrate with monitoring far more than legacy analog equipment did, and the components arrive through long, global supply chains that carry their own risk before anything is ever connected.

Supply chain is the part that gets underweighted. A component can be compromised in development, manufacturing, or distribution, well before installation, which is why federal guidance now treats cyber supply chain risk as a first-class program rather than an afterthought. NIST SP 800-161r1 lays out practices for managing that risk across the acquisition life cycle, including provenance, integrity, and the assurance of components sourced from third parties ^[8]. For a reactor built from digital modules, the boundary you are defending starts at the supplier, not at the fence line.

The international standards community reached the same conclusion from the I&C side. IEC 62645 defines requirements for security programs for computer-based systems in nuclear power plants, and it is built around the reality that these systems have life cycles, dependencies, and update paths that must be governed rather than assumed away ^[3]. It treats security as a program property of the whole system, not a perimeter you draw once.

The IAEA guidance is more explicit still about where the exposure lives. Its Nuclear Security Series No. 33-T addresses computer security of instrumentation and control systems at nuclear facilities and works through the life cycle from design through decommissioning, including the interfaces and remote access paths that a purely perimeter-based model tends to ignore ^[4]. Put together, the guidance points one direction: for a digital, connected, globally sourced microreactor, "isolated and therefore safe" is not a claim anyone can make at face value, and the threat model has to assume paths in rather than assume them away.

How autonomy and remote operation widen the attack surface

The direct answer is that every function you move from a person in a control room to software over a network becomes something that can be attacked over that network, and microreactor economics push hard toward exactly that shift. Reduced on-site staffing, remote monitoring, and centralized fleet operation are what make small reactors financially plausible, and each of those design moves converts a physical, local action into a digital, remote one that now has to be secured and verified.

The national laboratories have mapped what this disturbs. Oak Ridge, in its concepts for autonomous operation of microreactors, describes control approaches that reduce human intervention and lean on sensing, state awareness, and remote supervision, and it names the cybersecurity of those monitoring and control paths as a precondition rather than a detail ^[13]. Autonomy does not remove the human decision so much as move it, and it adds a data path that must be trustworthy for the moved decision to be sound.

Sandia, working on human factors for automating microreactors, examined designs where operators supervise from a distance and where a single control room may oversee multiple units, and it treated the reliability of the human-automation interface as a safety-relevant question rather than a usability nicety ^[14]. When one operator supervises several reactors through screens fed by remote data, the integrity of that data becomes part of the safety story, which is the through-line of fleet-scale verification with one operator and many reactors.

The regulatory frame is catching up to this. The proposed 10 CFR Part 57 rule contemplates licensing microreactors with operating models that include remote and reduced-staffing operation, and it is a proposal rather than a settled requirement ^[12]. None of this removes the human from reactivity and safety actions, and it should not be read that way. It does mean the attack surface now includes the command, monitoring, and attestation channels that carry operation across a distance, and those channels did not exist in the staffed analog plant. That is explained neutrally in our walkthrough of Part 57 and autonomous operation.

The standards landscape at a glance, with status

The most important thing to get right about this landscape is status: some of it is existing guidance, some is an international consensus standard, and one central piece is still a proposal. Conflating those is the most common error we see, so the table below separates what a document is from how settled it is. Reading a proposed rule as a present-day requirement, or a research project as a standard, produces bad decisions.

Two rows deserve emphasis. The proposed 10 CFR 73.110 is a technology-neutral cyber rule that remains under development and is not final or prescriptive, so it should be read as where the NRC may be heading and not as a requirement in force ^[1]. RG 5.71 is the existing guidance that the current power fleet actually works from, and it is the concrete reference point when people ask what "good" looks like today ^[2].

The international layer runs in parallel rather than underneath. IEC 62645 supplies consensus program requirements ^[3], NSS 33-T supplies life-cycle guidance ^[4], and the IAEA's coordinated research project J02021 is explicitly aimed at the SMR and microreactor case, which tells you the specialist questions for this reactor class are still being researched rather than resolved ^[5].

Why the standards point toward independent attestation

Read together, these documents keep circling the same requirement: a party that relies on a system needs evidence about that system's state that does not simply come from the system's own operator. That is the definition of attestation, and the general-purpose computing world has already standardized the architecture for it, which is why it is worth borrowing rather than reinventing.

RFC 9334, the Remote Attestation Procedures architecture, formalizes the split cleanly: an Attester produces evidence about its state, a Verifier appraises that evidence against a policy, and a Relying Party acts on the Verifier's result, on the premise that one party needs to know whether another is in an expected operating state before trusting it ^[10]. Mapped onto a reactor, the operator is not asked to be believed; the operator is asked to produce evidence a separate party can appraise, which is exactly the shape self-attestation versus independent verification describes.

The supply chain problem has an analogous emerging pattern. RFC 9943 sets out an architecture for trustworthy and transparent digital supply chains using signed statements recorded on an append-only transparency service, so that a later party can check what was claimed and when, without trusting the claimant to have been honest after the fact ^[11]. For a reactor assembled from digital modules, that maps directly onto proving what software and components went in and stayed in.

Durability is the piece people forget, and it is where cryptography choices become a long-horizon decision. Records meant to outlive a reactor design cycle have to survive advances in computing, which is why NIST's approval of post-quantum signature standards in 2024 is relevant to a nuclear conversation at all ^[9]. None of this makes a system "unhackable," and we do not use that word, because it is not a property any real system has. Attestation does something narrower and more useful: it makes divergence between claim and reality detectable by someone other than the party making the claim. That is the property the standards keep reaching for.

What is settled versus what is still proposed

The honest summary is that the direction is clearer than the destination, and it is worth being precise about which is which. What is settled: reactor cyber is a safety-linked discipline, RG 5.71 is the working baseline for the power fleet, and the international standards for computer-based I&C exist and are referenced. What is not settled: the technology-neutral rule aimed at this class, and much of the microreactor-specific detail, is still in development.

The proposed 10 CFR 73.110 illustrates the gap exactly. It is a proposal under development, technology-neutral in intent, and it is not final or prescriptive, so a vendor cannot truthfully say it complies with a rule that does not yet exist in final form ^[1]. The same discipline applies to the licensing frame around it: proposed Part 57 is a proposal whose provisions may change through the rulemaking process, not a set of requirements in force ^[12].

Staff analysis is another place precision matters. The NRC staff paper SECY-24-0008 on micro-reactor licensing and deployment lays out options and considerations for how this reactor class might be licensed, and it is staff analysis rather than a Commission decision or an adopted policy ^[6]. Reading a SECY paper as settled agency position is a common and consequential misread, because the staff can analyze a path the Commission does not ultimately take. We treat these documents as signals of direction and open questions, not as commitments.

So the defensible posture, and the one we hold, is to design toward where the guidance is clearly pointing while stating plainly that the specific rules for microreactor cyber are not final. That is not hedging for its own sake. It is the difference between a claim that survives contact with a docket and one that does not, and it is the standard we apply when we help others evaluate a microreactor vendor on exactly these questions.

A counterargument, stated plainly and answered

The strongest objection to all of this deserves to be stated in its own words rather than a strawman. It runs like this: nuclear operators already run mature cyber programs under existing NRC guidance, the fleet has a strong operational record, and adding an independent attestation layer is expensive complexity that duplicates controls the operator already has. On this view, self-run cyber programs plus regulatory inspection are sufficient, and a separate verifier is a solution in search of a problem.

That objection has real force for a staffed plant, and we do not dismiss it. Where it weakens is precisely the shift this article is about. When operation moves to remote and reduced-staffing models, the local human checks that quietly backstopped a self-run program thin out, and more of the assurance has to travel as data across a network the attacker can reach. The labs studying autonomous and automated operation flag the integrity of exactly those monitoring and control paths as a precondition, not a side issue ^[13][14]. An independent appraisal of state is not duplicating the operator's controls; it is covering the failure mode where the operator's own reporting path is the thing that is wrong.

The second half of the answer is that the specialist questions here are openly unresolved, which cuts against declaring any current program sufficient for this reactor class. The IAEA is running an active research project specifically on the computer security of SMRs and microreactors, which is a strong signal that the field itself does not consider the microreactor case closed ^[5]. The NRC's dedicated digital I&C guidance for advanced reactors exists for the same reason: the digital, autonomous case raises questions the analog fleet did not have to answer ^[7]. Our position, stated so it can be argued with, is that independent attestation is a hedge against an assurance gap that autonomy widens, and that the burden of proof sits with anyone claiming a self-run program alone closes it. This is where turning reactor state into an attestation record stops being abstract.

Where RankShield sits, honestly, and one limitation

To be clear about our own standing: RankShield Energy is a pre-applicant engaged in early interaction with the NRC. We hold no license, permit, or design approval, and nothing about our design or our attestation approach has been demonstrated to or accepted by the NRC ^[15]. Independent, verifier-separate attestation of reactor and I&C state is a concept we apply in our engineering work, not a deployed or certified capability, and we will not describe it as one. We do not claim to meet any finalized cyber standard, because for this reactor class the central rule is still proposed and under development.

Where our actual first-hand experience lives is worth naming precisely, because it bounds what we can honestly assert. Our working domain is attestation and verification engineering: independent verifiers, signing, append-only transparency logs, and post-quantum signature choices. That is real hands-on work, and it is the lens through which we read the reactor cyber problem. It is also not reactor operating experience, which we do not have and do not claim, and none of it removes the human from reactivity and safety decisions.

The honest limitation is this: attestation proves properties of records and system state, and it is only as meaningful as the sensors and the appraisal policy behind it. A verifier can prove that a signed measurement was recorded and not altered, and that it matched a stated policy at the time. It cannot, by itself, prove that the underlying sensor was correctly calibrated or that the policy captured every failure worth catching. Those are engineering and analysis problems that sit upstream of the cryptography, and any vendor telling you attestation alone makes a reactor secure is overselling it. We would rather draw that boundary ourselves than have a regulator or a customer draw it for us.

So the defensible claim, and the only one we make, is narrow: as microreactors move toward autonomous and remote operation, the standards landscape is pointing toward evidence a party other than the operator can check, the specific rules for this class are not yet final, and we are building toward the verifier-separate version of that architecture as a pre-applicant with everything still to prove. That is less exciting than a guarantee, and it is the version that will still be true after the rulemaking closes.