Annex I, Part I, (2)(k)
Mapped SPARTA techniques (21)
Techniques referencing this article
CRA Annex I (2)(k) incident-impact reduction is domain-relevant but does not mitigate DE-0005, which exploits the recovery/safe-mode posture itself; the harm is blended unauthorised activity under relaxed checks, not an availability impact. The operative control is recovery-posture hardening that preserves checks during contingency. Addresses.
CRA Annex I (2)(k) is domain-relevant but does not mitigate DE-0006: whitelist modification is an execution-control vector that subverts the mitigation mechanism itself, not an incident-impact availability loss. The operative control is allowlist integrity and execution control. Addresses.
CRA Annex I (2)(k) is domain-relevant but does not mitigate DE-0007: a rootkit's harm is concealment of activity, not an incident-impact availability loss. The operative controls are runtime and kernel integrity with tamper-resistant observability. Addresses.
Pre-OS persistence is exactly the long-lived high-privilege impact (2)(k)'s exploitation-mitigation mechanisms are meant to reduce.
CRA Annex I (2)(k) is domain-relevant but does not mitigate DE-0009.04: onboard proximity-sensor deception distorts relative-state estimates (a deception vector), not an incident-impact availability loss. The operative controls are sensor-fusion integrity and cross-checks. Addresses.
CRA Annex I (2)(k) is domain-relevant but does not mitigate DE-0009.05: terrestrial SDA spoofing skews external decision-support (deception), not the product's availability. The operative controls are SDA data-source authentication and corroboration. Addresses.
Exploitation mitigation mechanisms (memory-safety primitives, ASLR, stack canaries, hypervisor-level controls) reduce the impact of a successful code-flaw exploitation.
Exploitation-mitigation mechanisms (memory-safety primitives, partition isolation, defensive coding) reduce the impact of successful FSW exploitation even when the underlying defect remains.
Exploitation-mitigation mechanisms reduce the impact of successful malicious-code introduction by constraining what executable content can do at runtime.
Exploitation-mitigation mechanisms (immutable storage, write-protected partitions) bound the destructive scope of wiper attacks.
Side-channel countermeasures (masking, hiding, dual-rail logic, EM shielding, blinded crypto) are exploitation-mitigation mechanisms (2)(k) requires manufacturers to apply at design and production time.
Masking, randomization, and power-balanced crypto cores are exactly the exploitation-mitigation mechanisms (2)(k) places on the manufacturer at design time.
EM-leakage countermeasures (TEMPEST-grade shielding, harness routing, package selection) are the manufacturer-side exploitation-mitigation mechanisms (2)(k) requires.
Constant-time MAC verification and branch-free crypto are exploitation-mitigation mechanisms (2)(k) places on the design and production phase.
mitigates DOWNGRADE: (2)(k) exploitation-mitigation is domain-adjacent but does not interdict a thermal side-channel that extracts secrets through physical heat emission; the operative controls are physical (thermal masking, balanced thermal layout, TEMPEST/EMSEC shielding), not generic incident-impact mechanisms.
TEMPEST-grade enclosure, harness routing, optical baffling, and emission shaping are exploitation-mitigation mechanisms (2)(k) places on the manufacturer at design and production phases.
Exploitation mitigation mechanisms (sandboxing, partition isolation, separation kernels) reduce the impact of payload compromise on host-bus operations.
Exploitation mitigation mechanisms in ground-system products (memory protection, sandboxing, separated commanding-authority components) reduce the impact of foothold-to-commanding conversion.
Exploitation mitigation mechanisms (separation kernels, partition isolation) bound the host's reach into the payload, the inverse of IA-0006 with the same isolation discipline.
Rapidly-induced subsystem degradation is a high-impact incident outcome (2)(k)'s exploitation-mitigation mechanisms (rate limiting on actuators, watchdog-bounded operation, sanity-checked thermal/power profiles) are meant to reduce.
Hypervisor-escape via parser flaws or driver out-of-bounds is the canonical exploitation scenario (2)(k)'s exploitation-mitigation obligation (IOMMU, capability checks, hardened parsers) is meant to reduce the impact of.