Why do supplier identities create so much NIS2 compliance risk?

Why Supplier Identities Become a NIS2 Liability

Supplier identities are risky under NIS2 because they sit outside the strongest parts of most organisations’ identity governance model while still retaining real access to systems, data and change paths. That combination creates a compliance problem, not just an operational one. NIS2 expects proportionate control over access, third-party risk and security accountability, and supplier accounts often fail all three when ownership is unclear or reviews are incomplete. The legal text of the EU NIS2 Directive raises the bar from “track access” to “prove governance.”

NHIMG research shows how common this gap is in practice: 92% of organisations expose NHIs to third parties, and 97% of NHIs carry excessive privileges, which makes supplier access a frequent source of residual risk rather than a niche exception. The problem is amplified because supplier identities are often created for delivery speed, then left in place long after the business need changes. In practice, many security teams encounter supplier identity risk only after an audit finding or incident has already exposed weak offboarding and over-privilege.

How Supplier Access Becomes a Control Failure

Supplier identities usually enter the environment through onboarding workflows that optimise for service delivery, not for continuous governance. The security team may approve a vendor account once, but the account then persists across contract renewals, staff changes, tool migrations and emergency support events. That is where NIS2 compliance risk accumulates: the identity exists, remains active, and is difficult to justify at review time.

Current guidance suggests treating supplier identities as a distinct governance population with named owners, explicit purpose, expiry dates and periodic recertification. The practical controls are straightforward:

• Bind each supplier identity to a specific contract, service or change window.
• Use least privilege and remove broad standing access where task-based access is sufficient.
• Require strong authentication and separate supplier accounts from internal user accounts.
• Review access on a fixed schedule and at termination, not only during annual audits.
• Revoke credentials and API keys immediately when the supplier relationship ends.

That lifecycle view aligns with NHIMG guidance on Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and with the broader governance themes in Ultimate Guide to NHIs — Regulatory and Audit Perspectives. For a baseline control model, the NIST Cybersecurity Framework 2.0 is useful because it ties identity governance to broader risk management and oversight. These controls tend to break down in fast-moving outsourcing environments where supplier access is granted through multiple systems and no single owner can prove where it still exists.

Common Failure Patterns and Audit-Ready Responses

Tighter supplier access control often increases operational overhead, requiring organisations to balance delivery speed against demonstrable governance. That tradeoff is real, especially when suppliers support incident response, managed services or development pipelines. There is no universal standard for every environment, but current guidance consistently favours short-lived access, explicit accountability and evidence that access is reviewed, not assumed to be temporary.

Common failure patterns include shared vendor accounts, inactive accounts that remain enabled “just in case,” and credentials embedded in tooling that survive contract termination. Supplier identities are also more likely to bypass normal joiner-mover-leaver processes because they are treated as exceptions. Best practice is to close that gap by making supplier accounts part of the same evidence chain used for NIS2: who approved the access, what business need justified it, when it expires, and how revocation is verified. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Why NHI Security Matters Now both reflect the same point: unmanaged third-party identity sprawl becomes audit evidence of weak control design, not just a hygiene issue.

Where programmes struggle most is in environments with many subcontractors, emergency access requests and shared operational tooling, because ownership becomes fragmented and revocation is difficult to prove.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-employee identities create more governance risk than employee accounts?