NIS2 and Remote Access: A Practical Review for IT Teams

Remote access is not a separate NIS2 compliance category. However, its use affects many of the areas covered by the Directive, including access control, authentication, vulnerability management, supply-chain security, incident handling and business continuity.

For sysadmins, lean IT teams and managed service providers, the practical question is therefore not whether NIS2 mentions Remote Desktop Protocol by name. The question is whether remote connections create risks which the organization has identified, controlled, monitored and documented and how TSplus Advanced Security can prove an indispensable tool in these processes as well as in keeping your servers secure.

What is NIS2?

Commonly known as NIS2, Directive (EU) 2022/2555 is a European Union directive aiming to protect digital infrastructure It is aimed primarily at critical infrastructures and broadened the scope of the previous directive (NIS1). NIS 2 continues the cyber protection work begun with NIS in 2016. One of the requirements it sets are maximum delays for incident notification (24h initial and 72h detailed) and for a full report to be turned over (under 1 month).

In a nutshell, the organisations concerned by this widening saw their IT infrastructure legal obligations reinforced, mainly with regards to risk management, incident reporting and responsibility. For our purpose, remember the particular emphasis placed on cyber risks. The notable change was how NIS2 sectors considered to be highly sensitive (high criticality) additionally included smaller companies, public and private organisations and bodies than NIS and “critical” encompasses extra sectors and sizes.

PDF: ENISA NIS 2 - flyer showing NIS1 to NIS2 evolution

NB: national implementation and advisors

NIS2 is implemented through the legislation of individual countries, and sector-specific obligations may apply. This guide provides technical security information rather than legal advice. Organizations should confirm their status and responsibilities with the appropriate national authority or a qualified adviser.

What Does NIS2 Mean for Remote Access?

The NIS2 Directive describes a common European cybersecurity framework covering 18 critical sectors. It requires that medium-sized and larger entities operating in those sectors implement proportionate cybersecurity risk-management measures and report significant incidents.

Remote access enters this framework from the instant an employee, administrator, contractor or provider connects to a network and information system from outside its normal security boundary. NIS 2 establishes how any potential cybersecurity concerns or risks must be managed, overseen, logged, reported, and how to react to events, and perforce, this includes how companies and bodies remotely access any data, apps, services and IT infrastructures.

PDF: ENISA NIS 2 - flyer showing sectors within NIS2 scope

Which Organizations Need to Assess NIS2 compliance?

Organizations in sectors such as energy, transport, healthcare, banking, digital infrastructure, public administration, manufacturing and ICT service management may fall within scope. Managed service providers and managed security service providers are specifically relevant because their technicians often hold elevated access to several customer environments.

Size is only one factor among others. Some entities may fall within scope regardless of size because of their function, criticality or designation under national law. MSPs should therefore assess both their own obligations and the security conditions under which they access customer systems.

Why Does National Implementation Matter?

NIS2 is a Directive, so each Member State must implement it through national legislation, according to defined transposition guidelines. Definitions, registration processes, competent authorities, supervision and enforcement procedures can consequently differ between countries.

The European Commission also proposed targeted amendments to NIS2 in January 2026 to clarify scope and simplify parts of the framework. The Commission’s current NIS2 page still describes those changes as proposed amendments, so IT teams should verify their legislative status and the applicable national rules before relying on a compliance interpretation.

What Should IT Teams Review Under NIS2 Article 21?

Article 21 requires essential and important entities to take appropriate and proportionate technical, operational and organizational measures. The following matrix translates the most relevant areas into remote access questions.

NIS2 review area	Remote access question	Evidence to examine
Risk and asset management	Which systems accept remote or administrative connections?	Inventory and architecture diagrams
Access control	Who can connect, and what can each account access?	User, group and privilege reviews
Authentication	Where is MFA required and enforced?	Policies and configuration records
Supply-chain security	How do MSPs and suppliers connect?	Approvals, accounts, contracts and logs
Incident handling	Can suspicious sessions be reconstructed?	Events, alerts and retained logs
Business continuity	Can affected services recover securely?	Backup and recovery test records

The review should produce both corrective actions and evidence that decisions were made. A technically sound configuration that nobody reviews, tests or documents may still leave an operational gap.

Mapping Remote Access Systems and Internet Exposure

Begin with a complete inventory of remote access paths. Include Remote Desktop listeners, RD Gateways, VPN concentrators, browser portals, cloud-hosted Windows servers, management consoles, unattended support agents and out-of-band administration interfaces.

The inventory should identify the owner, business purpose, exposed ports, authentication method, authorised users and systems reachable through each path. Dormant gateways, temporary firewall rules and forgotten vendor accounts often remain outside routine monitoring.

