DORA, NIS2, and the CRA: The Three EU Laws Rewriting Vendor Risk for Network Access

Three EU laws now touch the secure access layer directly, each from a different angle: DORA governs financial-sector ICT third-party risk, NIS2 sets cybersecurity baselines across critical sectors, and the Cyber Resilience Act (CRA) regulates the security of the software itself. Together, they mean that “our VPN vendor is reputable” is no longer a sufficient answer in a vendor risk review.

Here's what each one actually requires, and where the access layer specifically comes into scope.

Read Part I in this series for Zero Trust basics in Europe.

DORA compliance: concentration risk gets a name and a list

The Digital Operational Resilience Act has applied to EU financial entities since 17 January 2025, and 2026 is when it moved from paperwork to enforcement. Regulators describe the shift bluntly: from reviewing policy documents to demanding “real-time, data-driven evidence of resilience.”

DORA's most consequential provision for the access layer is its ICT third-party risk framework (Articles 28–44), which requires financial entities to maintain a Register of Information covering every ICT vendor relationship and to negotiate contractual provisions for exit, audit rights, and data accessibility. On 18 November 2025, the European Supervisory Authorities designated the first cohort of Critical ICT Third-Party Providers (CTPPs) subject to direct EU oversight — 19 providers, including AWS, Microsoft, Google Cloud, IBM, and several others. That list is itself a statement: regulators are now formally naming the concentration risk that comes from large parts of the financial sector depending on the same handful of providers.

This matters for network access specifically because DORA doesn't stop at your cloud provider. If your secure access layer runs through a third-party vendor's control plane, that relationship falls under the same register, the same audit-rights requirements, and the same exit-strategy obligations as any other critical ICT dependency. A self-hosted Access Server — where the vendor supplies software rather than an operated service — simply isn't a third-party ICT dependency in the same sense, because there's no vendor-operated control plane in the relationship to register, audit, or exit from.

NIS2 compliance: supply chain scrutiny and incident-reporting clocks

NIS2 expanded the definition of “essential” and “important” entities across energy, digital infrastructure, health, and other sectors, with penalties of up to €10 million or 2% of global turnover and — notably — personal accountability for senior management. Its supply chain provisions are where the access layer comes in most directly: NIS2 expects organizations to understand and manage the cybersecurity risk of their suppliers, not just their own systems.

See the fuller sovereignty context on NIS2 supply-chain exposure in Part II of our EU digital-sovereignty series — this section focuses specifically on the two practical requirements that matter when evaluating access infrastructure.

Two practical requirements stand out for teams evaluating access infrastructure:

Incident reporting timelines

NIS2 requires a 24-hour early warning and 72-hour full notification after a significant incident. Meeting that clock is considerably easier when your security team has direct visibility into the systems sitting between users and applications, rather than waiting on a third-party vendor's status page or incident disclosure process.

Auditability

Supply chain risk reviews increasingly ask whether a vendor's software can be independently audited, not just whether the vendor claims to be secure. Software built on an open, inspectable codebase gives procurement and security teams something to actually verify — which is a meaningfully different conversation than trusting a closed platform's compliance attestations.

The EU Cyber Resilience Act: security obligations attach to the software itself

The CRA is the newest and, for software vendors, potentially the most far-reaching of the three. It entered into force in December 2024, with vulnerability and incident reporting obligations applying from 11 September 2026 and full requirements — including mandatory Software Bills of Materials (SBOMs), secure-by-design obligations, and CE marking — applying from December 2027. Non-compliance penalties run up to €15 million or 2.5% of global annual turnover.

The CRA takes a deliberately different stance toward open-source software than toward closed, commercial products. Non-commercial open-source projects are exempt from most obligations. Organizations that commercialize products built on open-source components — which is exactly how Access Server relates to the open-source OpenVPN protocol — carry full manufacturer responsibilities for the commercial product, while the underlying open-source project can be independently reviewed by anyone, rather than relying solely on a single vendor's internal security team.

That distinction is becoming a genuine procurement differentiator. Under the CRA's due-diligence expectations, a security team evaluating a closed-source platform has to take the vendor's word for how a vulnerability was found, scoped, and fixed. A security team evaluating software built on an open, community-audited protocol can — and increasingly does — check the code itself.

DORA vs. NIS2 vs. CRA, at a glance

Where this leaves the access layer

None of these three laws were written specifically about VPNs or ZTNA. But read together, they describe a consistent expectation: EU regulators want organizations to be able to name, register, audit, and if necessary exit every significant ICT dependency — and they want the software underpinning critical functions to be verifiably, not just contractually, secure.

Access Server is built to be evaluated on those terms. It's SOC 2 Type 2, ISO/IEC 27001:2022, HIPAA, and GDPR compliance-ready, it runs on infrastructure your organization operates directly — which keeps it out of the third-party-dependency category that DORA and NIS2 scrutinize most heavily — and it's built on the open-source OpenVPN protocol, which means the code underlying your access layer isn't a black box your auditors have to take on faith. For the architecture-level case behind this — the self-hosting-as-sovereignty argument — see Part III of our EU digital-sovereignty series. Explore Access Server to see how self-hosted deployment works in practice.

Frequently asked questions

Does DORA apply to companies outside the EU?

Yes, in effect. DORA applies to EU financial entities, but its ICT third-party risk provisions extend to the vendors those entities depend on, regardless of where the vendor is headquartered.

Is self-hosted software exempt from NIS2 supply chain requirements?

No software is automatically exempt, but self-hosted software changes the nature of the obligation. Since there's no vendor-operated service sitting in your data path, the supply-chain relationship is closer to “we use this vendor's code” than “we depend on this vendor's operations” — which is a materially different risk profile to document.

When do Cyber Resilience Act reporting obligations start?

Vulnerability and severe-incident reporting obligations apply from 11 September 2026. Full CRA requirements, including CE marking and conformity assessment, apply from 11 December 2027.

What is the DORA Register of Information?

The centralized inventory EU financial entities must maintain of every ICT third-party relationship supporting critical or important functions, covering contract terms, subcontracting chains, and criticality classification. It's typically the first document regulators request in an ICT risk review — and the exercise that surfaces hidden concentration risk when the same vendor appears across many nominally different relationships.

Does the Cyber Resilience Act apply to open-source software?

Not directly to non-commercial open-source projects, which are exempt from most CRA obligations. But a company that commercializes a product built on open-source components takes on full manufacturer responsibilities for that commercial product, even though the underlying open-source project itself stays outside the CRA's direct scope.

Further reading

• The Hidden Risks of US-Dependent Infrastructure for European Businesses (Part II)
• Why Europe Is Drawing Its Own Digital Borders (Part I)
• Part III: Sovereignty by Design — How Self-Hosting Puts European Businesses Back in Control
• OpenVPN Announces SOC 2 + HIPAA Compliance
• OpenVPN Compliance Overview (SOC 2, ISO 27001, HIPAA, GDPR)