Who is accountable when supplier access exposes defence information?

Why This Matters for Security Teams

Supplier access is not a paperwork issue; it is an identity governance issue with operational and legal consequences. When a supplier account reaches defence information, the organisation that approved the access, scoped the entitlement, and failed to monitor the session remains accountable for the risk. Contracts can allocate liability, but they do not enforce revocation, conditional access, or evidence of review. That is why identity controls must sit alongside procurement and programme oversight, not after it.

This becomes more serious when supplier credentials are shared, long-lived, or exempted from standard joiner-mover-leaver processes. NHIMG research shows that 92% of organisations expose NHIs to third parties, which means supplier access is often part of a wider non-human identity exposure pattern rather than an isolated exception. The OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both point to the same operational reality: access must be governed, reviewed, and retired with evidence. In practice, many security teams discover supplier overreach only after sensitive data has already been accessed outside the expected control path, rather than through intentional access governance.

How It Works in Practice

Accountability should be split by function, but not diluted by it. Security owns the control design, procurement owns contractual enforcement, and the business or programme owner owns the need for access. For defence information, that means every supplier identity should have a named sponsor, a documented purpose, an approval trail, a defined expiry, and a review cadence that matches the sensitivity of the data. Access should be granted through centrally managed identities wherever possible, not through ad hoc credentials created inside projects.

Practically, this requires a lifecycle model for supplier access:

• Pre-approval: validate business need, data classification, and export or handling restrictions.
• Provisioning: issue individual accounts with least privilege, MFA, and time-bound access where feasible.
• Monitoring: log authentication, session activity, privilege escalation, and data movement.
• Recertification: reassess need, role, and scope on a fixed schedule and after contract changes.
• Revocation: remove access immediately at contract end, role change, incident, or missed review.

For AI-enabled supplier workflows, the question widens beyond human contractors to include service accounts, API keys, and agentic tools that can touch defence repositories. NHIMG’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That matters because a supplier may be the user, but the real attack path may be an unattended token or overprivileged integration. Current guidance suggests treating every supplier-operated secret as a governed identity, not a convenience artifact. These controls tend to break down when supplier access is embedded in legacy defence programmes with shared accounts, unmanaged exceptions, or no authoritative offboarding process.

Common Variations and Edge Cases

Tighter supplier control often increases onboarding friction and coordination cost, requiring organisations to balance mission speed against exposure. That tradeoff is real in defence environments where urgent delivery, classified handling, and subcontracted work are common. The right answer is not to remove controls, but to calibrate them to the sensitivity of the information and the trustworthiness of the supplier relationship.

There is no universal standard for this yet, especially where suppliers need intermittent access, remote support, or access via a prime contractor. In those cases, current guidance suggests layering compensating controls such as just-in-time access, session recording, device posture checks, and segregated environments. If the supplier uses its own tooling, governance must extend to its secrets, not just its users. The 52 NHI Breaches Analysis is a useful reminder that repeated failures usually come from weak ownership, not a single technical gap. Where the defence context includes regulated personal data or critical supply chain dependencies, NIST control mapping should be explicit and auditable, because ambiguity over ownership is where accountability most often disappears.

Related resources from NHI Mgmt Group

• Who is accountable when an autonomous agent misuses access or exposes data?
• Who is accountable when a SAML integration exposes privileged access?
• Who is accountable when a supplier support workflow exposes customer data?
• Who is accountable when an endpoint management breach exposes privileged access?