Once the access map is complete, remove unnecessary exposure. Directly publishing RDP to the internet is best avoided. Where RDP remains necessary, the RDP hardening checklist provides deeper guidance on Network Level Authentication, gateways, certificates, firewall restrictions and session controls.

Strengthen Identity, MFA and Least Privilege

Assigning accounts

Every remote user should have an attributable identity. Shared administrator accounts make it difficult to establish who connected, what actions were performed and whether credentials were misused.

For instance, actions in this area will lead you to:

• separate standard and privileged accounts,
• limit membership of administrative groups and
• regularly remove access which is no longer required.

But you will also need to assign owners to service accounts, emergency accounts and dormant identities as well as set their review schedules and documented exceptions.

Cybersecurity risk-management measures

Article 21 describes cyber security measures for risk management. These include access control policies, asset management, and multi-factor or continuous authentication where appropriate. ENISA’s technical guidance recommends secure authentication based on access restrictions and asset classification, with evidence such as authentication logs, access policies, and configuration records.

Further security levers

MFA should receive particular attention for internet-facing access, administrative accounts and third-party connections. A Zero Trust remote access The approach can then add device trust, contextual restrictions and repeated verification instead of treating every authenticated connection as equally safe.

Control MSP, Supplier and Third-Party Access

Managing external access

Supplier access should be managed as a defined service relationship, not as an informal technical convenience. IT teams should know which provider has access, why access is required, to which systems and who approved the arrangement.

• Use named accounts wherever possible.
• Restrict privileges to the work being performed.
• Set expiration dates for temporary access.
• Disable accounts promptly when a contract or support task ends.
• Connections outside approved locations or working hours should trigger review.

Agreements for incident reporting

Contracts and operating procedures should also define how suppliers report suspected incidents, preserve relevant logs and cooperate with investigations. This helps connect technical access controls to the NIS2 requirement for supply-chain security.

MSPs and other service providers

For MSPs The same principle works in both directions. The provider must protect its technician accounts while giving customers sufficient evidence that privileged access is controlled and attributable.

Reduce Vulnerability and Ransomware Exposure

Remote access servers sit close to authentication systems, applications and business data. Missing security updates, weak credentials or excessive permissions can therefore turn one compromised account into a wider server incident.

• Define ownership for operating system, gateway, client and application patching.
• Where a security update cannot be deployed immediately, document the reason, residual risk and compensating measures.
• ENISA cites patch records, risk-treatment plans and documented non-patching decisions as examples of useful evidence.
• Exposure reduction should accompany patching.
• Restrict accepted IP addresses and geographic origins where operationally appropriate, segment critical servers and limit what a remote session can access.

Ransomware defenses also need to cover prevention, detection, containment and recovery. Our Ransomware Playbook for RDS Environments explains how these stages apply to Windows remote session infrastructure.

Centralise Events, Alerts and Security Reviews

Remote access logs should show more than whether a service is running. IT teams need successful and failed authentication events, blocked connections, privileged activity, firewall changes, security alerts and unusual access patterns.

Time synchronization is essential because investigators may need to compare events from Windows servers, gateways, firewalls, identity platforms and supplier systems. Additionally, retention periods should support the organisation’s incident-response and regulatory requirements.

ENISA identifies VPN and remote access logs, including attempts, successful connections and anomalies, as examples of evidence. It also recommends retaining current network diagrams, firewall configurations and access logs showing that only authorised personnel changed security rules.

It is also important to assign an owner to each alert category and define when an event must be escalated. Indeed, a dashboard nobody reviews does not provide effective monitoring.

What Evidence Should a NIS2 Remote Access Review Produce?

NIS2 readiness depends on more than enabling security features. IT teams should be able to demonstrate how controls were selected, configured, reviewed and improved.

Document Controls and Security Decisions

A practical review file should include:

• A current remote access inventory and architecture diagram
• Approved remote access and privileged-access policies
• User, group and administrative privilege reviews
• MFA policies and configuration evidence
• Firewall, IP allowlist and geographic restriction records
• MSP and supplier access approvals
• Patch records and documented exceptions
• Security test and incident exercise results
• Backup and recovery test records
• Remediation plans and accepted residual risks

These records should match the live environment. An old diagram or an account spreadsheet that no longer reflects Active Directory does not provide reliable assurance.

The ENISA technical implementation guidance contains practical examples of evidence and control implementation. Its direct scope is limited to entity categories governed by Commission Implementing Regulation (EU) 2024/2690. These include relevant digital infrastructure, ICT service management and digital provider entities. While other organizations can still use its examples as technical guidance, they should not assume every detail automatically applies to them.

Prepare Remote Access Data for Incident Reporting

Article 23 establishes a staged reporting process for significant incidents. It includes an early warning within 24 hours of becoming aware of the incident, an incident notification within 72 hours and, generally, a final report within one month of the incident notification. National procedures and sector-specific requirements must still be checked.

