From Sensors to an Attestation Record: How Reactor State Is Confirmed

Raw telemetry is data, and data by itself is not proof

A sensor reading is a claim made by equipment the operator owns, carried over a path the operator controls, into a display the operator renders. Nothing in that sequence establishes for an outside party that the value is complete, current, and unaltered. It is perfectly good data for running a plant. It is not, on its own, evidence anyone else can rely on months or years later, because every step of its journey traces back to the party whose performance is in question.

Measurement quality sits upstream of everything else, and the national labs have named what it demands. Oak Ridge identified sensor and instrumentation technologies capable of long-term unattended operation, complete system state awareness, and cybersecurity appropriate to remote monitoring as preconditions for operating microreactors with reduced on-site presence ^[7]. If the measurement layer is thin, no amount of cryptography downstream improves it. Signing a bad number produces a durable record of a bad number.

The transport path matters just as much as the sensor. The IAEA's guidance on computer security of instrumentation and control systems at nuclear facilities treats those systems as protected assets across their life cycle rather than as ordinary information technology ^[9], and the reason is that a compromised I&C path does not announce itself. It produces plausible readings. A viewer looking at a rendered feed has no way to distinguish a healthy plant from a healthy-looking report.

So the chain has to start at measurement, but it cannot end at a screen. It has to end at a record. Model-based cross-checks help here, and we cover that separately in how digital twins fit remote reactor verification, but a model is another input to appraisal rather than a substitute for it.

Appraisal by a party separate from the operator is what turns data into evidence

The second step is appraisal, and the internet already standardized what appraisal means. RFC 9334 defines an architecture in which an Attester produces evidence about its state, a Verifier appraises that evidence against an appraisal policy, and a Relying Party acts on the Verifier's result, built on the premise that one end of a communication needs to know whether the other end is in an intended operating state ^[1]. The separation of those three roles is not incidental. It is the whole design.

Nuclear has the same insight in a different form. The NRC keeps roughly 150 resident inspectors in the field, at least two at every plant, and describes their function as independently verifying that requirements are being met ^[10]. The IAEA safeguards system exists so that an outside body applies its own technical measures to independently verify that facilities are not misused, rather than relying on a state or operator assertion ^[8]. Safeguards address non-proliferation rather than operational safety, so do not overread the analogy, but the structural move is identical: place the checker outside the checked.

Applied to reactor state, appraisal means comparing what the plant reports against what independent measurement shows and what the design permits, then recording the comparison. The property that matters most is unglamorous: disagreement has to be recorded as faithfully as agreement. A system that writes a record only when everything matches is not verifying anything. It is publishing.

That distinction is the subject of a companion piece on self-attestation versus independent verification, and it is the reason verifying an autonomous microreactor is a different job from monitoring one.

Signing and logging are what make an appraisal durable

An appraisal that lives in a database is an opinion with a timestamp. Signing it binds the content to a key, so a later reader can tell whether the bytes changed. That is necessary and still not sufficient, because a signature says nothing about what was not shown. A party holding a set of signed statements cannot tell whether it received all of them, or whether an inconvenient one was quietly withdrawn before anyone looked.

Closing that gap is what append-only transparency infrastructure is for. RFC 9943 describes an architecture in which statements are registered into an append-only service that issues a receipt for each registration, so that the existence of a statement becomes checkable rather than asserted ^[2]. The record stops being something the issuer holds and becomes something the issuer has committed to in a place it cannot silently edit.

The receipt is the portable part. RFC 9942 standardizes receipts as compact cryptographic proofs, carrying inclusion proofs that a given statement is in the log and consistency proofs that the log has not been rewritten between two points in time ^[3]. A holder can check both without contacting the party that produced the statement.

It is worth being precise about what this does and does not establish. A receipt proves what was claimed, by whom, and when it entered the record. It does not prove the reactor was safe. Safety is established by analysis, testing, and regulatory review. What the record contributes is that the account of what happened cannot be quietly revised after the fact to suit the outcome, which is a narrower claim and a more defensible one.

The test that matters is what an outsider can check without the operator's help

The fourth step is the one that decides whether any of the preceding work was real. If checking the record requires the operator to hand something over, stay online, or vouch for something, then the operator is still the source of trust and the architecture is decorative. The useful question is what a party can establish unaided, which is exactly the Relying Party role RFC 9334 separates out ^[1].

This is where a table earns its place, because it says something the four-step chain above the article does not: different parties want different things from the same record.

Every row in the middle column is checkable with the receipt, the verifier's public key, and the log ^[3]. None of it requires the operating organization to be cooperative, solvent, or in existence. Every row in the right-hand column is a reminder that a record is a floor rather than a ceiling. It removes a category of dispute about what was said and when, which frees the harder conversation to be about engineering rather than about whose screenshot to believe.

Records meant to outlive the equipment need post-quantum signatures

A reactor operating record may need to be checkable for decades, and potentially long after the equipment that produced it has been decommissioned and the organization that operated it has been reorganized or dissolved. That makes the choice of signature algorithm a durability decision rather than a security fashion. The question is not only whether a signature is sound today. It is whether a reviewer in the 2050s will still regard the algorithm as sound enough to settle a dispute.

The standards ground has moved recently enough that this is now a concrete choice rather than a speculative one. NIST announced approval of three Federal Information Processing Standards for post-quantum cryptography in August 2024 ^[4], and FIPS 204 specifies a module-lattice-based digital signature standard ^[5]. A signature scheme intended for long-lived records now has a published, standardized option rather than a research paper.

