Authors: Amit Pawar (Xage Security), Bill Lawrence (ITEGRITI), Michael Sanchez (ITEGRITI), Tushar Trivedi (LTIMindtree)

In part one of this series, we provided an overview of the U.S. nuclear cybersecurity baseline, explaining what 10 CFR 73.54, Regulatory Guide 5.71 (Rev. 1), and NEI 08-09 require, and why these regulations have become increasingly significant as advanced reactors are deployed to support hyperscaler power requirements for AI and cloud data centers.

In part two, we shift the focus from interpreting the guidance to operationalizing it under real-world delivery pressures. This blog serves as a practical operating model for executives and program leaders, presenting six key implementation disciplines to meet NEI 08-09 and RG 5.71 expectations without destabilizing advanced reactor project deployments.

We will also discuss how applying Zero Trust principles, using technology solutions, like the Xage Fabric Platform, can support the consistent operationalization of these controls throughout new deployments, and do so without compromising the high-assurance posture mandated by 10 CFR 73.54.

CDA Boundary Design: Scope Early, Keep It Stable

One of the first steps in a nuclear cyber program is defining the Critical Digital Assets (CDAs) and their boundaries. In advanced reactors (with extensive digital instrumentation and control systems), the “digital boundary” can be large and complex. It is crucial to scope that boundary early––during design––and keep it as stable as possible through commissioning and operation. Why? Changes in what is considered a CDA or where the protected boundary lies can trigger costly redesigns or re-approval delays. As part one noted, the key question is no longer “do we have digital?” but rather where the digital asset boundary sits and how CDAs are identified and isolated. To implement this theme:

• Start identification early: Inventory all digital systems that support safety, security, or emergency functions, and classify which are CDAs as early as the conceptual design stage. NEI 08-09 provides a template for this classification, aligned to NIST controls.
• Define a clear security perimeter: Establish a well-defined boundary around those CDAs (logical and physical) beyond which any connection is considered untrusted. This could mean a dedicated network enclave or subnet for plant protection systems and their support systems (which RG 5.71 Rev.1 now explicitly includes as part of CDA scope).
• Avoid scope creep: Resist adding systems into the CDA boundary unless absolutely necessary. A stable scope means your protection strategy and documentation remain valid. If new interfaces must be added (e.g. data links to a data center or cloud service), channel them through well-defined, mediated points (more on that in segmentation) so the core boundary doesn’t constantly shift.

By establishing and stabilizing the CDA boundary early, advanced reactor programs can design security in from the start, and prevent scope volatility from becoming a late-stage redesign driver. This proactive approach lays the groundwork for everything else––you know exactly which assets need the rigorous protections of 10 CFR 73.54. An identity-based Zero Trust architecture reinforces this boundary by requiring authentication and policy enforcement for every cross-boundary interaction, eliminating assumptions of internal trust. 

Defense-in-Depth Segmentation: Zones, Conduits, and No “Temporary” Pathways

A core principle in NEI 08-09 and RG 5.71 is a defensive architecture built around zones and conduits. The intent is straightforward: segment networks so that Critical Digital Assets sit behind multiple enforced protection layers, and require that only tightly controlled communications pass through controlled mediation points.

In practical terms, this is defense-in-depth segmentation. You divide the OT environment into discrete security zones, typically aligned to criticality, and route all inter-zone data flows through approved conduits or mediation points such as firewalls, data diodes, and secure gateways.

There are three implementation points that matter most:

• Design layered zones: Group systems by criticality and security level, with the highest-impact CDAs placed in the most protected zone. Each zone needs hardened boundaries, and trust between zones should be minimal by design. This structure forces an attacker to clear multiple barriers instead of moving freely once inside.
• Use chokepoints for conduits: Any connection between zones should pass through a controlled chokepoint. A chokepoint can be a gateway, firewall, secure access broker, or a brokered data exchange point. The job of that chokepoint is to force traffic through a narrow, observable path where authentication, filtering, protocol enforcement, allow-listing, and monitoring can be applied consistently. Outbound plant data should flow through mediated paths such as a diode or broker. Inbound maintenance access should land through a controlled entry point, not a direct link into protected systems.
• Eliminate “temporary” backdoors: Fast-moving projects create shortcuts for testing and troubleshooting. A firewall rule left open, a direct vendor tunnel brought online, a diagnostic path that never gets removed. These are the connections that become a permanent risk. Unmediated pathways cannot be accepted as an end state. If data needs to move to external platforms, route it through an intermediary in a DMZ or data broker that pulls information out securely, rather than allowing inbound access to the plant.

