Evidence boundary: Present standards address cyber-resilient systems, operational technology, software supply chains, zero trust, incident response, and AI risk in bounded terrestrial settings. They establish useful engineering practices, not a validated generation-ship security architecture. No cited source demonstrates century-scale cyber defense, permanent separation from external authorities, or safe recovery of an entire closed habitat. This lesson is a civil-and-defensive educational synthesis. It excludes offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions. Safety-critical cyber and dual-use conclusions require two-person review.
Plain-language summary
A generation ship would not merely carry computers. It would be a civilization whose air, water, food, power, medicine, manufacturing, records, and government depend on computers. Cybersecurity therefore means preserving the ability to operate, diagnose, repair, learn, decide legitimately, and recover—not simply hiding information.
Threat-modeling begins by asking what must remain true, what can cause it to become false, how anyone would know, and how the crew could recover without calling Earth. The answer must include accidents, radiation faults, worn hardware, bad updates, compromised suppliers, manipulated AI, insider misuse, collusion, lost expertise, and governance capture. It must also protect residents from a security program becoming a system of permanent surveillance.
The useful product is not an exhaustive list of villains. It is a living map from essential services to dependencies, dangerous states, detection evidence, bounded responses, recovery paths, and accountable decision rights.
Begin with missions, not malware
NIST SP 800-160 Volume 2 defines cyber resiliency around the ability to anticipate, withstand, recover from, and adapt to adverse conditions involving cyber resources. That mission-centered framing fits a closed habitat better than a catalog of attack techniques.
NASA-STD-1006A is an active Agency-level standard requiring NASA missions to address protection and resilience against threats. NASA’s Space Security Best Practices Guide Revision B translates selected NIST controls into space-vehicle and ground-segment language and describes itself as a risk-based starting point. These are important space-specific authorities and methods. Requirements and guidance are not evidence that a system has implemented them successfully, and neither source validates a generation-ship architecture.
Start with functions whose loss could harm people:
- maintain breathable atmosphere within declared limits;
- keep safe water and sanitation available;
- supply stable electrical power and heat rejection;
- preserve medical capability and trustworthy patient records;
- operate food production and ecological monitoring;
- navigate, communicate, and maintain attitude or trajectory;
- manufacture and qualify replacement parts;
- preserve constitutional, scientific, and maintenance records; and
- conduct legitimate emergency decisions and return authority afterward.
For each function, identify the minimum safe service, maximum tolerable outage, manual or local fallback, required measurements, recovery material, and people authorized to change it. “The network is up” is not a safety outcome. A water controller could be online while acting on a biased sensor. A medical archive could be confidential but incomplete. A factory could produce dimensionally correct parts from a poisoned process record.
Draw the cyber-physical chain
A useful threat model follows effects in both directions. A digital change can move a valve, alter a nutrient dose, corrupt metrology, erase a legal record, or misroute power. A physical event can upset memory, break timing, damage a sensor, change a network topology, or force operators into an unsafe software state.
For each critical service, map:
- Physical process. What matter or energy changes, and what states are hazardous?
- Sensing. Which instruments indicate the state? What independent observation could challenge them?
- Control. Which deterministic controllers, software services, models, and human procedures choose actions?
- Actuation. Which devices create a physical effect, and what limits exist below application software?
- Dependencies. Which power, cooling, timing, identity, communications, calibration, and maintenance services are required?
- Authority. Who may observe, propose, approve, execute, override, and audit a change?
- Recovery. Which known-good code, configuration, tools, spares, and knowledge can restore service?
NIST SP 800-82 warns that operational technology has performance, reliability, availability, safety, and physical-process constraints that differ from ordinary information systems. A security response that abruptly stops a business server may be acceptable; stopping circulation, thermal control, or a treatment process may create the greater hazard. The threat model must therefore represent both compromise risk and response risk.
Model causes, not stereotypes
The same dangerous state can arise from malice or error. A false oxygen reading might result from a manipulated calibration file, connector corrosion, radiation-induced bit upset, a maintenance mistake, a counterfeit sensor, or a model trained on the wrong operating regime. Designing detection around an imagined adversary can miss those shared failure paths.
Use at least these cause classes:
- hardware defect, wear, environmental damage, and common-mode failure;
- software defect, unsafe interaction, stale configuration, and undocumented dependency;
- corrupted design, build, update, calibration, or manufacturing data;
- compromised supplier, toolchain, component, or maintenance instrument;
- accidental operator action, fatigue, inadequate training, or ambiguous interface;
- malicious insider, coercion, collusion, stolen identity, or abuse of emergency privilege;
- institutional failure, discriminatory policy, governance capture, or loss of appeal;
- AI confabulation, poisoned data or model, unsafe automation bias, and model drift; and
- external communications carrying malformed, misleading, obsolete, or unauthorized material.
This classification avoids treating every anomaly as an attack and every resident as a suspect. It also creates common mitigations: independent sensing helps against sabotage and drift; signed configurations help against tampering and mistakes; rehearsed recovery helps after an attack or a radiation fault.
People, rights, and authority are inside the model
An onboard security system could become an extraordinary concentration of power. Identity services may mediate access to work, housing, medical care, archives, communications, and civic participation. Continuous monitoring can chill association or create permanent social scores. Emergency powers can outlive the emergency.
Security requirements should therefore include civil constraints:
- collect the least personal data consistent with a declared safety purpose;
- separate process telemetry from behavioral surveillance;
- require warrants or equivalent accountable process for invasive access, except under narrow emergency conditions;
- log use of exceptional authority and require later independent review;
- provide notice, correction, appeal, and restoration of wrongly restricted access;
- rotate sensitive duties and separate authorization from execution;
- preserve anonymous or confidential reporting channels; and
- prohibit immutable caste, lineage, or political status in identity credentials.
These are normative choices, not conclusions proven by engineering standards. They belong in the threat model because governance abuse can disable truthful reporting and safe maintenance as effectively as a software compromise.
Manufacturing expands the attack surface
Onboard industry turns information into physical artifacts. Product definitions, material pedigrees, toolpaths, heat-treatment recipes, acceptance thresholds, calibration corrections, and maintenance histories become safety assets.
A threat model should trace a replacement part from requirement through feedstock, process, inspection, installation, and service history. It should ask whether a malicious design change, poisoned toolchain, counterfeit input, compromised metrology record, or silent configuration rollback would be detected by an independent path. Digital provenance helps, but a valid signature only identifies an approved signer and protected bits; it does not prove that the design is safe or the measurement true.
High-consequence production changes should require two qualified people, independent measurement, and physical acceptance evidence. Cyber staff alone should not waive structural, medical, nuclear, ecological, or process-safety requirements.
LLMs change both capacity and risk
An offline language model could search manuals, compare logs, translate old terminology, draft hypotheses, or help a trainee understand a procedure. That may make a small crew more capable. It also creates new failure modes.
Models can confabulate plausible but unsupported explanations. Retrieval stores, maintenance notes, or training data can be poisoned. A compromised model or prompt pipeline can omit evidence, frame uncertainty deceptively, or amplify a privileged operator’s assumptions. Repeatedly useful output can produce overreliance even when the model lacks authority or current context.
The defensible role is evidence-bounded and non-authoritative:
- cite the controlled record and exact revision behind each material statement;
- distinguish observation, inference, proposal, and unknown;
- operate offline when external service cannot be trusted or reached;
- have no direct path to life-support actuators, identity revocation, weapons, or final safety acceptance;
- preserve inputs, outputs, model version, retrieval set, and human disposition for review;
- compare recommendations against deterministic limits and approved procedures; and
- rehearse operation with the model absent, corrupted, or confidently wrong.
AI is one advisory channel. It is not the incident commander, judge, root of trust, or substitute for physical verification.
Turn the model into tests
A threat register that never changes a test, architecture, spare, or decision is paperwork. Each high-consequence scenario should connect to a testable claim:
- Can two independent measurements reveal a corrupted sensor family?
- Can a zone continue minimum safe service when isolated?
- Can operators identify a false but correctly signed configuration?
- Can the crew rebuild a controller from locally held known-good material?
- Can a resident challenge an erroneous access restriction during an incident?
- Can a mixed-experience team work without a specialist or AI assistant?
- Can investigators preserve evidence while restoring urgent service?
The strongest test combines conditions: communications lost, an update suspect, one trusted operator unavailable, one sensor family biased, and life support still required. NIST frameworks do not establish success in that environment. Repeated representative demonstrations would.
Evidence ledger
- L11-01-A — Cyber resilience should be framed around essential mission outcomes and recovery, not confidentiality alone. Basis: normative synthesis grounded in NIST cyber-resiliency engineering. Readiness: operational as a systems-engineering practice; unproven for a generation ship. Confidence: strong for the framing, tentative for ship integration.
- L11-01-B — Current cyber-resilience, OT, zero-trust, supply-chain, and AI guidance provides relevant but fragmented reference points. Basis: observed. Readiness: operational within bounded terrestrial contexts; major scale-up and integration required. Confidence: strong.
- L11-01-C — Cyber and physical causes can converge on the same hazardous state, so the model must include faults, mistakes, suppliers, insiders, institutions, and AI. Basis: demonstrated across current system classes and proposed for this application. Readiness: operational as analysis; early research for integrated closed habitats. Confidence: supported.
- L11-01-D — Onboard manufacturing makes controlled engineering data and metrology cyber-physical safety assets. Basis: normative inference from OT, supply-chain, and manufacturing assurance practice. Readiness: early research for a self-maintaining factory. Confidence: supported.
- L11-01-E — Privacy, due process, and bounded emergency authority are security requirements, not optional social additions. Basis: normative. Readiness: proposed for this context. Confidence: supported as an ethical requirement; implementation is contested.
- L11-01-F — No source reviewed here demonstrates a generation-ship cyber standard or century-scale integrated deployment. Basis: observed within the bounded source set. Readiness: no known path to demonstrated century assurance. Confidence: supported, not an exhaustive literature claim.
Linked corpus claims: claim-12-01, claim-12-02, claim-12-04, claim-12-06, claim-12-07, and claim-12-10. See the claim registry for each record's current evidence grade and independent-review state.
Assumptions and limits
- No particular population, network topology, propulsion system, constitutional order, adversary, or mission duration is assumed.
- NIST publications are voluntary guidance for present organizations; citation does not make them flight requirements.
- “Threat” includes hazardous causes and institutional misuse, not only intentional attackers.
- Monitoring is not assumed to justify pervasive surveillance.
- Cryptographic validity is not treated as proof of physical truth, competence, legitimacy, or safety.
- LLM support is offline-capable, evidence-linked, logged, advisory, and removable; deterministic protection and accountable people retain authority.
- This lesson offers no exploit sequence and no offensive or weapon-integration guidance.
What would change this conclusion?
Confidence would rise if representative closed habitats repeatedly maintained essential service through combined cyber, physical, human, and governance failures; detected poisoned engineering and AI data; restored from locally held known-good material; and protected due process under independent observation. A failure to sustain minimum safe service, rotate authority, preserve recoverable trust, or operate without remote vendor support should narrow the mission, require redesign, or trigger a wait/do-not-launch gate.
Sources and locators
- S01 — NIST SP 800-160 Volume 2 Revision 1, Developing Cyber-Resilient Systems (opens external site in a new tab). Locator: executive summary; chapters 2–3; cyber-resiliency goals, objectives, techniques, approaches, and design principles; December 2021; accessed 2026-07-25.
- S02 — NIST SP 800-82 Revision 3, Guide to Operational Technology Security (opens external site in a new tab). Locator: sections 2–3 on OT characteristics and threats; sections 5–6 on risk management and countermeasures; September 2023; accessed 2026-07-25.
- S03 — NIST Cybersecurity Framework 2.0 (opens external site in a new tab). Locator: Govern, Identify, Protect, Detect, Respond, and Recover functions and Profiles; February 2024; accessed 2026-07-25.
- S04 — NIST SP 800-161 Revision 1 Update 1, Cybersecurity Supply Chain Risk Management Practices (opens external site in a new tab). Locator: executive summary; sections 2–3; multilevel risk management and supply-chain threat examples; updated November 2024; accessed 2026-07-25.
- S05 — NIST SP 800-207, Zero Trust Architecture (opens external site in a new tab). Locator: sections 2–3 on zero-trust tenets and logical components; August 2020; accessed 2026-07-25.
- S06 — NIST AI 100-2 E2025, Adversarial Machine Learning (opens external site in a new tab). Locator: taxonomy of evasion, poisoning, privacy, and misuse attacks; life-cycle stages and mitigation limits; March 2025; accessed 2026-07-25.
- S07 — NIST AI 600-1, Generative Artificial Intelligence Profile (opens external site in a new tab). Locator: confabulation, information integrity, human-AI configuration, automation bias, and value-chain risk sections; July 2024; accessed 2026-07-25.
- S08 — NIST SP 800-154 Initial Public Draft, Guide to Data-Centric System Threat Modeling (opens external site in a new tab). Locator: sections 2–4 on threat-modeling concepts, attack vectors, security controls, and iterative assessment; March 2016 draft, with NIST finalization planning note dated 2025-01-23; accessed 2026-07-25.
- S09 — NASA-STD-1006A, Space System Protection Standard (opens external site in a new tab). Locator: active Agency-level protection requirements, mission-resilience scope, status, and applicability; 2022; accessed 2026-07-26. This is normative authority, not implementation evidence.
- S10 — NASA, Space Security: Best Practices Guide Revision B (opens external site in a new tab). Locator: sections 1–3 on space-vehicle and ground-segment scope, mission-centered security principles, risk-based tailoring, and guidance status; 2024; accessed 2026-07-26.
Editorial record
- Prepared by: GShips Project
- Last edited: 2026-07-26
- Status: Substantive editorial draft
- Independent domain review: Pending; high-consequence cyber, governance, and dual-use claims require explicit two-person review before publication
- Required review: cybersecurity, safety engineering, operational technology, human factors, governance, privacy, AI/autonomy, and manufacturing assurance
- Reviewer: No independent reviewer assigned
- Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
- Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, NIST, CISA, IETF, or any named organization
- Scope boundary: Civil and defensive resilience only; offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
- Corrections: Suggest a correction