Why does NIS2 make third-party access harder to ignore?

Why Third-Party Access Becomes a NIS2 Resilience Issue

NIS2 pushes third-party access out of the “vendor management” bucket and into operational resilience. That matters because external identities often carry production reach, but sit outside the organisation’s normal joiner-mover-leaver controls. The legal text makes supply chain and access governance part of security accountability, which is why dormant vendor accounts, shared contractor credentials, and unmanaged API keys are no longer tolerated as administrative leftovers. The NIS2 Directive and the OWASP Non-Human Identity Top 10 both reflect the same reality: access that is not continuously governed becomes a resilience gap. NHI Mgmt Group research shows that 92% of organisations expose NHIs to third parties, which makes supplier access a common control failure rather than an edge case, as covered in the Ultimate Guide to NHIs.

In practice, many security teams encounter this only after a partner relationship ends but the account, token, or integration is still live.

How It Works in Practice

Under NIS2, the practical question is not whether a supplier needs access, but whether that access is provably limited, monitored, and removable at the moment risk changes. Current guidance suggests treating third-party identities like any other privileged workload or operator identity: define ownership, scope, logging, and revocation from the start. That means every external account should have a named business sponsor, an explicit purpose, and a documented expiry or review cycle. Where access is provided through machines rather than humans, workload identity and short-lived credentials are increasingly preferred over static secrets.

In mature environments, this usually translates into four controls:

• Time-bound access with automatic offboarding when the contract, project, or incident window closes.
• Central logging of external activity so supplier actions are attributable and reviewable.
• Secret storage and rotation discipline for API keys, certificates, and tokens.
• Periodic recertification tied to service ownership, not just procurement status.

That approach aligns with the resilience intent of NIS2 and with broader identity control practice described in Ultimate Guide to NHIs — Key Challenges and Risks. It also fits the control logic in NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially where organisations need least privilege, auditing, and lifecycle enforcement across external access paths. 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 no longer a single action.

Common Variations and Edge Cases

Tighter third-party access often increases operational overhead, requiring organisations to balance rapid supplier collaboration against stronger revocation and review discipline. That tradeoff is real, especially in incident response, managed services, and software supply chain integrations where access must be granted quickly. Best practice is evolving, but the direction is clear: temporary access should be the default, not the exception, and shared credentials should be eliminated wherever attributable identity is possible.

One common edge case is the “vendor tool” that behaves like an internal system but is owned externally. Those integrations frequently bypass normal access review because they are seen as technical plumbing rather than third-party access. Another is emergency access during incidents, where the business pressure to preserve uptime can delay offboarding. In both cases, the governance failure is the same: access persists longer than its original risk justification.

NIS2 also intersects with incident reporting and supplier assurance, so evidence matters. Organisations should be able to show who approved access, when it was last used, what it touched, and how it is revoked. For teams mapping real-world breach patterns, the 52 NHI Breaches Analysis is a useful reminder that access sprawl and weak offboarding are recurring failure modes, not isolated mistakes. Where third-party access is delivered through unmanaged API keys or long-lived secrets, NIS2-style accountability often collapses because the organisation cannot prove timely control over the identity at all.

Related resources from NHI Mgmt Group

• Why does NIS2 make third-party access a governance issue?
• Why do VPNs make third-party access harder to govern?
• What breaks when third-party access is left open too long?
• Who is accountable when third-party administrators access regulated systems?