In December 2024, the Department of Defense rewrote the rules for nuclear weapon safety. For the first time, the Fourth Nuclear Surety Standard explicitly requires prevention of unauthorized actions "by physical or digital means." Cybersecurity is no longer an IT compliance checkbox — it is a nuclear surety requirement demanding the same rigor as two-person control and stronglink architecture. But cybersecurity demands agility. Surety demands stability. No computational framework exists to prove they don't conflict.
On December 17, 2024, the Department of Defense reissued DoDI 3150.02, "DoD Nuclear Weapon Systems Surety Program".[1] The four surety standards now read:
| Standard | Requirement |
|---|---|
| NSI-1 | Prevent nuclear weapons involved in accidents or incidents from producing a nuclear yield |
| NSI-2 | Prevent deliberate unauthorized pre-arming, arming, launching, or releasing — except upon execution of emergency war orders |
| NSI-3 | Prevent inadvertent pre-arming, arming, launching, or releasing in all normal and credible abnormal environments |
| NSI-4 | Prevent unauthorized access or unauthorized actions, by physical or digital means, that may result in loss or unauthorized use of a nuclear weapon |
This creates a constraint surface that did not formally exist before December 2024. Every cyber control applied to Sentinel must be proven compatible with nuclear surety invariants. Every surety design choice must be evaluated for impact on cyber maintainability. The instruction mandates integration but provides no methodology for proving it.[1]
The fundamental tension between cybersecurity and nuclear surety is structural, not procedural.
RMF mandates continuous monitoring
Zero-day response in days or hours
Unpatched systems violate ATO
Demand: Agility
DAFI 91-101 requires configuration control[4]
DAFMAN 91-119 governs safety-critical software[3]
Changes trigger months of NSCCA
Demand: Stability
The paradox: You cannot patch the system without triggering safety review (months). You cannot leave the system unpatched without violating Authorization to Operate (cyber risk). The system is either vulnerable to attack OR operating in uncertified configuration.
Nuclear weapon safety is implemented through four physical themes that have been engineered into weapons for decades. CSJ-K maps cyber requirements directly to these mechanisms — not to abstract "safety controllers."[7]
| Mechanism | Function | Cyber Relevance |
|---|---|---|
| Stronglink (Intent) | Blocks arming until valid human-authorized Unique Signal received | Digital signal path integrity; PAL code authentication |
| Stronglink (Trajectory) | Blocks arming until environmental sensors confirm valid flight path | Sensor data integrity; anti-spoofing |
| Weaklink | Fails safe under abnormal environment before stronglink compromise | No direct cyber interface; protected by isolation |
| Exclusion Region | Physical barrier around detonators | Defines SURETY_CORE boundary; no external digital paths |
| PAL | Cryptographic lock preventing unauthorized arming | Key management; CMS interface; authentication |
Source: Nuclear Matters Handbook, Chapter 8[7]
The Code Management System is the PAL code logistics infrastructure developed by Sandia National Laboratories and produced at the NNSA Kansas City Plant. Initially operational November 30, 2001; fully deployed by spring 2004. It comprises 14 custom products (9 software, 5 hardware), including a specialized cryptographic processor — a secure metal-cased device containing three cryptographic chips.[18]
CMS is the authoritative PAL key management boundary. Any component interfacing with CMS for PAL code distribution is part of SURETY_CORE and cannot be modified without full recertification.
CSJ-K divides the entire Sentinel weapon system into two envelopes separated by hardware data diodes — optical devices where the transmitter is physically incapable of receiving light.[32]
▸ Stronglinks (intent + trajectory)
▸ PAL hardware + CMS interfaces
▸ Weaklinks, ESDs, exclusion region
▸ Type-1 cryptographic modules
▸ NC3 command endpoints
▸ W87-1/Mk21A digital bus interface
Class 2 changes only · NSCCA mandatory
▸ CLS fiber network routing
▸ SIEM and security analytics
▸ LCC displays and planning tools
▸ DevSecOps pipelines
▸ Network monitoring
▸ Training and simulation
Class 0/1 changes · Rapid patching OK
The governing rule: No AGILE change may increase SURETY_CORE reachability. Formally: RSURETY(t + Δ) ⊆ RSURETY(t). The data diode enforces this physically — telemetry flows out, nothing flows back.
CSJ-MATRIX v2.1 maps every Nuclear Surety Invariant against every cyber attribute. Each cell must have a binding rule, a verification method, and a mission-risk scenario trace. No cell may remain in TENSION_OPEN status at closure.
Scenario: LCC issues arming/launch command without valid two-person authorization
Rule R-2.1-v2: Every digital signal contributing to PAL code acceptance must originate under two-person, multi-factor, split-knowledge cryptographic control. Verified inside the exclusion region as producing a Unique Signal pattern with Paccidental ≪ 10⁻⁶.
Verification: Formal proof, NSCCA, penetration test
Scenario: Automated CLS self-healing reroutes traffic creating unintended control path
Rule R-3.4-v2: Adaptive routing must not increase SURETY_CORE reachability from any AGILE node. Default failure mode: "inhibit launch" — never "keep operating at all costs."
Resolution: Availability desires adaptivity; non-interference proof keeps surety intact. Adaptation constrained to AGILE surfaces only.
Scenario: Sensor data exfiltration reveals weapon location, readiness posture, or fault status
Rule R-4.1-v2: Any sensor data exported from weapons or LCC facilities to lower-classification environments must pass through unidirectional gateways with strict field-level filtering. Data diodes must be NCDSMO-baselined, RTB-compliant with RAIN principles. Receiving networks are semi-core: no user-driven code execution, no further transit to enterprise IT except via controlled boundary with content filtering. Maintenance ports physically lockable and logically disabled in normal modes.[21]
Verification: Test, inspection
The matrix consumes outputs from mission-based cyber risk assessment frameworks. URAMS (developed by Dr. William D. Bryant at MTSI) is one such framework, integrating STPA-Sec to generate risk scenarios.[23] Other approaches include Cyber Table Tops and MRAP-C. The matrix structure is methodology-agnostic.
Every proposed change to CLS, NC3 interfaces, LCC systems, or warhead interfaces must pass through a mandatory front-end before it can proceed.
| Step | Mechanism | Authority |
|---|---|---|
| 1. NCIS | Nuclear Certification Impact Statement submitted to AFNWC | DAFI 63-125[5] |
| 2. Classification | Class 0 / 1 / 2 assigned based on NCIS determination | CSJ-K taxonomy |
| 3. Verification | Class 2 → mandatory NSCCA by independent organization | DAFI 91-101[4] |
| Class | Name | Example | Required Actions |
|---|---|---|---|
| 0 | Non-interfering | New dashboard reading diode telemetry | Non-interference check; expedited approval |
| 1 | Assurance-tightening | Add IDS that can only increase inhibition | Targeted analysis; evidence reuse |
| 2 | Assurance-altering | Modify launch command processing code | Full NCIS; mandatory NSCCA[24]; recertification |
Nuclear Safety Cross-Check Analysis is governed by DAFMAN 91-119.[3] It must be performed by an independent verification organization — not the prime developer.[4] The Performance Work Statement describes it as "primarily an analysis of code and other evaluation" to ensure no violation of DoD nuclear surety standards.[24] It includes adversarial testing for trojans, logic bombs, and unintended interactions. Applied to ICBM software for both Minuteman III and Sentinel.
NSCCA is why Class 2 changes take months. CSJ-K does not accelerate this — it makes the requirement explicit and gates deployment on completion.
Sentinel will deploy with two different warhead types and confirmed multi-reentry-vehicle capability, creating interface complexity unprecedented in ICBM history.
| Phase | Warhead | Interface | Protocol |
|---|---|---|---|
| Phase 1 (Initial) | W87-0 / Mk21 | Analog/discrete | Simple arming/inhibit lines |
| Phase 2 (2030s) | W87-1 / Mk21A[25] | Digital serialized bus | Versioned message set (FROZEN) |
WARHEAD_IF_CONTRACT rules:
▸ The Post-Boost Vehicle must maintain independent interface sessions with each RV
▸ No cross-RV command mapping — a command for RV-1 must never reach RV-2
▸ Interface type (W87-0 vs W87-1) confirmed through hardware interrogation — not software flag
▸ Mis-configuration must trigger safe state, not wrong-protocol transmission
Minuteman III may operate into the 2050s[8] — an extended period where both weapon systems share geographic footprint and must be commanded from potentially shared infrastructure with strict logical separation.
| Constraint | Requirement |
|---|---|
| Squadron Isolation | Transition at squadron granularity (~50 missiles). No mixed flights. |
| Cable Deconfliction | HICS copper and Sentinel fiber share easements. Construction deconfliction protocols required. "Backhoe fade" — construction cutting active nuclear command cables — must be prevented. |
| Ground Potential Rise | Sentinel's new grounding grids create GPR risk for legacy HICS. Isolation transformers and staged de-energization required. |
| Wing Command Post Air Gap | Separate physical networks for MMIII vs Sentinel reporting chains. Cyber intrusion on Sentinel side cannot pivot to MMIII side. |
Interface failures, configuration drift, and cyber vulnerabilities are not theoretical — they manifest in operational nuclear systems.
These incidents demonstrate the pattern CSJ-K addresses: interface configuration errors, internal system failures producing denial-of-service against legitimate command, and systemic cyber vulnerabilities in weapon systems designed before digital threats were recognized.
CSJ-K's closure condition is precise:
In plain language: for every combination of nuclear surety invariant and cyber attribute, there must be a documented rule proving they don't conflict, a method for verifying it, and evidence that the verification was performed. No unresolved tensions. No assertions without derivation.
Without this closure, the Sentinel program can assert cyber-surety compatibility but cannot demonstrate it — replicating exactly the pattern of assertion-without-derivation that caused the original breach.[2]
All components use mature technologies. NCIS[5] is mandated. NSCCA[4] is operational. RTB CDS products[21] are available. No statutory changes required. The architecture must be established during the restructuring period — before the new baseline is approved without cyber-surety closure requirements.
| Component | Technology | TRL |
|---|---|---|
| CSJ-MATRIX | Structured assurance cases, databases | 9 |
| MBCRA Integration | STPA-Sec tooling, risk databases | 9 |
| NSCCA | Established DoD process (DAFMAN 91-119) | 9 |
| NCIS | DAFI 63-125 mandated process | 9 |
| NMR/Voting Logic | Fault-tolerant computing standard | 9 |
| OMS/Containerization | Air Force prototypes operational | 8 |
| RTB CDS | NCDSMO-certified products available | 9 |
| Evidence Ledger | Append-only stores, hash chains | 9 |
No component requires research-grade algorithms or unprecedented capabilities. Seven of eight components are at TRL 9 — fielded and proven. OMS/containerization is at TRL 8 with Air Force prototypes operational.[28]
Not a hazard analysis methodology. CSJ-K consumes outputs from established frameworks (MBCRA for mission risk, NSCCA for verification, NCIS for certification impact). It does not replace STPA-Sec or other hazard analysis methods.
Not a cost or schedule tool. Cost estimation is UC-BCK's domain (SPK-01); schedule milestones are SI-CK's domain (SPK-02).
Not a weapon system design. CSJ-K defines boundary conditions and joint rules. It does not design PAL implementations, launch control software, or NC3 message protocols.
Not a breach prevention system. CSJ-K cannot prevent cyber attacks, requirements changes, or funding instability. It ensures that whatever configuration is proposed has the structural properties required for valid verification.
Cyber attacks exploiting unknown vulnerabilities. No framework can defend against threats it cannot model.
Requirements changes that invalidate certification basis. If the surety standards themselves change, the matrix must be re-evaluated.
Funding instability affecting NSCCA capacity. If independent verification organizations lack resources, Class 2 changes queue regardless of CSJ-K's classification speed.
Threat evolution beyond current MBCRA scenarios. The matrix is only as complete as the mission-risk scenarios that populate it.
CSJ-K makes incompatibilities visible before operational commitment. It does not claim to eliminate them.
Cost implications of cyber-surety flow indirectly through schedule (NSCCA duration) and workforce (NSCCA demand multiplier). SPK-05 does not directly produce cost data.
Class 2 changes trigger recertification durations that SPK-02 must encode as schedule constraints. SPK-05 defines what triggers a freeze violation; SPK-02 encodes the consequences.
Thin interface. If cyber-surety requirements affect facility design (TEMPEST shielding, physical access controls), those flow into SPK-03's facility specifications.
Primary coupling. SPK-04 defines NC3 interface boundaries. SPK-05 proves those boundaries are jointly satisfiable under both cyber and surety requirements. If SPK-04's interface contracts change, SPK-05's proofs may break.
Secondary but load-bearing. SPK-05's frozen/agile classification determines what SPK-06 must test to what standard. Frozen surfaces require deterministic verification. Agile surfaces accept different evidence thresholds.
NSCCA creates a ~2× demand multiplier on nuclear-critical software workforce. SPK-05's classification of what counts as nuclear-critical software drives SPK-07's workforce numbers.
CSJ-K must satisfy nine acceptance criteria for cyber-surety joint satisfiability closure. All remain unmet as of the current date.