Computing Library › Security & Safety-Critical Computing
Security & Safety-Critical Computing

Secure by Design

Building security into a system from the first architecture decision is cheaper and more effective than bolting it on afterward.

Security as a Property, Not a Feature

Secure by design treats security as an intrinsic property of the system's architecture, established from the earliest requirements. The alternative, adding controls after the design is fixed, produces awkward retrofits that never cover the gaps the original structure created. Decisions made on day one, about trust boundaries, data flows, and default behavior, constrain what security is even possible later.

Principles

Kronos motion — materials first

Shifting Left

In software this is often called shifting left: moving security activity earlier in the lifecycle, into design and coding rather than testing and deployment. Threat modeling during design catches architectural flaws that no amount of later scanning can fix. A missing trust boundary is a design defect; you cannot patch your way out of it.

Secure Defaults Matter Most

Most systems are deployed as shipped. If the default is insecure, most installations will be insecure. Secure-by-design systems ship locked down, requiring a deliberate choice to open anything up, rather than shipping open and hoping operators harden them.

Fusion Context

Because a fusion plant is safety-critical and long-lived, retrofitting security is especially costly, so the Hyperion breeder and burner designs specify segmentation, authenticated control paths, and independent safety instrumentation as first-class architecture, not additions. Construction begins Q2 2027, which means the secure-by-design work happens now, in the design and simulation phase, where trust boundaries can still be drawn correctly.