Why does third-party access create so much regulatory risk under DORA and NIS2?

Why This Matters for Security Teams

Third-party access becomes a regulatory risk because it expands the number of identities that can reach regulated services, data, and operational workflows without always being governed like internal users. Under DORA and NIS2, the issue is not just whether access exists, but whether the organisation can demonstrate control over who granted it, why it was granted, how it is monitored, and when it is removed. That evidence burden is central to auditability.

Security teams often underestimate how quickly supplier accounts, support channels, API tokens, and remote admin paths can drift outside normal identity governance. The result is a gap between policy and proof: access may be approved informally, inherited through contracts, or left active after a project ends. Current guidance aligns with the broader control direction in the NIST Cybersecurity Framework 2.0, which emphasises governance, access control, and continuous oversight across the full asset and identity lifecycle. In practice, many security teams encounter third-party access as a compliance failure only after a supplier relationship has already outlived the original approval record.

How It Works in Practice

In operational terms, third-party risk under DORA and NIS2 is created when supplier access touches systems that matter to resilience, incident reporting, or service continuity. That includes managed service providers, software vendors, contractors, outsourced support desks, and non-human identities such as service accounts and API keys. The regulatory concern is not limited to human users. If a third party can authenticate, change settings, retrieve data, or trigger workflows, that access can affect regulated outcomes.

Practitioners should treat third-party access as a governed identity class with the same lifecycle controls as internal access, plus stronger contractual and monitoring expectations. A workable approach usually includes:

• documented business justification for each supplier identity or secret
• explicit ownership for approval, review, renewal, and revocation
• time-bound access with periodic revalidation rather than open-ended entitlement
• logging and alerting for privileged or unusual supplier activity
• offboarding checks that include dormant accounts, tokens, certificates, and remote support paths

This is where identity governance intersects with non-human identity control. The OWASP Non-Human Identity Top 10 is useful because supplier access is frequently implemented as secrets, integrations, and automation credentials rather than only interactive accounts. For resilience-focused environments, DORA expects firms to maintain control over ICT third parties, while NIS2 raises the bar on security measures and accountability for essential and important entities. These controls tend to break down when access is embedded in shared admin tooling or inherited from legacy vendor integrations because ownership becomes unclear and revocation is hard to prove.

Common Variations and Edge Cases

Tighter third-party control often increases operational overhead, requiring organisations to balance regulatory evidence against delivery speed and vendor usability. That tradeoff matters most where suppliers need rapid support access, where environments are highly automated, or where multiple business units manage their own vendor relationships.

Best practice is evolving for environments that rely on machine-to-machine access, ephemeral credentials, or outsourced engineering teams. There is no universal standard for this yet, but current guidance suggests treating these as high-risk access paths when they can reach production, sensitive data, or safety-critical workflows. A supplier does not need to be “in” the network permanently to create risk; one long-lived token or shared break-glass credential can be enough to bypass normal oversight.

For regulated organisations, the practical question is whether access can be evidenced end to end, not whether a vendor is trusted in principle. That means aligning access reviews, contract clauses, logging, and incident escalation paths with the obligations described in DORA — Digital Operational Resilience Act and the NIS2 Directive — official EU legal text. In some environments, especially heavily outsourced service chains, this guidance becomes harder to apply because the organisation may not control the full downstream identity path.

Related resources from NHI Mgmt Group

• Why do third-party access paths create so much NYDFS compliance risk?
• Why do third-party access paths create DORA risk?
• Why do third-party vendors create so much identity risk?
• Why do third-party vendors create identity and access risk?