safemode.space
← All techniques
IA-0009.02
ST0003Initial Access
sub-technique

Vendor

Parent: IA-0009

Description

Vendors that design, integrate, or support mission systems often hold elevated, persistent routes into operations: remote administration of ground software and modems, access to identity providers and license servers, control of cloud-hosted services, and authority to deliver firmware, bitstreams, or patches. Attackers who compromise a vendor’s enterprise or build environment can assume these roles, issuing commands through approved consoles, queuing updates in provider-operated portals, or invoking maintenance procedures that the mission expects the vendor to perform. Some vendor pathways terminate directly on RF equipment or key-management infrastructure; others ride cross-account cloud roles or managed SaaS backends that handle mission data and scheduling.

Mappings

EU regulation articles

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

    Authentication obligations bound vendor remote-administration access; manufacturer-enforced auth on these privileged paths prevents credential leak from converting into operations-affecting access.

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

    Because the Vendor technique turns vendor-delivered firmware, bitstreams, and patches into an attack path, the requirement to identify and document vulnerabilities and components, including an SBOM covering at least top-level dependencies, makes those vendor-supplied components and their known weaknesses enumerable rather than opaque. This documentation addresses the technique by giving the operator a tracked inventory of the vendor dependencies an attacker would have to subvert, though it does not by itself control the vendor's access routes.

  • craArt. 13(5)
    addresses
    high
    derived

    Vendor due-diligence is the canonical case for Art. 13(5): manufacturers must vet remote-administration suppliers and integration partners that hold persistent access to the product.

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

    Vendor accounts with elevated, persistent routes into operations are the precise IAM target of 81(1) — least-privilege and lifecycle disciplines limit vendor-derived initial access.

  • eu-space-actArt. 81(4)
    addresses
    moderate
    direct

    81(4)'s issuance/management/revocation/audit lifecycle limits the persistence of vendor credentials beyond engagement scope, reducing the window for vendor-derived compromise.

  • eu-space-actArt. 81(5)
    addresses
    moderate
    direct

    Vendor-trust persistent routes (primary: Art. 81(1) + Art. 81(4)) cascade to 81(5) — vendor authorizations should be auto-revoked when engagements end.

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

    Vendor remote administration and patch-delivery routes are the canonical supplier-trust channels 92(1)'s contracts must cover — limiting vendor-derived compromise via security clauses.

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

    Vendors with persistent remote-administration routes, IdP/license access, and patch-delivery authority are core direct service providers; Art. 21(2)(d)'s supplier-relationship security obligation is the central control over those high-trust relationships.

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

    MFA on vendor remote-admin accounts, signing-tool sessions, and cross-account cloud roles under Art. 21(2)(j) reduces the credential-driven escalation path from vendor enterprise to mission infrastructure.

  • nis2Art. 21(3)
    addresses
    high
    direct

    Compromise of a vendor's enterprise/build environment escalates directly into mission systems via approved consoles and managed SaaS — the canonical supplier-specific vulnerability Art. 21(3) requires the entity to factor in.

  • nis2-implAnnex 11.3.1
    addresses
    high
    derived

    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.

  • nis2-implAnnex 11.7.1
    addresses
    high
    derived

    Multi-factor authentication on vendor remote-administration paths is the procedural defense that prevents a vendor credential leak from converting into operations-affecting access.

  • nis2-implAnnex 3.3.2
    addresses
    moderate
    derived

    Vendors with admin access must know how to report suspicious events back to the entity; Annex 3.3.2 requires the entity to communicate event-reporting mechanisms to suppliers.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    Vendors with persistent administrative routes into mission systems (ground software, modems, identity providers) are the canonical direct-supplier population the supply-chain policy governs.

  • nis2-implAnnex 5.1.6
    addresses
    high
    derived

    Vendors with persistent admin access require Annex 5.1.6 ongoing monitoring of their security posture, incident disclosures and remote-access usage patterns.

  • nis2-implAnnex 5.1.7
    addresses
    high
    derived

    Annex 5.1.7 follow-up procedures operationalize vendor-monitoring signals into vendor-access review, MFA-enforcement adjustments and contract remediation.

ENISA controls

  • ENISA-STL-2025-03-sD.20-i04
    addresses
    moderate

    Multi-supplier strategies and cyber-SCRM processes reduce single-vendor dependency that enables the IA-0009.02 footprint.

  • ENISA-STL-2025-03-sD.26-i07
    addresses
    high

    Remote-access management governs vendor remote-administration sessions to ground software and modems, including possible remote deletion when compromise is detected.

  • ENISA-STL-2025-03-sD.28-i01
    addresses
    high

    Supplier security management with ISMS audits and reviews directly addresses vendor compromise as the IA-0009.02 vector.

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

    Outsourced-development controls direct, monitor, and review contractor access including remote administration, the privileged routes IA-0009.02 inherits.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, IA-0009.02 (SPARTA v3.2).

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