Why do third-party identities matter so much under NIS2?

Why Third-Party Identities Matter Under NIS2

Third-party identities matter because they extend your attack surface beyond staff-managed accounts and into supplier, contractor, and integration access that often persists after the original need has changed. NIS2 expects organisations to manage operational risk across the supply chain, so weak offboarding, poor verification, and unclear ownership can turn an external account into a compliance and incident-response problem.

This is not a theoretical issue. NHIMG research shows that 92% of organisations expose NHIs to third parties, which creates a broad supply-chain exposure layer that many teams underestimate. That risk is reflected in the NIS2 Directive itself, which places strong emphasis on supply chain security and access control expectations in the EU NIS2 Directive. In practice, third-party identities are often granted once and reviewed too late, if at all.

Security teams also need to account for the way external credentials are used in real environments. Supplier accounts frequently connect to SaaS platforms, CI/CD systems, admin consoles, and data pipelines, which makes them attractive for lateral movement if they are compromised. The OWASP Non-Human Identity Top 10 maps the governance patterns that fail when identities are not continuously controlled.

In practice, many security teams discover third-party identity exposure only after a supplier account is reused, forgotten, or abused, rather than through intentional access review.

How Third-Party Access Should Be Controlled in Practice

Under NIS2, the practical objective is not to eliminate third-party access, but to make it visible, justified, time-bound, and revocable. That starts with a complete inventory of external identities, including contractor logins, vendor support accounts, service integrations, shared admin access, and delegated API credentials. If an account cannot be tied to a named supplier relationship and business purpose, it should be treated as an unresolved risk.

Current guidance suggests treating supplier access as a lifecycle problem, not a one-time onboarding event. Access should be approved with a documented owner, a clear expiration date, and a defined remediation path for offboarding. Where possible, use strong authentication, separate identity domains, and least-privilege scoping. For machine-to-machine access, the same logic applies to secrets and service accounts: short-lived credentials, automated rotation, and revocation on contract end or incident trigger.

Useful operational checks include:

• Map every third-party identity to a contract, system owner, and renewal date.
• Require periodic re-attestation for supplier access that reaches production or sensitive data.
• Separate vendor admin access from internal privileged accounts.
• Log and review all supplier activity, especially support actions and privilege changes.
• Revoke credentials immediately when a vendor relationship changes or ends.

NHIMG research on the 52 NHI Breaches Analysis and the Ultimate Guide to NHIs shows why lifecycle gaps become operational failures: only 20% have formal offboarding and revocation processes, and 91.6% of secrets remain valid five days after notification. These controls tend to break down in complex supplier ecosystems because ownership is split across procurement, IT, and security, leaving no single team accountable for timely revocation.

Common Variations and Edge Cases

Tighter third-party access control often increases operational overhead, requiring organisations to balance supply-chain agility against stronger verification and review. That tradeoff is especially visible with managed service providers, software vendors, and emergency support accounts, where business teams want fast access but NIS2 pushes toward stricter control and evidence.

There is no universal standard for every supplier scenario yet, so best practice is evolving. For high-risk access, many organisations use just-in-time approvals, step-up authentication, and session recording. For lower-risk integrations, they may rely on scoped tokens, automated rotation, and API-level constraints. The important point is that the control should match the access path, not the vendor’s commercial status.

Edge cases appear when third-party access is embedded in automation or hidden inside tools that staff do not consider “accounts.” Examples include CI/CD runners, support bots, marketplace plugins, and outsourced monitoring agents. Those identities still count because they can read secrets, change configurations, or exfiltrate data. NHIMG reporting on the Hard-Coded Secrets in VSCode Extensions and the Shai Hulud npm malware campaign shows how quickly supplier-adjacent access can become a secret-exposure path. In regulated environments, these hidden identities are where NIS2 readiness often fails first.

Related resources from NHI Mgmt Group

• Why does third-party access create so much regulatory risk under DORA and NIS2?
• Why do non-human identities matter under NIS2?
• Why do service accounts and machine identities matter under NIS2?
• Why does third-party risk matter so much in healthcare cybersecurity?