Annex 11.3.1

Authority to alter FDIR thresholds, watchdog timeouts or safing autonomy is privileged-account authority; the privileged-account policy bounds the population and applies the review obligations that surface misuse.

Authority to disable telemetry channels, mute event reports or alter packet filter rates is privileged-account authority; the privileged-account policy bounds the population that can issue such modifications.

Authority to write to housekeeping registers and obfuscate operator-visible state is privileged-account authority; the privileged-account policy is the lever that bounds the population that can issue these obfuscations.

Authority to switch crypto profiles, select keys or enter clear-mode is privileged-account authority; the privileged-account policy is the procedural lever that prevents single-actor downgrade-to-clear.

Authority to modify execution whitelists is privileged; the privileged-account policy applies its identification and review obligations to that population.

Hardware-level commands (memory-mapped register writes, JTAG/test-mode commands) are privileged-account actions; the privileged-account policy bounds who can issue them and under what review.

Operators authorized to alter encryption state are privileged-account holders; the privileged-account policy bounds the population, applies strong identification and requires review of crypto-disabling actions.

Operators authorized to alter on-board values are privileged-account holders; the privileged-account policy bounds the population that can issue parameter modifications and applies strong identification and review obligations.

Memory-write authority is privileged; the privileged-account policy bounds who can issue raw memory operations and applies the review obligations that detect misuse.

Authority to alter propulsion parameters is privileged-account authority; the privileged-account policy bounds the population and applies strong identification.

ADCS-parameter modification authority is privileged; the privileged-account policy bounds the population and applies the review obligations that detect misuse.

Authority to alter EPS parameters is privileged; the privileged-account policy applies its identification and review obligations to the population that holds it.

Authority to alter communications configuration is privileged-account authority; the privileged-account policy bounds the population that can issue such modifications and applies the review obligations that detect malicious reconfiguration.

Authority to remap transponder paths and adjust translation parameters is privileged; the privileged-account policy bounds the population that can issue such mirroring/forwarding configurations.

Build operators, simulator administrators and ATLO test controllers are privileged-account holders; the privileged-account policy bounds the population that can ever extract development artefacts at scale.

Operator commanding accounts are privileged accounts; the privileged-account policy specifies strong identification, separated administration and review obligations that constrain how a compromised mission-owned GS can issue mission-affecting commands.

Where third parties hold privileged access (vendor admin, partner ops), the privileged-account policy bounds the population and applies the strong identification, separation and review obligations that limit trusted-relationship abuse.

Vendor admin access is privileged-account access by definition; the privileged-account policy is the procedural lever that constrains how vendor accounts are provisioned, monitored and reviewed.

Privileged-account policy bounds which credentials confer cross-boundary authority; the privileged-account discipline is the procedural lever that constrains how far credentialed traversal can travel.

Authority to replace cryptographic keys is privileged-account authority; the privileged-account policy bounds the population, applies strong identification and review obligations and resists single-actor key-rotation events.

Service accounts and maintenance accounts are privileged-account population; the privileged-account policy applies strong identification, periodic review and separation-of-duty requirements that detect attacker-controlled long-lived credentials.

COMSEC custodians and key-management operators are privileged accounts under Annex 11.3; the privileged-account policy bounds the population that can ever extract live key material.

Build operators, release engineers and code-signing custodians are privileged accounts under Annex 11.3, and the privileged-account policy is the procedural lever that bounds source-code and binary-with-symbol exposure to the smallest set of trusted operators.

Custodians of cryptographic algorithm and key documentation are privileged-account holders by definition; the privileged-account policy bounds the population that can access COMSEC documentation.

Build pipelines, code-signing services and release-train operators are privileged-account environments whose access policies bound the population that can pull or copy FSW artefacts.

Privileged accounts on build servers, signing nodes and dev-cluster admin consoles are within the privileged-account population whose recon exposure must be constrained.