Sectona at Infosecurity Europe 2025 | June 3–5 | ExCeL London
Stop by our booth (Stand C 95) for live demo of Sectona’s Modern Infrastructure Access Platform
The Hidden Backdoor in Your Supply Chain: Third-Party Access under NIS2
Across Europe’s critical infrastructure, third-party vendors, contractors, and managed service providers (MSPs) often require privileged access to the systems that keep energy grids running, hospitals operating, factories producing, and essential services online. While this access is necessary, it also expands the organisation’s attack surface.
A 2026 cyberattack on an AWS cloud account used by the European Commission highlights the risk. According to CERT-EU, attackers gained initial access through the Trivy supply-chain compromise, which exposed an AWS API key with management rights. The incident demonstrates how vulnerabilities in trusted third-party technologies can quickly become an organisation’s problem.
NIS2 is raising the stakes. With stronger requirements around cybersecurity risk management, supply-chain security, accountability, and incident handling, third-party access cannot be treated as an operational afterthought.
The question is no longer about who has access. Organisations must also ask why they need it? When should they have it? How much access is enough? And what are they doing with it?
NIS2 expands on the previous NIS Directive and places greater emphasis on managing supply-chain and third-party risks. For critical infrastructure organisations, this means rethinking persistent privileges, shared accounts, and unmanaged vendor access.
In this blog, we’ll explore why NIS2 is driving a shift toward temporary, least-privileged, approved, and monitored third-party access and how Just-in-Time access can help organisations achieve it.
Who Does NIS2 Apply to?
The NIS2 Directive (EU) 2022/2555 applies to medium and large organisations operating across 18 critical sectors in the European Union. It sorts entities into two groups based on size and sector importance, such as Essential Entities and Important Entities.
Size and Employee Rules
- Medium-sized enterprises: Generally, 50 to 249 employees, with an annual turnover up to €50 million or a balance sheet total up to €43 million.
- Large enterprises: 250 or more employees, with an annual turnover above €50 million or a balance sheet total over €43 million.
- Special rule: Smaller companies can still fall into scope if they are critical single providers or key digital service providers regardless of size.
How Does NIS2 Affect an Organisation?
NIS2 (Directive (EU) 2022/2555) sets out a baseline of cybersecurity risk-management measures under Article 21 that all in-scope essential and important entities must implement. These aren’t prescriptive technical standards the directive deliberately uses an “all-hazards” and risk-based approach, leaving organisations to size the controls to their actual risk exposure, size, and the state of the art. That flexibility is also why regulators expect to see evidence of reasoning, not just a list of tools purchased.
What Are the Core Risk-Management Measures under NIS2?
NIS2 requires organizations to take a proactive, risk-based approach to cybersecurity. Its core measures cover areas such as risk management, incident handling, supply-chain security, access control, business continuity, and accountability.
Let’s take a look at them in details.
Risk management
Organisations must conduct systematic risk analyses covering their network and information security management systems and use the results to shape their security policies. This isn’t a one-off exercise NIS2 expects an ongoing risk-management process that gets revisited as the threat landscape, asset base, or business model changes.
Access control and authentication
Entities must implement policies and procedures for access control systems security, along with the use of multi-factor authentication or continuous authentication solutions where appropriate, secure voice/video/text communications, and secured emergency communication systems within the organisation. Access should be governed by least-privilege principles and role-based permissions rather than broad, standing access.
Incident handling
A defined incident-handling process is mandatory covering detection, analysis, containment, and response. This ties directly into NIS2’s strict reporting obligations: a 24-hour early warning, a 72-hour incident notification, and a final report within one month of a significant incident. Organisations need to know in advance what qualifies as “significant” for their sector and who has authority to trigger a report on short notice.
Business continuity and crisis management
This includes backup management, disaster recovery, and crisis management procedures the ability to keep operating (or fail safely) during and after a disruptive event, not just restore data afterward.
Supply-chain security
Entities must address security in relationships with direct suppliers and service providers, including assessing the cybersecurity practices of vendors and the quality of their products and development processes. This is one of the areas NIS2 expands significantly compared to its predecessor.
Security in network and information security management systems
This spans acquisition, development, and maintenance of systems, including vulnerability handling and disclosure processes, and covers policies and procedures to assess the effectiveness of security measures (i.e., testing and evaluating whether controls actually work, not just whether they exist).
Accountability and management oversight
Management bodies must approve the cybersecurity risk-management measures, oversee their implementation, and can be held personally liable for non-compliance. Management is also required to undergo training, and NIS2 encourages offering similar training more broadly across the organisation. This is a deliberate shift cybersecurity is framed as a governance and board-level responsibility, not something delegated entirely to IT/security teams.
Also Read: Turkey’s Cybersecurity Law No. 7545: What Businesses Need to Know
Demonstrating Controls, Not Just Documenting Them
A recurring theme across NIS2’s requirements is the expectation of evidence over paperwork. Having a written access control systems security policy, an incident-response plan sitting in a shared drive, or a risk register that hasn’t been updated in two years does not satisfy the directive’s intent and it’s unlikely to hold up under regulatory scrutiny or after an actual incident.
In practice, this means organisations should be able to show:
- Operational proof that controls function as described e.g., logs showing MFA enforcement, records of patch cycles being followed, results of penetration tests or vulnerability scans, rather than just a policy stating these things happen.
- Testing and validation, since Article 21 explicitly calls for assessing the effectiveness of measures tabletop exercises, incident response drills, and business continuity tests all serve as evidence, not just checkboxes.
- Traceable decision-making, particularly for management: minutes or records showing the board reviewed and approved risk-management measures, rather than a policy that was never actually discussed at that level.
- Audit trails for third parties, such as vendor risk assessments, contractual security clauses, and evidence that supplier access is monitored and reviewed not just a vendor list.
This shift is important practically because national authorities enforcing NIS2 have investigatory powers, including on-site inspections and requests for evidence and penalties (up to €10M or 2% of global turnover for essential entities) are tied to demonstrable non-compliance, not just the absence of a document. A policy that exists only on paper offers no defence if it can’t be shown to have been implemented, tested, and maintained.
Why Standing Privileges Are Becoming a Liability
Standing privileged access means elevated permissions that exist persistently available 24/7 regardless of whether they’re being used. For example, a vendor with permanent admin rights to a PLC station, or an always-on VPN into the OT network, are both standing access. But with that the problem is that access that exists continuously creates exposure that exists continuously. Just-in-time models limit exposure to the task window; standing access exposes the system for the credential’s entire lifetime.
Key risks:
- Compromised vendor credentials: Third parties often hold standing remote access for support. If the vendor’s own network is breached, attackers inherit that access without ever touching your perimeter a well-documented path into industrial environments.
- Unused accounts remaining active: Contracts end, roles change, but accounts are often not deprovisioned. Dormant privileged accounts are attractive targets precisely because no one is watching them.
- Excessive permissions: Access is often provisioned broadly “to avoid friction” and rarely revisited, so accounts accumulate rights beyond current need expanding the blast radius of any compromise.
- Lateral movement after initial compromise: Standing privileged accounts are what let an attacker turn one foothold (phishing, a vulnerable service) into IT-to-OT or plant-to-plant movement.
- Difficulty determining who accessed what and when: Long-lived, loosely governed accounts often can’t answer basic forensic questions after an incident, slowing response and root-cause analysis.
“Trusted vendor” ≠ “trusted identity.” Trusting a company due to contract history or reputation is not the same as trusting the specific credential, device, or individual using that access at a given moment. In practice, “vendor access” often means a shared login used by several people, broad network reach beyond the actual task, and no process to revoke access when personnel change. The vendor relationship may be sound; the access path frequently is not.
This is why NIS2 treats risk management and supply-chain security as core requirements, not formalities. Article 21 requires assessing risk from supplier relationships and standing privileged access is one of the most direct, measurable forms that risk takes. Reducing it through time-bound, least-privilege, continuously reviewed access is how organisations operationalise that requirement, and it’s exactly the kind of control regulators expect to see evidenced.
Shared Accounts and the Accountability Gap
Shared administrator and vendor accounts remain common despite being a known anti-pattern often for reasons that feel practical: one “admin” login is simpler than provisioning per-engineer access, legacy OT systems may not support multi-user auth, or a vendor team shares credentials to avoid onboarding overhead. Convenience creates the practice, and convenience is exactly what makes it risky.
Core problems:
- No individual accountability: Actions taken under a shared login can’t be attributed to a specific person, making routine oversight impossible.
- Poor attribution during incidents: Responders can’t quickly determine who was logged in or what they did, forcing reliance on slower secondary evidence.
- Difficulty conducting audits: Auditors expect a clear identity-to-action mapping; shared accounts break that structurally, not just as a logging gap.
- Credential leakage: More people knowing a password means more chances it’s reused, written down, or passed along and shared credentials tend to get rotated less often.
- Former contractors retaining access: Individual accounts can be disabled cleanly; disabling a shared account cuts off everyone still using it legitimately, so it often just doesn’t happen leaving departed personnel with standing access to critical systems.
Why Does Individual Traceability Matter?
NIS2’s incident handling, risk management, and accountability requirements all converge on one question – which individual accessed which system, when, why, and for how long; not which vendor or shared account. This matters for faster incident response, demonstrable compliance (a session log beats a policy document), behavioural deterrence, and clean offboarding that doesn’t disrupt other legitimate users.
The underlying shift is from account-based access (“does this login work?”) to identity-based and session-level access (“which verified person is doing what, right now, and for how long”). That’s the same principle that closes both the standing-privilege exposure and the shared-account accountability gap.
What Organisations Should Do Now
Third-party access is no longer a necessary exception that security teams can manage with a username, password, and a standing permission. For European critical infrastructure, it is becoming one of the most important pathways that organisations need to control, monitor, and continuously reassess.
NIS2 makes this shift hard to ignore. As organisations take strict responsibility for supply-chain and cybersecurity risks, privileged access granted to vendors must be treated with the same scrutiny as internal privileges access. That means moving away from broad, persistent permissions towards least privilege, just-in-time access, strong authentication, session monitoring, and automatic access expiration.
The end goal is to make the third-party access safer without slowing down the people who keep critical operations running. For Europe’s critical infrastructure, this isn’t just a compliance checkbox. It’s a fundamental part of building resilience in an increasingly interconnected threat landscape.
Don’t let vendor access become an open door to your critical systems. Discover how a modern privileged access management strategy can help you enforce least privilege, control access in real time, monitor every privileged session, and reduce third-party risk.
Book a demo with us to explore how we can help you address your compliance requirements and answer any questions you may have.
Recent Posts
