safemode.space
← All techniques
IA-0009
ST0003Initial Access

Trusted Relationship

Description

Adversaries obtain first execution by riding connections that the mission already trusts, formal interconnections with partners, vendors, and user communities. Once a third party is compromised, the actor inherits that entity’s approved routes into mission enclaves: VPNs and jump hosts into ground networks, API keys into cloud tenants, automated file drops that feed command or update pipelines, and collaboration spaces where procedures and dictionaries circulate. Because traffic, credentials, and artifacts originate from known counterparts, the initial execution event can appear as a routine payload task, scheduled procedure, or software update promoted through established processes.

Mappings

EU regulation articles

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

    Authentication obligations bound the privileges third-party connections receive within the product; products designed under (2)(d) require explicit, factor-bound auth even from trusted relationships.

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

    Trusted-relationship initial-access exploitation (primary mapping: Art. 13(5)) implies SBOM-grade documentation of partner-provided components and access paths under (1).

  • craArt. 13(5)
    addresses
    moderate
    derived

    Manufacturer due-diligence applies to third-party integration relationships (vendors, partners, support providers) whose connections trusted-relationship attacks ride through.

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

    Federated VPNs, jump hosts, API keys, and identity-provider integrations are governed by 81(1)'s IAM protocols — the discipline that prevents inherited trust from converting into unrestricted access.

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

    Trusted-relationship initial-access (primary: Art. 81(1)) cascades to 81(4) — federated-credential lifecycle audit limits cross-domain reach of inherited trust.

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

    Trusted-relationship initial-access exploits formal interconnections with partners, vendors, and user communities — exactly the contractual supplier landscape 92(1) requires the operator to govern with information-security clauses.

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

    The technique is precisely the supplier-relationship security obligation in Art. 21(2)(d): formal interconnections with partners, vendors, and user communities (VPNs, jump hosts, API keys, automated file drops) all sit on direct supplier and service-provider trust.

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

    Multi-factor authentication on partner integration accounts, jump hosts, and federated identities under Art. 21(2)(j) limits the value of credentials harvested from a compromised counterpart.

  • nis2Art. 21(3)
    addresses
    high
    direct

    A compromised partner inheriting approved routes is the canonical scenario Art. 21(3) covers: vulnerabilities specific to each direct supplier (and the variable quality of their cybersecurity practices) propagate into the entity's enclaves through trusted channels.

  • nis2-implAnnex 11.2.1
    addresses
    high
    derived

    Access-rights provisioning to third-party connections must follow the same provision-modify-remove discipline as internal accounts; trusted-relationship abuse is the consequence of stale or over-broad third-party rights.

  • nis2-implAnnex 11.3.1
    addresses
    moderate
    derived

    Where third parties hold privileged access (vendor admin, partner ops), the privileged-account policy bounds the population and applies the strong identification, separation and review obligations that limit trusted-relationship abuse.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    Trusted relationships, with partners, vendors and user communities, are exactly the relationships the supply-chain policy is established to govern; the policy specifies how the entity contracts with and monitors third parties whose connections it trusts.

  • nis2-implAnnex 5.1.6
    addresses
    high
    derived

    Trusted-relationship counterparties hold persistent connections; Annex 5.1.6 monitoring is the procedural lever that detects deteriorating posture, breaches and policy non-compliance among those counterparties before they are weaponized against the entity.

  • nis2-implAnnex 5.1.7
    addresses
    high
    derived

    Annex 5.1.7 reporting and follow-up procedures convert third-party monitoring signals into access-rights review, contract action and incident-coordination escalations.

ENISA controls

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

    Cyber supply-chain risk management of partners, vendors, and user communities is the named operator-side discipline that scopes the trust relationships IA-0009 abuses.

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

    Supplier security management requires evidence of security posture from the third parties whose compromise enables the IA-0009 inheritance pattern.

  • ENISA-STL-2025-03-sD.29-i02
    mitigates
    moderate

    Intrusion detection and prevention on connections from partner enclaves identifies anomalies even when traffic originates from a trusted route.

Cross-reference controls

SPARTA countermeasures

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

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