Art. 81(3)
Mapped SPARTA techniques (31)
Techniques referencing this article
FDIR is a critical function; 81(3)(b)'s restrict-access-to-critical-functions clause limits which entities can write to fault-management parameters.
81(3)(b)'s restrict-access-to-critical-functions clause limits which entities can disable telemetry publishers or alter packet filters.
Receiver-enable changes are critical-function actions; 81(3)(b)'s restriction governs who can issue them.
WDT registers and supervisor commands are critical-function controls; 81(3)(b) restricts which entities can edit them.
81(3)(c) requires IAM protocols to be tailored to standard operations and emergency situations — safe-mode is the emergency context DE-0005 exploits, and the obligation forbids unbounded relaxation.
Whitelist edits are critical-function actions; 81(3)(b) restricts which entities can write to enforcement tables.
81(3)(b)'s restrict-access-to-critical-functions clause directly governs who can issue low-level hardware commands (memory-mapped writes, fuse-programming, actuator primitives) that bypass high-level mediation.
81(3)(b)'s restrict-access-to-critical-functions clause limits which entities can write to executable regions, load tables, or invoke maintenance consoles that deliver malicious code.
81(3)(c)'s requirement that IAM protocols be tailored to standard operations and to emergency situations directly governs the safe-mode authentication discipline EX-0011 exploits.
Direct memory commands, table loaders, and maintenance procedures that edit on-board values must be governed by 81(3)(b)'s restrict-access-to-critical-functions clause — the population that can invoke these mechanisms must be bounded.
Internal-register writes during FSW operation are critical-function actions — 81(3)(b) restricts the population that can issue register-modification commands.
Direct memory write/load commands are precisely the critical-function-access scenario 81(3)(b) restricts — only authorized identities should be able to invoke raw memory operations.
Real-time scheduling parameters (priorities, periods, deadlines, watchdog thresholds) are critical-function configuration — 81(3)(b)'s access restriction governs which entities can edit these.
Propulsion is a critical function — 81(3)(b)'s restrict-access-to-critical-functions clause is foundational for who can edit thruster calibration, valve timing, and inhibit masks.
ADCS parameters (sensor alignments, estimator covariances, controller gains) are critical-function configuration; 81(3)(b)'s access restriction limits who can write to these.
Electrical power subsystem parameters govern survival; 81(3)(b)'s restrict-access-to-critical-functions clause applies to bus voltage limits, MPPT setpoints, battery thresholds.
C&DH tables (opcode-to-handler maps, queue depths, message ID routing) are core control-flow configuration — 81(3)(b)'s critical-function restriction governs who can modify these.
Communications-link configuration is a critical-function setting under 81(3)(b)'s scope — only restricted entities should be able to edit transponder routing or modulation profiles.
SDR profile/configuration changes are critical-function actions; 81(3)(b)'s access restriction governs which entities can write to SDR control planes.
Transponder configuration is a critical-function setting; 81(3)(b)'s restrict-access clause governs which entities can edit translation/QoS rules.
81(3)(a) explicitly safeguards access to the ground segment and centres for the control of the space segment — the precise infrastructure EXF-0007 attacks.
81(3)(b)'s restriction-of-access-to-critical-functions obligation governs which docking-interface tooling can write to bus gateways or push firmware loads.
81(3)(a)'s safeguard-access-to-the-space-segment clause covers physical-access pathways — debug interfaces and checkout connectors that grappling exposes are critical-equipment entry points.
81(3)(b)'s restriction-of-access-to-critical-functions covers the boundary between hosted payload and host bus — limiting the population that can issue payload commands or alter memory across the gateway.
81(3)(a) explicitly requires safeguarding access to the ground segment and centres for the control of the space segment — the precise infrastructure IA-0007 attacks.
81(3)(c) requires identity-and-access-management protocols to be tailored to standard operations and to emergency situations — safe-mode is exactly the emergency case where IA-0010 exploits relaxed checks; the obligation forbids unbounded relaxation.
81(3)(b)'s restrict-access-to-critical-functions clause covers the host-payload boundary — limiting the population that can reach across the gateway.
81(3)(b)'s restrict-access-to-critical-functions limits which entities can write to non-volatile partitions, fuses, and golden-image stores.
81(3)(a)'s safeguarding of access to the ground segment and centres for control of the space segment, combined with (b) restricting access to critical assets/functions, mitigates lateral spread post-initial-access into mission ground.
81(3)(b) restricts physical and logical access to critical assets, critical functions, and critical operations — propulsion and attitude-control documentation typically falls in this category, restricting the population that can read GNC artifacts.
FDIR is a critical function; 81(3)(b)'s access-restriction-to-critical-functions clause restricts access to fault-management documentation and tooling.