IT teams should be able to quickly establish:

• Which accounts and systems were affected
• Where the connection originated
• When authentication and session events occurred
• Which indicators of compromise were observed
• Whether a supplier or MSP was involved
• Which containment measures were applied
• Whether services or customers were disrupted
• Which evidence has been preserved

These details should flow into an established incident process. They should not need to be reconstructed for the first time during the 24-hour reporting window.

NIS2 Remote Access Review Checklist

Use this checklist to prioritise the first review cycle:

1. Inventory every remote and administrative access path.
2. Remove unnecessary internet exposure and obsolete firewall rules.
3. Enforce MFA where appropriate, especially for privileged access.
4. Separate administrator accounts from standard user accounts.
5. Review users, groups, service accounts and dormant identities.
6. Restrict supplier and MSP access by purpose, system and duration.
7. Patch remote access servers, gateways and supporting components.
8. Monitor failed logins, blocked connections and ransomware events.
9. Test incident escalation, backups and secure recovery.
10. Retain evidence of reviews, exceptions and corrective actions.

The checklist supports technical prioritisation.

Please note: completing it does not, by itself, prove NIS2 compliance.

How TSplus Advanced Security Supports NIS2-Aligned Controls

TSplus Advanced Security can support implementing several technical measures relevant to a NIS2 remote access review. It does not make an organization compliant on its own, but its features strengthen the protection and visibility surrounding Windows application servers and Remote Desktop environments.

- Brute force protection

Bruteforce Protection monitors failed Windows login attempts and can automatically block an offending IP address after a configured number of failures. This helps IT teams respond to repeated password guessing while retaining records of blocked activity.

- Geographic restrictions

Geographic Protection can allow or block connections by country, restrict internet access to private and whitelisted IP addresses and monitor selected processes or ports. The integrated Firewall provides a centralised list of blocked and approved addresses. These controls can reduce unnecessary connection origins when geography and IP restrictions suit the operating model.

- Working hours restrictions

Restrict Working Hours limits when selected users or groups may connect and can disconnect sessions after the permitted period. Trusted Devices associates approved device names with user accounts, adding another condition before access is accepted.

- Permissions management

Permissions Management helps administrators review and adjust access to local filesystems, printers and registry areas. Secure Sessions can reduce what a connected user sees or can launch within a Windows session. These features support least privilege, but they must be configured around genuine business roles rather than applied as generic restrictions. implementing

- Ransomware protection

Ransomware Protection uses static and behavioural analysis to detect suspicious activity, stop affected processes and quarantine files. Reports, snapshots and email alerts support investigation and response, although organisations still need independent backups and tested recovery procedures.

- Reports and alerts

Advanced Security also presents security events, reports and configurable alerts in one interface. This can improve day-to-day visibility for small teams who need to review failed attacks, blocked connections and ransomware detections without introducing a larger security platform.

Using versatile features to protect application servers and enhance security provision

Advanced Security does not replace identity management, MFA, network segmentation, patch deployment, supplier governance or incident reporting. In fact, it is most effective when these responsibilities form part of a documented remote access security programme. According to your usage of remote access, your infrastructure and the working goals of your organisation or company, other guides and articles of ours discuss education , finance, health, agro-industry and other contexts.

Conclusion

NIS2 makes remote access a documented risk-management responsibility rather than a configuration task alone. IT teams should inventory every access path, control privileges, monitor suspicious activity and preserve usable evidence. TSplus Advanced Security can strengthen several Windows server safeguards while the organization retains responsibility for governance and compliance.

FAQ

1. Does NIS2 Require MFA for Remote Access?

NIS2 includes multi-factor or continuous authentication where appropriate. The decision depends on risk, privilege, system sensitivity and national implementation. Internet-facing, administrative and supplier access should receive particular attention.

2. Does NIS2 Apply to Managed Service Providers?

Managed service providers and managed security service providers are included within the NIS2 framework, subject to definitions, size rules, exceptions and national law. MSPs should assess both their internal systems and technician access to customer environments.

3. Does NIS2 Prohibit Remote Desktop Protocol?

No. NIS2 does not prohibit RDP. Organizations must assess its risks and apply proportionate controls such as limited exposure, MFA, least privilege, patching, monitoring and tested incident procedures.

4. What Remote Access Evidence Should IT Teams Retain?

Useful evidence includes inventories, architecture diagrams, access reviews, MFA configurations, supplier approvals, firewall rules, authentication logs, alerts, patch records, recovery tests and remediation decisions.

5. Can TSplus Advanced Security Make an Organization NIS2 Compliant?

No single product establishes NIS2 compliance. TSplus Advanced Security can support server protection, access restrictions, ransomware defence and security visibility. Compliance also depends on governance, identity systems, policies, supplier management, continuity planning and applicable national law.