safemode.space
← All techniques
PER-0002.02
ST0005Persistence
sub-technique

Software Backdoor

Parent: PER-0002

Description

Software backdoors are code paths intentionally crafted or later inserted to provide privileged functionality on cue. In flight contexts, they appear as hidden command handlers, alternate authentication checks, special user/role constructs, or procedure/script hooks that accept nonpublic inputs. They can be embedded in flight applications, separation kernels or drivers, gateway processors that translate bus/payload traffic, or update/loader utilities that handle tables and images. SDR configurations offer another avenue: non-public waveforms, subcarriers, or framing profiles that, when selected, expose a private command channel. Activation is often conditional, specific timetags, geometry, message sequences, or file names, to keep the feature dormant during routine testing and operations. Once present, the backdoor provides a repeatable way to execute commands or modify state without traversing the standard control surfaces, sustaining the adversary’s access over time.

Mappings

EU regulation articles

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

    Software backdoors are exploitable vulnerabilities; manufacturers must not place products on the market with such defects under (2)(a).

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

    Software-backdoor persistence (primary mappings: Part II, (3) + Art. 13(5)) requires SBOM-grade documentation under (1) so persistent third-party-derived modules are visible to the manufacturer.

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

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

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

    Software-backdoor persistence (primary mappings: Part II, (3) + Art. 13(5)) implies CVD policy under (5) for inbound vulnerability reports concerning persistent malicious software.

  • craArt. 13(5)
    addresses
    moderate
    derived

    Software supply chains are the principal vehicle for backdoor introduction; manufacturer due-diligence frames the security expectations on supplier secure-development practices.

  • eu-space-actArt. 76(6)
    addresses
    moderate
    direct

    Software-backdoor detection (primary: Art. 88(1)) needs ongoing effectiveness assessment per 76(6).

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

    Software backdoors hide in code paths the testing programme under 88(1) is meant to surface — code review, fuzzing, and TLPT under 88(3) are the operator-side disciplines.

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

    Software-backdoor testing (primary: Art. 88(1)) cascades to 88(3) — TLPT cadence with adversary-emulating code review surfaces nonpublic command paths.

  • eu-space-actArt. 92(1)
    addresses
    moderate
    inferred

    Art. 92(1)'s supplier-contract information-security obligation is domain-relevant to supplier-introduced backdoors, but contractual governance does not itself interdict an embedded backdoor; signed-build and provenance verification would be the interdiction.

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

    Software backdoors are sometimes introduced at FSW-vendor or SDR-firmware-vendor sites; Art. 21(2)(d)'s supplier-relationship security obligation governs the vetting and assurance posture across those vendors.

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

    Hidden command handlers, alternate-authentication checks, special user/role constructs, and procedure/script hooks are integrity failures Art. 21(2)(e)'s secure development/maintenance and vulnerability-handling/disclosure obligation is meant to catch through code review, fuzzing, and disclosure response.

  • nis2Art. 21(3)
    addresses
    high
    derived

    Primary mapping to Art. 21(2)(d) covers the software-supply-chain origin where the backdoor is planted. Art. 21(3) procedurally extends to assessment of the supplier's secure-development practices and disclosure procedures, the only lever for catching backdoors that ship signed and provenance-clean from the supplier's build environment.

  • nis2-implAnnex 5.1.1
    addresses
    moderate
    derived

    Software supply chains are the principal vehicle for backdoor introduction; the supply-chain policy frames the security expectations on supplier secure-development practices that bound this risk.

  • nis2-implAnnex 5.1.6
    addresses
    high
    derived

    Software backdoor planting through software suppliers requires Annex 5.1.6 ongoing monitoring of supplier-side build-pipeline integrity, signing-key incidents and disclosure compliance.

  • nis2-implAnnex 5.1.7
    addresses
    moderate
    derived

    A software backdoor is hidden code that reaches flight applications, drivers, gateway processors, or loader utilities through a supplier-delivered ICT product or a later change to one, which is exactly what Annex 5.1.7(d) requires entities to catch by analysing the risks presented by changes related to suppliers' ICT products and taking mitigating measures. Point (b)'s duty to review incidents related to those ICT products and services covers the case where a planted command handler or alternate authentication path is reported, giving this article a specific hold on backdoors that enter through the supply chain rather than generic supplier oversight.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    Software backdoors are exactly the threat the secure-development life cycle counters: code review, mandatory authentication paths and signing/verification procedures resist hidden command handlers and alternate auth paths.

  • nis2-implAnnex 6.5.1
    addresses
    high
    derived

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

  • nis2-implAnnex 6.5.2
    addresses
    high
    derived

    Software-backdoor testing scope (taint analysis, behavioral testing of authentication paths, hidden-handler discovery) is what Annex 6.5.2 requires the entity to define under risk-assessment-driven testing.

  • nis2-implAnnex 6.5.3
    addresses
    moderate
    derived

    Annex 6.5.3 review-cadence ensures software-backdoor testing scope tracks code-base evolution and disclosure-driven new-attack patterns.

ENISA controls

  • ENISA-STL-2025-03-sD.21-i03
    addresses
    moderate

    Secure development lifecycle principles surface intentionally crafted hidden command handlers and special user/role constructs during code review.

  • ENISA-STL-2025-03-sD.25-i08
    addresses
    high

    Software source control prohibiting unverified binaries and requiring source visibility is relevant to keeping covert backdoors out of flight builds, but Software Source Control is a governance control and does not itself actively detect an inserted software backdoor.

  • ENISA-STL-2025-03-sD.33-i04
    mitigates
    moderate

    Static code analysis with two tools and CWE prioritisation can flag hidden command handlers, special role constructs, and conditional logic typical of software backdoors.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, PER-0002.02 (SPARTA v3.2).

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