Cybersecurity of nuclear I&C

Malik Osei has moved from materials engineering into the cyber security program at Meridian Nuclear Engineering, which supports licensees in meeting 10 CFR 73.54. He shows Hana a diagram on the wall of his office: a set of nested boxes, the innermost containing the reactor protection system and safety-related digital equipment, the next the plant control systems, and so on outward to the corporate network and the internet. “Cyber security in a nuclear plant is mostly about this picture,” he says. “Decide what matters most, put it in the innermost level, and control every path in and out. The technology changes every year. The principle does not.”

This lesson explains why digital I&C needs cyber security, the regulatory framework in Canada and the United States, the defensive architecture of levels and zones, the role of one-way devices, and the programs that keep a plant's digital assets protected over their life. It is written from the defender's point of view: what plants must protect and how programs are organized to do it.

Why I&C needs cyber security

Analog relay logic cannot be reprogramd from a distance. Digital I&C can be changed by anyone who reaches it with the right access, whether through a network, a maintenance laptop, a removable drive or a compromised update from a supplier. As plants have modernized, the number of digital assets that could affect safety, security or emergency preparedness has grown into the thousands at a typical site. Cyber security aims to make sure that these assets perform their functions as designed, that data used for decisions can be trusted, and that the plant can detect, respond to and recover from cyber incidents.

The industry learned from public events. In 2003 a computer worm entered the plant network at the Davis-Besse plant in Ohio through a contractor's connection, slowing the safety parameter display system for several hours while the plant was already shut down. In 2010 the Stuxnet malware, reported publicly to have targeted industrial controllers at an enrichment facility in Iran, showed that malware could be designed to damage physical equipment while showing operators normal readings, and that an isolated network could be reached by removable media. These events changed the question from whether plants might be targets to how programs should be built to protect them.

The regulatory framework

In the United States, 10 CFR 73.54, issued in 2009, requires power reactor licensees to protect digital computer and communication systems and networks associated with safety-related and important-to-safety functions, security functions, emergency preparedness, and support systems whose compromise would adversely affect these. Licensees implement the rule through an NRC-approved cyber security plan, most based on the template in NEI 08-09, with Regulatory Guide 5.71 giving the NRC's guidance, revised in 2023. Programs were implemented in milestones, with the full program in place across the fleet by the late 2010s, and the NRC inspects them. The rule is part of Part 73, the physical protection requirements, so cyber security is treated as part of the plant's overall security program. Internationally, the IAEA Nuclear Security Series, especially NSS 17-T, gives guidance that many states use.

Identifying what to protect

A program starts with an inventory. The licensee lists every digital asset at the site, from reactor protection components to radiation monitors and fire panels, and identifies the critical digital assets whose compromise could affect the functions in the rule. The analysis then identifies every connection to each asset, including temporary ones such as maintenance laptops and portable media, because an asset is only as secure as its paths. Each critical digital asset is assigned to a defensive level that sets the controls applied to it.

Defensive levels and zones

The heart of the architecture is defense in depth through levels and zones. Assets with similar importance are grouped into zones, and zones are arranged in levels, from the most protected, which contains the systems that perform safety functions, out to the corporate network and the internet. The rules are simple to state. Data may flow from a more protected level to a less protected one only through approved boundary devices. For the most protected levels, the flow must be one-way, enforced in hardware by a data diode that physically cannot carry signals in the reverse direction. No remote access is allowed into these levels. Flows inward are not allowed except under strict, documented processes, such as controlled transfer of approved software updates on verified media.

The NEI 08-09 template uses five levels numbered upward, with level 4 the most protected for safety and security systems and a deterministic one-way device between levels 3 and 4. IAEA guidance numbers in the opposite direction. What matters is that the most important functions receive the strongest protection, and that every boundary has a defined device and a defined set of allowed flows.

# Check data flows against a defensive-level policy: only allowed flows, only outward from higher levels.
levels = {"reactor protection": 1, "safety display": 2, "plant control": 2, "plant historian": 3,
          "maintenance workstation": 3, "business network": 4, "internet": 5}
flows = [("reactor protection", "safety display", "one-way"),
         ("plant control", "plant historian", "data diode"),
         ("plant historian", "business network", "firewall"),
         ("maintenance workstation", "plant control", "two-way"),
         ("business network", "plant control", "two-way"),
         ("reactor protection", "plant historian", "data diode")]
def check(src, dst, kind):
    a, b = levels[src], levels[dst]
    if a <= 2 and b > a and kind not in ("one-way", "data diode"):
        return "not allowed: flows out of levels 1-2 must be one-way hardware"
    if b < a:
        if b <= 2: return "not allowed: no flow from a lower level into levels 1-2"
        return "review: inbound flow needs a documented exception"
    if b - a > 1: return "review: flow skips a level"
    return "allowed"