It also pays to be careful about the threat model, because post-quantum marketing tends to blur it. The exposure for signatures is not identical to the exposure for encrypted data. Data captured today and decrypted later is a harvesting problem. Signatures face a different issue: a key that remains in use, or a record that must still be verified long after the algorithm has fallen out of trust, is the thing that ages badly. That argues for algorithm agility and for planning key lifetimes deliberately rather than for treating a single algorithm choice as permanent.

This is the part of the problem where our own hands-on work actually sits, and the tradeoff we accepted is worth stating plainly. Building for signature agility means carrying more than one verification path and accepting the operational overhead of maintaining both. It is slower and more complex than picking one algorithm and moving on. We took the overhead because a record that becomes unverifiable is indistinguishable from a record that was never made.

The evidence is only as trustworthy as the components that produce it

There is a quiet assumption underneath every attestation architecture: that the components doing the measuring, appraising, and signing are the components their manufacturer intended. If a signing module, gateway, or sensor was altered before installation, the resulting record is well formed, correctly signed, verifiable by anyone, and wrong. Cryptography faithfully propagates whatever it is fed.

This is a supply-chain discipline rather than a cryptographic one, and federal guidance for it already exists. NIST SP 800-161r1 sets out cybersecurity supply chain risk management practices for systems and organizations, updated in November 2024 ^[6]. The relevant idea for a reactor evidence chain is that assurance about a component has to be established and maintained across acquisition, integration, and operation, not asserted once at purchase.

The nuclear-specific version of the same point is in the IAEA's I&C computer security guidance, which frames protection of instrumentation and control as a life-cycle obligation covering design, procurement, and maintenance rather than a deployment-time checklist ^[9]. A reactor is a long-lived asset. Components get replaced, firmware gets updated, and vendors change hands, all while the record is expected to remain continuous.

There is a recursion here that deserves an honest word. Attestation about a component is itself an attestation, appraised by something, signed by something else. That regress has to stop somewhere, and where it stops is a design decision with real consequences. We treat the placement of that root of trust as an explicit, documented choice rather than an implementation detail, because a root of trust nobody can name is a root of trust nobody can evaluate.

Tamper-evident means changes are detectable, not that they are impossible

This distinction is worth stating bluntly, because it is the one most often blurred in vendor language. Tamper-evident is a defined property: an alteration to a record, or a withdrawal of one, is detectable by a party who checks. That is a claim about detection. It is not a claim about prevention. Nothing described in this article is tamper-proof, unhackable, or unbreakable, we do not use those words about our own work, and a vendor who does is telling you something about their marketing rather than their architecture.

What detection buys is specific. An altered statement fails signature verification. A statement missing from the log fails its inclusion proof. A log that has been rewritten between two checks fails its consistency proof ^[3], and the registration model that produces those proofs is what makes absence detectable rather than merely suspected ^[2]. The result is not that misconduct becomes impossible. It is that misconduct becomes visible to someone who was not present when it happened.

The obvious objection is that this is over-engineering for a reactor, since nuclear already has among the most demanding recordkeeping and inspection regimes of any industry. The objection is fair and the answer is that the existing regime was built around presence. It assumed inspectors on site who could look, ask, and form a judgment that instrumentation missed ^[10]. Those records were trustworthy in large part because people were standing next to the thing being recorded. As that presence thins, the same obligations travel as data over networks, and the mechanism that made them credible does not travel with them automatically. This is not extra rigor bolted onto a solved problem. It is the existing rigor relocated into a medium that needs different machinery to hold it.

The honest limitation is that none of this fixes a bad input. A faithfully signed record of a miscalibrated sensor is a faithful record of a wrong number, and the chain will confirm that wrong number with perfect fidelity for decades. Calibration, sensor diversity, and validation are separate engineering problems, and they stay separate. Evidence integrity and measurement quality are two different disciplines, and buying one does not get you the other.

Why thinning on-site presence raises the stakes, and where we actually are

The reason this matters more now than it did a decade ago is that the compensating mechanism is being reconsidered. Proposed 10 CFR Part 57 contemplates remote operation and reduced on-site staffing for microreactors ^[11], and the NRC's microreactor regulatory activities page tracks that work as it develops ^[12]. Part 57 is a proposal rather than a final rule, it may change, and no developer is licensed under it. It is also not a move to unattended operation: reactivity and safety actions keep a human in the loop, and we take care not to describe anything as unmanned or fully autonomous, because that is not what is on the table. We walk through that framework in our explainer on Part 57 and autonomous operation.

Meanwhile, the operations side has been advancing faster than the verification side, and it is worth saying so. DOE reported that Idaho National Laboratory demonstrated a digital twin of a simulated microreactor that predicted heat pipe temperatures and then autonomously controlled the heat pipe ^[13], while Oak Ridge's own framing of autonomous operation named the instrumentation and state-awareness preconditions that remain open ^[7]. Capability to run with fewer people is arriving ahead of capability to independently confirm what those systems did, and the gap widens further at fleet scale, where one organization oversees many units.

On where we stand, plainly. RankShield Energy is a pre-applicant engaged in early interaction with the NRC ^[14]. We hold no license, permit, or design approval, and nothing about our design or our attestation architecture has been demonstrated to or accepted by the NRC. The chain described in this article is design intent and an architecture we apply in our attestation engineering work. It is not a deployed reactor capability and not a certified one, and we would rather say that flatly than let the distinction blur.

One further limitation belongs here, since it is the sharpest one we know about our own position. A verifier is only as independent as the witnesses that observe its log, and witnesses an organization hosts itself do not establish independence no matter how they are engineered. External witnesses are the open item, and we do not currently have them. If you are evaluating developers on any of this, the questions in our microreactor vendor evaluation guide should be aimed at us as unsentimentally as at anyone else.