They often treat vendor access as a connectivity issue instead of a governance issue. NIS2 makes external access part of the regulated attack surface, which means every supplier pathway needs explicit boundaries, ownership, and containment logic. Broad persistent access is not operational convenience; it is unmanaged exposure.
Why Security Teams Misread Third-Party Access Under NIS2
Security teams often focus on whether a vendor can connect, but NIS2 is concerned with whether that connection is governed, bounded, and defensible. Third-party access is part of the regulated attack surface because suppliers can trigger data movement, administrative actions, and service disruption. The obligation is not just to allow access, but to ensure it is proportionate, documented, and contained under explicit ownership, as reflected in the NIS2 Directive and the control expectations in the OWASP Non-Human Identity Top 10.
This is where many programmes fail: they inherit vendor accounts, shared secrets, and standing VPN paths without a lifecycle model. NHIMG research shows that 92% of organisations expose NHIs to third parties, while only 20% have formal offboarding and revocation processes for API keys. That gap turns supplier access into residual exposure rather than managed risk. In practice, many security teams encounter supplier misuse only after access has already been overprovisioned, not during the approval of the connection.
How Third-Party Access Should Be Governed in Practice
The operational answer is to treat every supplier pathway as a governed identity, not a network exception. That means defining who owns the access, what business purpose it supports, which systems it can reach, how long it exists, and how it is revoked. Current guidance suggests aligning vendor access with least privilege, explicit asset scoping, and evidence-based reviews rather than relying on broad trust in the supplier relationship.
For regulated environments, this often means replacing persistent shared credentials with individually attributable access, short-lived tokens, and time-bound approvals. Where possible, access should be tied to service accounts or workload identities with clear provenance, instead of generic accounts that blur accountability. Monitoring should capture both authentication events and downstream actions, because NIS2 relevance is not limited to login success. It extends to what the third party can change, exfiltrate, or interrupt.
- Inventory every third-party pathway, including SaaS integrations, remote support, API access, and outsourced operations.
- Assign a business owner and technical owner for each supplier entitlement.
- Remove standing access where task-based or time-limited access is workable.
- Log and review privileged actions, not just authentication events.
- Revoke access on contract end, role change, incident, or inactivity.
NHIMG’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which is especially dangerous when vendors are given long-lived credentials. These controls tend to break down in outsourced support environments because emergency access, break-glass practices, and legacy VPN dependencies create exceptions that are difficult to monitor consistently.
Where NIS2 Third-Party Controls Break Down
Tighter vendor controls often increase operational overhead, requiring organisations to balance regulatory assurance against business continuity. The hardest cases are not ordinary partner integrations, but environments with legacy platforms, emergency support, and high-churn supplier ecosystems. In those settings, current guidance is still evolving on how much segmentation, authentication strength, and evidence retention is sufficient for every type of external access.
One recurring blind spot is OAuth and API-based supplier access, because it looks low-friction but can create broad delegated authority. NHIMG research from The State of Non-Human Identity Security found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. That matters because delegated access often persists after the original approval context has changed. Another common failure is assuming vendor risk can be solved by contract language alone. NIS2 expects operational containment, not only procurement clauses. In practice, the weakest point is usually the exception path: urgent support, inherited admin roles, or integrations nobody fully owns after deployment.
Related resources from NHI Mgmt Group
- What do security teams get wrong about third-party access oversight?
- What do security teams get wrong about third-party access in CJIS environments?
- What do security teams get wrong about third-party access management?
- What do security teams get wrong about third-party access after a relationship ends?
