Annex I, Part II, (3)

Subvert-protections-via-safe-mode (primary mapping: Annex I, Part I, (2)(k) exploitation mitigation) requires regular tests under (3) of the safe-mode posture itself — only repeated security review validates that contingency dictionaries do not relax authentication beyond intended.

Modify-whitelist (primary mapping: Annex I, Part I, (2)(k)) requires regular tests under (3) of whitelist tamper-resistance — periodic verification that the whitelist enforcement mechanism remains intact.

Rootkit evasion (primary mapping: Annex I, Part I, (2)(k)) cascades to (3)'s regular-tests obligation — exploitation-mitigation mechanisms (signed code, control-flow integrity) require ongoing validation through fuzzing and integrity-attestation tests.

Bootkit evasion (primary mapping: Annex I, Part I, (2)(k)) cascades to (3) — secure-boot and root-of-trust mitigations require regular boot-chain integrity testing to validate that bootkit attacks remain detected.

Onboard SSA/SDA-sensor deception (primary mapping: Annex I, Part I, (2)(k)) requires regular tests under (3) of the fusion algorithm's robustness against adversarial inputs (dazzling, spoofed transponder replies).

Ground-SDA corruption/overload (primary mapping: Annex I, Part I, (2)(k)) requires regular tests under (3) of the ingestion and detection-model robustness against adversarial inputs.

Effective and regular tests and reviews of product security surface dormant geofenced trigger logic before release; static analysis, taint analysis and behavior-state testing are within the scope of (3).

Effective and regular security tests and reviews surface time-keyed dormant logic before release; behavior-state and time-fast-forward testing fall within (3) scope.

Regular security testing is the manufacturer-side discipline that uncovers absolute-time dormant-trigger code in the product before release.

Effective security testing surfaces relative-time-keyed triggers that activate after specific event sequences.

Effective and regular security testing (static analysis, fuzzing, integration testing) surfaces code flaws before they reach production, narrowing the attack surface.

Effective and regular tests and reviews (static analysis, fuzzing of command parsers and table loaders, integration testing on flatsats) are the manufacturer-side discipline that surfaces FSW flaws before flight.

Malicious-code-execution exploitation (primary mapping: Annex I, Part I, (2)(k)) cascades to (3)'s regular-tests obligation — exploitation-mitigation mechanisms must be validated through ongoing security testing.

Memory-tampering exploitation (primary mapping: Annex I, Part I, (2)(k)) requires regular tests under (3) — memory-protection mitigations need periodic validation through fuzzing and overflow testing.

Effective and regular tests and reviews extend to model validation (data-distribution checks, robustness testing) that surfaces poisoning effects before deployment.

Security testing (fuzzing of telecommand parsers and bus decoders) is the manufacturer-side discipline that surfaces parser fragility erroneous-input flooding exploits.

Security testing of estimation pipelines and outlier-rejection logic surfaces fragility that fabricated sensor data exploits.

Effective and regular tests and reviews include side-channel-resistance testing (DPA/SPA, EM probing, timing analysis) as part of the manufacturer's security-testing program.

Side-channel exfiltration parent (primary mapping: Annex I, Part I, (2)(k)) cascades to (3) — side-channel countermeasures (masking, blinded crypto, EM shielding) require regular validation through dedicated side-channel testing.

Power-analysis attacks (primary mapping: Annex I, Part I, (2)(k)) require regular DPA/CPA testing under (3) — masking and randomization countermeasures lose effectiveness if not validated under realistic measurement scenarios.

Electromagnetic-leakage attacks (primary mapping: Annex I, Part I, (2)(k)) cascade to (3) — TEMPEST shielding requires regular validation by near-field probe testing in the security review.

Timing attacks (primary mapping: Annex I, Part I, (2)(k)) require regular constant-time-implementation testing under (3) — micro-architectural changes can reintroduce timing variance over the support period.

Thermal-imaging attacks (primary mapping: Annex I, Part I, (2)(k)) cascade to (3) — thermal-balancing countermeasures require periodic validation through thermal-imaging-based security testing.

Proximity-operations TEMPEST/EMSEC exfiltration (primary mapping: Annex I, Part I, (2)(k)) requires regular EMSEC validation under (3) — proximity attack vectors evolve with sensor capabilities, demanding ongoing testing.

Effective and regular security tests must extend to test harnesses, simulators, and flight builds — the development-pipeline artifacts EXF-0008 attacks; (Part II, 3)'s testing obligation applies to the supply chain that produces the product.

Regular security tests and reviews of the product would exercise the hosted payload's exposed command sets, file services, and payload-host bus interface, surfacing the rarely-used modes, table-load and firmware-update paths, and unvalidated command channels that this technique exploits for a first foothold. Without that recurring testing discipline, the cross-strapped and contingency-mode behaviors that appear only in maintenance go unprobed and remain available to an attacker who knows the interface specification.

Secondary/backup-comm initial-access (primary mapping: Annex I, Part I, (2)(k)) requires regular testing under (3) of the alternate-channel security posture — these channels often miss the test scope of primary TT&C.

IA-0013 gains initial access by exploiting vulnerabilities in the host spacecraft's onboard systems, communication interfaces, and software, which are exactly the weaknesses that the obligation to apply effective and regular tests and reviews of the product's security is meant to surface. Regular security testing of the host vehicle reduces the unaddressed onboard flaws an adversary uses to reach the hosted payload, supporting an addresses-level relationship.

Degradation-impact (primary mapping: Annex I, Part I, (2)(k)) cascades to (3) — exploitation-mitigation mechanisms (rate limiting, watchdog-bounded operation) require regular tests to validate effectiveness against degradation scenarios.

Effective and regular tests of separation-kernel/hypervisor boundaries (fuzzing of message ports, IOMMU validation) is the (Part II, 3) obligation manufacturers must apply for products relying on virtualization separation.

Effective and regular security testing (static analysis, taint analysis, behavioural testing of authentication paths) is the procedural mechanism that surfaces backdoors before they reach production.

Security-testing procedures (taint analysis, integration-level authentication tests) surface software backdoors before they reach production.

Annex I, Part II, (3) requires manufacturers to apply effective and regular tests and reviews of product security; the same disciplined testing program that surfaces vulnerabilities also drives the test-tool inventory that security-testing-tools reconnaissance attempts to enumerate, but a manufacturer that systematically tests narrows the gap-discovery surface.