Done well, segmentation satisfies the defense-in-depth expectations of the guidance and also aligns naturally with modern Zero Trust. Instead of assuming internal networks are trusted, Zero Trust treats every cross-zone interaction as something that must be explicitly verified and governed. Each conduit becomes a policy enforcement point. Only authenticated and authorized flows are permitted, and nothing gets access by default. This discipline is what prevents temporary engineering shortcuts from becoming permanent regulatory exposure.

Identity-based segmentation is what makes this defensible at scale. It replaces “network proximity” as the trust model with explicit policy decisions tied to identity, asset, and session context. In other words, cross-zone access only happens through an enforcement point that can authenticate, authorize, mediate protocols, and generate evidence. That is the model the Xage Fabric Platform is built for. It helps operators keep the boundary intact while still enabling the small set of approved interactions they actually need, with sessions that are narrow, time-bound, and auditable.

Privileged Access and Vendor Operations: Speed Without Standing Access

Even with strong segmentation, there will be moments when internal teams, OEMs, EPC partners, and integrators need to cross boundaries to maintain, patch, or troubleshoot systems that qualify as CDAs. That is expected. What cannot become normal is standing privileges or open-ended remote access.

NEI 08-09 expects strict access control for CDAs, and part one emphasized a simple rule: access must be explicit, time-bound, and auditable. The operational challenge is enabling necessary work quickly without creating persistent trust.

Programs that scale treat privileged access as a governed workflow, not a standing entitlement:

• Just-in-time, just enough, time-bound access: No user should have permanent administrative access to critical systems. Privilege should be granted only for a defined task, to a defined target, for a defined window. When the window closes, access closes.
• Step-up verification and session-level control: Network reachability is not authorization. Whether the user is onsite or remote, accessing a CDA should require step-up verification and an explicit policy decision. That means strong authentication, least-privilege entitlements, and session controls that match the risk. For higher-risk work, sessions should be constrained and observable. File transfer, clipboard access, and tool usage should be limited to what the task requires.
• Centralized revocation and an operational kill switch: Operators must be able to terminate a session or revoke access immediately if something looks wrong, without scrambling to change firewall rules in the middle of an incident. Hard-coded accounts and unmanaged vendor credentials have no place in a high assurance environment.

If you implement an agentless secure access platform such as Xage that unifies zero trust secure remote access and privileged access management capabilities, a traditional VPN is not required. Access is brokered through policy, tied to identity, and granted only to the specific asset and protocol approved for the job. The transport mechanism is secondary. What matters is that authorization happens at the moment of access, and the session remains accountable from initiation to termination.

Change Control Under Compressed Timelines: Govern Change Without Slowing Delivery

Commissioning and early operations are where change velocity is highest. That is also where controls drift, because teams optimize for schedule and treat cyber review as a downstream task.

The answer is to embed change control into the agile processes so that speed and security can coexist.

What works: 

• Defined update gating: Every change to CDA-adjacent systems needs a defined review and approval path. Make it fast, make it consistent, and make it non-optional.
• Configuration drift management: NEI 08-09 emphasizes maintaining a baseline configuration for each CDA and tracking any changes Define what “known good” looks like, then detect and reconcile drift continuously. Drift is how environments quietly become ungovernable. Use tools that regularly scan configurations and detect drift from the approved baseline. 
• Emergency change protocols: Emergency change procedures that remain compliant. Emergencies happen. The right answer is a documented emergency process that captures the rationale, the approver, and the post-change validation.

The strongest programs treat change control as an engineering reliability discipline. It protects the schedule by preventing configuration drift, late-stage rework, and audit findings that surface during critical commissioning windows.

Continuous, Audit-Ready Evidence Collection

Nuclear programs are not only judged on controls. They are judged on evidence. The best way to reduce audit overhead is to stop treating evidence as a separate activity. 

A practical evidence model includes:

• Log everything that matters: Identify the events that constitute security-significant actions on your CDAs and supporting systems. This typically includes access attempts (successful and failed), changes to configurations, software update installations, file transfers, security system alerts (e.g. an AV or IDS alert), and any use of emergency accounts or procedures. Enable detailed logging on control systems, network devices, and security appliances. Where native logging is weak, consider compensating controls like network monitoring to catch anomalies.
• Centralize and correlate logs: Implement a central log management or SIEM that can correlate and complete a story. Logs are not evidence until you can connect them to identity, asset, and intent. This is where consistent identity and session control pays off.
• Inspection-grade reporting on demand: You want to produce proof of access controls, change approvals, and segmentation enforcement without manual log hunting. If a regulator asks for remote access activity for a defined period, you should be able to answer with a query, not a spreadsheet exercise. The goal is to be able to, at any moment, produce evidence like “show me all remote access sessions in the last 90 days” or “prove that your backup protection system has not been accessed by anyone except the authorized admins.”

