If your organization is covered by NIS2 or DORA, you’ve probably spent the past year working through policies, risk assessments and incident procedures. Network access tends to get less attention. Yet it’s one of the areas where auditors can quickly tell whether controls are real or only on paper.
This article explains what the two regulations require for network access, authentication and certificates, and what that means in practice for your Wi-Fi and wired network.
This article is general information, not legal advice. Your own scope and obligations depend on your sector, size and national implementation.
Who is covered?
NIS2 (Directive (EU) 2022/2555) covers medium and large organizations in 18 critical sectors, including energy, transport, health, digital infrastructure, ICT service management (B2B), public administration and manufacturing. In Denmark, it is implemented through the NIS2 Act (NIS2-loven), which entered into force on 1 July 2025. Several other member states have implemented it as well.
DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025 to banks, insurers, investment firms, payment institutions and other financial entities. It also places requirements on their ICT suppliers.
Many organizations that aren’t covered directly still feel both regulations. Covered entities have to manage their supply chain, so the requirements are passed on to suppliers and service providers through contracts and supplier assessments.
Neither regulation mentions Wi-Fi, but both cover it
NIS2 and DORA are deliberately technology-neutral. You won’t find “802.1X” or “Wi-Fi” in either text. What you will find are requirements for who and what can access your systems, and your network is one of those systems.
NIS2
Article 21 of NIS2 lists the cybersecurity risk-management measures covered entities must take. Several of them apply directly to network access:
Access control policies and asset management (Art. 21(2)(i))
Policies and procedures for cryptography and encryption (Art. 21(2)(h))
Multi-factor or continuous authentication where appropriate (Art. 21(2)(j))
Supply chain security, including the security of your suppliers (Art. 21(2)(d))
For digital infrastructure providers, including managed service providers (MSPs) and cloud providers, Implementing Regulation (EU) 2024/2690 turns these into concrete technical requirements. Section 6 of its Annex covers network security and network segmentation. Section 11 covers access control, including management of access rights, unique identification, authentication and multi-factor authentication. The regulation formally applies only to those provider types, but many other organizations use it as a practical reference for what “appropriate measures” look like.
DORA
DORA’s technical standards for ICT risk management (Delegated Regulation (EU) 2024/1774) are more specific than NIS2:
Network security (Art. 13) requires the segregation and segmentation of networks. It also requires network access controls that prevent and detect connections by unauthorized devices or systems, and by devices that don’t meet your security requirements.
Cryptographic key management (Art. 7) requires managing keys through their whole lifecycle, including revocation. It also requires a register of all certificates and certificate-storing devices, at least for ICT assets supporting critical or important functions, and renewal of certificates before they expire.
Identity management and access control (Art. 20–21) requires that every person and system has a unique identity, and only the access it needs.
ICT third-party risk (DORA Art. 28–30) requires financial entities to assess and document the ICT suppliers they depend on.
What this means for your network
Put simply, the regulations expect you to be able to answer these questions with evidence:
Who and what is connected to our network?
How do we keep unauthorized and unmanaged devices out?
How do we remove access for one person or device?
How are devices separated by risk, for example guests, IoT and company laptops?
Which certificates do we have, and how do we make sure they don’t expire?
Which suppliers does this depend on, and how have we assessed them?
A shared Wi-Fi password can’t answer any of the first four. Everyone has the same key, you can’t revoke it per person, and the network can’t tell a company laptop from a visitor’s phone. (We explain the wider risks in Why shared-password Wi-Fi is a bigger risk than you think.)
How certificate-based 802.1X maps to the requirements
Certificate-based network access, meaning 802.1X with EAP-TLS, gives every device its own identity in the form of a certificate. A RADIUS server checks that certificate before letting the device in. (New to this? Read Certificates vs. passwords: how certificate-based Wi-Fi works.)
Requirement | Reference | With a shared password | With certificate-based 802.1X |
|---|---|---|---|
Unique identification of users and devices | NIS2 CIR 11.5; DORA RTS Art. 20 | One key for everyone | Each device has its own certificate |
Manage and remove access rights | NIS2 Art. 21(2)(i), CIR 11.2; DORA RTS Art. 21 | Change the password everywhere | Revoke one certificate |
Keep unauthorized devices out | DORA RTS Art. 13; NIS2 CIR 6.7 | Anyone with the password can join | Only devices with a certificate from your CA can join |
Network segmentation | DORA RTS Art. 13; NIS2 CIR 6.8 | Everyone on the same network | Devices placed on the right VLAN based on identity |
Cryptography and key protection | NIS2 Art. 21(2)(h); DORA RTS Art. 6–7 | Password can be shared, leaked or guessed | Private keys generated on and kept on the device |
Certificate register and timely renewal | DORA RTS Art. 7 | Not applicable | CA and RADIUS server certificates in the register; device certificates recorded by the issuing CA and renewed automatically |
Evidence and logging | NIS2 Art. 21(2)(b); DORA RTS Art. 12 | Device list without owners | Authentication log per device |
Certificates managed through Microsoft Intune add another control: only devices enrolled in your device management receive a certificate. Unmanaged devices simply have nothing to present.
Don’t forget the supplier side
Under both NIS2 and DORA, the services you use to secure your network are part of your supply chain. When you assess a cloud PKI or RADIUS provider, ask:
Where is our data stored and processed? Can it stay within the EU?
Which sub-processors are involved? How are we notified of changes?
What availability is committed to, and how is the service built to survive a regional outage?
How fast will the supplier notify us of an incident? Does that fit our own reporting deadlines?
What evidence can the supplier provide? Security documentation, certifications, a data processing agreement and audit rights.
What’s the exit plan if we need to change provider?
If you’re an MSP
Managed service providers are explicitly in scope of NIS2 as part of ICT service management, and they are covered by Implementing Regulation 2024/2690. That means two things. Your own administrative access to customer environments must meet the access control and authentication requirements. And your customers in NIS2 and DORA sectors will increasingly expect the services you deliver to them to be documented to the same standard.
How EasyScep and EasyRadius support NIS2 and DORA compliance
EasyScep is a cloud PKI for Microsoft Intune:
Every customer gets a dedicated root certificate authority. There is no shared CA between customers.
CA private keys are protected in Azure Key Vault.
Certificates are delivered through Intune SCEP profiles. Private keys are generated on the device and never leave it.
Intune renews certificates automatically before they expire.
Revocation status is published via OCSP, so revoked devices lose access.
A full history of issued and revoked certificates is kept. It can serve as the device-certificate part of your DORA certificate register.
EasyRadius is a cloud RADIUS service for 802.1X:
It validates EAP-TLS certificates, including revocation status.
It assigns VLANs dynamically based on identity, which supports network segmentation.
It provides live authentication logs showing which device connected, when, and with what result.
On the supplier side, both services:
run active-active across two Azure regions, with a 99.95% availability SLA
offer EU data residency
are delivered by Just Software ApS, which is D-seal certified (the Danish label for IT security and responsible data use)
come with a data processing agreement and a documented sub-processor list
offer options for customers with NIS2 or DORA obligations, including extended log retention and stricter incident notification terms
To be clear about what this means: there is no such thing as a “NIS2-certified” or “DORA-certified” product, and using any product doesn’t make you compliant by itself. Compliance is your organization’s responsibility. What the right tools do is make the controls easy to implement and the evidence easy to produce, and what the right supplier does is give you the documentation your own assessments need.
Frequently asked questions
Does NIS2 require 802.1X or certificate-based Wi-Fi?
No. NIS2 is technology-neutral. It requires appropriate access control, authentication and cryptography measures. For most organizations, certificate-based 802.1X is the most straightforward way to meet those requirements for network access.
Does DORA require a certificate inventory, and does it include device certificates?
Yes, DORA requires one. Its technical standards (Delegated Regulation 2024/1774, Article 7) require a register of certificates and certificate-storing devices, at least for ICT assets supporting critical or important functions, and renewal of certificates before they expire. In practice, the focus is on certificates whose expiry can take down a service, such as server, TLS and CA certificates. The text doesn’t exclude device certificates, though. For network access, the CA and RADIUS server certificates clearly belong in the register. Device certificates can number in the thousands. For those, a central record at the issuing CA combined with automatic renewal through Intune is the practical way to keep the register current.
Does DORA require network access control?
Yes. Article 13 of the same regulation requires network access controls that prevent and detect connections from unauthorized devices, and from devices that don’t meet your security requirements. It also requires network segmentation.
Do we need on-premises servers to do this?
No. A cloud PKI integrated with Intune, combined with a cloud RADIUS service, provides certificate-based network access without on-premises certificate or RADIUS servers.
Are EasyScep and EasyRadius NIS2 or DORA certified?
No product can be, because no such certification exists. Just Software ApS is D-seal certified and provides the documentation and contract terms that NIS2 and DORA entities need for their supplier assessments.
Working on NIS2 or DORA and want to talk network access? Contact us.
Products in this article
Want to talk it through?
Tell us about your setup and we’ll help you find the simplest path.
Contact us
JS
Just Software
The Just Software team
We build cloud services that make secure IT simple: certificates, RADIUS, Azure governance and more, with no servers for you to run.
Share this article:
