Accountability sits with the organisation that owns the service, because NIS2 expects supplier risk to be governed inside operational resilience processes. In practice, that means business owners, identity teams, and security leadership must share responsibility for access issuance, review, and revocation, especially when third-party credentials touch critical systems.
Why This Matters for Security Teams
NIS2 does not let supplier access become a gray area. When a third party uses an account, token, API key, or integration path to reach critical services, the regulated organisation still owns the risk, the review process, and the incident outcome. That is why supplier governance must sit inside identity, resilience, and change management, not only in procurement. The legal baseline is set by the NIS2 Directive - official EU legal text, while NHI exposure patterns show why this matters operationally: the Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties.
That supplier relationship can be perfectly documented and still fail if access is overbroad, long-lived, or not revoked when the contract ends. NHI controls are often the missing link between supplier assurance and actual containment, especially when service accounts are shared across teams or embedded in automation. In practice, many security teams encounter supplier-driven access misuse only after an incident review, rather than through intentional control testing.
How It Works in Practice
Accountability should be organised around the service owner, with identity, security, and procurement each carrying defined tasks. The service owner approves business need, the identity team issues and reviews access, and security validates that supplier access follows least privilege, logging, and revocation rules. The OWASP Non-Human Identity Top 10 is useful here because supplier access is often an NHI problem first and a vendor problem second.
Operationally, this usually means:
- Maintain an inventory of supplier identities, secrets, service accounts, and API integrations tied to each critical service.
- Assign a named business owner for each supplier path, with explicit review and revocation responsibility.
- Use short-lived credentials or JIT approval where possible, rather than persistent shared secrets.
- Log every supplier access grant, elevation, and renewal so incident teams can reconstruct who had access and why.
- Test revocation on contract exit, breach response, and inactive account cleanup.
NHIMG research reinforces the stakes: only 20% have formal offboarding and revocation processes for API keys, and 91.6% of secrets remain valid five days after notification, which means supplier access can outlive the business need by a wide margin. Controls should map back to the incident response and resilience obligations described in Ultimate Guide to NHIs - Regulatory and Audit Perspectives. These controls tend to break down when supplier access is embedded in CI/CD pipelines or shared automation because ownership becomes diffuse and revocation is not tied to a single operational trigger.
Common Variations and Edge Cases
Tighter supplier controls often increase onboarding time and administrative overhead, requiring organisations to balance resilience against delivery speed. That tradeoff is real, especially when suppliers need emergency access, run managed services, or support multi-tenant platforms. Current guidance suggests the answer is not blanket trust or blanket denial, but clearly scoped access with time limits, monitoring, and pre-agreed escalation paths.
There is no universal standard for supplier accountability mapping yet, but NIS2-aligned programs usually distinguish between ownership of the service, operation of the account, and legal responsibility for the incident. For example, a managed service provider may administer access, while the regulated entity still owns approval, review, and containment decisions. This becomes especially important when secrets are stored in code, shared across environments, or granted to multiple external operators.
Best practice is evolving toward contract language plus technical enforcement. That means supplier obligations should reference the Ultimate Guide to NHIs for lifecycle control expectations and the 52 NHI Breaches Analysis for real-world failure patterns. In practice, the hardest cases are emergency access, inherited credentials, and suppliers embedded so deeply in operations that no one can prove who last approved the access path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIS2 | Article 21 | Requires supplier risk and access governance inside operational resilience. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Supplier credentials must be rotated and revoked to limit third-party exposure. |
| NIST CSF 2.0 | PR.AA-05 | Identity and access management should cover external service accounts and suppliers. |
Tie supplier access review, revocation, and incident reporting to the organisation's resilience process.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