A platform approach helps when it makes the access and policy trail verifiable by design. For example, Xage can provide a cryptographically verifiable audit trail for access and policy changes, so evidence is reliable and difficult to tamper with. More broadly, the goal is the same regardless of tooling: evidence should be a natural byproduct of how the program operates.

Supply Chain Security Enforcement

Advanced reactor programs depend on a broad supply chain, including I&C vendors, OEM software and firmware, integrators, cloud services, and remote support. That ecosystem is now part of the attack surface. The integrity of what you install, update, transfer, and connect matters as much as the controls you run inside the plant.

NEI 08-09 was written before some of the modern supply chain headlines, but the principle holds. Accept updates and components only when they are verified and sourced through approved channels. part one also made the point clearly. Supplier obligations must include secure update and change-control behaviors, not generic “best efforts.” In practice, supply chain security comes down to contractual enforcement and technical verification.

• Update provenance and validation: Require that every software and firmware update destined for CDAs is delivered through controlled channels and verified independently by the operator. That includes cryptographic signature verification for OEM updates, integrity checks for custom software, and hardware integrity controls where appropriate.
• Secure delivery pipelines: Where projects involve frequent releases, secure the build and delivery process end to end. Use dev and test environments that mirror production closely enough to catch surprises. Scan and validate artifacts before promotion. Treat update pathways like any other conduit, favor controlled pull models and inspection points over unmanaged vendor push mechanisms.
• Remote service constraints: Vendors will need remote service access, particularly during startup and early lifecycle support. That access must be governed as rigorously as any other privileged operation. Time-limited approvals, strong authentication, session monitoring, and clear revocation capability should be standard, and reinforced contractually through vulnerability notification and compliance requirements.

A Zero Trust mindset fits naturally here. Trust is earned through verification, not assumed based on vendor brand. This is also an area where Xage can help operationalize policy, for example by enforcing that only approved, signed software is permitted to load on protected assets, and mediating data exchanges so integration pipelines remain policy-bound. The goal is consistent verification that scales with the supplier footprint and the program timeline.

A Practical Mapping for Leaders

If you want a simple test of readiness, ask whether your program can do the following without exceptions:

• Define the CDA boundary, and keep it stable through design churn
• Enforce segmentation with mediated conduits, not informal connectivity
• Grant vendor access that is time-bound, least-privilege, and auditable
• Govern change at delivery speed, without bypassing review
• Produce evidence continuously, not just for audits
• Verify supply chain inputs, including updates and remote service paths

If any answer is “we can, but only sometimes,” that is where risk will concentrate. Also, if any of these capabilities require exception handling, informal pathways, or manual reconciliation, that is where schedule risk and regulatory exposure will accumulate.

Closing Thoughts

Part one established the baseline. Part two is the operating model.

The programs that will succeed in the nuclear-for-AI era are the ones that embed cybersecurity as an architectural discipline from day one, rather than treating it as documentation that trails engineering progress. The good news is that the implementation patterns are known, and they are repeatable. When combined with a Zero Trust access and segmentation model, they also scale, which is what advanced reactor deployment timelines demand.

 

Sources

• U.S. NRC: 10 CFR 73.54 “Protection of digital computer and communication systems and networks” 
• U.S. NRC: Regulatory Guide 5.71 Rev. 1 (2023) – “Cyber Security Programs for Nuclear Power Reactors”
• Nuclear Energy Institute: NEI 08-09 Rev. 7 – “Cyber Security Plan for Nuclear Reactors” (industry guidance aligned to 73.54/RG 5.71)
• Sandia National Labs: “Design of Defensive Cybersecurity Architectures for Advanced Reactors” (2024) – on zones, conduits, and defensive strategies (chokepoints, access control)
• Xage Security: Zero Trust for OT solution capabilities (identity-first access control, secure remote access, segmentation, tamper-resistant logging)
• part one Contracting Recommendations – specific best practices to require: time-bound remote access, no persistent connections, vendor patch obligations, mediated data flows.