for src, dst, kind in flows:
    print(f"{src:24s} -> {dst:24s} {kind:11s} {check(src, dst, kind)}")

reactor protection       -> safety display           one-way     allowed
plant control            -> plant historian          data diode  allowed
plant historian          -> business network         firewall    allowed
maintenance workstation  -> plant control            two-way     not allowed: no flow from a lower level into levels 1-2
business network         -> plant control            two-way     not allowed: no flow from a lower level into levels 1-2
reactor protection       -> plant historian          data diode  review: flow skips a level

The checker flags the two flows that a real review would reject: a two-way connection from a maintenance workstation into plant control, and a two-way connection from the business network into plant control. It accepts the one-way flows outward and flags for review a data diode flow that skips a level, which may be acceptable but needs justification. Real reviews also look at what each flow carries, who can configure the boundary device, and how the configuration is protected and monitored.

Controls beyond architecture

Architecture limits the paths; other controls protect the assets and the people who work on them. Portable media and mobile devices are controlled by kiosks that scan files before use, by inventories of approved devices, and by rules that devices used on protected systems are never used elsewhere. Supply chain controls make sure that equipment and software come from trusted sources, are verified before installation and are delivered without tampering. Configuration management keeps a baseline of every protected asset so that unexpected changes are detected. Physical security keeps unauthorized people away from cabinets, consoles and cable runs. Training gives staff the knowledge to recognize suspicious behavior, and personnel security programs establish trustworthiness for those with access.

Defensive programs also plan for failure. Monitoring of logs and network traffic at boundaries detects anomalies. Incident response plans set out how to isolate affected systems, preserve evidence, notify the regulator and restore from trusted backups. Exercises test these plans together with operations, so that operators know how to run the plant safely on independent indications if a digital system cannot be trusted. Above all, the safety design does not depend on cyber security alone: independent shutdown systems, hardwired backups, diverse actuation and manual controls give layers that remain effective even if one digital system misbehaves.

Security by design

For new plants and major modernizations, security is now considered from the start. Designers choose architectures with few connections, prefer one-way communication, avoid unnecessary features in safety platforms, separate engineering and maintenance access from operational networks, and design for secure update and recovery. Standards such as IEC 62645 for nuclear I&C computer security and IEC 62443 for industrial automation provide frameworks, and IEEE 7-4.3.2 and CSA N290.14 include expectations for a secure development environment, so that software cannot be altered between development and installation. The BWRX-300 and other small modular reactor designs present an opportunity to build these features in from the beginning rather than retrofitting them.

People and organization

A cyber security program is run by people. The licensee appoints a responsible manager and a team with the authority to set rules for engineering, maintenance and operations. Engineers who design or modify digital systems must consider cyber security in every design change, and procurement staff must include security requirements in specifications. Maintenance staff follow procedures for connecting test equipment and transferring files. Operators must know how to recognize abnormal behavior of digital systems and how to report it. Regular assessments and inspections check that the controls work in practice, not just on paper.

Programs are also living. New vulnerabilities are announced, new equipment is installed and old equipment is retired. Licensees review vulnerability information from vendors and government agencies, assess its relevance to their assets, and decide on mitigation. Because patching a safety system is itself a design change that must be verified, most protected systems are not patched frequently; instead, their defense relies on architecture and access control, with patches applied when they matter and can be qualified. The program records each decision so that the reasoning is clear to inspectors.

Coordination with physical security and safety

Cyber security, physical security and safety are planned together. Physical barriers and access control protect the rooms where digital equipment sits, and cyber controls protect the equipment itself. A design change that improves safety, such as adding a diagnostic connection, may weaken security, and a security control, such as locking a configuration, may slow a safety response. The program resolves these interactions by assessing both sides and documenting the result. Malik tells Hana that the best cyber security decisions are made in the design meeting, not after the equipment is installed.

The regulators share information with licensees through confidential channels, and national agencies in both countries support the nuclear sector with threat information and incident response. Details of plant defenses are protected information and are not published, which is why this lesson, like the public standards themselves, describes the structure of programs rather than specific configurations.

Recovery and resilience

Programs plan for the possibility that, despite all controls, a digital system is compromised or simply misbehaves in a way that cannot be explained. Resilience means that the plant can be kept safe while the problem is investigated: independent safety systems that do not share software with the affected system, hardwired manual controls, indications that are independent of the digital network, and procedures that tell the crew which systems to trust. Recovery means that trusted software images and configuration baselines are kept offline, that the restoration process is tested, and that a system is returned to service only after its integrity has been verified. These measures connect cyber security directly to the defense in depth of lesson 9.