Evidence boundary: Secure-development frameworks, signed firmware manifests, software bills of materials, platform recovery, and staged deployment practices exist today. They do not establish that a software, firmware, AI-model, data, or engineering update will remain interpretable, compatible, and safely reversible across centuries. A valid signature proves neither safety nor truth. This lesson is a civil-and-defensive assurance pattern, not an operational procedure or certification. It excludes offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions. Safety-critical releases and dual-use changes require two-person review.
Plain-language summary
An update can repair a vulnerability, improve a controller, add a scientific model, or preserve compatibility with replaced hardware. It can also disable life support, corrupt records, poison a factory, break recovery, or quietly change who holds authority.
An update airlock is a controlled path between untrusted or merely unproven material and a live system. It receives the candidate; identifies its origin and contents; rebuilds or inspects it where possible; tests compatibility and safety; checks authorization; deploys to a limited target; watches declared health signals; and either expands the release or rolls back to a known-good state.
The airlock is not one scanning appliance. It is a sociotechnical process with independent evidence, separated duties, physical test environments, and a refusal state. It must work after Earth, vendors, cloud services, and original developers are gone.
What counts as an update?
Treat every executable or decision-shaping change as a release object:
- application, operating-system, bootloader, and device firmware;
- programmable-logic and controller configurations;
- cryptographic algorithms, certificates, trust anchors, and revocation data;
- AI model weights, prompts, retrieval collections, embeddings, and evaluation sets;
- calibration curves, material specifications, toolpaths, and manufacturing recipes;
- medical protocols, ecological thresholds, navigation tables, and digital-twin parameters;
- identity policy, authorization rules, and emergency procedures; and
- compilers, build systems, test tools, and the airlock’s own code.
A text file can be safety critical if a person or model acts on it. A sensor-calibration update may produce a physical effect without containing conventional executable code. Scope must follow consequence, not file extension.
The release evidence packet
No object should enter the airlock alone. Its evidence packet should include:
- unique identity, version, creation time or sequence, and intended targets;
- content digest and authorized signatures;
- human-readable purpose, hazards, assumptions, and affected requirements;
- source, build recipe, compiler and tool versions where available;
- component inventory, licenses, known defects, and supply-chain history;
- compatibility bounds, dependencies, migration steps, and prohibited states;
- test plan, expected results, independent results, and unresolved anomalies;
- resource demands such as memory, power, bandwidth, storage, and operator time;
- rollout groups, health metrics, pause thresholds, and rollback path; and
- named proposers, reviewers, authorizers, and conflict disclosures.
NIST SP 800-218 organizes secure software development around preparing the organization, protecting software, producing well-secured releases, and responding to vulnerabilities. NIST SP 800-161 adds supply-chain risk across acquisition and lifecycle. These are relevant disciplines; neither says that an SBOM or signature is enough.
An SBOM can expose declared components and versions. It may omit build-time dependencies, hardware behavior, data provenance, or undiscovered defects. A reproducible build can show that declared inputs produce matching outputs under controlled conditions; it does not prove that the inputs or design are safe. Provenance is evidence to reason with, not a ceremonial pass.
Intake without inheriting trust
An update arriving from Earth could be years old relative to onboard conditions. It may be authentic but obsolete, or based on hardware and regulations that no longer apply. A locally authored change could be relevant but compromised by a faulty toolchain, coerced reviewer, or poisoned reference corpus.
Intake should therefore:
- preserve the received object and transport metadata;
- verify integrity and signatures against the applicable historical policy;
- quarantine active content and render documentation safely;
- resolve target identity and reject ambiguity;
- inventory components and compare with local vulnerability knowledge;
- reconstruct the change against the prior approved baseline;
- identify which assumptions can be tested locally; and
- flag unknown, expired, revoked, or politically disputed authority for accountable human resolution.
RFC 9019’s firmware-update architecture distinguishes authoring, authorization, distribution, manifest processing, and installation. It also describes authenticated manifests, target matching, sequence checks, dependency handling, interruption tolerance, and recovery from invalid firmware. Those ideas matter beyond small devices, but a habitat needs additional safety and governance layers.
NASA-STD-1006A and NASA’s Space Security Best Practices Guide add current mission-protection requirements and space-segment guidance. They strengthen the case that flight and ground systems need explicit protection planning. They do not demonstrate that a particular update path is safely integrated, flight-qualified, recoverable after key loss, or maintainable across generations.
Compatibility is multidimensional
“It installed” is not a compatibility result. Evaluate at least:
- hardware model, revision, wear state, and locally manufactured substitutions;
- firmware, driver, protocol, schema, and file-format versions;
- timing, processor, memory, storage, bandwidth, power, and thermal margins;
- control-loop stability and physical safety limits;
- human interface, alarms, accessibility, language, and training burden;
- cryptographic and identity transitions;
- interactions with neighboring islands;
- recoverability of old records and configurations; and
- the ability to build, inspect, and roll back with onboard tools.
Test the candidate in an isolated digital environment, hardware-in-the-loop rig, physical test article, or sacrificial spare proportional to consequence. A digital twin is useful only within its validated range. It can miss manufacturing drift, sensor aging, emergent ecology, human adaptation, and unknown interactions.
Authorization and separation of duties
One identity should not be able to write, approve, deploy, and erase the evidence for a critical update. Roles can include proposer, builder, safety reviewer, security reviewer, mission owner, deployment operator, and auditor. Small populations may require role rotation and threshold approval rather than permanent specialists.
Emergency changes need a narrow path:
- a defined qualifying condition;
- minimum necessary scope and lifetime;
- two-person approval when physically possible;
- automatic expiry or mandatory reassessment;
- preserved before-and-after state;
- resident-visible disclosure consistent with privacy and safety; and
- independent retrospective review.
This boundary is especially important for identity, medical, reproductive, nuclear, ecological, navigation, and life-support systems. High consequence and dual use require two independent qualified reviewers. An AI system cannot serve as either reviewer.
Staged rollout and health evidence
Deploy first to the least consequential representative target, never simultaneously to every redundant unit. Preserve diversity: if two independent controllers provide fault tolerance, do not erase that independence by giving both the same unproven release at once.
Before deployment, define:
- expected functional and safety behavior;
- invariant physical limits;
- leading indicators of degradation;
- observation duration across representative operating states;
- who can pause, abort, or roll back;
- what data may be collected and for how long; and
- how success will be distinguished from an absence of detected failure.
A signed health report from the updated system is not independent evidence. Compare external instruments, process outputs, operator observations, and known test stimuli. Do not let the same component make the change, evaluate itself, and certify success.
Rollback is a tested capability
Rollback may fail because data schemas changed, keys rotated, hardware fused a new state, the prior image was overwritten, or the old version cannot understand newly produced records. “A backup exists” is not proof.
NIST SP 800-193’s protect-detect-recover model supports preserving recovery mechanisms and critical data. The update airlock should retain independently bootable known-good material, migration reversals where feasible, readable records, and a means to validate restored state. Anti-rollback controls that block a known vulnerable version must coexist with emergency recovery. The design needs an authorized way to choose the least unsafe recoverable state, not an irreversible monotonic rule whose assumptions cannot be revised.
Rehearse interruption during download, installation, migration, and restart. Test loss of power, clock disagreement, corrupt media, absent personnel, failed new hardware, and incompatible old data. Rollback completion should be measured by restored service and verified state, not by a boot message.
AI and model updates
Models deserve stricter—not looser—airlock treatment because behavior is statistical and evidence can be hard to trace. NIST’s Generative AI Profile identifies confabulation, information-integrity, human-AI configuration, and value-chain risks. NIST AI 100-2 classifies model and data poisoning among adversarial-ML concerns.
An onboard model update should include model and dataset provenance, evaluation coverage, known limitations, resource demand, retrieval-store changes, and comparison against frozen safety cases. Tests should include misleading context, poisoned documents, unavailable retrieval, ambiguous instructions, and human overreliance.
The model remains offline-capable, evidence-linked, advisory, and separated from actuators and roots of trust. It may help compare evidence packets or explain logs. It cannot authorize itself, alter its evaluation record, approve a safety release, or decide that missing evidence is acceptable. Retain a usable non-AI workflow and regularly exercise it.
Evidence ledger
- L11-03-A — Secure update, software assurance, supply-chain, SBOM, and platform-recovery practices exist today. Basis: observed and demonstrated. Readiness: operational in bounded contexts; integration and century sustainment unproven. Confidence: strong.
- L11-03-B — A valid signature establishes protected provenance under a policy, not safety, correctness, legitimacy, or compatibility. Basis: normative inference from cryptographic and assurance boundaries. Readiness: operational as a review principle. Confidence: strong.
- L11-03-C — Safety-relevant updates require an evidence packet, separated duties, representative testing, staged deployment, independent health signals, and tested recovery. Basis: normative synthesis. Readiness: major scale-up for an integrated closed habitat. Confidence: supported.
- L11-03-D — Onboard manufacturing and calibration data belong inside update assurance. Basis: proposed application of OT and supply-chain principles. Readiness: early research. Confidence: supported.
- L11-03-E — AI model and retrieval updates introduce poisoning, confabulation, drift, and overreliance risks that conventional signature checks do not resolve. Basis: observed risk taxonomy and modeled system concern. Readiness: early research for high-consequence onboard use. Confidence: strong for risk existence, tentative for controls.
- L11-03-F — No cited pattern demonstrates safe update and rollback across generational hardware, governance, cryptography, and expertise change. Basis: observed within this source set. Readiness: no known demonstrated path. Confidence: supported.
Linked corpus claims: claim-12-02, claim-12-03, claim-12-05, claim-12-07, claim-12-08, and claim-12-10. See the claim registry for each record's current evidence grade and independent-review state.
Assumptions and limits
- The airlock covers local and externally received changes; neither is trusted by origin alone.
- No specific operating system, compiler, signature scheme, vendor, or deployment platform is prescribed.
- SBOMs, signatures, reproducible builds, attestation, simulations, and digital twins provide partial evidence only.
- Some physical or data migrations may be irreversible; this must be disclosed before authorization.
- Privacy limits apply to rollout telemetry and operator monitoring.
- LLMs are offline-capable, evidence-linked, non-authoritative, logged, removable, and unable to approve or deploy their own changes.
- No exploit instructions, offensive operations, or weapon integration are included.
What would change this conclusion?
Readiness would improve through repeated representative releases across mixed old and new hardware, including interrupted installation, poisoned provenance, revoked authority, AI-data corruption, schema migration, failed health checks, and recovery without vendor services. The exercise must preserve minimum safe service and independently verify restored state. A system that cannot decline an update, rebuild its toolchain, explain its installed configuration, or recover after a failed release should not cross the relevant decision gate.
Sources and locators
- S01 — NIST SP 800-218, Secure Software Development Framework Version 1.1 (opens external site in a new tab). Locator: SSDF practices Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities; February 2022; accessed 2026-07-25.
- S02 — NIST SP 800-161 Revision 1 Update 1, Cybersecurity Supply Chain Risk Management Practices (opens external site in a new tab). Locator: sections 2–3 and appendices on lifecycle, provenance, supplier risk, and multilevel controls; updated November 2024; accessed 2026-07-25.
- S03 — IETF RFC 9019, A Firmware Update Architecture for Internet of Things (opens external site in a new tab). Locator: sections 3–7 and 10 on roles, manifests, target matching, sequence numbers, dependencies, installation, and recovery; April 2021; accessed 2026-07-25.
- S04 — NIST SP 800-193, Platform Firmware Resiliency Guidelines (opens external site in a new tab). Locator: sections 3–4 on roots of trust, protection, detection, recovery, and critical data; May 2018; accessed 2026-07-25.
- S05 — CISA, Software Bill of Materials (opens external site in a new tab). Locator: SBOM definition, ecosystem roles, use cases, and current minimum-elements resources; accessed 2026-07-25.
- S06 — NIST SP 800-82 Revision 3, Guide to Operational Technology Security (opens external site in a new tab). Locator: OT safety and availability constraints, patch management, change control, maintenance, and recovery guidance; September 2023; 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, and value-chain risk sections; July 2024; accessed 2026-07-25.
- S08 — NIST AI 100-2 E2025, Adversarial Machine Learning (opens external site in a new tab). Locator: predictive- and generative-AI poisoning taxonomy, life-cycle stages, and mitigation limitations; March 2025; accessed 2026-07-25.
- S09 — NASA-STD-1006A, Space System Protection Standard (opens external site in a new tab). Locator: active Agency-level space-system protection requirements and mission scope; 2022; accessed 2026-07-26. Requirements are not implementation evidence.
- S10 — NASA, Space Security: Best Practices Guide Revision B (opens external site in a new tab). Locator: risk-based space-vehicle and ground-segment controls, planning context, and guidance boundary; 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 software, firmware, AI, cyber-physical, and dual-use claims require explicit two-person review before publication
- Required review: software assurance, firmware security, operational technology, safety engineering, supply-chain risk, AI/autonomy, and configuration management
- 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