safemode.space
← All techniques
EX-0012.13
ST0004Execution
sub-technique

Poison AI/ML Training Data

Parent: EX-0012

Description

When missions employ AI/ML, for onboard detection/classification, compression, anomaly screening, guidance aids, or ground-side planning, training data becomes a control surface. Data poisoning inserts crafted examples or labels into the training corpus or fine-tuning set so the resulting model behaves incorrectly while appearing valid. Variants include clean-label backdoors (benign-looking samples with a hidden trigger that later induces a targeted response), label flipping and biased sampling (to skew decision boundaries), and corruption of calibration/ground-truth products that the pipeline trusts. For space systems, poisoning may occur in science archives, test vectors, simulated scenes, or housekeeping datasets used to train autonomy/anomaly models; models trained on poisoned corpora are then packaged and uplinked as routine updates. Once fielded, a simple trigger pattern in imagery, telemetry, or RF features can cause misclassification, suppression, or false positives at the time and place the adversary chooses, turning model behavior into an execution mechanism keyed by data rather than code.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(f)
    addresses
    high
    derived

    Integrity protection on training-data inputs and model artefacts is the (2)(f) obligation engaged by data-poisoning attacks against onboard ML.

  • craAnnex I, Part II, (1)
    addresses
    moderate
    direct

    ML-model exploitation (primary mappings: Part II, (3) + Art. 13(5)) triggers (1)'s SBOM/component-documentation obligation for ML pipeline components and model dependencies.

  • craAnnex I, Part II, (3)
    addresses
    moderate
    derived

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

  • craArt. 13(5)
    addresses
    high
    derived

    AI/ML training-data suppliers (data brokers, annotation services, pretrained-model vendors) fall within manufacturer due-diligence obligations on third-party component integration.

  • eu-space-actArt. 88(1)
    addresses
    moderate
    direct

    88(1)'s testing programme can include adversarial-input testing and model-validation against poisoned-corpus scenarios — surfacing clean-label backdoors and decision-boundary skew.

  • eu-space-actArt. 88(3)
    addresses
    moderate
    direct

    AI/ML training-data testing (primary: Art. 88(1)) cascades to 88(3) — TLPT cadence covers ML pipeline adversarial-input scenarios.

  • eu-space-actArt. 92(1)
    addresses
    high
    direct

    AI/ML training data and pretrained models often arrive from third-party scientific archives, partners, or simulator providers — 92(1)'s contractual information-security obligation governs how training-data provenance is disciplined.

  • nis2Art. 21(2)(d)
    addresses
    moderate
    direct

    Training corpora, fine-tuning sets, calibration/ground-truth products, and simulated scenes ride supplier and service-provider data flows; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around those data products.

  • nis2Art. 21(2)(e)
    addresses
    moderate
    direct

    Model training, packaging, and uplink as routine updates are part of the network-and-information-systems acquisition/development/maintenance pipeline Art. 21(2)(e) governs, including disclosed-weakness handling for clean-label backdoors and label-flipping attacks.

  • nis2Art. 21(2)(i)
    addresses
    moderate
    direct

    Training corpora and test vectors are access-controlled assets; Art. 21(2)(i)'s access-control + asset-management obligation governs who can submit, label, or modify the data on which on-board models are trained.

  • nis2Art. 21(3)
    addresses
    high
    derived

    Primary mapping to Art. 21(2)(d) covers the data-supplier relationship for AI/ML training inputs. Art. 21(3) extends that obligation to the supplier's overall security quality, since the training-data poisoning surface depends on the data broker's secure-development discipline more than on the entity's own controls.

  • nis2-implAnnex 12.1.1
    addresses
    moderate
    derived

    Training datasets and reference labels are mission-critical information assets; their classification level drives the storage, access and integrity controls that constrain poisoning paths.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    AI/ML training data is supplied through data brokers, annotation services and pretrained-model vendors; the supply-chain policy is the procedural mechanism that constrains how those data suppliers are vetted and monitored.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    AI/ML model training is part of the secure-development life cycle; the rules for that lifecycle govern data integrity verification, model provenance and pre-deployment validation that detect poisoned training inputs.

ENISA controls

  • ENISA-STL-2025-03-sD.25-i10
    addresses
    moderate

    Integrity checking on training datasets and packaged model artefacts detects unauthorised modifications before models are deployed.

  • ENISA-STL-2025-03-sD.33-i06
    addresses
    high

    ML data-integrity testing for poisoning is the named control: regression testing, validity checking, manual analysis, and statistical analysis on training datasets.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, EX-0012.13 (SPARTA v3.2).

Built 2026-07-25 from 216 techniques, 334 regulation articles, 125 ENISA controls, 2,610 framework controls, and 90 countermeasures.